原文链接： When a Zero Day and Access Keys Collide in the Cloud: Responding to the SugarCRM Zero-Day Vulnerability
译者：知道创宇404实验室翻译组

摘要

本文讨论了SugarCRM 0-day漏洞（CVE-2023-22952）的认证如何绕过远程代码执行，并总结出了防御者们应该注意的事项。由于该漏洞是一个Web应用程序，如果没有进行正确配置或保护，一旦黑客了解了云服务提供商使用的基础技术，并获取了适当权限，可能会引发多次安全事件。

在过去的一年中，Unit 42响应了多起案例，其中 SugarCRM 漏洞 （CVE-2023-22952） 是主要的初始攻击媒介，其允许黑客访问AWS 账户。但这并不是因为AWS的漏洞，任何云环境都可能发生这种情况。相反，黑客后期利用错误配置来扩大他们的访问权限。

本文参考 MITRE ATT&CK 框架对AWS环境遇到的各种攻击事件进行分析，并总结了各个组织可以来保护自己的多种预防保护机制。这些保护措施包括利用AWS提供的控制和服务、云最佳实践以及足够多的数据来捕获完整的攻击过程。

这些攻击的复杂性更加表明了设置日志记录和监控对于检测未经授权的AWS API调用的重要性。一旦黑客得以立足，那么可能会导致更加严重的威胁行为，而这些行为是不可被追溯的。云安全保护并非一刀切，这些攻击暴露了需要重点关注的领域，而这样也可以让我们在面对攻击时能做出更充分的准备。

MITRE ATT&CK 框架

本次事件中采用 MITRE ATT&CK 框架，该框架矩阵由十四个不同的战术组成，以此描述了网络安全攻击的各个组成部分。在我们应对的各种案例中，其中有九个战术描述了黑客的活动。这九个是初始访问、凭证获取、发现、横向移动、执行、数据外泄、权限提升、持久化和防御规避。

事件概览

CVE-2023-22952 初次访问

这些AWS账户遭到入侵的初始攻击媒介是0-day SugarCRM漏洞 CVE-2023-22952，SugarCRM是一个专注于跨团队协作的客户关系管理平台，其应用较广泛。

CVE-2023-22952于2023年1月11日被NIST国家漏洞数据库发布，基础评分为8.8。由于缺少输入验证，这个漏洞允许黑客通过SugarCRM 电子邮件模板注入自定义的PHP代码。

要了解黑客为何将SugarCRM作为攻击的目标，重点了解SugarCRM客户数据库中存在的大量敏感数据(如电子邮件地址、通信地址和帐户信息)是很有帮助的。如果这些数据被泄露，黑客要么会选择直接出售这些信息，要么会敲诈受害者以获得更多的钱。

通过利用SugarCRM中的这个漏洞，黑客可以通过远程执行组件直接访问运行该应用程序的底层服务器。在我们响应的案例中，这些服务器是Amazon弹性云计算(EC2)实例，具有存储在主机上的长期AWS访问密钥，黑客能够扩大他们的访问权限的作用。由于这些组织将他们的基础架构托管在云端，与本地托管相比，黑客会面临不同的攻击向量。

访问凭证

一旦黑客获取EC2实例的访问权限，他们就成功地破坏了存储在主机上的AWS长期访问密钥。无论计算机部署在本地上还是云上，如果用户使用AWS命令行界面（CLI），他们可以选择将用于进行身份验证的凭据存储在主机的存储凭据文件中(如下面的图1所示，其中包括文件路径)。

在我们观察的案例中，这些明文凭据存储在被入侵的主机上，使得黑客能够窃取这些凭据并开始使用访问密钥进行访问活动。

发现

在黑客执行任何扫描活动前，首先会运行GetCallerIdentity命令。GetCallerIdentity是AWS版本的whoami命令，它返回有关执行调用实体的各种信息，如用户ID、账户、亚马逊资源名称(ARN)和用于签署请求凭证相关的主体，如图2所示。用户ID是执行调用的唯一实体标识符，账户凭证是12位数字标识符，ARN包括执行调用主体的账户ID和可读的名称。

在黑客对泄露的凭据有了更多的了解后，他们就会开始进行扫描活动。主要利用Pacu和Scout Suite这两个工具来了解AWS客户中存在哪些资源，Pacu是一个开源的AWS渗透测试框架，旨在成为云上Metasploit的等效工具。Scout Suite则是一种安全审计工具，主要用于云环境安全状况评估。

在所响应的一些案例中，我们看到Pacu已经存在于之前用于渗透测试主机上。至于Scout Suite，我们没有看到它被下载到被入侵的EC2实例中，但根据黑客活动相关的用户代理，我们知道它被使用了。这两个工具都为黑客提供了大量信息，以便他们了解他们所入侵的AWS账户的情况。

这些案例中，这些工具扫描了各种传统服务，例如：

• EC2
• IAM
• RDS
• S3
• SNS
• SES
• Lambda

黑客还对其他服务执行了发现调用，这些服务可能并不需要向攻击者提供有用的信息，如组织服务（Organizations service）和成本用途服务（Cost and Usage service）。

AWS Organizations为公司提供了集中管理多个AWS帐户和资源的场所。在查看CloudTrail日志中的黑客活动时，有三个Organizations API调用引起了注意。第一个调用是ListOrganizationalUnitsForParent，它列出了所有的组织单元（OUs）。

在此之后，黑客运行了ListAccountsAPI调用，该调用返回与每个OU关联的所有账户ID。提供给黑客最有用信息的最后一个调用是DescribeOrganization API调用。该事件返回了主账户ID以及与该账户关联的主账户电子邮件地址。通过这些信息，黑客有足够的理由尝试以Root用户身份登录该账户。

最后一个有趣的发现是调用涉及到成本和使用情况服务（Cost and Usage service）。黑客执行了各种GetCostandUsage调用，并且响应返回了受攻击账户内的一般成本信息。

防御者需要意识到黑客可以通过了解云账户中的费用情况来判断账户的活跃程度。如果一个开户的总费用较高，那么对于黑客来说，在未被察觉的情况下创建新的资源可能更容易，因为这样的费用可能不会引起过多的关注。

另一方面，如果一个账户的开支很少，那么几个新资源可能会更加显眼。支出较少的账户所有者可能对费用情况有更严格的通知设置，这可能在黑客创建新资源时触发警报。

组织（Organizations）和成本和使用情况（Cost and Usage）API调用都是展示云环境中攻击面的好例子。通过使用这些看似无害的API调用，黑客获得了大量关于账户结构和使用情况的信息，而无需执行过多可能触发警报的可疑活动。

RDS 横向移动、执行、渗透

在我们观察到的事件中，一旦黑客完成对环境的扫描，就有足够的信息来缩小他们的活动范围，从发现整个帐户到对从关系数据库服务(RDS)。黑客通过远程桌面服务迁移到受损的SugarCRM EC2实例，然后开始执行命令，从各个SugarCRM RDS数据库创建新的RDS快照。这些快照的创建不会导致原始RDS数据库的停机。

根据提供的信息，攻击者通过修改已经允许SSH入站流量的安全组规则，并为MySQL流量添加了端口3306。然后黑客开始进行数据外泄，从快照创建全新的数据库，将它们公开并附加修改后的安全组。最后修改了新创建的RDS数据库的主用户密码，以便能够登录到这些数据库中。

为了确定是否发生了数据外泄，在启用了虚拟私有云（Virtual Private Cloud，VPC）流日志的情况下，我们可以使用日志来查看有多少字节的数据离开了环境。对于没有启用VPC流日志的情况，我们在发现数据外泄方面有限。

EC2横向移动、执行

在攻击者完成RDS活动后，他们再次横向移动回到EC2服务并进行了一些更改。黑客首先创建了正在运行的SugarCRM EC2实例的新的Amazon Machine Images (AMIs)，然后使用第三方工具创建的公钥对已运行ImportKeyPair命令的导入公钥对。完成这些任务后，黑客会继续创建新的EC2实例，并将现有的安全组附加到EC2实例上，允许来自任意IP地址的入站22端口访问。

黑客在组织用于正常基础设施相同的区域中创建EC2实例。他们还切换到另一个新的地理区域，并创建了一个新的安全组，允许来自任意IP地址的22端口SSH流量。随后，黑客导入了另一个密钥对。由于黑客切换到了不同的区域，即使是相同的密钥对也必须重新导入。

设置完成后，他们创建了一个新的EC2实例，但这次他们使用了AWS Marketplace上提供的公共AMI。这个EC2实例的活动显示了所有地区启用安全服务(如GuardDuty)的重要性，以便对AWS账户中发生的一切有所了解。作为一种主动措施，组织还可以禁用未使用的区域。

提权Root

在这种攻击中，黑客并没有尝试创建新的IAM用户，而是选择尝试以Root用户身份登录。尽管他们利用了在发现阶段获取的组织通话的信息，但黑客仍然无法以Root用户身份登录。Root登录尝试会有较大的动静，所以在CloudTrail日志中很容易被察觉，如图6所示。

区域的持久性

除了尝试使用Root账号登录之外，黑客在持久性方面并没有做太多尝试。最明显的尝试是在不同的区域创建EC2实例，而不是在组织通中来托管其基础设施的区域。与Root登录尝试类似，这些新的EC2实例也在CloudTrail日志中会非常突出。然而，在审核控制台中的资源时可能会错过一些东西，因为随着云环境变得越来越大，切换区域并跟踪所有创建的资源是相当繁琐的工作。

防御规避

一旦黑客入侵AWS账户后，在账户所有者发现问题之前，他们有短暂的时间进行攻击。为了不被发现，黑客在非标准区域部署资源，并在一段时间内在环境中反复重启EC2实例。

黑客选择这样做可能有以下有几个原因：第一个是降低他们的知名度。在AWS控制台的EC2实例页面上，默认情况下仅显示运行EC2实例。除非用户主动尝试查看未运行的EC2实例，否则当黑客创建的新EC2实例被置于停止状态，它们将会被遗漏。

其次，停止这些资源还可以避免在组织账户中产生额外的费用。如果组织对费用设置了严格的通知机制，黑客停止他们创建的资源可以最大限度地降低成本，有助于防止触发成本警报，这也是他们逃避防御的另一种方式。

除了在不同区域创建资源和停止所创建的资源之外，黑客暂未尝试其他防御逃避技术，如停止CloudTrail日志记录或禁用GuardDuty。

补救

访问键

组织可以采取以下四个补救措施来保护自己免受此类攻击。首先，关注访问密钥的安全。保护访问密钥非常重要，因为我们经常看到它们成为AWS被入侵的根本原因。

在EC2实例上使用长期访问密钥没有任何好处。相反使用EC2角色和实例元数据服务（IMDS）中提供的临时凭证，还要确保只使用IMDSv2，这样它可以防止服务器端请求伪造（SSRF）攻击。

我们建议为存储在主机上凭据文件中的任何长期访问密钥都创建一个清理过程。这可以通过要求用户在完成工作后清理这些文件，或者通过创建一个组织级别的流程来自动清理这些文件。

我们还建议按计划定期轮换和删除访问密钥。访问密钥存在的时间越长，被攻击的风险就越大。定期轮换并删除未使用的密钥可以主动保护AWS账户。整个过程可以自动化，也有助于检查确保访问密钥的安全性。

Least-Privileged IAM Policies

最低特权IAM策略

这些威黑客能够完成他们在这些攻击中所做一切的唯一原因是组织在SugarCRM主机上给予IAM用户主体广泛权限。主机上的这些IAM用户确实需要一些AWS权限，但这些权限应该被严格限制到仅包括使用应用程序所需的准确权限。根据云安全威胁报告第6卷显示：这些组织并不少——99%的云用户、角色、服务和资源被授予了过多的权限，并且这些权限是闲置的。

可以使用AWS Access Analyzer来检查特定IAM主体对API的历史使用情况，并自动生成一个访问策略，限制其只能访问在您选择的时间段内使用过的API。

编写过于宽松的策略可能更容易，但为了更好地保护您的AWS帐户，编写狭窄范围的权限无疑是值得的。

监控 Root

另一个我们建议这些组织采取的纠正措施是对Root账户进行监控。Root账户应该仅用于执行需要Root权限的一些账户管理任务，这样它将此作为高保真警报来维护，其有助于保护最有价值的账户。我们还建议始终对Root启用多因素身份验证，并确保它受到长密码的保护。

记录和监控

我们建议这些组织采取的最后补救措施是确保他们配置了正确的日志记录。在所有区域内启用CloudTrail和GuardDuty，并将日志发送到一个集中的位置。

当涉及到GuardDuty时，警报应该发送给一个应急团队。在我们观察到已经启用了GuardDuty的组织中，GuardDuty在攻击的前期就成功地捕获到了这些访问密钥的漏洞，而这也是保护账户的最简单的办法。

我们还建议组织启用VPC流日志来帮助捕捉任何可能发生的数据泄漏。这些日志在排除网络连接时非常用。对于不同的服务，确保数据有一个良好的保留期非常重要。无论环境如何，任何地方都可能发生危害，确保日志保留足够长的时间以全面应对攻击至关重要。

结论

尽管黑客能够在这些攻击中完成很多任务，但我们看到组织可以采取一些有效的补救措施来更好地保护自己。由于访问密钥是最常见的初始攻击向量，尽可能避免使用长期访问密钥是明智的。在AWS中，这意味着使用EC2角色、IAM角色或Identity Center集成。保护这些密钥的另一层是设置监控异常使用情况。在这些攻击中，黑客执行了异常的API调用，这些都可以通过长尾日志分析检测出来。

此外，进行基本的最小特权分析非常重要，以确保在云内外运行的代码仅具有其所需的权限。

除了监控访问密钥外，始终确保对云账户进行异常活动监控也是至关重要的。在AWS中，这可以包括监控各种服务，如CloudTrail、VPC流日志和S3服务器访问日志。如果云帐户中的服务正通过异常端口被新的异常IP地址访问，您需要确保监控配置能够对此活动进行警报。此外，如果组织在S3存储桶中有敏感数据，则监控S3服务器访问日志以记录对存储桶的异常调用有助于主动发现攻击。

最后，黑客能够在这些情况中取得如此成果的原因之一是缺乏细粒度的权限。如果这些属于IAM用户的被破坏的访问密钥具有较少的权限，那么就可以阻止黑客的踪迹。

Iocs

IPs:

• 13.90.77.93 ZoomEye搜索结果
• 31.132.2.66 ZoomEye搜索结果

User Agents:

• Boto3/1.26.45 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 Botocore/1.29.45

• Boto3/1.7.61 Python/3.5.0 Windows/ Botocore/1.10.62

• aws-cli/1.19.1 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 botocore/1.29.58

• aws-cli/1.18.69 Python/3.5.2 Linux/4.4.0-1128-aws botocore/1.16.19

• Scout Suite/5.12.0 Python/3.9.2 Linux/6.0.0-2parrot1-amd64 Scout Suite/5.12.0

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/3006/