这几天,Apache Log4j2 绝对是众多 Java 程序员提到的高频词之一:由于 Apache Log4j2 引发的严重安全漏洞,令一大批安全人员深夜修 Bug、发补丁。此次漏洞更是因为其触发简单、攻击难度低、影响人群广泛等特点,被许多媒体形容为“核弹级”漏洞。
据彭博社本周一报道,其实早在 11 月 24 日阿里云安全团队便已向 Apache 官方具体报告了此次 Apache Log4j2 漏洞,并将之称作“一个会有重大影响的安全漏洞”。报告中详细描述了黑客将如何利用该漏洞实现远程代码执行,从而完成远程操控计算机的目的。
可即便 Apache Log4j2 项目维护者在收到消息后便立即着手修复漏洞,也还是没赶上事态的急剧变化。12 月 8 日,阿里云又向 Apache 发了一封邮件称该漏洞已被人披露,并有安全研究人员在对此讨论:“我们承诺在你们正式发布(修复)版本之前,会保守这个秘密。请快点。”大约 20 个小时后,Apache Log4j2 团队发布了漏洞补丁,随之而来的就是程序员与黑客之间的速度比拼(有研究人员发现,该漏洞自 2013 年 9 月以来就一直存在于 Log4j 中,但之前无人发现)。
在这起事件发生之前,就连 Apache Log4j2 自身团队可能都没意识到,这么一个基于 Java 的日志框架影响范围竟有那么广。据前 Log4j 开发者、现 Apache 软件基金会的副总裁 Christian Grobmeier 表示,当他第一次得知这一消息时非常震惊:“苹果参与其中、Twitter 也会受到影响,然后我才意识到居然有这么多人在使用它:基本上是半个世界,甚至更多,这太疯狂了。”
自 12 月 9 日 Apache Log4j2 漏洞曝光以来,尽管各大企业都为此紧急引入了保护机制,但黑客依旧在想法设法绕过限制利用漏洞。为进一步具体了解 Apache Log4j2 漏洞对全球的影响,Check Point Research(知名网络安全解决方案提供商 Check Point 旗下的威胁情报部门,简称 CPR)统计了一份漏洞爆发 4 天的报告——自 12 月 10 日至 12 月 13 日,Check Point 对此总结道:“这显然是一场尚未见顶的网络流行病(Cyber Pandemic)。”
据 CPR 统计,在 Apache Log4j2 漏洞发现早期的 12 月 10 日,黑客尝试利用该漏洞进行攻击的次数仅有几千次,但这一数据在隔天却增至 4 万次。而截至 Check Point 发布该报告,即漏洞爆发 72 小时后,仅 CPR 传感器捕捉到利用该漏洞尝试攻击的行为就已超过 80 万次:
不仅攻击次数在持续攀升,基于该漏洞的新变种也在短时间内迅速衍生,截至报告发布已超过 60 种:
基于这两个现象,Check Point 认为此次 Apache Log4j2 漏洞具备“网络流行病”的特征——迅速传播毁灭性攻击。Check Point 表示:“它显然是近年来互联网上最严重的漏洞之一,其潜在危害是无法估量的。”
“迅速传播毁灭性攻击”的前提是,这个漏洞影响着全球大量组织,像野火般蔓延。这一点,作为一个特别通用的开源日志框架,Apache Log4j2 无疑具备这个特点:Check Point 表示,全球近一半企业因为该漏洞受到了黑客的试图攻击:
在被波及的企业中,系统集成商(SI)/增值代理商(VAR)/经销商受到的冲击最大(59.1%),其次是便是教育与科研行业(56.9%),互联网服务提供商(ISP)/管理服务提供商(MSP)也是这次漏洞的主要“受害者”之一,近 55.1% 的企业受到影响:
值得一提的是,对比其他国家,中国受 Apache Log4j2 漏洞影响相对较小:即便在漏洞爆发高峰期,也只有近 34% 的企业受到波及。这或许与漏洞刚被曝出时,国内如阿里云、斗象科技、绿盟科技、默安科技、奇安信等众多安全厂商第一时间发布危害通报有关,使许多企业足以赶在黑客利用漏洞高峰期之前便打好补丁。
但 Check Point 指出,由于 Apache Log4j2 应用范围大、漏洞修复较为复杂,而利用漏洞却十分简便,因此除非企业和相关服务立即采取行动并实施保护以防止对其产品的攻击,否则这个 Apache Log4j2 漏洞很可能在未来几年内也将一直存在。
具体漏洞修复措施参见《Flink等多组件受影响,Apache Log4j曝史诗级漏洞 》文末。不过升级到 Log4j 2.15 也并非完全安全,因为该版本默认禁用了部分容易被黑客利用的 Java 库主要功能,但在某些非默认配置中仍可以被利用,为此 Apache 最新发布了 Log4j 2.16,该版本在默认情况下禁止访问JNDI(JNDI 是 Log4j 漏洞中可被利用的 API),并完全删除消息查找功能,进一步阻止漏洞被利用。
除此之外,在临时修复措施中还可从以下三种方式中任选其一:
(1)JDK 使用 11.0.1、8u191、7u201、6u211 及以上的高版本;
(2)限制受影响应用对外访问互联网;
(3)部署使用第三方防火墙产品进行安全防护,并更新 WAF、RASP 规则等。
参考链接: