log4j2 JNDI 注入漏洞分析

p4nda

发布于 2023-01-03 14:44:02

8500

发布于 2023-01-03 14:44:02

0x01 写在前面

2021 年 12 月 9 号注定是一个不眠之夜，著名的Apache Log4j 项目被爆存在远程代码执行漏洞，且利用简单，影响危害巨大，光是引入了 log4j2 依赖的组件都是数不清，更别提项目本身可能存在的风险了，如下图所示，mvnrepository搜索引用了 log4j-core version 2.14.1的项目就十几页了：

本文就来简单分析一下该漏洞的原理。

0x02 影响范围

引用了版本处于2.x < 2.15.0-rc2的 Apache log4j-core的应用项目或组件

0x03 漏洞分析

根据官方的修订信息：https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3201?filter=allissues

可以明确知道，是通过 jndi 中 LDAP 注入的方式实现了 RCE，然后查看其补丁的更改记录：

可以发现对lookup函数进行了修改判断

知道了漏洞类型，那么就好入手了，首先翻阅官方文档中关于lookup的说明：

lookup提供了一种在任意位置向 Log4j2 配置添加值的方法，是实现StrLookup接口的特殊类型的插件，查看官方文档发现log4j2 支持的方法有很多：

总计有：base64、data、ctx、main、env、sys、sd、java、marker、jndi、jvmrunargs、map、bundle、log4j

由于这里主要说明的是关于 JNDI lookup 的用法，其他的不再赘述。

关于 JNDI lookup官方文档有说明：

JndiLookup 允许通过 JNDI 检索变量，然后给了示例：

<File name="Application" fileName="application.log">
    <PatternLayout>
        <pattern>%d %p %c{1.} [%t] $${jndi:logging/context-name} %m%n</pattern>
    </PatternLayout>
</File>

实际上通过 log4j2 支持的方法那张图中就可以发现log4j 中 jdni 的用法格式如下：

${jndi:JNDIContent}

既然明确了lookup是触发漏洞的点，并且找到了可以触发 lookup的方法，那么就可以找入口点，只要找到入口点，然后传入 jndi 调用 ldap 的方式，就能够实现 RCE。

那么，哪一个入口点可以传入${jndi:JNDIContent}呢？

没错了，就是LogManager.getLogger().xxxx()方法

在log4j2中，共有8 个日志级别，可以通过LogManager.getLogger()调用记录日志的方法如下：

LogManager.getLogger().error()
LogManager.getLogger().fatal()

LogManager.getLogger().trace()
LogManager.getLogger().traceExit()
LogManager.getLogger().traceEntry()
LogManager.getLogger().info()
LogManager.getLogger().warn()
LogManager.getLogger().debug()
LogManager.getLogger().log()
LogManager.getLogger().printf()

上述列表中，error()和fatal()方法可默认触发漏洞，其余的方法需要配置日志级别才可以触发漏洞。因为在logIfEnabled方法中，对当前日志等级进行了一次判断：

只有当当前事件的日志等级大于等于设置的日志等级时，才会符合条件，进入logMessage()方法

知道这些基本信息后，就可以进一步了解漏洞的触发原理了。

测试 case 如下：

public class log4j {  
  
    private static final Logger logger = LogManager.getLogger();  
  
    public static void main(String[] args) {  
        Collection<org.apache.logging.log4j.core.Logger> current = LoggerContext.getContext(false).getLoggers();  
        Collection<org.apache.logging.log4j.core.Logger> notcurrent = LoggerContext.getContext().getLoggers();  
        Collection<org.apache.logging.log4j.core.Logger> allConfig = current;  
        allConfig.addAll(notcurrent);  
        for (org.apache.logging.log4j.core.Logger log:allConfig){  
            log.setLevel(Level.ALL);  
        }  
        logger.error(Level.ALL,"payload");  
//        logger.warn("payload");  
//        logger.info("payload");  
//        logger.debug("payload");  
//        logger.traceExit("payload");  
//        logger.trace("payload");  
//        logger.fatal("payload");
//        logger.printf(Level.ALL,"payload");  
//        logger.traceEntry("payload");  
//        logger.log(Level.ALL,"payload");  
 }    
}

由于这些调用方法触发漏洞的原理都是一样的，所以本文就以 error 举例说明。

查看 error 的类继承关系可以发现，实际上会调用AbstractLogger.java中的public void error()方法：

在该方法中会调用logIfEnabled判断是否符合日志记录的等级要求，如果符合，那么会进行logMessage操作：

后续不关键调用路径如下：

logMessage ----> logMessageSafely ----> logMessageTrackRecursion ----> tryLogMessage ----> log

----> DefaultReliabilityStrategy.log ----> loggerConfig.log ----> processLogEvent ----> callAppenders ----> tryCallAppender ----> append ----> tryAppend ----> directEncodeEvent ----> encode ----> toText ----> toSerializable ---->format----> PatternFormatter.format