PS: 文章仅用于研究漏洞原理，促进更好的防御，禁止用于非法用途，否则后果自负!!!
log4j是Apache开发的一个日志工具。可以将Web项目中的日志输出到控制台，文件，GUI组件，甚至是套接口服务器。本次出现漏洞就是因为log4j在启动套接口服务器后，对监听端口传入的反序列化数据没有进行过滤而造成的。下面我们以log4j-1.2.17.jar的源码来进行分析。
当log4j启动套接字服务器时，会监听我们命令行传入的端口。然后会创建一个SocketNode类的对象来对端口接收到的数据进行处理。
![log4j<=1.2.17反序列化漏洞（CVE-2019-17571）分析]( "log4j<=1.2.17反序列化漏洞（CVE-2019-17571）分析")
跟进SocketNode类，可以发现在对象初始化时,将端口接收到的数据封装为一个Object流对象。在run()方法中直接调用readObject()进行反序列化操作。
这个过程中没有任何过滤措施，总体下来可谓简单粗暴。所以只要运行log4j的classpath中存在可以利用的Gadget就可以直接命令执行了。
为了方便演示我主动将commons-collections-3.2.1.jar加入到log4j
的classpath中。然后使用nc提交生成的恶意序列化文件到log4j监听的4560端口，漏洞触发。
![log4j<=1.2.17反序列化漏洞（CVE-2019-17571）分析]( "log4j<=1.2.17反序列化漏洞（CVE-2019-17571）分析")
在实际的生产环境中，开发人员有时候需要对日志进行集中存储和管理时,会单独在日志服务器上，启动log4j套接字服务器，来接收各个Web项目发送过来的日志。在这种场景下可能会存在该漏洞。但鸡肋的是这样启动的log4j一般不会有当下已知的Gadget。虽然如此，在渗透测试过程中还是可以注意下4560端口，说不定有惊喜。
本文始发于微信公众号（回忆飘如雪）：log4j<=1.2.17反序列化漏洞（CVE-2019-17571）分析
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/345904.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论