网络安全漏洞分析之远程代码执行
介绍
Apache Flume 是一个分布式的,可靠的,并且可用于高效地收集,汇总和移动大量日志数据的软件。它具有基于流数据流的简单而灵活的体系结构。它具有可调的可靠性机制以及许多故障转移和恢复机制,并且具有健壮性和容错性。它使用一个简单的可扩展数据模型,该模型允许进行在线分析应用程序。
漏洞描述
在 7 月 22 日,Apache 发布安全公告,修复了一个存在于 Apache Flume 中的远程代码执行漏洞,CVE 编号为 CVE-2022-34916。当攻击者控制目标 LDAP 服务器时,如果配置使用带有 JNDI LDAP 数据源 URI 的 JMS 源,Apache Flume 版本 1.4.0 到 1.10.0 很容易受到远程代码执行 (RCE) 攻击。
利用范围
1.4.0 <= Apache Flume <= 1.10.0
漏洞分析
环境搭建
从 GitHub 上下载 1.10.0 版本,导入 IDEA。
项目 jdk 使用 1.8,然后修改 TestIntegrationActiveMQ 测试类中的 DESTINATION_NAME,因为 destinationName 是由 DESTINATION_NAME 定义;修改 JNDI_PREFIX 为 ldap://

①网络安全学习路线
②20 份渗透测试电子书
③安全攻防 357 页笔记
④50 份安全攻防面试指南
⑤安全红队渗透工具包
⑥网络安全必备书籍
⑦100 个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年 CTF 夺旗赛题解析
在 JMSMessageConsumerTestBase.java 中将 destinationLocator = JMSDestinationLocator.CDI;修改为 destinationLocator = JMSDestinationLocator.JNDI;

最后运行 TestIntegrationActiveMQ 测试类即可。
漏洞原理
根据 Apache Flume 漏洞描述,可以确定问题是出现在了 JMSMessageConsumer 中。

查看 DIff(https://github.com/apache/flume/commit/7fe9af49)记录发现,修复方式是在 JMSMessageConsumer 中的 else 分支下,在 initialContext.lookup(destinationName)前新增了对 destinationName 的校验。

那么漏洞触发点已经很明确了,在没有增加校验前,只要进入 JMSMessageConsumer 中 else 分支,控制 destinationName 参数,即可实现 JNDI 注入。
代码分析
知道了漏洞原理后,分析一下代码。
首先在 TestJMSMessageConsumer#testCreateDurableSubscription 初始化了 JMSMessageConsumer 并传入 destinationLocator

destinationLocator 的定义是在 JMSMessageConsumerTestBase.java 中。

在搭建环境时,我们是将 destinationLocator = JMSDestinationLocator.CDI;修改为了 destinationLocator = JMSDestinationLocator.JNDI;

这样配置,是为了在 JMSMessageConsumer 中不满足 if 条件后,能够进入到 else,到达漏洞触发点。
而在官方提供的测试类中,TestIntegrationActiveMQ 类存在 testQueueLocatedWithJndi,将作为 source 点传入参数。

修改 DESTINATION_NAME 为恶意 JNDI 地址,将 JNDI_PREFIX 修改为 ldap://

通过参数的传入,经过如上分析的流程,到达 else 后,由于没有校验,直接触发 initialContext.lookup,造成 JNDI 注入,从而执行恶意远程代码。
漏洞复现

修复建议
官方已发布安全版本,请尽快更新至安全版本
评论