本文来源无问社区,更多实战内容,渗透思路尽在无问社区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