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

随着2021年渐行渐远，我们回顾今年公开披露的云数据泄露和漏洞事件。
最后更新：2022年3月14日。

引言

关于云安全事件的公开数据稀缺，且往往缺乏攻击者使用的战术、技术和程序（TTP）细节。受影响的组织通常不会公开披露具体信息。可用数据存在生存偏差；我们了解的是被检测到的攻击，而非未被发现的潜在高级入侵。

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

我们特别包括以下内容：

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

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

免责声明：我目前受雇于Datadog，该公司也是一家云安全供应商。本文非公司或赞助内容。

2021年趋势

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

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

数据泄露

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

Codecov发布了一个公共Docker镜像，其中一层包含GCP服务账户的静态凭证（来源）。攻击者使用这些凭证替换了托管在Google Cloud Storage中的Codecov安装脚本，改为恶意脚本窃取环境变量并发送到恶意服务器（来源）。

Codecov攻击者在托管于GCS存储桶的安装脚本中添加了恶意命令。
攻击者窃取了Juspay的“未回收访问密钥”，并用其转储了3500万条“掩码卡数据和卡指纹”以及未披露数量的用户个人信息（来源）。
Kaspersky与第三方承包商共享了一个静态AWS SES令牌。攻击者窃取该令牌，并使用SES发送针对Office365凭证的网络钓鱼邮件。由于邮件使用真实的Kaspersky邮件基础设施发送，网络钓鱼能够从合法的Kaspersky拥有域发出（来源）。

使用Kaspersky的AWS SES发送的示例网络钓鱼邮件。
据称，被窃取的访问密钥用于访问Upstox和MobiKwik的私有S3存储桶中的数据（来源，来源），导致350万客户的敏感文档（身份证和其他KYC数据）泄露。我写“据称”是因为存在争议；安全研究员Rajshekhar Rajaharia称泄露是由于两次事件中使用的访问密钥被窃取，而Upstox的CEO称泄露是由于“第三方数据仓库系统”。当然，两者可能都成立。

漏洞

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

Glassdoor员工在公开可访问的GitHub存储库中泄露了AWS IAM用户访问密钥。该访问密钥具有访问“与大数据相关的特定AWS账户”的权限——这并不特别令人安心（HackerOne #801531）。
BeVigil的研究人员识别出40个高度流行的Android应用程序（部分安装量超过100万）打包了静态AWS访问密钥（来源）。任何人都可以通过下载并解压APK访问它们。使用这些密钥，研究人员能够访问S3中的敏感用户数据、源代码、包含数据库凭证的备份等。

打包AWS凭证的流行Android应用程序。图片来自BeVigil。
配置错误的Apache Airflow实例未经身份验证暴露在互联网上，泄露AWS凭证（来源）。

暴露的Apache Airflow实例向未经身份验证的攻击者泄露AWS凭证。图片来自Intezer。
SEGA Europe不安全地存储了多组静态AWS凭证，以及MailChimp和Steam API密钥。这些凭证可通过公共S3存储桶访问，本可让攻击者入侵受信任的SEGA域（如sega.com）和云基础设施。更具体地说，AWS凭证允许访问数十个S3存储桶、CloudFront分发、EC2实例和SNS主题（来源：https://vpnoverview[.]com/news/sega-europe-security-report/，HN讨论）。

攻击者在窃取公开可访问的静态AWS凭证后可以访问的示例SNS主题。

恶意软件

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

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

似乎TeamTNT是唯一公开讨论的积极针对AWS凭证的威胁行为者。截至2021年12月，我不知道任何其他知名行为者。MITRE ATT&CK也不知道（见此Google搜索）。很可能会有更多出现，因为AWS凭证在入侵机器后可能是高价值低挂果实。

公共S3存储桶

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

公司	描述	泄露数据	受影响数据主体数量
Hobby Lobby	美国手工艺品商店	姓名、电子邮件、物理地址、公司应用程序源代码	> 30万
Decathlon Spain	法国体育用品零售商	姓名、电子邮件、电话号码、身份验证令牌	> 7.8万
86 US cities	使用“PeopleGIS”服务的美国城市	税务报告、护照副本等	未披露
Pixlr	在线照片编辑工具	电子邮件、哈希密码、国家	190万
Acquirely	澳大利亚营销公司	姓名、电子邮件、出生日期、物理地址、电话号码	> 20万
MobiKwik	印度数字支付提供商	KYC数据（包括护照副本）、交易日志、电子邮件地址、电话号码	350万（KYC数据）约1亿（其余）
Senior Advisor	老年护理服务比较器	姓名、电子邮件、电话号码	> 300万
TeamResourcing	招聘公司（前身为“TeamBMS”和“FastTrack Reflex Recruitment”）	简历、护照副本、姓名、电子邮件、物理地址	> 2万
İnova Yönetim	律师事务所	法庭案件及相关PII	> 1.5万（1.5万法庭案件）
Cosmolog Kozmetik	美容产品公司	姓名、物理地址、购买物品	> 57.6万
Premier Diagnostics	COVID-19检测公司	护照/身份证副本、姓名、出生日期	5.2万
PaleoHacks	原始饮食应用	姓名、电子邮件、哈希密码、出生日期、雇主	7万
Phlebotomy Training Specialists	医疗培训公司	姓名、出生日期、图片、物理地址、身份证、简历、文凭、电话号码	2.7万至5万之间
CallX	电话营销公司	聊天记录、姓名、物理地址、电话号码	1万至10万之间
Prisma Promotora	企业软件提供商	姓名、电子邮件、出生日期、背景调查、物理地址、身份证、借记卡信息	> 1万
Sennheiser	音频硬件制造商	姓名、物理地址、电话号码	> 2.8万
Fleek	已停业的Snapchat替代品	应用用户共享的图片	未披露
Ghana’s National Service Scheme	加纳公共组织	身份证、就业记录	> 10万
BabyChakra	怀孕和育儿平台	儿童图片、医疗检测结果、医疗处方、全名、电话号码、物理地址	> 10万
SEGA Europe	视频游戏和娱乐公司	AWS / MailChimp / Steam API密钥	未披露
D.W. Morgan	运输和物流	全名、电话号码、物理地址、订单详情、发票、货物图片、合同	未披露

我还发现一个引用，涉及法国房地产机构GSI Immobilier的开放Azure Blob存储存储桶，泄露了约1000客户的PII。

通过SSRF漏洞窃取实例凭证

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

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

Evernote中的SSRF允许攻击者窃取临时AWS凭证（HackerOne #1189367），
Logitech拥有的StreamLabs Cloudot中的SSRF，具有类似影响（HackerOne #1108418），
利用Slack中TURN代理的漏洞，具有类似影响（HackerOne #333419，详细说明），
Positive Security的研究人员在Microsoft Teams中发现SSRF，允许他们访问Azure实例元数据服务（他们无法提取有价值信息，因为Azure需要显式设置请求头）（来源），
2020年底——Google产品本身的SSRF，可用于调用GCP元数据服务器（来源）。

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

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

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

摆脱静态长期凭证

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

对于人类用户

通过AWS SSO（免费）或账户内的IAM角色联合验证人类用户身份。人类没有理由使用IAM用户。IAM用户不仅糟糕因为它们有静态长期凭证，而且因为它们未链接到集中身份提供商。我建议使用组织范围的Service Control Policy（SCP）阻止创建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中运行。在这种情况下，如果应用程序有其他方式引导其身份到Vault，像Hashicorp 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账户，包括工程师用个人信用卡注册的账户（您的账户经理可以帮助运行基于域的AWS账户发现）。
如果使用基础设施即代码，使用工具在进入生产前扫描基础设施代码中的错误配置。参见我之前的博客文章比较各种工具，如tfsec、checkov和regula：扫描基础设施即代码的安全问题。
开启账户范围的S3公共访问阻止。这将确保您不会错误地使S3存储桶公开。同时：使其成为AWS账户配置过程的一部分，并使用SCP保护s3:PutAccountPublicAccessBlock，确保无人可以更改它（是的，它也覆盖删除，但有一个单独的AWS权限）。您仍然可以通过CloudFront分发使S3存储桶公开。但“通过显式创建新CloudFront分发错误地使S3存储桶公开”似乎具有挑战性。
在运行时扫描AWS环境以识别配置错误的S3存储桶。您可以使用开源工具如Prowler、ScoutSuite或CloudMapper。市场上还有许多“云安全态势管理”（CSPM）产品，包括Datadog（我目前的雇主）今年早些时候推出的产品。

值得时强化

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

如果您的S3存储桶仅需要从特定VPC或子网访问，可以使用存储桶策略的Deny语句中的aws:SourceVpce和aws:SourceVpc条件键确保只能从那里访问（参见：AWS文档）。
使用客户管理的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实例上运行命令

1
2
3
4
5


user/christophe IS authorized to call action s3:GetObject for resource my-aws-cloudtrail-logs/*
role/DB_InstanceRole IS authorized to call action s3:GetObject for resource my-aws-cloudtrail-logs/*
user/dany CAN call action s3:GetObject for resource my-aws-cloudtrail-logs/* THRU role/DB_InstanceRole
   user/dany can call ssm:SendCommand to access an EC2 instance with access to role/DB_InstanceRole
   role/DB_InstanceRole IS authorized to call action s3:GetObject for resource my-aws-cloudtrail-logs/*

保护实例元数据服务

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

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

如果使用AWS EKS，还应阻止出口Pod流量到实例元数据服务，并使用“IAM服务账户角色”功能。参见我关于该主题的详细博客文章。

最后，注意GuardDuty有两种发现类型（InstanceCredentialExfiltration.InsideAWS和

2021年云安全漏洞与数据泄露回顾：AWS、S3与凭证管理

本文回顾了2021年公开披露的云安全事件，重点分析了AWS环境中的静态凭证泄露、S3存储桶配置错误、SSRF漏洞利用以及恶意软件窃取云凭据等技术细节，并提供了防护建议和最佳实践。