社区译者：朱婷
审校：韦世滴
原文地址(原作者:CloudSploit)：https://blog.cloudsploit.com/a-technical-analysis-of-the-capital-one-hack-a9b43d7c8aea
最近披露的一个因云安全配置错误导致个人敏感信息丢失事件成为上周的头条新闻。伴随着来自被告方的起诉书中更多信息的公开，我们整理了这一特殊事件公开的数据并对已发生的事情进行有根据猜测：此次事件导致超过1亿张信用卡申请数据资料以及十万个社会保险号丢失。
这一直在发生
黑客事件的根源在于一个常见的问题：云基础架构资源的错误配置允许未经授权的用户提升其权限并破坏敏感信息文档。类似的事件在过去的2-3年里引发了新闻关注，其中包括引人注目的近2亿选民记录、五角大楼的数十亿份机密文件和5亿个 Facebook 个人资料事件。
论据分析
据12页的起诉书 (PDF)内容，这种授权协议起因于 Capital One 的 AWS 账户可以在运行的服务器上任意调用用户请求。起诉书没有对触发这些命令的漏洞进行详细说明，但大多数迹象表明它是服务器端请求伪造（SSRF）漏洞攻击。SSRF 攻击诱使服务器代表远程用户执行命令，使用户将服务器视为其请求的代理，并获得对非公共终端的访问权。
AWS 元数据服务
由于此服务器托管在 AWS 中，因此它可以访问元数据服务的唯一 URL:http://169.254.169.254。通常此 URL 用于提供 HTTP API，以获取节点级别信息，例如节点的 IP 地址、AWS 网络中的位置以及主机名。对于 AWS 云中的应用程序开发人员而言，这是一项非常有用的终端服务。
元数据服务的一项特别重要的功能是提供临时凭证，该凭证可根据实例中IAM角色定义的权限策略为节点提供其他 AWS 服务的访问权限。IAM 角色可以替代长期使用的用户访问密钥和密文；应用程序定期向元数据终端请求凭证，而不是将访问密钥硬编码到应用程序的配置中。所有 AWS 开发工具包（SDK）都会通过一连串的检查来自动处理此请求。在这些检查中，它们会在环境变量、配置文件、本地应用程序代码或元数据终端中查找凭证的内存指示位。
催化剂
将早期的 SSRF 攻击与 AWS EC2 服务器可以访问包含临时证书的元数据终端的知识结合起来，攻击者能够欺骗服务器向以下 URL 发出请求：http://169.254.169.254/iam/security-credentials。该终端返回了一个角色名称，该起诉状中列出了该角色名称为”*****-WAF-Role“，这表明所访问的服务器可能是 Capital One 网络上的 Web 应用程序防火墙。拥有角色名称后，攻击者便查询了整个终端： http://169.254.169.254/iam/security-credentials/*****-WAF-Role 它返回了最初分配给 EC2 实例本身的整套临时凭证：
{
AccessKeyId: "<access key>",
SecretAccessKey: "<secret key>",
}
这些是标准的 AWS 凭证，可用于通过 AWS CLI 或任何 SDK 访问 AWS API。由于 IAM 角色没有附加禁止在 Capital One 外网使用的条件，因此地球上的任何人都可以使用这些凭证像 EC2 实例一样在内网将自己的 API 请求签名到 AWS API。
累加效应
根据起诉书，一旦攻击者获得了对这些凭证的访问权，她便运行了 AWS S3 “ListBuckets” 命令。为此，IAM 角色策略允许通过其 IAM 策略中定义的权限来调用 API。该起诉书没有概述分配的确切权限，但是我们可以假定它至少允许了此类 API 调用（如果没有太多的话）。以下策略就足以引发此攻击，如下:
{
"Effect": "Allow",
"Actions": [
"s3:ListBuckets",
"s3:Sync"
],
"Resource": "*"
}
运行 s3：ListBuckets 之后，将会打印出包含受感染帐户中所有 AWS S3 存储桶的完整列表。
$ aws s3 ls 2019-08-01 11:01:10 bucketone 2019-08-01 12:00:23 buckettwo
起诉书提到该命令被运行了几次，并使用 AWS s3：Sync 命令将这些存储桶中的数据复制到攻击者的本地计算机上，这引发了后面铺天盖地的媒体报道。
$ aws s3 sync s3://bucketone .
什么地方出了错？
这次攻击是系统漏洞与错误配置相结合的最终结果。SSRF 攻击获得了元数据终端访问权限是整个事故的关键，但是错误配置使安全漏洞演变为后续的全面沦陷。
安全分层通常被称为安全洋葱。一旦攻击者获得对实例的IAM凭据的访问权限，她便利用严重的配置错误（该实例列出了过多的权限），访问了大量 S3 存储桶中的数据。
虽然很容易将数据丢失归咎于 Capital One 的开发人员，但事实是，几乎每个 AWS 账户中都可能存在 IAM 角色配置错误。很少有开发人员花时间仔细列出所需的每个权限。通配符经常在不该应用的地方被更多的使用，从而导致被意外访问。如果没有攻击侵害因素，这种配置错误可能会被无期限地忽略。
有人也可能会辩论说，事故是由于 Capital One 没有足够的监控来检测网络外部对凭证的初始访问导致。根据起诉书的分析，我们可以得出结论，CloudTrail 日志记录已启用。这些日志可以表明该角色当时正在从外部被访问使用，Capital One 可以有足够的时间供某人做出响应并停用该角色的权限。
正确的做法
尽管这无疑是一个可怕的情况，但是 Capital One 能够找到有问题的确切请求这一事实，意味着它们至少遵循了启用 CloudTrail 日志的最佳实践。
此外，虽然先前发生的许多事件是由 S3 存储桶权限可以直接被公共访问引起的，但在这个案例中似乎并非如此，而是攻击者能够通过外部漏洞获得内部访问。
保护自己
如果我们不得不猜测，我们打赌大多数 AWS 账户都容易受到上述至少一半的攻击。创建紧耦合的 IAM 策略非常耗时，并且将来可能很难向应用程序中添加其他功能。
至少考虑以下几点建议：
- 确保每个应用程序，EC2 实例或自动伸缩群组具有其自己的 IAM 角色。不要在不相关的应用程序之间共享角色。
- 调整每个角色的权限范围，仅允许访问所需的 AWS 资源。上述 “WAF” 角色不需要“在正常业务过程中”（根据起诉书内容）访问列表 S3 存储桶。
- 如果可能，在 IAM 角色中设定“条件”语句，以限制对已知 IP 地址或 VPC 终端的访问。
- 确保在所有区域和所有服务中都启用了 AWS CloudTrail。如果您在 S3 中存储了特别敏感的数据（社会安全号码肯定合格！），请确保 S3 存储桶对象可以启用读取日志级别权限。
- 监视 CloudTrail 日志中的可疑活动，如从已知网络地址之外的 IP 访问 API。
- 持续审核 Web 应用程序是否存在应用程序安全漏洞，请牢记基于云的应用程序可以集成到更广泛的 AWS 生态系统中，因此可以访问其他终端和服务。
结论
云安全是极富挑战性的。此事故正如我们在过去几年中看到的很多其他黑客那样，有时一家公司要丢失数百万条记录或客户数据，仅仅是因为在 IAM 策略中使用了星号。持续审核和监视这些问题对于维护安全的云环境至关重要。
