Cloudflare如何安全应对Log4j 2漏洞？

在Cloudflare，当我们得知一个新的安全漏洞时，我们会迅速召集各个团队，设法回答两个不同的问题：(1)我们可以采取什么措施来确保客户的基础结构受到保护，以及(2)我们可以采取什么措施来确保我们自己的环境是安全的。昨天，即2021年12月9日，热门的基于Java的日志记录程序包Log4j中的一个严重漏洞被公开披露，我们的安全团队迅速采取行动，帮助应对第一个问题并回答第二个问题。本帖探讨第二个问题。

总而言之，该漏洞使攻击者能够在远程服务器上执行代码。由于Java和Log4j被广泛使用，这很可能是自Heartbleed和ShellShock以来互联网上最严重的漏洞之一。该漏洞列示为CVE-2021-44228。CVE描述称该漏洞会影响不高于2.14.1的Log4j2版本，而在2.15中已修补漏洞。该漏洞还会影响log4j 1.x的所有版本；但是，1.x已终止生命周期，还包含不会被修复的其他漏洞。推荐的操作是升级到2.15。

时间表

每当应对突发事件时，我们首先会做的一件事情就是，开始草拟我们需要在相关情况的背景下评估和了解事件的时间表。此处时间表中的一些示例包括：

·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]+。对于每个潜在受影响的服务，我们执行了日志分析，以暴露任何漏洞利用企图。

审查网络分析

利用网络分析，我们可以识别可疑的网络行为，这些行为可能表明有人企图或实际对我们的基础结构进行漏洞利用。我们仔细检查了网络数据，识别到以下情况：

1.可疑的入站和出站活动

通过分析可疑的入站和出站连接，我们能够扫描我们的环境，并识别我们的系统是否表现出正在被破坏的迹象。

2.针对的系统和服务

通过利用针对我们网络数据的模式分析，我们发现了威胁入侵者针对的系统和服务。这样一来，我们可以针对资产清单执行相关性搜索，并向下钻取到每个主机以确定这些机器是否暴露于该漏洞或正在被漏洞利用。

3.网络指标

从上述分析中，我们洞察了各种威胁入侵者的基础结构，并识别到攻击者企图利用该漏洞时所采用的网络指标。在Cloudflare Gateway中阻止了对这些指标的出站活动。

审查端点

我们能够将日志分析和网络分析工作流程相关联，以补充端点分析。从这两种分析的发现结果中，我们能够制定端点扫描标准，以识别任何额外的潜在受影响系统，并分析各个端点，找出正在被破坏的迹象。我们采用了以下方法：

基于签名的扫描

我们正在部署自定义Yara检测规则，以提醒漏洞利用情况。这些规则将部署到我们的全部基础结构和我们的集中安全信息与事件管理(SIEM)工具上运行的端点检测和响应代理中。

异常进程执行和持久性分析

Cloudflare持续从我们的基础结构收集和分析端点进程事件。我们使用这些事件来搜索了漏洞利用后方法，如下载第二阶段漏洞利用、异常子进程，等等。

使用所有这些方法，我们没有发现遭到破坏的证据。

第三方风险

在上述分析中，我们关注的是审查我们自己生成的代码和数据。但就像大多数公司那样，我们也依赖我们从第三方获得许可的软件。当我们开始调查这件事的时候，我们还与公司的信息技术团队合作，拟出了每一家主要第三方提供商和所有子处理者的列表，以便询问他们是否受影响。我们正在从提供商接收答复并进行审查。我们视为重要的任何提供商，只要受到该漏洞影响，都会被禁用和阻止，直至他们完全修复漏洞。

验证我们的纵深防御方法的效果

随着我们应对该突发事件，我们发现我们的纵深防御方法在几个地方发挥了作用。

1.限制出站流量

限制呼叫服务器的能力是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也为本博客做出了贡献，谢谢你们！