【紧急】Log4j又发新版2.17.0，只有彻底搞懂漏洞原因，才能以不变应万变，小白也能看懂

推荐原创

Tom弹架构 2021-12-20 12:51:58 博主文章分类：开发工具 ©著作权

©著作权归作者所有：来自51CTO博客作者Tom弹架构的原创作品，请联系作者获取转载授权，否则将追究法律责任

1 事件背景

经过一周时间的Log4j2 RCE事件的发酵，事情也变也越来越复杂和有趣，就连 Log4j 官方紧急发布了 2.15.0 版本之后没有过多久，又发声明说 2.15.0 版本也没有完全解决问题，然后进而继续发布了 2.16.0 版本。大家都以为2.16.0是最终终结版本了，没想到才过多久又爆雷，Log4j 2.17.0横空出世。 file 相信各位小伙伴都在加班加点熬夜紧急修复和改正Apache Log4j爆出的安全漏洞，各企业都瑟瑟发抖，连网警都通知各位站长，包括我也收到了湖南长沙高新区网警的通知。 file 我也紧急发布了两篇教程，给各位小伙伴支招，我之前发布的教程依然有效。

【紧急】Apache Log4j任意代码执行漏洞安全风险升级修复教程

【紧急】继续折腾，Log4j再发2.16.0，强烈建议升级

file

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

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

2 JNDI介绍

2.1 JNDI定义

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

2.2 JNDI架构

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

file

2.3 JNDI核心API

类名	解释
Context	命名服务的接口类，由很多的name-to-object的健值对组成，可以通过该接口将健值对绑定到该类中，也可通过该类根据name获取其绑定的对象
InitialContextNaming	（命名服务）操作的入口类，通过该类可对命名服务进行相关的操作
DirContext	Directory目录服务的接口类，该类继承自Context，在Naming服务的基础上扩展了对于对象属性的绑定和获取操作
InitialDirContext	Directory目录服务相关操作的入口类，通过该类可进行目录相关服务的操作

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

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <Resource name="jndi/person"
            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"/>
</Context>

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

Connection conn=null; 
PreparedStatement ps = null;
ResultSet rs = null;
try { 
  Context ctx=new InitialContext(); 
  Object datasourceRef=ctx.lookup("java:comp/env/jndi/person"); //引用数据源 
  DataSource ds=(Datasource)datasourceRef; 
  conn = ds.getConnection(); 
  
  //省略部分代码
  ...
  
  c.close(); 
} catch(Exception e) { 
  e.printStackTrace(); 
} finally { 
  if(conn!=null) { 
    try { 
      conn.close(); 
    } catch(SQLException e) { } 
  } 
}

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

5 源码分析

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

file

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


private int substitute(LogEvent event, StringBuilder buf, int offset, int length, List<String> 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服务，下图所示：

file

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

file