大聪明教你学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 查找模式制作恶意输入数据，导致部分环境信息泄露和远程代码执行。
说白了就是2.15.0也不靠谱了，还是存再一些问题，所以我们需要升级到2.16.0版本。
接下来再解释一下第二个问题：为什么不用修改配置文件的办法去修复漏洞？
原因就更简单了，通过修改参数的办法去修复漏洞属于治标不治本的办法，更不靠谱，所以个人非常不推荐通过此方法来修复漏洞，为了避免“按下葫芦浮起瓢”，我们还是选择使用上面的两种办法更保险一些
小结
本人经验有限，有些地方可能讲的没有特别到位，如果您在阅读的时候想到了什么问题，欢迎在评论区留言，我们后续再一一探讨
希望各位小伙伴动动自己可爱的小手，来一波点赞+关注 (✿◡‿◡) 让更多小伙伴看到这篇文章~ 蟹蟹呦(●’◡’●)
如果文章中有错误，欢迎大家留言指正；若您有更好、更独到的理解，欢迎您在留言区留下您的宝贵想法。
你在被打击时，记起你的珍贵，抵抗恶意；
你在迷茫时，坚信你的珍贵，抛开蜚语；
爱你所爱 行你所行 听从你心 无问东西