最新爆发的Log4j2安全远程漏洞，又称“Log4Shell”，让整个互联网陷入了威胁之中，大量企业和Java项目都在紧锣密鼓的升级更新补丁，还有很多安全研究人员在研究复现和利用以及防范方法，我们今天就来说说相关的常识和进展。

Log4Shell漏洞(正式编号CVE-2021-44228) 归根结底是一个非常简单的JNDI注入漏洞。Log4J在扩展占位符时在记录消息时候(或间接作为格式化消息的参数)执行JNDI lookup()操作。在默认配置中，JNDI支持两种协议：RMI和LDAP。在这两种情况下，lookup()的调用实际上是为了返回一个Java对象。这通常为序列化的Java对象，但是还有一个通过于间接构造的JNDI引用。这个对象和引用字节码可以通过远程URL加载代(java类.class)。

关于JNDI和JNDI注入

JNDI，全称Java Naming and Directory Interface(Java命名和目录接口) 是Java中引入一种Java API，它允许客户端通过名称发现查找和共享Java数据和对象。这些对象可以存储在不同的命名或目录服务中，例如远程方法调用(RMI)、通用对象请求代理架构(CORBA)、轻量级目录访问协议(LDAP)或域名服务(DNS)等。

换句话说，JNDI是一个简单的Java API，例如：InitialContext.lookup(String name)它只接受一个字符串参数，如果该参数来自不信任的来源，则可能会有远程代码的加载和执行。

当请求对象的名称被攻击者控制时，有可能将存在问题的Java应用程序指向恶意的rmi/ldap/corba 服务器并使用任意对象进行响应。如果该对象是“javax.naming.Reference”类的实例，则JNDI客户端会尝试解析此对象的“classFactory”和“classFactoryLocation”属性。如果目标Java应用程序不知道“classFactory”值，Java将使用Java URLClassLoader 从“classFactoryLocation”位置获取Factory字节码。

由于它的简单性，即使“InitialContext.lookup”方法没有直接暴露到受污染的数据，它对于利用Java漏洞也非常有用。在某些情况下，它仍然可以通过反序列化或不安全反射攻击来访问。

一段易受攻击的应用程序示例如下：

Java 8u191之前JNDI注入

通过请求“/lookup/?name=ldap://127.0.0.1:1389/Object”的链接，可以让易受攻击的服务器连接到控制的地址，并触发远程类加载。

一个恶意RMI实例服务示例如下：

由于目标服务器不知道“ExploitObject”，它的字节码将从_attacke_指定的服务加载并执行触发RCE远程执行。

该方法在Java 8u121 中可良好运行,在Java 8u191 更新中，Oracle对LDAP添加了的限制，并发布了CVE-2018-3149补丁，关闭了JNDI远程类加载。然而，仍然有可能通过JNDI注入触发不可信数据的反序列化，但其利用高度依赖于现有的小工具。

Java 8u191+中利用JNDI注入

从Java 8u191开始，当JNDI客户端接收到一个Reference对象时，无论是在RMI还是在LDAP中，都不会使用其“classFactoryLocation”值。但是，仍然可以在“javaFactory”属性中指定任意工厂类。

该类将用于从攻击者控制的“javax.naming.Reference”中提取真实对象。它应该存在于目标类路径中，实现“javax.naming.spi.ObjectFactory”并至少有一个“getObjectInstance”方法：

1. public interface ObjectFactory {
3. public Object getObjectInstance(Object obj, Name name, Context nameCtx,
5. Hashtable environment)
7. throws Exception;
9. }

主要思想是在目标类路径中找到一个Factory，它对引用的属性做一些危险的事情。例如，在Apache Tomcat服务器的“org.apache.naming.factory.BeanFactory”类包含使用反射创建bean的逻辑：

“BeanFactory”类创建任意bean的实例并为所有属性调用其设置器。目标bean 类名、属性和属性值都来自被攻击者控制的Reference对象。

目标类应该有一个公共的无参数构造函数和只有一个“字符串”参数的公共设置器。 事实上，这些 setter 可能不一定从 'set..' 开始，因为“BeanFactory”包含一些为任何参数指定任意setter名称的逻辑。

这里使用的魔法属性是“forceString”。 例如，通过将其设置为“x=eval”，我们可以对属性“x”进行名称为“eval”而不是“setX”的方法调用。

因此，通过利用“BeanFactory”类，我们可以使用默认构造函数创建任意类的实例，并使用一个“String”参数调用任何公共方法。

此处可能有用的类之一是“javax.el.ELProcessor”。 在它的“eval”方法中，可以指定一个字符串来表示要执行的Java表达式语言模板。

一个在评估时执行任意命令的恶意表达式：

编写一个示例的RMI服务器，它以精心制作的“ResourceRef”对象进行响应：

该服务以“org.apache.naming.ResourceRef”的序列化对象进行响应，其中包含了精心设计的属性在客户端触发所需的行为。

然后在受害Java进程上触发JNDI解析：

当这个对象被反序列化时，不会发生任何不受欢迎的事情。但由于它仍然扩展“javax.naming.Reference”，“org.apache.naming.factory.BeanFactory”工厂将在受害者方使用以从引用中获取“真实”对象。在此阶段，将触发通过模板评估的远程代码执行，并执行“nslookup jndi.s.xxx”命令。

这里唯一的限制是目标Java应用程序的类路径中应该有一个来自 Apache Tomcat服务器的“org.apache.naming.factory.BeanFactory”类，但其他应用程序服务器可能有自己的对象工厂，可以实现类似的功能。

总结

实际问题不在JDK或Apache Tomcat=中，而是由于用户将不可控数据传递给“InitialContext.lookup()”函数的自定义应用程序中。即使使用最新的漏洞完全修补的JDK中，它存在潜在的安全风险。

在许多情况下，其他漏洞(例如“不受信任数据的反序列化”)也可能导致JNDI解析。通过使用源代码审查来防止这些漏洞始终是一个好主意。

长期以来，对于RMI和LDAP，的引用没有做任何限制。这样对攻击者指定的JNDI RMI或LDA 名称的lookup调用就会导致直接的远程代码执行。

自Java 8u121开始，RMI协议(但不是LDAP)默认不再允许远程代码库。

LDAP之前有一个补丁(CVE-2009-1094)，但这完全是对引用对象无效。因此，LDAP仍然允许直接远程执行代码。直到Java 8u191的 CVE-2018-3149漏洞补丁中才解决。

在Java 8u191版本之前，都存在从受控JNDI lookup远程类加载任意代码执行的风险。

但是新版本中RMI引用和工厂构造对象仍未被去除，只是禁止远程代码库。可以通过Apache XBean BeanFactory 返回的引用来实现远程代码执行。只要该类在目标系统上本地可用既可以，例如被包含到Tomcat或者 WebSphere中则仍然有利用的可能。

另外，RMI本质上是基于Java序列化的，而LDAP支持一个特殊的对象类，从目录中反序列化Java对象从lookup()返回。 在这两种情况下，除非应用了全局反序列化过滤器，否则JNDI注入将会导致反序列化不受信任的攻击者提供的数据。虽然有一定的攻击的复杂性，在许多情况下，仍然可用于远程代码执行。

总之，不要依赖当前Java版本来解决这个问题，需要及时更新Log4j(或删除JNDI lookup)，或者禁用JNDI扩展才是完全的解决方案(可能不太现实)。

原文链接：https://www.toutiao.com/a7041097579668554244/