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

引言

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

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

我们特别包括：

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

不要期待新的突破性攻击技术。阅读本文时请自问：我的云安全控制措施是否覆盖了这些基础？本文强烈聚焦于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万客户的敏感文档（身份证和其他KYC数据）泄露。

漏洞

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

• Glassdoor员工在公开可访问的GitHub存储库中泄露了AWS IAM用户访问密钥。该访问密钥具有访问“与大数据相关的特定AWS账户”的权限——这并不特别令人放心。
• BeVigil的研究人员发现40个高度流行的Android应用程序（有些安装量远超100万）打包了静态AWS访问密钥。任何人都可以通过下载和解压APK访问它们。使用这些密钥，研究人员能够访问S3中的敏感用户数据、源代码、包含数据库凭证的备份等。
• 错误配置的Apache Airflow实例在无身份验证的情况下暴露在互联网上，泄露了AWS凭证。
• SEGA Europe不安全地存储了多组静态AWS凭证，以及MailChimp和Steam API密钥。这些凭证可通过公共S3存储桶访问，本可让攻击者入侵可信的SEGA域和云基础设施。

恶意软件

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

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

似乎TeamTNT是唯一公开讨论的积极针对AWS凭证的威胁行为者。截至2021年12月，我不知道还有其他知名行为者。MITRE ATT&CK也不知道。

公共S3存储桶

您知道这会来。我编译了以下2021年涉及错误配置S3存储桶的公开披露数据泄露的非详尽列表。再次强调，它仅包括2021年公开披露的数据泄露。我们可以合理想象还有更多。

我还发现GSI Immobilier（一家法国房地产机构）的开放Azure Blob存储桶参考，泄露了约1000客户的PII。

通过SSRF漏洞窃取实例凭证

四年半前，我写了一篇博客文章，题为“利用SSRF漏洞滥用AWS元数据服务”——甚至在我开始从事安全工作之前。不幸的是，利用SSRF漏洞访问AWS元数据服务仍然存在，主要由于不安全的默认设置和AWS缺乏沟通。为什么在即将到来的2022年，新启动的实例仍然默认使用不安全的实例元数据服务版本？（IMDSv1）

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

• Evernote中的SSRF允许攻击者窃取临时AWS凭证
• StreamLabs Cloudot（Logitech旗下）中的SSRF，具有类似影响
• Slack中利用TURN代理的漏洞，具有类似影响
• Positive Security的研究人员在Microsoft Teams中发现SSRF，允许他们访问Azure实例元数据服务
• 2020年末——Google产品本身的SSRF，可用于调用GCP元数据服务器

这也是我们首次看到威胁行为者TeamTNT在入侵机器后通过实例元数据服务窃取临时凭证。这可能表明攻击者的自动化程度提高，因为窃取的凭证仅在几小时内有效。

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

现在，我们知道哪里出了问题。让我们看看如何改善，并修复这些泄露和漏洞的根本原因。

摆脱静态长期凭证

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

对于人类用户

通过AWS SSO（免费）或账户内的IAM角色联合验证人类用户身份。人类没有理由使用IAM用户。IAM用户不仅糟糕在于它们有静态长期凭证，还在于它们未链接到集中身份提供商。我建议使用组织范围的服务控制策略阻止IAM用户的创建。如果确实需要IAM用户，请确保只有有限的人员可以创建它们，最好在专用AWS账户中。根据我的经验，许多不熟悉AWS的人创建IAM用户时错误地认为需要在本地开发机器上使用CLI或AWS SDK。

请注意，AWS SSO完全支持AWS CLI、AWS SDK和aws-vault。说到这个：使用aws-vault，它确保始终加密磁盘上的凭证。

对于应用程序

访问AWS服务的应用程序理想情况下应在AWS中运行。在这种情况下，使用原生AWS构造为它们提供具有正确权限和临时凭证的身份：EC2实例角色、Lambda执行角色、EKS IAM服务账户角色。

在某些情况下，访问AWS的应用程序不在AWS中运行。在这种情况下，像Hashicorp Vault这样的工具很好，如果您的应用程序有其他方式将其身份引导到Vault。例如，Vault可以轻松验证在Kubernetes中运行的应用程序，并动态生成临时AWS凭证。如果您的应用程序在AWS外部运行，并且在未提供可验证“工作负载身份”的平台上运行，则必须使用静态凭证向Vault进行身份验证，这只会转移问题。但至少，它允许您将所有AWS凭证集中在Vault中，并确保您的应用程序仅使用临时AWS凭证。

请注意，您也可以为人类利用Vault。例如，它非常适合将Okta/AD组映射到AWS角色。

对于SaaS解决方案

许多SaaS解决方案与您的AWS账户集成。这些不应持有静态AWS凭证。相反，您应创建专用的IAM角色，它们可以从自己的AWS账户中担任，使用随机生成且保密的ExternalID以避免混淆代理问题。

请参阅AWS指南和Praetorian的这项伟大研究。一个很好的例子是Datadog如何与其客户的AWS账户集成。

扫描不应存在的凭证

存在多种解决方案来扫描源代码中的秘密，本地（例如在预提交钩子中）或在CI/CD中。流行的开源和免费解决方案有detect-secrets、gitleaks和truffleHog。GitGuardian的ggshield对最多25用户免费。

根据我的经验，静态凭证最终出现在Docker镜像中也容易被忽视。以下是一个Dockerfile示例，乍一看（至少对我而言）看起来无害，但在镜像层中泄露了访问密钥：

1
2
3
4
5

FROM amazon/aws-cli:2.4.6
ARG AWS_ACCESS_KEY_ID
ARG AWS_SECRET_ACCESS_KEY
RUN aws s3 cp s3://my-app/artifact.jar /app.jar
CMD ["java", "-jar", "/app.jar"]

示例Dockerfile在镜像层中泄露AWS凭证。在这种情况下，应使用多阶段构建将应用程序工件复制到第二阶段构建。

然而有趣的是，唯一支持扫描Docker镜像中秘密的开源容器扫描工具似乎是DeepFence的SecretScanner。多个VCS产品现在附带秘密扫描，包括Gitlab（免费）和GitHub（对公共存储库免费）。GitGuardian也支持扫描Docker镜像中的秘密。它效果很好，并有大量VCS和CI/CD集成。另外，它是一家法国公司！

GitGuardian识别Docker镜像层中的AWS凭证。它甚至针对AWS验证凭证，以减少误报。

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

有许多资源可用于保护S3存储桶。尽管如此，我想在下面编译一些您应采取的行动来保护S3存储桶，以及如果您在S3中存储特别敏感的数据，还有一些更高级的强化技巧。

循序渐进

让我们从基础开始。

• 您无法防御看不见的东西。首先清点您的AWS账户，包括工程师用个人信用卡注册的账户。
• 如果使用基础设施即代码，使用工具在进入生产环境前扫描您的基础设施代码是否存在错误配置。
• 开启账户范围的S3公共访问阻止。这将确保您不会错误地使S3存储桶公开。同时：将其作为AWS账户配置过程的一部分，并使用SCP保护s3:PutAccountPublicAccessBlock，以确保无人可以更改它。您仍然可以通过CloudFront分发使S3存储桶公开。但“通过显式创建新的CloudFront分发错误地使S3存储桶公开”似乎具有挑战性。
• 在运行时扫描您的AWS环境以识别错误配置的S3存储桶。您可以使用开源工具如Prowler、ScoutSuite或CloudMapper。市场上也存在许多“云安全态势管理”产品。

在值得时强化

然后，让我们看看潜在的强化措施。

• 如果您的S3存储桶仅需要从特定VPC或子网访问，您可以使用存储桶策略Deny语句中的aws:SourceVpce和aws:SourceVpc条件键确保只能从那里访问。
• 使用客户管理的KMS密钥加密S3存储桶。当您这样做时，访问存储桶的应用程序和用户需要额外、明确的权限才能使用KMS密钥进行加密和解密。换句话说：使用客户管理的KMS密钥加密的公共S3存储桶不是公共的，这是一个有价值的额外安全层。
• 开启S3数据事件。默认情况下，CloudTrail不记录s3:GetObject、s3:PutObject及类似操作。在敏感的低流量存储桶中，启用这些事件是个好主意。您可以启用读取事件、写入事件或两者。例如，由一组内部EC2实例用于备份的S3存储桶不应生成许多读取请求；然而，记录谁和什么访问了您的备份绝对有价值。
• 了解谁可以访问您的存储桶。PMapper对此非常有用；它不仅告诉您谁可以直接访问您的存储桶，还绘制了您账户中信任关系的完整图。例如，直接询问PMapper“谁可以对my-aws-cloudtrail-logs/*执行s3:GetObject”显示以下主体可以读取存储桶：
  • 管理员用户christophe
  • EC2实例角色DB_InstanceRole
  • 但还有用户dany，他有权在具有此角色的EC2实例上运行命令

保护实例元数据服务

2019年7月，Capital One遭受了众所周知的泄露。攻击者利用了SSRF漏洞，并用其窃取具有特权角色的EC2实例的凭证。几个月后，AWS发布了IMDSv2，这是实例元数据服务的新版本，使其更难被利用。

然而，AWS选择保持不安全的默认设置，因此您必须明确强制执行。最好的方法是使用组织范围的SCP要求使用IMDSv2。在使用自动缩放等功能时，请确保启动模板配置为启用它。无论如何，请查看metabadger和Latacora团队整理的精彩博客文章。

如果您使用AWS EKS，还应阻止出口Pod流量到实例元数据服务，并改用“IAM Roles for Service Accounts”功能。

最后，请注意GuardDuty有两种发现类型标志实例凭证在AWS外部或另一个AWS账户中的使用。

结论

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

2022年很可能还会看到由类似弱点引起的数据泄露。我们可能会看到恶意软件作者和威胁行为者采用与TeamTNT类似的技术，将云特定逻辑添加到他们的武器库中。攻击者可能还会开始使用更高级的持久化技术——到目前为止，我们几乎看不到比创建IAM用户或恶意AMI更高级的东西。

感谢阅读，让我们在Hacker News或Twitter上继续讨论！

参考和致谢

感谢Rami McCarthy的彻底审查。他积极帮助改进了这篇博客文章，他精彩的演讲“从AWS客户安全事件中学习”在我的AWS安全旅程中给了我启发。不要错过他在DEFCON29 Cloud Village的精彩Cloud Security Orienteering文章和演讲。

我还喜欢推荐以下优秀资源：

• Scott Piper的“AWS安全成熟度路线图”，11页充满可操作的见解。
• fwd:cloudsec 2021上许多关于云安全的精彩演讲！
• “Hacking the Cloud”，Nick Frichette的云安全TTP百科全书。
• “CloudSecDocs”和“CloudSecList”，由Marco Lancini编写
• “tl;dr sec”，由Clint Gibler编写
• “How to 10X Your Security”，由同一位Clint Gibler编写。这是我读过（并重读，再重读）的最有见地的幻灯片之一。虽然关于AppSec，但它也非常适用于云安全。

更新

• 2021-12-31 – 添加了SEGA Europe泄露的参考。
• 2021-12-31 – 删除了报告SEGA Europe泄露的“VPNOverview”网站的直接链接。我认为他们暂时污损网站越界了，不想为他们的SEO做贡献。
• 2022-01-05 – 添加了ONUS泄露的参考
• 2022-01-05 – 添加了Positive Security发现的Teams中SSRF的参考
• 2022-01-06 – 删除了ONUS泄露的参考，因为深入分析显示泄露不是由于公共S3存储桶，而是由于通过Log4shell入侵的应用程序的受损凭证。
• 2022-01-06 – 添加了D.W. Morgan泄露（公共S3存储桶）的参考
• 2022-01-06 – 添加了GSI Immobilier泄露（公共Azure Blob存储）的参考
• 2022-03-14 – 添加了新GuardDuty发现InstanceCredentialExfiltration.InsideAWS的参考