使用亚马逊云科技安全服务防御、检测和响应 Log4j 漏洞

2022 年 1 月 13 日
本文字数：4072 字
阅读完需：约 13 分钟

概述

在本文中，我们将为针对最近披露的 Log4j 漏洞所影响的客户提供一些指导意见。内容包括如何限制漏洞的风险，如何尝试识别是否易受此问题影响，以及如何使用适当的补丁更新基础架构。

Log4j 漏洞（CVE-2021-44228、CVE-2021-45046）是无处不在的日志平台 Apache Log4j 中的一个关键漏洞（CVSS 3.1 基本分数为 10.0）。此漏洞允许攻击者在易受攻击的平台上执行远程代码。介于版本 2.0-beta-9 和 2.15.0 之间的 Log4j 版本 2 受影响。

该漏洞使用 Java 命名和目录接口（JNDI），Java 程序使用该接口查找数据，通常通过目录查找数据，在出现此漏洞的情况下通常通过 LDAP 目录查找数据。

下面图 1 重点介绍了 Log4j JNDI 攻击流程。

图 1、Log4j 攻击进程。资料来源：GovCERT.ch，瑞士政府计算机应急响应小组（GovCERT）

本篇内容作为一个即时响应，希望您关注这个设计用于使用任何 Log4j 2.0+ 对正在运行的 JVM 进行热补丁的工具。亚马逊云科技的首席信息安全官史蒂夫·施密特（Steve Schmidt）也探讨了这个热补丁。

防御

客户可以使用多个亚马逊云科技提供的服务来帮助限制来自 Log4j 漏洞所带来的风险/暴露。客户可以建立分层控制方法，并/或选择以下确定的控制方法，以帮助限制他们的风险。

Amazon WAF

客户可以使用 Amazon WAF，遵循其相应的托管规则，以帮助保护其 Amazon CloudFront 分布、Amazon API Gateway REST API、Amazon ALB 或 Amazon AppSync GraphQL API 资源。

AWSManagedRulesKnownBadInputsRuleSet esp.：Log4JRCE 规则，有助于检查请求中是否存在 Log4j 漏洞。示例模式包括 ${jndi:ldap://example.com/}。
AWSManagedRulesAnonymousIpList esp.：AnonymousIPList 规则，该规则有助于检查匿名化客户端信息的已知源的 IP 地址。
AWSManagedRulesCommonRuleSet esp.：SizeRestrictions_BODY 规则，用于验证请求正文大小是否最多为 8 KB（8192 字节）。

对于使用 Amazon WAF Classic 的客户，您需要迁移到 Amazon WAF 或创建自定义正则表达式匹配条件。

拥有多个帐户的客户可以按照说明使用 Amazon Firewall Manager 跨 Amazon Organization 集中部署 Amazon WAF 规则。

Amazon Network Firewall

客户可以在 Amazon Network Firewall 中使用与 Suricata 兼容的 IDS/IPS 规则来部署基于网络的检测和防护。可从 corelight、NCC Group、ET Labs 和 CrowdStrike 获得解决 Log4j 的开源 Suricata 规则。这些规则有助于识别 Log4j 漏洞的扫描和攻击后活动。由于目前存在大量良性扫描，我们建议客户首先关注潜在的攻击后活动，例如从其 VPC 向不受信任的互联网目的地的发送出站 LDAP 流量。

我们还建议客户考虑实施出站端口/协议执行规则，以监控或防止诸如 LDAP 之类的实例使用 53、80、123 和 443 等非标准 LDAP 端口。对于监控或防止使用端口 1389 出站，会有助于识别由互联网扫描仪触发进行出站命令和控制呼叫的系统。我们还建议，对于没有合法业务需要向互联网发起网络呼叫的系统，在默认情况下不应被赋予该功能。出站网络流量过滤和监控不仅对 Log4j 非常有用，而且对其他类型的漏洞也非常有用。

使用 IMDSv2

在 log4j 漏洞出现的早期，研究人员注意到，一旦主机受到初始 JDNI 漏洞的危害，攻击者有时会尝试从主机获取凭据，并通过 LDAP、HTTP 或 DNS 查找等机制发送这些凭据。我们建议客户使用 IAM 角色而非使用长期访问密钥，并且不要将凭据等敏感信息存储在环境变量中。客户还可以利用 Amazon Secrets Manager 来存储和自动轮换数据库凭证，而不是在主机的环境变量中存储长期数据库凭证。

为了在可能使用 Amazon EC2 角色时，帮助 Amazon Web Services 防范此类攻击以及帮助保持所有 IMDS 数据的私密性，客户应该考虑需要使用实例元数据服务版本 2（IMDSv2）。由于默认情况下启用了 IMDSv2，因此可以通过禁用 IMDSv1（默认情况下是启用的）来要求使用 IMDSv2。使用 IMDSv2，请求受到初始交互的保护，在初始交互中，调用进程必须首先使用 HTTP PUT 获取会话令牌，而且后续请求必须在 HTTP 头中包含该令牌。这使得攻击者更难从 IMDS 获取凭据或任何其他数据。虽然所有最新的 Amazon SDK 和工具都支持 IMDSv2，但与任何可能非向后兼容的更改一样，在广泛部署之前，请在代表性系统上测试此更改。

检测

这篇文章介绍了如何潜在地限制攻击此漏洞的能力。接下来，我们将着重介绍哪些亚马逊云科技服务可以帮助检测您环境中是否存在此漏洞。

Amazon Inspector

如图 2 所示，Amazon Inspector 团队创建了一个覆盖范围，用于在 Amazon EC2 实例和 Amazon Elastic Container Registry Images (Amazon ECR)（Amazon ECR）中识别此漏洞的存在。利用新的 Amazon Inspector，扫描是自动化且持续的扫描。持续扫描受发布的新软件包、新实例和新的通用漏洞披露（CVE）等事件驱动。

例如，一旦 Inspector 团队增加了对 Log4j 漏洞的支持（CVE-2021-44228 和 CVE-2021-45046），Inspector 立即开始在所有受支持的 Amazon Systems Manager 托管实例中查找此漏洞，其中 Log4j 通过操作系统包管理器安装，并且此包存在于与 Maven 兼容的 Amazon ECR 容器映像中。如果存在此漏洞，将开始显示发现结果，而无需任何手动操作。如果您使用的是 Inspector Classic，则需要确保针对所有 Amazon EC2 实例运行评估。您可以遵循文档，以确保为所有 Amazon EC2 实例创建评估目标。

GuardDuty

除了通过 Inspector 发现存在此漏洞外，Amazon GuardDuty 团队还开始添加与攻击 Log4j 漏洞相关的危害指标，并将继续这样做。GuardDuty 将监控试图访问已知错误 IP 地址或 DNS 条目的行为，还可以通过基于异常的行为结果来发现攻击后的活动。例如，如果 Amazon EC2 实例开始在异常端口上通信，GuardDuty 将检测此活动并创建查找行为：EC2/NetworkPortUnusual。不过，此活动并不限于 NetworkPortUnusual 结果。GuardDuty 有许多与攻击后活动相关的不同结果，这些结果可能是对受损亚马逊云科技资源的响应。

Security Hub

今天，许多客户还使用与 Inspector 和 GuardDuty 集成的 Amazon Security Hub 聚合警报并启用自动修复和响应。从短期来看，我们建议您使用 Amazon Security Hub 通过 Amazon Chatbot、Amazon Simple Notification Service 或票务系统设置警报，以便在 Inspector 在您的环境中发现此漏洞时进行查看。从长远来看，我们建议您在适当的时候使用安全中心来启用安全警报的自动修复和响应。这里是关于如何使用安全中心设置自动修复和响应的一些想法。

VPC flow logs

客户可以使用 Athena 或 CloudWatch Logs Insights queries 对其 VPC 流量日志进行查询，以帮助识别与 log4j 攻击后出站网络活动相关的 VPC 资源。VPC 流量日志的 Version 5 特别有用，因为它包含“流向”字段。我们建议客户首先特别注意使用目标端口 1389 的出站网络呼叫，因为该端口的出站使用在合法应用程序中不太常见。客户还应调查使用目标端口 389 向不受信任的互联网目标 IP 地址发送的出站网络呼叫。免费套餐 IP 声誉服务，如 VirusTotal、GreyNoise、NOC.org 和 pinfo.io，可以提供与记录的活动中找到的公共 IP 地址相关的有用见解。

注意：如果在查询的捕获的 VPC flow logs 中有 Microsoft Active Directory 环境，则可能会由于使用端口 389 而出现误报。

响应

前两部分讨论了帮助防止潜在的攻击企图的方法，以及如何检测存在漏洞和潜在的攻击企图。在本部分中，我们将重点介绍您可以采取哪些步骤来缓解此漏洞。正如我们在概述中指出的，建议立即响应博客，并使用旨在用于使用任何 Log4j 2.0+对正在运行的 JVM 进行热补丁的工具。亚马逊云科技的首席信息安全官史蒂夫·施密特（Steve Schmidt）也探讨了这个热补丁。

Amazon Patch Manager

如果您使用 Amazon Systems Manager Patch Manager，并且已将关键补丁设置为立即安装在补丁基线中，则您的 Amazon EC2 实例将已经具有该补丁。值得注意的是，这一步您还没有完成。接下来，您需要在应用程序代码中使用库的任何位置更新类路径，以确保使用的是最新版本。

容器缓解

为了将概述中提到的热补丁安装到 Amazon EKS 集群工作节点上，亚马逊云科技开发了一个执行 JVM 级别热补丁的 RPM，该热补丁禁用来自 Log4j2 库的 JNDI 查找。ApacheLog4J2 节点代理是亚马逊云科技的 Kubernetes 团队构建的一个开源项目。

一旦确定，Amazon ECR 容器映像将需要更新以使用 Log4j 2.16.0 版本。在下游，您需要确保使用易受攻击的 Amazon ECR 容器映像构建的所有容器都已更新，以便尽快使用新映像。这可能会有所不同，具体取决于您用于部署这些映像的服务。例如，如果您使用的是 Amazon Elastic Container Service (Amazon ECS),您可能希望更新该服务以强制进行新部署，这将使用新的 Log4j 版本毁坏映像。检查支持您用于部署容器的方法的文档。

我们建议客户在打补丁后立即提供新的应用程序凭据并撤销现有凭据。

无法升级时的缓解策略

如果您无法升级到 2.16.0 版，该版本默认情况下禁用对 JDNI 的访问，或者如果您仍在确定为您的环境打补丁的策略，则可以通过更改您的 Log4j 配置来缓解此漏洞。要在>=2.10 版本中实施此缓解措施，您需要从 classpath 中删除 JndiLookup 类：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class