由Log4j2安全漏洞引发的思考

新闻
2年前

  Log4j2 安全漏洞(编号 CVE-2021-44228)事件已经过去一个多月了,但它造成的危害影响却非常严重,各大软件安全厂商在第一时间针对此漏洞紧急做了补丁。

  虽然漏洞最早是由阿里发现的,但实际上它是一个0day漏洞,这就意味着早在国内发现它之前,国外可能利用该漏洞已经有一段时间了。

Log4j2 漏洞也许早就被发现了

  想发现这个安全漏洞其实并不难,使用常规的挖洞工具、SAST(静态应用安全测试)工具、SCA(软件成分分析)工具都能挖掘出来,但为什么一直没有引起重视或暴露出来呢?

  事实上,可能很多 hackerone 上的“安全人士”早就发现了该漏洞了,并作为 0day 来利用。平时我们关注 SQL、XSS 等漏洞,大家非常容易理解,而对于写 log 文件,很多人认为只是日志而已,并且文件在服务器上,做好防护后,一般人也拿不到。

  关于如何利用 JNDI 注入漏洞,其实有很多辅助性工具可用,例如:Rogue JNDI、JNDIIExploit 和 JNDI-Injection-Exploit 等,Log4j2 漏洞被报出后,很多人使用这些工具辅助做 Payload。

  其实这类漏洞已经出现过很多次了,而且被纳入 CVE 编号的漏洞就包括:CVE-2021-2109 WebLogic LDAP,远程代码执行漏洞;CVE-2018-1000130,Jolokia 代理版本1.3.7 中存在 JNDI 注入漏洞。

利用 SAST 工具扫描 Log4j2 漏洞

  在 Log4j2 漏洞被报出后,笔者于2022年元旦放假期间做了一些深入的研究,并尝试利用几款 SAST 工具来验证,看是否能检测出 Log4j2 漏洞。

  经过验证,有几款耳熟能详的 SAST 工具没能检测出该漏洞,并且这些工具中也没有找到关于 JNDI 注入漏洞相关的检测器(具体哪几款产品,在这里不直接说明了),而使用 Fortify 20.1 版本能够检测出来该漏洞具有2处。

20220118223620.jpg

图1 Fortify 检测结果1

  第1个漏洞的代码位置,程序在 ClientGui.java 中第277行使用不受信任的地址运行 JNDI 查找,这可能导致攻击者远程运行任意 Java 代码。

20220118223703.jpg

图2 Fortify 检测的漏洞代码位置1

  第2个漏洞的代码位置,程序在 JndiManager.java 中第 203 行使用不受信任的地址运行 JNDI 查找,这可能导致攻击者远程运行任意 Java 代码。

20220118223744.jpg

图3 Fortify 检测的漏洞代码位置2

国产工具 PK 国外老牌工具

  Fortify 作为老牌 SAST 工具,理应能够检测出该漏洞。但是在当前自主可控大背景下,笔者还是想找一款支持检测这个漏洞的国产化工具,最后尝试了开源网安 CodeSec 3.2 版本进行检测。而检测结果让人感到非常的欣慰,CodeSec 3.2 也顺利检测出了 Log4j2 漏洞,这说明了国产工具也具备了与 Fortify PK 的能力。

  CodeSec 检测出6个 JNDI 安全漏洞,这是比较重要的一页,可以看到检测出6个 JNDI 注入漏洞。

20220118223842.jpg

图4 CodeSec 检测结果截图1

  通过对上面6个漏洞的路径进行分析,归纳出来主要有两个路径,跟 Fortify 检测出的两个漏洞一致。这说明 CodeSec 不但检测出了 Log4j2 漏洞,而且分析路径更全面。

  第1类位置:

20220118223931.jpg

图5 CodeSec 检测的漏洞代码定位1

  第2类位置:

20220118224002.jpg

图6 CodeSec 检测的漏洞代码定位2

  其中检测出5个对应的触发点都是同一个位置,而 Fortify 只检测到3个。

20220118224043.jpg

图7 CodeSec 检测结果截图2

  关于这个漏洞 Payload 网络上已经有很多方法,大家可以自行搜索。在此笔者借鉴 SAST 工具中的资料,给大家解释一下这个漏洞:

  JNDI 注入漏洞是通过 JNDI 查找和使用不受信任的地址,这可能导致攻击者远程运行任意 Java 代码。

  如果攻击者可以控制 JNDI 查找和操作的地址,则他通过将该地址指向其控制的服务器的地址并将 JNDI 命名引用返回到具有自定义对象工厂的 RMI 存储对象,有可能能够远程运行任意代码,类似下面示例。

  示例:以下示例中的代码使用不可信赖的数据运行 JNDI 查找。

20220118224153.jpg

  Log4j2 安全事件后,很多 SCA 工具也进行了相应升级,把 Log4j2-***.jar 作为一个开源组件进行分析。在该漏洞被报出之前,是否有工具可以检测该漏洞未知。但是 Log4j2 是一个开源组件,可以以组件形式进行检测,也可以通过源代码进行检测,相对于 SCA,SAST 工具能够从源代码本身检测出该漏洞,检测粒度更细。

  另外,笔者发现 CodeSec 也集成了 SCA 功能,同时也能够检测出 Log4j2 本身就存在两个 CVE 漏洞,应该尽早引起重视。

20220118224232.jpg

图8 通过 CodeSec 集成的 SCA 功能检测的结果

  通过 Log4j2 漏洞事件,我们可以看到,研发过程中,除了对自研代码进行检测之外,也需要对引用的开源组件进行检测,这是供应链安全的一个重要节点。

  即使你选择的 SAST 工具不具备 SCA 功能,SAST 工具本身也应该从源代码上分析开源组件 jar 包,能够从代码级别上检测出开源组件中的漏洞。

作者:开源网安


参考阅读

软件安全公司「开源网安」完成亿元级别B轮融资,琥珀资本领投

开源网安研究院发布《国内高校网络与信息安全研究成果调研报告(2016-2020)》