大聪明教你学Java | Log4j 漏洞到底是怎么一回事？Log4j 2.15.0 也不靠谱了...

本文主要是介绍大聪明教你学Java | Log4j 漏洞到底是怎么一回事？Log4j 2.15.0 也不靠谱了...，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

近日，被全球广泛应用的组件Apache Log4j被曝出一个已存在在野利用的高危漏洞，攻击者仅需一段代码就可远程控制受害者服务器。几乎所有行业都受到该漏洞影响，包括全球多家知名科技公司、电商网站等，漏洞波及面和危害程度均堪比 2017年的“永恒之蓝”漏洞。
据奇安信集团透露，根据安域云防护的监测数据显示，截至2021年12月10日中午12点，已发现近1万次利用该漏洞的攻击行为。奇安信应急响应中心已接到十余起重要单位的漏洞应急响应需求。奇安信已于2021年12月9日晚间将漏洞信息上报了相关主管部门。补天漏洞响应平台负责人介绍，2021年12月9日深夜，仅一小时内就收到白帽黑客提交的百余条该漏洞的信息。
经专家研判，该漏洞影响范围极大，且利用方式十分简单，攻击者仅需向目标输入一段代码，不需要用户执行任何多余操作即可触发该漏洞，使攻击者可以远程控制用户受害者服务器，90%以上基于java开发的应用平台都会受到影响。
（以上内容来自百度👆）

不知道各位小伙伴有没有被 Log4j 爆出的漏洞震惊到，Log4j 作为 Apache 的一个开源项目帮助我们轻易的实现了日志打印、日志记录等等功能。但是就是这么一个“妇孺皆知”的日志组件，却在程序猿的圈子里引起了一场巨大的风波。可能有很多小伙伴在2021年12月10日的凌晨就收到了甲方爸爸的电话，然后就开始马不停蹄的修复漏洞，其实这个漏洞并不算大，修复起来也不算麻烦（修复漏洞的办法在文章最后面哦~），但是却真的打了我们一个措手不及😭

Log4j 漏洞到底是怎么一回事？

首先引入一个低版本的 Log4j 依赖👇

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

然后我们写一个测试方法👇

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;/*** Log4j 漏洞复现* @description: Log4jTest* @author: 庄霸.liziye* @create: 2021-12-18 23:17**/
public class Log4jTest {private static final Logger log = LogManager.getLogger();public static void main(String[] args) {String info = "${java:os}";log.info("日志信息----> {}!", info);}
}

然后执行一下代码，我们看看会出现什么情况~
在这里插入图片描述
对！没有错！漏洞被修复了！！！

本来想给大家复现一下 Log4j 的漏洞，但是漏洞已经被修复了（低版本的 Log4j 依赖也都被修复了），这里就只能靠文字来给大家简单说一说了😅

多少有点尴尬，哈哈哈哈哈…

官方给出的漏洞描述是：Apache Log4j2 中存在JNDI注入漏洞，当程序将用户输入的数据进行日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码。

其实这个漏洞的原理也非常简单：在打印日志的时候，如果你的日志信息中存在 ${} 占位符，那么攻击者就可以利用这个占位符所对应的变量来进行攻击。以上面的代码为例，在漏洞没有修复之前，控制台会输出我们的系统信息，而不是一个简简单单的 “ ${java:os} ” 字符串，那么如果说攻击者此时传入了一个类似于“jndi:ldap//恶意链接”、“jndi:rmi//恶意链接” 形式的参数，这时候就会触发这个漏洞，从而执行攻击者自定义的程序，达到其不可告人的秘密🆘

到这里我们应该也就明白了，这个漏洞的根本原因就是字符替换导致的。
Apache Log4j2 组件通过 lookup 扩展的实现类 JndiLookup 来实现的这个功能，这个类存在于 log4j-core-xxx.jar 中，所以只有 log4j-core jar 文件受此漏洞影响，仅使用 log4j-api jar 文件而不使用 log4j-core jar 文件的应用程序依然是安全的。所以各位小伙伴就不用这么惊慌啦~
在这里插入图片描述

修复 Log4j 漏洞

如果我们的应用程序不小心中招了该怎么办呢？其实修复此漏洞的办法也跟简单👇

升级 Log4j 版本，将依赖或者jar包升级至最新的2.16.0版本
直接不用 Log4j （最简单粗暴的办法，直接斩草除根）

有些小伙伴会问了：不是升级到2.15.0就行吗？而且不是还有通过修改配置参数来修复漏洞的方式吗？

各位稍安勿躁，听我娓娓道来~

首先先解释一下第一个问题：为什么不是升级到2.15.0版本呢？
原因也很简单，Apache 官网给出了一个解释👇
在这里插入图片描述
翻译过来就是：发现Apache Log4j 2.15.0中针对CVE-2021-44228的修复在某些非默认配置中不完整。当日志配置使用带有上下文查找的非默认模式布局（例如，$${ctx:loginId}）时，控制线程上下文映射 (MDC) 输入数据的攻击者可以使用 JNDI 查找模式制作恶意输入数据，导致部分环境信息泄露和远程代码执行。