对SugarCRM零日漏洞（CVE-2023-22952）的防御

SugarCRM 零日身份验证绕过和远程代码执行漏洞（CVE-2023-22952）像是一个典型的漏洞。因为它是一个web应用程序，如果没有正确配置或保护，幕后的基础设施可以允许攻击者增加其影响。当攻击者了解云服务提供商使用的底层技术时，如果他们能够获得对具有正确权限的凭证的访问权限，就可以进行大量的操作。

在过去的一年中，Unit 42发现SugarCRM漏洞CVE-2023-22952是一个初始攻击向量，允许攻击者访问AWS账户。这不是由于AWS中的漏洞造成的，它可能发生在任何云环境中。初始攻击后，攻击者利用错误的配置扩大了他们的访问权限。

本文根据MITRE ATT&CK Matrix框架列出了针对AWS环境的各种攻击，并总结了组织可以设置的多种预防机制来保护自己。其中一些保护措施包括利用AWS提供的控制和服务、云最佳实践，以及确保足够的数据保留以应对全面攻击。

这些攻击的复杂性表明，设置日志记录和监控以检测任何未经授权的AWS API调用是多么重要，即使它们看起来无害。如果允许攻击者获得一个攻击立足点，这可能导致更可怕的活动，而这些活动并不总是可追踪的。

MITRE ATT&CK Matrix

MITRE ATT&CK Matrix由14种不同的策略组成，这些策略描述了网络安全攻击的不同组成部分。

初始访问：CVE-2023-22952

这些AWS账户泄露的最初攻击载体是零日SugarCRM漏洞CVE-2023-22952。Sugar是一个价格合理并且容易使用的企业级CRM，Sugar的设计初衷是为了帮助您的企业于千载客户沟通，共享销售信息，促成交易以及保持客户开心。

CVE-2023-22952由NIST国家漏洞数据库于2023年1月11日发布，得分为8.8。由于缺少输入验证，此漏洞允许攻击者通过SugarCRM电子邮件模板模块注入自定义PHP代码。

要理解攻击者为什么针对SugarCRM进行这些攻击，了解SugarCRM客户数据库中存在大量敏感数据（如电子邮件地址、联系信息和帐户信息）是很有帮助的。如果它被泄露，攻击者要么选择直接出售这些信息，要么勒索受害者以获得更多经济利益。

通过利用SugarCRM中的此漏洞，攻击者可以通过该漏洞的远程执行组件直接访问运行此应用程序的底层服务器。在发现的示例中，这些服务器是Amazon Elastic Cloud Compute (EC2)实例，主机上存储有长期的AWS访问密钥，允许攻击者扩展其访问权限。由于这些组织将其基础设施托管在云中，因此与本地托管相比，它为攻击者提供了不同的攻击载体。

凭证访问

一旦攻击者获得了对EC2实例的访问权限，他们就成功地盗取了主机上存在的长期AWS访问密钥。无论计算机是位于本地还是云中，如果用户使用AWS命令行界面（CLI），他们都可以选择将用于身份验证的临时或永久凭证存储在存储在主机上的凭证文件中，具体如下图所示，其中包括文件路径。

在我们观察到的情况下，这些明文凭证存在于受攻击的主机上，这允许攻击者窃取它们并开始使用访问密钥开始攻击活动。

凭证文件位置的文件路径

发现过程

在攻击者执行任何扫描活动之前，他们首先运行命令GetCallerIdentity。GetCallerIdentity是AWS版本的whoami。它返回关于执行调用目标的各种信息，例如与用于签署请求的凭证相关联的

的用户ID、帐户和Amazon Resource Name (ARN)，如下图所示。用户ID是执行调用的实体的唯一标识符，帐户是凭证所属的AWS帐户的唯一12位标识符，ARN包括执行调用的目标帐户ID和人类可读的名称。

GetCallerIdentity响应

一旦攻击者窃取了足够多的凭证，他们就开始了扫描活动。他们利用Pacu和Scout Suite工具来更好地了解AWS账户中存在哪些资源。Pacu是一个开源的AWS开发框架，它被设计成云中的Metasploit。Scout Suite是一个用于云环境安全状态评估的安全审计工具。

根据检测结果，Pacu已经存在于主机上。虽然Scout Suite并不是我们看到下载到受感染的EC2实例上的工具，但我们知道它是基于与攻击者活动相关的用户代理使用的。这两种工具都为攻击者提供了大量信息，以了解他们所破坏的AWS账户的情况。

在本文的示例中，这些工具扫描了各种传统服务，例如：

EC2
IAM
RDS
S3
SNS
SES
Lambda

攻击者还对服务(例如Organizations服务和Cost and Usage服务)执行其他发现调用，这些服务不一定会为攻击者提供有用的信息。

AWS组织为公司提供了一个集中的场所来管理多个AWS帐户和资源。在查看CloudTrail日志中的攻击者活动时，有三个组织API调用非常突出。第一个调用是ListOrganizationalUnitsForParent，它列出了所有的组织单元(OU)。

这样，攻击者就可以运行ListAccounts，它返回与每个ou关联的所有帐户id，并向攻击者提供最有用信息的最后一个调用是descripbeorganization API调用。此事件返回主帐户ID以及与该帐户关联的主帐户电子邮件地址。有了这些信息，攻击者就有足够的能力尝试以Root用户的身份登录目标帐户。最后一个感兴趣的发现调用涉及成本和使用服务。如下图所示，攻击者执行各种GetCostandUsage调用，响应返回关于受攻击帐户中的一般成本的信息。

防御者需要意识到，攻击者可以通过了解云帐户内的成本来确定帐户的活跃程度。如果一个帐户的总成本很大，他们可能更容易在不被发现的情况下增加新资源，因为成本可能不会突出。

另一方面，如果帐户中的支出很少，一些新资源可能会更加突出。支出较少的帐户所有者可能也有更严格的成本通知，这可能会在攻击者创建新资源时触发警报。

GetCostandUsage请求参数示例

GetCostandUsage响应示例

通过使用这些看似无害的API调用，攻击者获得了大量关于账户结构和使用情况的信息，而无需执行大量可能触发警报的可疑活动。

横向移动、执行、渗透

在我们观察到的事件中，一旦攻击者完成了对环境的扫描，他们就有足够的信息来缩小他们的活动范围，从发现整个帐户到对从关系数据库服务(RDS)开始的各种服务采取行动。攻击者从受攻击的SugarCRM EC2实例横向移动到RDS服务，并开始执行命令，从各种SugarCRM RDS数据库创建新的RDS快照。创建这些快照不会导致原始RDS数据库停机。

这样，攻击者就修改了已经允许SSH入站的预先存在的安全组规则，并为MySQL流量添加了端口3306。然后，攻击者开始进行渗透，从快照中创建全新的数据库，将其公开，并附加修改后的安全组。最后，他们通过更改主用户密码修改了新创建的RDS数据库，这将允许他们登录数据库。

为了了解是否发生了任何数据泄露，在启用了虚拟私有云(VPC)流日志的情况下，我们可以使用日志查看有多少字节的数据离开了环境。在没有启用VPC流日志的情况下，我们发现的数据泄露受到限制。

横向移动/执行

在RDS活动之后，攻击者再次横向移动回EC2服务并进行了一些更改。攻击者做的第一件事是从正在运行的SugarCRM EC2实例中创建新的Amazon Machine Images（AMI），然后从那里运行ImportKeyPair命令导入他们使用第三方工具创建的公钥对。完成这些任务后，攻击者继续创建新的EC2实例。攻击者还将现有的安全组附加到允许从任何IP地址访问入站端口22的EC2实例，如下图所示。

允许端口22访问的安全组示例

攻击者在组织用于其正常基础设施的其余部分的相同区域中创建了EC2实例。他们还将区域切换到地理上的新区域，并创建了一个新的安全组，允许来自任何IP地址的端口22 SSH流量。然后，攻击者导入另一个密钥对。由于攻击者切换到不同的区域，即使密钥对与其他区域使用的密钥对相同，也必须重新导入该密钥对。

完成设置后，攻击者们创建了一个新的EC2实例，但这次他们使用了AWS Marketplace上的公共AMI。此EC2实例活动显示了在所有区域启用GuardDuty等安全服务的重要性，以便能够查看AWS帐户内发生的所有事情。为了增加主动防御，组织也可以禁用未使用的区域。

权限升级

对于这些攻击的权限升级部分，攻击者并没有像我们在其他情况下看到的那样试图创建新的IAM用户。相反，他们选择尝试以Root用户身份登录。尽管使用了他们在发现阶段从组织调用中获得的信息，攻击者仍然未能成功地以Root用户登录。Root登录尝试非常嘈杂，因此这些失败的Root登录在CloudTrail日志中非常突出，如下图所示。

从CloudTrail日志中查看Root登录失败

持久性

除了尝试使用Root帐户登录之外，攻击者并没有尝试太多持久性。最明显的持久性尝试是在不同的区域创建EC2实例，而不是通常用于托管其基础设施的组织。与Root登录尝试类似，这些新的EC2实例在CloudTrail日志中很突出。然而，在检查控制台中的资源时很容易遗漏一些内容，因为随着云环境变得更大，切换区域和跟踪所有创建的资源非常耗时。

逃避检测

一旦攻击者攻击了AWS账户，在账户所有者发现问题之前，他们只有有限的时间来逃避。为了不被发现，攻击者在非标准地区部署了资源。但是，他们还在环境中打开和关闭了EC2实例。

攻击者这样做有几个原因。第一个原因是降低他们的可见度。在AWS控制台中EC2实例页面上，它默认只显示正在运行的EC2实例。除非用户积极地尝试查看未运行的EC2实例，否则，一旦将攻击者创建的新EC2实例处于停止状态，用户就不可能检测到他们。

第二个原因是，停止这些资源也可以避免在组织帐户中产生额外的成本。如果组织对成本有严格的通知，攻击者停止他们创建的资源可以最大限度地降低成本，并有助于防止触发成本警报，这是他们逃避检测的另一种方式。除了在不同区域创建资源并停止他们创建的资源外，攻击者没有尝试其他防御规避技术，例如停止CloudTrail日志记录或禁用GuardDuty。

通过访问密钥进行缓解

组织可以采取四种主要的补救措施来保护自己在未来免受这类型的攻击。第一个是关于访问密钥的，对于组织来说，保护他们的访问密钥是至关重要的，因为我们经常看到它们是AWS被攻击的根本原因。

在EC2实例上使用长期访问密钥从来都不是一个好的理由。相反，应该使用实例元数据服务(IMDS)中的EC2角色和临时凭证。另外，请确保只使用IMDSv2，它可以防止服务器端请求伪造(SSRF)攻击。

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

我们还建议定期轮换和删除访问密钥。访问密钥的寿命越长，它被泄露的可能性就越大。持续地轮换它们并主动删除未使用的密钥可以保护AWS帐户。整个过程可以自动化，并有助于检查访问密钥的安全性。

最低权限IAM策略

攻击者能够完成攻击唯一原因是，组织在SugarCRM主机上给予IAM用户主体广泛的权限。这些主机上的IAM用户需要一些AWS权限，但是这些权限应该被限定得很窄，只包括使用这些权限的应用程序所需要的权限。这些组织并不是唯一遇到这种情况的组织，99%的云用户、角色、服务和资源被授予了过多的权限，而这些权限没有被使用。

建议组织可以使用AWS Access Analyzer检查特定IAM主体对API的历史使用情况，并自动生成访问策略，将其访问权限限制为仅在你选择的时间段内使用过的API。

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

通过监控Root进行缓解

还有一个预防措施是围绕Root帐户设置监控，此帐户应该只用于需要Root的几个帐户管理任务的环境中，并进行精心维护。我们还建议始终在Root上启用多因素身份验证，并确保使用长密码对其进行保护。

日志记录和监控

最后一项防御措施是确保它们配置了正确的日志记录。CloudTrail和GuardDuty都应该在所有区域中启用，并将日志发送到集中位置。

当涉及到GuardDuty时，攻击警报应该被发送到一个团队，该团队将根据警报的严重性做出响应。在本文的示例中，组织启用了GuardDuty，我们看到GuardDuty在攻击的早期就发现了这些访问密钥泄露。

我们还建议组织启用VPC流量日志，以帮助捕获可能发生的任何数据泄露。这些日志在解决网络连接问题时非常有用。对于所有这些不同的服务，确保保留好操作记录是很重要的。无论环境如何，任何地方都可能发生攻击，确保日志保留足够长的时间对于捕获完整的攻击至关重要。

总结

尽管攻击者能够在这些攻击中完成很多任务，但我们发现组织可以采取一些很好的补救措施来更好地保护自己。由于访问密钥是最常见的初始攻击向量，因此尽可能避免使用长期访问密钥。在AWS中，这意味着为开发人员工作站使用EC2角色、IAM Roles Anywhere或Identity Center集成。保护这些密钥的另一个方式是设置异常使用监控。对于这些攻击，攻击者执行异常API调用，这些调用都可以通过日志分析检测到。

还必须进行基本的最低权限分析，以便在云内部或外部运行的代码只具有完成其工作所需的权限。

除了监控访问密钥外，还需要确保监控云帐户的异常活动。在AWS中，这看起来像是监控各种服务，如CloudTrail、VPC流程日志和S3服务器访问日志。如果你的云帐户中的服务正在通过异常端口访问新的和不寻常的IP地址，则需要确保监控配置可以发出警报。此外，如果组织在S3桶中有敏感数据，则监控S3服务器访问日志以记录对存储桶的异常调用有助于主动发现攻击。