Log4j2安全漏洞引起的思考

Log4j2安全漏洞（编号CVE-2021-44228）事件已经过去一个多月了，但它造成的危害影响却非常严重，各大软件安全厂商在第一时间针对此漏洞紧急做了补丁。虽然漏洞最早是由阿里发现的，但实际上它是一个0day漏洞，这就意味着早在国内发现它之前，国外可能利用该漏洞已经有一段时间了。

想发现这个安全漏洞其实并不难，使用常规的挖洞工具、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注入漏洞。

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

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

 图1：Fortify检测结果1

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

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

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

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

国产工具CodeSec VS Fortify

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

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

图4：CodeSec 检测结果截图1

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

第1类位置：

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

第2类位置：

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

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

 图7：CodeSec检测结果截图2

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

JNDI注入漏洞是通过JNDI 查找和使用不受信任的地址，这可能导致攻击者远程运行任意 Java 代码。如果攻击者可以控制 JNDI 查找和操作的地址，则他通过将该地址指向其控制的服务器的地址并将 JNDI 命名引用返回到具有自定义对象工厂的 RMI 存储对象，有可能能够远程运行任意代码，类似下面示例。
示例：以下示例中的代码使用不可信赖的数据运行 JNDI 查找。

// 
...
String address = request.getParameter("address");
Properties props = new Properties();
props.put(Provider_URL, "rmi://secure-server:1099/");
InitialContext ctx = new InitialContext(props);
ctx.lookup(address);
//

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

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

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

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

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

（结束）

更多推荐

Log4j2安全漏洞引起的思考