Capital One数据泄漏事件技术分析

最近披露的另一起因云安全配置错误导致个人敏感信息泄露的事件已成为上周的头条新闻。结合起诉书上的一些信息，我们将有关该事件的公开数据拼凑起来，并依据推测此次导致超过1亿张信用卡申请信息和10万个社会安全号码泄露的事件过程。

类似事件不断发生

导致被黑客攻击的根源问题在于：云基础架构资源的错误配置允许未经授权的用户提升权限并最终获取文档。类似的事件在过去2-3年被曝光了多次，包括著名的近2亿选民数据泄露，五角大楼TB级机密文件泄露，以及5亿Facebook用户数据泄露。

推测立足点

根据12页的起诉书（PDF），此次入侵源于Captial One的AWS服务器上存在允许发送任意用户请求的漏洞。起诉书没有详细说明导致配置错误的漏洞细节，但多数迹象表明是SSRF（服务器端请求伪造）攻击导致的。SSRF攻击欺骗服务器执行远程用户的命令，使用户能够以服务器作为代理，发送请求，并访问内网节点。

AWS元数据服务

由于服务器托管在AWS上，可访问被称为实例元数据的唯一URL，即http://169.254.169.254。通常，此URL用于通过HTTP API向AWS网络内提供节点级信息（例如节点IP地址、节点在AWS网络中的位置、以及节点主机名）。对于使用AWS云的应用程序开发者来说，是非常有用的功能。

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

提升权限

AWS EC2服务器可以访问包含临时凭证的元数据节点，结合之前介绍的SSRF攻击，攻击者能够欺骗服务器向以下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网络之外被使用的限制，任何人都可以使用这些凭证签名访问AWS API的请求，就好像请求是发起于内网的EC2实例一样。

把细节拼凑起来

根据起诉书，攻击者拿到这些凭证后，运行了AWS S3 “ListBuckets”命令。IAM角色策略需要配置其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命令把这些bucket数据复制到了攻击者的本地电脑，结果就是之后铺天盖地的媒体报道：

$ aws s3 sync s3://bucketone .

哪里出了问题

最终，此攻击是漏洞与错误配置共同导致的。获取到对元数据节点访问权限的SSRF攻击是整个过程的关键，但之后的错误配置将该漏洞恶化为数据泄露。

安全是分层设计的——通常也被称为安全洋葱。一旦攻击者获得了对实例的IAM凭证的访问权限，就会利用大量的错误配置——这个实例拥有过度的权限来列出和访问大量S3 bucket中的数据。

虽然这次我们可以理所应当将数据泄露归咎于Capital One的开发人员，但是实际上IAM角色错误配置几乎存在于每个AWS账户中。很少有开发人员花时间仔细列出每个必需的权限，通配符也经常被过度使用，从而导致未授权访问。如果不是因为被入侵，这种配置错误的问题可能会一直被忽视。

有人还辩解说，是由于监控措施不完善，所以在早期没有检测到有人从Capital One的外网访问了凭证。根据起诉书中的分析，我们知道Capital One启用了CloudTrail日志记录。日志中记录到了该角色是从外部被访问的，可是需要有足够的时间让相关人员做应急响应并移除该角色的权限。

可喜的是

虽然这无疑是一个糟糕的事件，但Capital One能够定位到问题，意味着他们至少遵循了CloudTrail日志的最佳实践。

此外，虽然许多之前的事件是由S3 bucket权限开放了直接公共访问导致的，但似乎不是此次事件的主要原因；攻击者利用了外部漏洞获取到了内部的访问权限。

做好防护

如果我们非得做个猜测，我们打包票，绝大多数AWS账户会受到至少上述一半问题的影响。创建严格的IAM策略非常耗时，并且可能会给以后在应用程序中添加其他功能的增加麻烦。

请至少考虑以下建议：

1. 确保每个应用程序、EC2实例或自动扩展组都有自己的IAM角色。不要在不相关的应用程序之间共享角色。
2. 限定每个角色的权限，仅允许其访问所需的AWS资源。上述”WAF“角色不需要”在正常业务中“拥有列举S3 bucket的权限（根据起诉书）。
3. 如果可能的话，请在IAM角色中包含”条件“语句，只允许来自已知IP地址或VPC节点的访问。
4. 确保在所有区域和所有服务中启用AWS CloudTrail。如果在S3中存储了特别敏感的数据（比如社会安全号码），请务必同时针对S3 bucket对象启用可读日志。
5. 监控CloudTrail日志中的可疑活动，包括从未知IP访问API。
6. 持续审核Web应用程序是否存在安全漏洞，并记住，云应用程序可以访问其他节点和服务，因为它们会集成到更广阔的AWS生态系统中。

结论

云安全非常具有挑战性。正如我们在此次入侵事件中看到的那样，也包括过去几年发生的案例，有时公司丢失数百万条记录或客户数据可能只是在IAM策略中多加了个通配符*。持续审计和监控这些问题对于维护安全的网络环境至关重要。

原文链接：https://blog.cloudsploit.com/a-technical-analysis-of-the-capital-one-hack-a9b43d7c8aea

翻译：看雪翻译小组 SpearMint

校对：看雪翻译小组 lordvice

[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法