Log4j漏洞原理及修复

一：基本介绍

2021年12月8号爆出的log4j2的远程代码执行漏洞：Log4j漏洞（CVE-2021-44228）起源于其在处理环境变量时的一个安全漏洞，攻击者可以通过构造恶意环境变量，使Log4j在处理日志时自动将代码注入到受影响的应用程序中，从而获取应用程序的系统权限。由于Log4j广泛地应用于Java程序中，该漏洞也因此影响了大量的应用程序，包括但不限于服务器、网站、应用程序等。

触发方式 远程
用户认证 不需要用户认证
配置方式 默认
影响版本 Apache Log4j 2.0-alpha1 到 2.14.1（包括这些版本） Apache Log4j 1.2.19 到 1.2.20（包括这些版本）
利用难度 极低，无需授权即可远程代码执行
威胁等级 严重，能造成RCE

触发方式	远程
用户认证	不需要用户认证
配置方式	默认
影响版本	Apache Log4j 2.0-alpha1 到 2.14.1（包括这些版本）Apache Log4j 1.2.19 到 1.2.20（包括这些版本）
利用难度	极低，无需授权即可远程代码执行
威胁等级	严重，能造成RCE

二：原理

在Log4j2中提供了Lookups机制，Lookups提供了一种在Log4j配置文件任意位置添加值的方法；而Lookups机制中，存在JNDI，在Log4j日志输出时，未对字符合法性进行严格的限制，造成JNDI协议加载的远程恶意脚本被执行，从而造成RCE。

1.Lookups机制

"Lookups provide a way to add values to the Log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface. "
以上內容来源log4j2的官方文档lookup - Office Site。其说明了lookups的主要功能就是提供另外一种方式以添加某些特殊的值到日志中，以最大化松散耦合地提供可配置属性供使用者以约定的格式进行调用。（lookups是实现StrLookup接口的特定类型的插件）lookups给开发者提供了更加方便的后端开发过程中的调试效率。lookups可以通过 {$xx} 的方式来执行一些命令和操作,log4j支持在日志中使用该表达式执行命令。下面是log4j使用lookup的简单示例，可以打印系统os信息。

public void test() {
	log.info("{$java:os}");
} 

所以常见的Log4j漏洞的payload是以下格式的：

${jndi:ldap}
${jndi:ldaps}
${jndi:rmi}
${jndi:iiop}
${jndi:iiopname}
${jndi:corbaname}
${jndi:dns}
${jndi:nis}

以上每个payload里面都有jndi，下面将介绍JNDI的作用

2.JNDI注入介绍

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

JNDI主要由JNDI API和JNDI SPI两部分组成，Java应用程序通过JNDI API访问目录服务，而JNDI API会调用Naming Manager实例化JNDI SPI，然后通过JNDI SPI去操作命名或目录服务其如LDAP， DNS，RMI等，JNDI内部已实现了对LDAP，DNS， RMI等目录服务器的操作API。

通过上面可以知道，JNDI可以实现对LADP、RMI等服务的操作，所以攻击者只需要构建一个LADP或RMI远程服务即可，让远程服务器返回恶意class

LDAP（Lightweight Directory Access Protocol）：顾名思义，一个轻量级的目录访问协议，用来访问目录服务（Directory Service）。
那么LDAP协议作为一个访问协议，它在技术架构的表现上是一个CS架构模式：以IDaaS为例，IDaaS产品要解决的三个问题，都是会作为LDAP Client去访问LDAP Server（这里LDAP Server和Directory Service等同了），来实现功能

RMI（Remote Method Invocation） 是Java平台一个分布式应用程序的应用编程接口（API），它是Java Remote Method Protocol（JRMP）的实现，这个协议代表了Java语言特有的远程过程调用（RPC）系统。RMI允许一个对象通过一个网络在另外一个虚拟机上被调用，这些对象称之为远程对象

攻击者定义一个接口，在接口中定义数据库操作等。
攻击者携带lookup支持表达式进行请求服务器。
服务器通过log4j打印出请求信息。
log4j打印完成后会执行JNDI操作。
这样就解释了漏洞的产生，危害不容小觑

三：Log4j漏洞修复

1.升级到受影响版本的修复版：
（1）对于Apache Log4j 2.x 用户，建议升级到2.17.0版本以上。这些版本修复了漏洞，并包含其他安全增强措施。
（2）对于Apache Log4j 1.x 用户，目前官方并未针对1.x版本提供官方修复版。建议升级到Log4j 2.x版本，或者考虑使用其他日志记录库。

2.阻止使用JNDI来加载远程资源：
如果您无法立即升级到修复版本，可以通过在Log4j配置中禁用使用JNDI来加载远程资源来减少风险。可以通过在log4j2.xml文件中将JndiLookup类从配置中移除或设置为安全的FallbackJndiLookup或DummyLookup来实现。

3.启用安全策略：
为了进一步减少潜在的风险，应该考虑启用安全策略来限制代码执行。可以通过在log4j2.xml文件中添加安全策略配置来实现。

4.清除受影响系统的缓存：
Log4j有一个缓存机制，可以存储已解析的XML配置。为了确保新的配置生效，您可能需要清除缓存。可以通过清除 Log4j 的上下文选择器缓存来实现。

除了以上方法外，了解并关注官方发布的漏洞修复和更新是非常重要的，因为该漏洞的细节和修复程度可能会发生变化。推荐遵循安全最佳实践，并随时关注官方漏洞通告和安全更新。

总结
Log4j漏洞能造成RCE等危害，所谓是为所欲为，虽然现在大部分系统早已经安装补丁进行修复升级，但仍有部分老系统未进行修复，这是在安全测试中我们不可忽视的一个重大漏洞，任然需要对Log4j版本等进行排查修复。