Capital One银行数据泄漏事件分析

2024-04-04 17:27:17

最近，一起和云有关的大型数据泄露事件成了头条新闻。美国的Capital One银行由于“服务器配置错误”，被某个黑客窃取了上亿张信用卡数据以及十多万社保号码。目前，有关此次泄露事件中涉及的技术和黑客的各类分析报告都已出炉，让我们看看到底是什么原因导致了这起事件的发生。

危险一直在身旁

让黑客有可乘之机的是一个常见的云安全问题：云上基础设施资源的错误配置使得未经权限验证的用户非法提升自己的权限，从而接触到敏感文档。在过去的2-3年里，这种问题所导致的安全事件也频频见报，例如，近2亿份选民记录泄露，五角大楼Tb级机密文件泄露，5亿份Facebook个人资料泄露。

获得立足点

根据12页的*起诉书(PDF)，此次事件所涉及的具体漏洞是Capital One在其AWS帐户中的服务器会执行任意用户所发起请求。起诉书虽然没有详细说明具体漏洞，但大多数迹象表明这是一个针对服务器端的SSRF攻击。SSRF攻击可让攻击者借助放置在公网上的服务器去非法访问内网中的服务器，造成命令执行、数据泄露等危害。

AWS元数据服务

由于目标服务器托管在AWS中，所以它可以访问一个被称为元数据服务的[站点](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-me tadata.html)，地址为[http://169.254.169.254](http://169.254.169.254)。通常，这个URL通过HTTP接口为使用者提供各类节点信息，例如节点的IP地址、在AWS网络中的位置和主机名。对于AWS中应用程序的开发人员来说，这是一个非常有用的服务。

而这个服务的一个特别重要的功能就是提供临时凭证。根据实例的IAM角色中定义的权限策略，为节点提供对其他AWS服务的访问权。IAM角色是一种新型的授权管理方案，用于替代传统的用户访问密钥；应用程序不需要将固定的访问密钥硬编码到配置中，只需定期从元数据服务请求临时凭据。AWS的所有SDK都通过一系列检查自动处理请求，检查在环境变量、配置文件、本地应用程序代码或元数据服务中是否存在凭据。

权限获取

通过早期摸索，攻击者知晓了某台AWS EC2服务器的SSRF漏洞，并且这台服务器很可能具有元数据服务发布的临时凭证。于是攻击者便利用（通过SSRF）这台服务器发出以下请求：

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命令行或任何SDK访问AWS的API。此外，IAM角色也没有额外限制,阻止在Capital One网络之外使用这些凭证。因此，世界上任何人都可以使用这些凭证对自己的API请求进行签名，就像它们是Capital One网络内的EC2实例发出的一般。

危害

根据起诉书，一旦攻击者获得了这些凭证，她就运行了AWS S3中的ListBuckets命令。要成功实现这一点，需要IAM角色策略中设置允许此API被调用。起诉书中虽然没有明确列出关于这点的权限控制，但是我们可以猜测在权限管理策略中是这个API是允许被调用的，相关策略可能如下：

{
 "Effect": "Allow",
 "Actions": [
     "s3:ListBuckets",
     "s3:Sync"
 ],
 "Resource": "*"
}

在运行了s3:ListBuckets之后，帐户中的所有AWS S3 bucket将完整列出。

$ 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角色配置缺陷。很少有开发人员会花时间仔细研究其中涉及的每个权限；他们通常会在很多配置处直接使用通配符，给攻击者可乘之机。

此外，根据起诉书的说法，我们可以推测得知Cloudtrail日志记录是启用的（用于监控），这其中也记录了有外部角色正访问内部服务，理应能让管理员及时止损。

此次事件和以往的AWS安全事件不同的是，Capital One确实启用了监控，它们的存储桶也并没有授权问题，但攻击者还是通过一个外部漏洞成功进行了攻击。

安全建议

确保每个应用、EC2实例等都有自己的IAM角色。不要在不相关的应用之间共享角色。

确保每个内网中角色仅能访问所需的资源。不要让WAF能访问到S3存储桶。

确保所有区域和所有服务都启用了AWS Cloudtrail。如果你在S3中存储了特别敏感的数据（例如社会保险号码），需确保记录下S3存储桶的每次读取行为。

时刻检查应用中的传统web漏洞，拒绝给攻击者提供内网落脚点。

结论

云中的安全管理一直都非常具有挑战性。正如我们在过去几年中所看到的那样，一条策略的缺陷，就有可能导致上亿条数据的泄露。只有持续的安全审计和监控，才是对抗安全风险的根本手段。

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场：https://nosec.org/home/detail/2835.html
来源：https://blog.cloudsploit.com/a-technical-analysis-of-the-capital-one-hack-a9b43d7c8aea

码农公寓