在 Cloudflare，当我们得知一个新的安全漏洞时，我们会迅速召集各个团队，设法回答两个不同的问题：(1) 我们可以采取什么措施来确保客户的基础结构受到保护，以及 (2) 我们可以采取什么措施来确保我们自己的环境是安全的。昨天，即 2021 年 12 月 9 日，热门的基于 Java 的日志记录程序包 Log4j 中的一个严重漏洞被公开披露，我们的安全团队迅速采取行动，帮助应对第一个问题并回答第二个问题。本帖探讨第二个问题。
我们在另一篇博客帖文中介绍关于该漏洞运作方式的详情：Log4j2 漏洞详解 (CVE-2021-44228)，但总而言之，该漏洞使攻击者能够在远程服务器上执行代码。由于 Java 和 Log4j 被广泛使用，这很可能是自 Heartbleed 和 ShellShock 以来互联网上最严重的漏洞之一。该漏洞列示为 CVE-2021-44228。CVE 描述称该漏洞会影响不高于 2.14.1 的 Log4j2 版本，而在 2.15 中已修补漏洞。该漏洞还会影响 log4j 1.x 的所有版本；但是，1.x 已终止生命周期，还包含不会被修复的其他漏洞。推荐的操作是升级到 2.15。您还可以在以下帖文中阅读有关我们如何更新 WAF 规则来帮助保护客户的信息：CVE-2021-44228 - Log4j RCE 零日缓解
时间表
每当应对突发事件时，我们首先会做的一件事情就是，开始草拟我们需要在相关情况的背景下评估和了解事件的时间表。此处时间表中的一些示例包括：
2021-12-09 16:57 UTC - 收到关于 developers.cloudflare.com 上的 Log4j RCE 的 Hackerone 报告
2021-12-10 09:56 UTC - 第一条 WAF 规则已传输到 Cloudflare Specials 规则集
2021-12-10 10:00 UTC - 被操纵 INCIDENT 正式打开，开始工作以识别需要修复 Log4j 的区域
2021-12-10 10:33 UTC - Logstash 部署了修复程序以缓解漏洞。
2021-12-10 10:44 UTC - 第二条 WAF 规则作为 Cloudflare 管理的规则的一部分上线
2021-12-10 10:50 UTC - ElasticSearch 重启开始修复以缓解漏洞
2021-12-10 11:05 UTC - ElasticSearch 重启结束，不再有漏洞
2021-12-10 11:45 UTC - Bitbucket 已修复，不再有漏洞
2021-12-10 21:22 UTC - Hackerone 报告在无法复制之后作为有用信息 Informative 关闭
解决内部影响
处理任何软件漏洞时的一个重要问题，也可能是每家公司在这种特定情况下需要回答的最困难问题：有漏洞的软件实际上都在哪些地方运行？
如果漏洞位于一家公司向全世界许可的某个专有软件中，这个问题很容易回答 - 您只需找到那个软件即可。但在这种情况下，问题困难得多。Log4j 是广泛使用的一个软件，但 Java 开发人员之外的人群可能并不熟悉。我们的首要行动就是重新熟悉我们的基础结构中在 JVM 上运行该软件的所有地方，以便确定哪些软件组件可能容易受到该问题影响。
我们能够使用集中代码存储库创建在 JVM 上运行的所有软件的清单。我们使用该信息来研究并确定我们拥有的每一个 Java 应用程序，它是否包含 Log4j，以及其中编译了哪个版本的 Log4j。
我们发现 ElasticSearch、LogStash 和 Bitbucket 包含了版本介于 2.0 到 2.14.1 之间的有漏洞 Log4j 程序包的实例。我们能够使用官方 Log4j 安全性文档中描述的缓解策略来修复该问题。对于 Log4j 的每个实例，我们要么从 classpath 中删除了 JndiLookup 类：
zip -q -d log4j-core-*.jarorg/apache/logging/log4j/core/lookup/JndiLookup.class
要么在 log4j 配置中设置了起缓解作用的系统属性：
log4j2.formatMsgNoLookups
我们能够使用这些策略在这些程序包中迅速缓解该问题，同时等待程序包的新版本发布。
审查外部报告
早在我们完成有漏洞软件运行所在内部位置的列表拟定工作之前，我们就开始查看外部报告 - 来自我们的漏洞奖励程序 HackerOne，以及 GitHub 中提示我们可能面临风险的公开帖子。
我们识别到至少两个报告，似乎指示 Cloudflare 有漏洞并遭到破坏。在其中一个报告中有如下屏幕截图：
该示例针对的是在 https://developer.cloudflare.com 中托管的开发人员文档。在右侧，攻击者展示了针对他发送到我们服务器的有效负载，收到了 DNS 查询。但是，此处标记的 IP 地址是 173.194.95.134，属于 Google 拥有的 IPv4 子网 (173.194.94.0/23)。
Cloudflare 的开发人员文档作为 Cloudflare Worker 托管，仅提供静态资产。存储库是公开的。该 Worker 依赖 Google 的分析库，如此处所示，因此，我们假定攻击者不是从 Cloudflare 接收请求，而是通过 Google 的服务器接收。
我们的后端服务器从 Workers 接收日志记录，但在这种情况下也无法开展漏洞利用，因为我们利用强大的 Kubernetes 出口策略来防止向外传输到互联网。唯一允许的通信是传输到精选的一组内部服务。
我们在收集更多信息时收到漏洞披露程序中的类似报告时，研究人员无法重现该问题。这进一步强化了我们关于问题源自第三方服务器的假定，他们可能已经修复该问题。
Cloudflare 是否遭到破坏？
当我们运行如上所述的软件版本时，多亏了我们迅速应对并采用纵深防御方法，我们认为 Cloudflare 没有遭到破坏。我们投入了大量精力来验证这一点，并将继续开展这一工作，直至弄清楚该漏洞的全部细节。下面简单介绍一下这部分工作。
随着我们努力评估和隔离可能在运行有漏洞软件的所有场景并加以修复，我们也开始了一个单独的工作流，以分析其中是否有任何情况已被漏洞利用。我们的检测和应对方法遵循行业标准事件响应实践，并进行了彻底部署，以验证我们的资产是否确实遭到破坏。我们采用了下面描述的多管齐下方法。
审查内部数据
利用资产清单和代码扫描工具，我们可以识别依赖 Apache Log4j 的所有应用程序和服务。在审查并工具需要升级这些应用程序的同时，我们还对这些服务和主机执行了彻底的扫描。具体来说，CVE-2021-44228 的漏洞利用依赖日志消息和参数中的特定模式，例如 \$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+。对于每个潜在受影响的服务，我们执行了日志分析，以暴露任何漏洞利用企图。
审查网络分析
利用网络分析，我们可以识别可疑的网络行为，这些行为可能表明有人企图或实际对我们的基础结构进行漏洞利用。我们仔细检查了网络数据，识别到以下情况：
可疑的入站和出站活动通过分析可疑的入站和出站连接，我们能够扫描我们的环境，并识别我们的系统是否表现出正在被破坏的迹象。
针对的系统和服务通过利用针对我们网络数据的模式分析，我们发现了威胁入侵者针对的系统和服务。这样一来，我们可以针对资产清单执行相关性搜索，并向下钻取到每个主机以确定这些机器是否暴露于该漏洞或正在被漏洞利用。
网络指标从上述分析中，我们洞察了各种威胁入侵者的基础结构，并识别到攻击者企图利用该漏洞时所采用的网络指标。在 Cloudflare Gateway 中阻止了对这些指标的出站活动。
审查端点
我们能够将日志分析和网络分析工作流程相关联，以补充端点分析。从这两种分析的发现结果中，我们能够制定端点扫描标准，以识别任何额外的潜在受影响系统，并分析各个端点，找出正在被破坏的迹象。我们采用了以下方法：
基于签名的扫描
我们正在部署自定义 Yara 检测规则，以提醒漏洞利用情况。这些规则将部署到我们的全部基础结构和我们的集中安全信息与事件管理(SIEM) 工具上运行的端点检测和响应代理中。
异常进程执行和持久性分析
Cloudflare 持续从我们的基础结构收集和分析端点进程事件。我们使用这些事件来搜索了漏洞利用后方法，如下载第二阶段漏洞利用、异常子进程，等等。
使用所有这些方法，我们没有发现遭到破坏的证据。
第三方风险
在上述分析中，我们关注的是审查我们自己生成的代码和数据。但就像大多数公司那样，我们也依赖我们从第三方获得许可的软件。当我们开始调查这件事的时候，我们还与公司的信息技术团队合作，拟出了每一家主要第三方提供商和所有子处理者的列表，以便询问他们是否受影响。我们正在从提供商接收答复并进行审查。我们视为重要的任何提供商，只要受到该漏洞影响，都会被禁用和阻止，直至他们完全修复漏洞。
验证我们的纵深防御方法的效果
随着我们应对该突发事件，我们发现我们的纵深防御方法在几个地方发挥了作用。
限制出站流量
限制_呼叫服务器_的能力是 kill-chain 的基本组成部分，可大幅提高利用漏洞的难度。如上所述，我们利用 Kubernetes 网络策略在我们的部署上限制出口到互联网。在本场景下，这可防止攻击的后续阶段，并且与攻击者控制的资源网络连接会断开。
我们所有面向外部的服务都受到 Cloudflare 的保护。这些服务的源服务器是通过 Authenticated Origin Pulls 设置。这意味着，这些服务器均未直接暴露于互联网。
2. 使用 Cloudflare 保护 Cloudflare
我们的所有内部服务都受到我们的 Zero-trust 产品 Cloudflare Access 的保护。因此，一旦我们修补了我们所识别到的有限攻击面，对 Cloudflare 系统或利用 Access 的客户进行任何漏洞利用企图，都将需要攻击者进行身份验证。
由于我们部署了 Cloudflare WAF 产品，作为使用 Cloudflare 保护 Cloudflare 的工作的一部分，我们也受益于为保护客户所做的所有工作。为防护该漏洞而编写的所有新 WAF 规则已使用默认操作 BLOCK 进行了更新。就像部署了 WAF 的其他所有客户一样，我们现在无需采取任何行动也受到保护。
总结
随着我们继续应对这一带有挑战性的情况，我们希望此保护说明能够帮助大家防御漏洞。对于我们从 Cloudflare 内部和外部获得的所有支持，我们深表感激。
Evan Johnson、Anjum Ahuja、Sourov Zaman、David Haynes 和 Jackie Keith 也为本博客做出了贡献，谢谢你们！