Log4j2漏洞复现&原理&补丁绕过

本文来源无问社区，更多实战内容，渗透思路尽在无问社区http://www.wwlib.cn/index.php/artread/artid/8522.html

0x01 前言

我tm都呕了，昨晚出了这个洞，在家复现半天没搞出来，然后凌晨快两点的时候成功了两次，然后又不行，然后睡了，贼jb真实。

然后今天来公司随便搞了两下就成功了，唯一的变化就是换了台电脑，贼jb恐怖。

0x02 前言

经过测试就是jdk版本的问题。 0x02 漏洞复现这里我一共使用了两个jdk版本

8u202的情况比较特殊，其实我今天凌晨在家里用的也是8u202的版本，失败了。

今天来公司也是用的8u202版本的jdk，成功了。

我仔细研究了两者的不同，我发现唯一不同的就是我公司这个idea启的project带有springboot的库。

然后看了默安的一篇文章

明白了其中的原因

还可以参考以往的jndi注入

然后为了方便本地测试，就把jdk版本降下来了，高版本要搞也可以，需要加参数。

然后直接搞上一个poc

先拉一个maven项目，把dependency搞上去

复现成功

漏洞触发没有难度，就是个jndi注入撸一发各家的情报

安恒这个，我猜测和我遇到了一样的问题，所以没从本地复现，我猜测是这样，不一定对。

360，用的是挂恶意类的方法来做复现，弹个计算器，我也来弹一个吧。

和fastjson一个玩法

这里看看自家怎么复现的

他这里是用的System.setProperty来做的

用的是rmi，和网上通用的ldap的poc不同，也是去请求一个外链，协议不同而已，不过通常情况下rmi限制更多。

详细用法可以参考fastjson的利用

0x03 原理

默安写了篇文章，这里就不重复写了

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

最终的触发点在lookup上，然后用lookup去发请求。然后jndiName是用户可控的，也就是在log中的记录。

因此导致了漏洞产生

0x04 补丁绕过

这里的绕过指的是绕过 log4j-2.15.0-rc1 这个版本

exp这里我在公网上还没看到有人发出来，这里就不给exp了，讲一下原理，感兴趣可以自己构造首先看一看新版和老版的对比

这里可以看到5天前其实就开始搞了，他就放了新版出来。

其实如果先知先觉，这个漏洞已经被打了5天了。

点进去看一下

这里对scheme和host做了白名单校验，如果不在这里面就走return null这段逻辑。

但是，兄弟们，这个白名单都是需要自己配置的，默认是空。

那么意思就是说，如果自己不去配置，那就莫得法来绕过，因为是白名单。

再看看怎么修复lookup的

这里把原来的直接formats解析做了限制，还写了一个withoutLookupOptions方法

跟一下这个方法看看

曰死，我们着重看一下这段。

这个判断很有意思，在老版本，这个lookup是默认开启的，那么!过去就是默认不开启，于是注入payload是能够走的通的。

现在新版本lookups是默认不开启的，如果想要开启，需要自己手动去配置。

看，像上面这些configuration和options都是需要手动进行配置的。

也就是说，这个版本基本没啥问题了，那为啥还能绕过呢。

继续比对最新版本和可以被绕过的版本

然后看看log4j家的开发，这个叫做rgoers的小伙子是怎么修复这个漏洞的

进入代码查看

这里是catch一个异常，从字面意思理解就是url的语法异常，原本catch后面是木有写东西的，但是现在加上了两行语句，然后return了null 什么意思呢？

意思就是先利用url语法错误报错然后把条错误语句注入到log里，然后payload解析，然后导致漏洞发生。

原先因为没有加上return null这个语句，所以语句不会被return，然后会接着走下面的代码逻辑，就中套了。

但是现在return之后，就直接跳出去了，就莫得事情了。

但是绕过归绕过，虽然这里绕过了，但是配置那块，指定是绕不过的，除非自己配置就有问题，那就怪不得别人。

根据官方文档来看，log4j2有多种配置文件的方法，并且到了2.15.0-rc1版本，默认配置就是安全的，因为默认没有配置文件，需要自己去创建，因此默认配置为空，如果自己配置的时候不乱来，就不会被日。

done