大聪明教你学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版本。

接下来再解释一下第二个问题:为什么不用修改配置文件的办法去修复漏洞?

原因就更简单了,通过修改参数的办法去修复漏洞属于治标不治本的办法,更不靠谱,所以个人非常不推荐通过此方法来修复漏洞,为了避免“按下葫芦浮起瓢”,我们还是选择使用上面的两种办法更保险一些💪

小结

本人经验有限,有些地方可能讲的没有特别到位,如果您在阅读的时候想到了什么问题,欢迎在评论区留言,我们后续再一一探讨🙇‍

希望各位小伙伴动动自己可爱的小手,来一波点赞+关注 (✿◡‿◡) 让更多小伙伴看到这篇文章~ 蟹蟹呦(●’◡’●)

如果文章中有错误,欢迎大家留言指正;若您有更好、更独到的理解,欢迎您在留言区留下您的宝贵想法。

你在被打击时,记起你的珍贵,抵抗恶意;
你在迷茫时,坚信你的珍贵,抛开蜚语;
爱你所爱 行你所行 听从你心 无问东西

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇

)">
下一篇>>