云安全漏洞与数据泄露：2021年回顾

引言

关于云安全事件的实际数据十分稀缺，且往往缺乏攻击者所用战术、技术和程序的详细信息。受攻击组织通常不会公开披露具体细节。现有数据存在幸存者偏差；我们只了解被检测到的攻击，而非那些未被发现的隐蔽入侵。

在本文中，我们将分析2021年公开披露的云安全事件和漏洞。我们将重点关注与云服务提供商使用相关的案例，而不涉及云服务提供商自身的漏洞。Scott Piper在其存储库"csp_security_mistakes"中对此做了出色工作。

我们特别包括：

• 受影响公司自身报告的事件
• 有充分证据的第三方记录的事件
• 公共漏洞赏金计划中披露的漏洞
• 恶意软件在云环境中使用的TTPs

不要期待新的突破性攻击技术。阅读本文时请自问：我的云安全控制措施是否覆盖了这些基础问题？本文主要关注AWS，因为涉及其他云提供商的事件数据更少。

免责声明：我目前受雇于Datadog，该公司也是一家云安全供应商。这不是企业赞助的帖子。

2021年趋势

静态凭证仍是主要初始访问向量

不出所料，许多攻击始于静态、长期有效的凭证泄露。长期凭证对安全从业者来说是噩梦，因为它们最终会泄露在日志文件、监控工具、构建日志、堆栈跟踪中…假设您的组织有10个静态凭证，每个每天有0.01%的泄露风险，那么在2年内至少有一个泄露的概率为52%！

数据泄露

以下是因静态长期凭证导致组织实际数据泄露的几个案例：

• Codecov发布了一个公共Docker镜像，其中一个层包含GCP服务账户的静态凭证。攻击者使用这些凭证替换了托管在Google Cloud Storage中的Codecov安装脚本，用恶意脚本窃取环境变量并将其发送到恶意服务器。
• 攻击者入侵了Juspay的"未回收访问密钥"，并用其转储了3500万"掩码卡数据和卡指纹"以及未公开数量的用户个人信息。
• Kaspersky与第三方承包商共享了静态AWS SES令牌。攻击者入侵了该令牌，并使用SES发送针对Office365凭证的网络钓鱼邮件。由于邮件是通过真实的Kaspersky电子邮件基础设施发送的，网络钓鱼能够来自合法的Kaspersky自有域。
• 据称被入侵的访问密钥被用于访问Upstox和MobiKwik的私有S3存储桶中的数据，导致350万客户的敏感文档泄露。

漏洞

我们还了解到几起放置不当、易受攻击的静态凭证事件。虽然没有证据证实它们导致了实际的数据泄露，但问题是相同的。

• Glassdoor员工在公开可访问的GitHub存储库中泄露了AWS IAM用户访问密钥。
• BeVigil的研究人员发现40个高度流行的Android应用程序打包了静态AWS访问密钥。
• 配置错误的Apache Airflow实例在无身份验证的情况下暴露在互联网上，泄露了AWS凭证。
• SEGA Europe不安全地存储了多组静态AWS凭证以及MailChimp和Steam API密钥。

恶意软件

恶意软件窃取AWS凭证的首个公开报告可追溯到2020年8月，归因于TeamTNT组织。它会将.aws/credentials的内容发送到恶意服务器。截至2021年，我们有证据表明TeamTNT现在也针对静态GCP和Docker凭证。

最近，我们看到攻击者利用Log4Shell漏洞通过远程代码执行和DNS外泄从环境变量中窃取AWS凭证。

公共S3存储桶

以下是2021年涉及配置错误S3存储桶的公开披露数据泄露的不完整列表：

通过SSRF漏洞窃取实例凭证

四年前半前，我写了一篇题为"使用SSRF漏洞滥用AWS元数据服务"的博客文章。不幸的是，使用SSRF漏洞访问AWS元数据服务仍然存在，主要由于不安全的默认设置和AWS缺乏沟通。

虽然没有2021年利用此技术的安全事件说明，但几个披露的漏洞赏金报告证实这仍然存在：

• Evernote中的SSRF允许攻击者窃取临时AWS凭证
• StreamLabs Cloudot中的SSRF具有类似影响
• Slack中利用TURN代理的漏洞具有类似影响
• Positive Security的研究人员在Microsoft Teams中发现SSRF

这也是我们首次看到威胁行为者TeamTNT在入侵机器后通过实例元数据服务窃取临时凭证。

预防和检测这些常见错误配置

消除静态长期凭证

以下建议通常归结为：除非别无选择，否则不要使用IAM用户。

对于人类用户 通过AWS SSO或账户内的IAM角色联合验证人类用户身份。没有理由让人类使用IAM用户。

对于应用程序 访问AWS服务的应用程序理想情况下应在AWS中运行。在这种情况下，使用原生AWS构造为它们提供具有适当权限和临时凭证的身份。

对于SaaS解决方案 许多SaaS解决方案与您的AWS账户集成。这些不应持有静态AWS凭证。相反，您应创建专用的IAM角色，它们可以从自己的AWS账户中担任。

扫描不应存在的凭证

存在多种解决方案可扫描源代码中的秘密。流行的开源和免费解决方案包括detect-secrets、gitleaks和truffleHog。

一劳永逸地避免配置错误的S3存储桶

基础步骤

• 建立AWS账户清单
• 使用工具扫描基础设施代码中的错误配置
• 开启账户范围的S3公共访问阻止
• 在运行时扫描AWS环境以识别配置错误的S3存储桶

强化措施

• 使用条件密钥限制S3存储桶访问
• 使用客户管理的KMS密钥加密S3存储桶
• 开启S3数据事件
• 使用PMapper了解谁可以访问您的存储桶

保护实例元数据服务

2019年7月，Capital One遭受了众所周知的泄露。攻击者利用了SSRF漏洞，并用其窃取具有特权角色的EC2实例的凭证。几个月后，AWS发布了IMDSv2。

保护实例元数据服务的最佳方法是使用组织范围的SCP来要求使用IMDSv2。

结论

虽然2021年在许多方面都是不寻常的一年，但我们不能说攻击者入侵云环境的技术也是如此。一些愤世嫉俗者甚至可能认为它们很无聊。对我来说，这重申了做好基础工作的必要性，以及实用安全、防护栏和安全默认设置的重要性。

2022年很可能会看到由类似弱点引起的数据泄露。我们可能会看到恶意软件作者和威胁行为者采用与TeamTNT类似的技术，将云特定逻辑添加到他们的武器库中。