目前oracle还没有在公开途径发布weblogic的JAVA反序列化漏洞的官方补丁，目前看到的修复方法无非两条：

1. 使用SerialKiller替换进行序列化操作的ObjectInputStream类;
2. 在不影响业务的情况下，临时删除掉项目里的 "org/apache/commons/collections/functors/InvokerTransformer.class"文件。

常言道，出来混总是要还的，看了乌云知识库的《网络小黑揭秘系列之黑产江湖黑吃黑 ——中国菜刀的隐形把手》一文，表示很震惊，网络竟然是如此的不安全，无聊之下花了一周时间来调查360所说的“从公开的whois信息显示，该域名注册邮箱为root90sec@gmail.com，同时，该邮箱同时还有注册“maicaidao.me”这个域名。安全圈的朋友们一看这个邮箱，应该并不陌生，没错这个邮箱的主人正是某sec组织的成员之一，接下来的我们就不多说了，有兴趣的可以自己去挖挖。”

前段时间在乌云知识库上面看到一篇比较有意思的文章利用机器学习进行恶意代码分类。这篇文章对Kaggle上的一个恶意代码分类比赛中冠军队伍所采用的方法进行了介绍，展现了机器学习在安全领域的应用与潜力。但是这个比赛的主题是恶意代码的分类，没有进一步实现恶意代码的检测；其次比赛的代码只是针对Windows平台的PE格式，缺少对移动应用的研究。受此启发，尝试利用机器学习方法在Android平台对恶意代码进行检测，最终得到了一定的检测效果。

近日，Bastille的研究团队发现了一种针对蓝牙键盘鼠标的攻击，攻击者可以利用漏洞控制电脑操作，他们将此攻击命名为MouseJack。 攻击者仅需要在亚马逊上以60美元购买设备，改造之后即可对百米范围内存在漏洞的蓝牙无线键鼠进行劫持，向受害计算机输入任意指令。相信对此感兴趣的人有很多，所以我根据其公布的信息购买了相应设备来进行测试，现将测试经验分享给大家。

最近openssl又除了一系列问题，具体可以看这里。CVE-2016-0799只是其中一个比较简单的漏洞。造成漏洞的原因主要有两个。

• doapr_outch中有可能存在整数溢出导致申请内存大小为负数
• doapr_outch函数在申请内存失败时没有做异常处理

关于JAVA的Apache Commons Collections组件反序列漏洞的分析文章已经有很多了，当我看完很多分析文章后，发现JAVA反序列漏洞的一些要点与细节未被详细描述，还需要继续分析之后才能更进一步理解并掌握这个漏洞。

二哥说过来自乌云，回归乌云。Web400来源于此，应当回归于此，有不足的地方欢迎指出。

Office作为Windows平台下一种非常流行的办公软件，越来越多的APT攻击通过构造恶意Office文件来进行实施，这也是成功率也是比较高的一种攻击方式。当然最隐蔽，最有效的攻击方式就是通过Office办公套件的一些0day来实施攻击，但是这也同样存在一些弊端，首先不是所有人都拥有0day，其次那些已经公布的Xday可能只能针对某些固定版本的Office，所以本文重点不在如果使用Xday，而是对现在已知的一些构造Office Phishing File的方式及方法进行总结，希望对学习Hack的同学有所帮助，当然也希望，通过此文，小伙伴能避免遭受此类攻击。

Cylance SPEAR发现了一起针对日本、韩国、美国、欧洲以及其他几个东南亚国家的威胁行动，在上述国家中，有大量的行业部门都遭到了攻击。

在前面的章节我们讨论了部分SSL/TLS握手协议、记录协议中存在的安全问题，针对它们的攻击以及相应的加固方案。在SSL/TLS所依赖的PKI体系中，证书吊销过程同样对SSL通信的安全性有着重要的影响，近几年很多重要安全事件（比如2008年Debian伪随机数发生器问题导致证书公钥易被破解、2014年Heartbleed漏洞导致服务器私钥泄露）都导致了大规模的证书吊销行为。本章我们将介绍传播证书吊销信息的几种方式、它们的优缺点和现状以及针对证书吊销标准的若干攻击1。

我不否认前端在处理XSS的时候没有后端那样方便快捷，但是很多人都在说过滤XSS的事就交给后端来做吧。前端做没什么用。我个人是非常反感这句话的。虽然说前端防御XSS比较麻烦，但是，不是一定不行。他只是写的代码比后端多了而已。而且前端防御XSS比后端防御XSS功能多，虽说后端也可以完成这些功能，但是代码量会比前端代码多很多很多。其实说了那么多，交给nginx||apache||nodeJs||Python会更好处理。但是我不会C，也就没办法写nginx模块了。而且也不在本文章的范围内，等我什么时候学会C再说把。

序列化的问题貌似在最近爆发的非常频繁，最近有小伙伴在问我关于这两天爆发的Xstream组建的反序列化的漏洞，最近公司非常忙，不过赶上周末刚好抽时间看了下，其实这次的漏洞和之前JRE的那个反序列化漏洞触发的条件基本上差不多，不过关于JRE的那个序列化似乎没人关注，有兴趣的同学可以去找找关于那个JRE的序列化，影响力不亚于11月份我分析的那个Apache CommonsCollection的漏洞。好了，回到正文吧。在分析Xstream漏洞时发现,XStream漏洞的根源在于Groovy组件的问题，其实在15年的时候有人给Groovy报了一个CVE-2015-3253的Bug，不过网上似乎没有太多细节，为什么这次分析XStream的漏洞的时候要提到Groovy的那个CVE，因为漏洞的根源就来自于那个CVE。

目前对Android模拟器的检测，主要是从特定的系统值来进行区分的。例如，getDeviceId()、getLine1Number()这类函数，还有android.os.Build类记录的一系列值等等。但是偶然发现有位老外提出了用cache来区分模拟器和真机的idea，但是这位老外可能当时比较懒，没有具体的细节，写了个简单的PoC后把Evaluation空着了，也没有实验，所以并不知道这个方法是否真的有效。因此，本文就把检测的整个方法从原理到实现完整地展现出来。

苹果做了非常多的努力来建造和维持一个健康并且干净的应用环境。其中对现在的现状起到很大作用的部分就是苹果APP STORE，它是被一个十分周密的对所有提交的应用进行检查的审批程序所保护的。尽管这个程序是被设计为用来保护IOS用户并且确保应用程序符合苹果的安全性和完整性的要求，体验过这个流程的开发者可能会觉得它太复杂了并且花费了大量的时间。发布一个新的release版本或者发布一个已经存在的APP的补丁也要遵守这个流程，这对于一个想要给一个影响现有APP用户的重要bug或者安全漏洞打补丁的开发者来说就会非常困扰。

如果在进程尝试加载一个DLL时没有指定DLL的绝对路径，那么Windows会尝试去指定的目录下查找这个DLL；如果攻击者能够控制其中的某一个目录，并且放一个恶意的DLL文件到这个目录下，这个恶意的DLL便会被进程所加载，从而造成代码执行。这就是所谓的DLL劫持。