深入浅出谈美国 Capital One 数据泄露事件

前段时间，我们报道了前 AWS 员工闯入 Capital One 服务器，窃取 1.06 亿用户信息的重大数据泄露事件。你也许会疑惑，为什么当下我们总能听到数据安全相关的新闻？如何才能避免此类事件的再次发生呢？本文将结合 Capital One 数据泄露的案例，从技术与非技术方面进行深入讨论。

免责声明：本文表达的观点为作者个人观点，不代表任何其他人或组织。本文中的假设基于法院文件中提供的数据。

近日，自 2005 年开始申请 Capital One 信用卡的客户数据被曝泄露。涉及数据包含约 1 亿美国人和 600 万加拿大人。泄露的数据存储在 AWS 的 S3 存储桶中。如果你的数据受到损害，除了信用监控外，不要指望任何其他信息，因为免费信用监控是从 Equifax 获得的。在这一点上，客户不知道他们的信息是否在那里，但他们想知道自己的财务记录。

在此次事件中，我认为 Capital One 应承担全部责任。经调查确认，Capital One 已经承认这是一起由于配置错误的防火墙策略导致的数据泄露事件。我认为它不像防火墙或许可安全策略那么简单。就防火墙策略问题，我知道这是攻击者利用的东西，但我认为实际情况不仅仅是这样，还有更多需要挖掘的内幕。

安全行业当前面临的挑战

安全专业人员试图检查这种规模的安全事件，我们希望了解受害者本可以采取的正确行动，以及防备攻击者可能利用的安全漏洞。这些知识可以帮助安全社区更好地防范威胁，修复错误的配置，修补可能使我们的基础架构遭受类似的安全漏洞。由于我们仍然没有收到来自 Capital One 的官方声明，但以我的经验来看，我依然怀疑会再次发生这种情况。我们可以参考法庭文件和其他报告中的关联信息内容，让我们开始分析吧。

在消息发生后的第二天，我在西雅图市中心和一些朋友喝咖啡聚会，我们当时在讨论关于 AS-Code 系统的未来。在聚会之后，一位从事安全工作的伙伴问道，“为什么 Capital One 的云托管系统无法保护客户数据呢？” 他抛出这个问题让我来回答，因为我倾向于使用工具而不是从轮子做起。我对自己说，这很公平，如果你推荐一项技术，你应该能说明其优缺点。我认为它对任何云安全团队来说都是一个很好的工具。根据我当时的信息，我对攻击者能够利用的AWS资源知之甚少。我只知道错误配置的防火墙，但我并不知道该防火墙是否有安全组，在 ELB 前面的 AWS Web 应用程序防火墙（WAF），还是一些第三方 Web 应用程序防火墙（开源/商业）。根据调查结果，附加到受损 EC2 实例的 IAM 角色，它让我认为有问题的防火墙确实属于第三方。作为 IAM 角色的应用程序防火墙（WAF）无法直接“附加”到 AWS 托管的应用程序防火墙 WAF。

典型的 ModSecurity 部署

幸运的是，Krebs 的一份报告显示，受损资源是一个配置错误的开源 Web 应用防火墙（ModSecurity）。我查看了技术细节来回答这个问题，我问自己，“它真的与工具有关吗？” 如果我们确定云托管有可以防止此类攻击的策略，我们是否会获得任何收益？ 正确的问法可能是：“像 Capital One 这种技术领先的公司，如何托管数以百万计的个人财务记录，而不是信任这些基本配置的东西。”

Capital One 执行副总裁兼首席技术官 George Brady 说：“在 Capital One 所做的一切工作中，我们始终从客户需求开始，以找出如何将服务提供给客户。与 AWS 合作最大的好处是我们不必担心构建和运营必要的云基础设施。所以，我们可以集中时间、金钱和精力为我们的客户创造更加良好的体验。“

下面，我们还会引用这句话！让我们继续深入分析。

那些活跃在云社区的人非常清楚 Capital One 在云应用方面是一个领导者。 Capital One 在众多云大会中公开谈论他们的云优先战略。通过阅读 Capital One AWS 案例研究，你可以轻松地在线找到更多相关信息。Capital One 背后有一个出色的云安全工具（Cloud Custodian）。数百名云专业人员使用该工具实施安全护栏，以增强安全性并帮助控制 AWS 的云成本。此外，Capital One 聘请了国际上相当有才华的安全专业人士。多年前，当我开始我的云生涯时，我申请过 Capital One 的云岗位。我通过了他们所有的数字和推理考试。同时，我花了几个星期的时间精心准备面试，而且我还有三个 AWS 认证。遗憾的是，我却没有得到这份工作，这是我在过去七年中唯一没有得到的工作机会。简而言之，Capital One 不雇用任何有实战背景的人来运维云系统。他们刚刚聘请前 Netflix 工程师 Will Bengtson，并让他担任云安全总监。在 Netfix 的时候，Will 就知道如何保护云基础设施，并在此次违规之前很久就已经为 Netflix 写了一篇关于 SSRF 的博客。在 Capital One，Will 提出了其所需的武器来阻止这种安全攻击。

那么，到底发生了什么情况？

Capital One 拥有强大的云计算能力、工具、才华横溢的安全专业人员，为什么仍遭到黑客攻击？让我们再次引用 George Brady 的发言，因为我认为这是一切开始的地方。

情况比想象中复杂

高管和决策者非常高兴地将部分运维成本转移到云提供商，其中包括安全运维部分。AWS 明确标注了他们的共享责任模型。在这种模型中，他们确定了客户需要拥有的区域。共享责任模型归结为我们使用的任何云服务，我们将始终承担保护数据的责任。

如果你再次阅读 George Brady 的引文，你很难看出他对安全性的关注。他对如何专注于客户表现出明显的兴奋，虽然这并不意味着他不关心安全，但它强化了我对行业的一致性看法，即企业高管并不关心安全问题，他们更关心缩短产品上市时间，并不断提高需求的数量，这意味着开发人员面临很大的压力。在以前的职位中，我一直非常接近客户。客户通常不太关心安全性，因为他们更关心当前功能的增强和新功能，这决定了高管需要关注的内容，基于客户的决策也会影响到开发人员，而且往往会使对安全性的建设削弱。

客户需要更多能点击的小界面部件和小工具，但他们只在安全事件发生时才关心。技术高管们正在忙着让公司赚更多钱，这就是他们被聘用的价值。问题是，对于技术支持可以帮助防止造成灾难性的安全计划方面，我们没有看到太多行动付诸实施。

高管希望开发人员快速交付，我也相信他们想避免违规行为。我认为，在缩小开发范围与安保行动之间的差距时，他们并没有走在路上。开发人员负责在云基础架构上构建这些服务、维护本地工作的负载很重，这使得他们很难为在安全性上保持应有的关注。

由于没有得到技术领导者的支持，安全人员注定在这种资源争夺战中失败。这一问题在整个企业范围内都很明显，并且不会很快消失。通常，在年度安全审核之后，软件开发团队的路线图会被修改以适应新的需要。我们很少在重载或活动冲刺中看到任何安全项。直到我们庆祝那些特意采取行动以改善安全状况的开发团队，才会出现积极的变化。

安全专业人员被迫创建和管理所有安全类型的情况。我们已经让一个不安全的版本构建进入生产阶段，因为我们没有权力阻止它。我们要运维一个易受攻击的基础设施，因为保护功能意味着开发人员必须做更多（不必要的）工作来使其应用程序工作。如果你几年来始终从事安全工作，你应该知道我的意思。

如果你阅读过我之前的博客，你会发现我是一个简化安全流程以适应业务的大力倡导者。重型安全流程和文档不是答案，答案是安全与开发之间的密切合作。编写了安全策略，却没有人能够找到它们，没有人阅读它们并把将其应用到实际过程中。安全和运营应为开发人员构建支持平台，以便将可靠和安全的代码顺利地转移到生产环境。没有 CTO 和技术领导的支持，就不会有健康的安全计划。而没有开发团队的支持，它将无法运作。

技术领导者的关键点

你的员工可能不会谈论这些，所以这几点请免费从我这里拿走并实践吧！

1. 首先了解你的安全状况：你有什么数据？谁想要它？它有多重要？你能做些什么来保护它？如果被盗，你会怎么样？

2. 这与你的工具无关：如果你的安全团队可以使用它们来实施安全策略，那么它们就毫无用处。

3. 这与你是否拥有才华横溢的安全团队无关：没有高层的全力支持，无法应对永无止境的安全挑战。

4. 这不完全是可以立即获得的利润，单次安全泄露意味着损失数百万美元和公司声誉受损。

5. 建立健康的安全文化，让每个人都对安全事件负责。每个人在实施安全措施时都会受到欢迎，因为他们在发布新服务时会受到称赞。

6. 通过鼓励团队范围的协作，雇佣有安全经验的专业人士，并改变组织安全文化。

7. 通过编写安全策略，将其提交到托管与应用程序代码的相同 Git 仓库来简化安全性。

即使本次调查没有从技术角度提供足够多的细节。 我们从安全工程师的角度来看，受感染的服务器、权限过度宽松的 IAM 角色、访问包含数据的 S3 存储桶策略问题都导致了此次数据泄露事件的发生。

实施步骤：

1. 攻击者破坏了配置错误的 Web 应用程序防火墙后面的 EC2 实例。

2. 受感染的服务器可以大量访问云存储桶（可怕的做法）。

3. 聪明的攻击者不会从元数据服务中提取角色凭据，并使用这些凭据进行 API 调用（如果已安装 AWS CLI）。（如果启用了 AWS Guard Duty 警报，则会触发警报）只有攻击者可以直接从受感染的 EC2 运行该命令，他们可以访问并运行 S3 数据同步。

最坏的情况下，你可以拥有 s3 资源的最后一个

我并不是说上图是最确切的，但考虑到本次攻击者能够完成的事情，实际情况应该八九不离十。

通过这些简单的方法可以预防这种攻击：

1. 最低权限：为什么要让 EC2 实例访问大量存储桶。我们需要制定细粒度权限策略，这样你就可以让代码只访问特定存储桶。

2. 健康安全组/防火墙：你的安全组或防火墙绝不应允许从入站流量到可直接访问敏感数据。

3. 监控：Capital One 承认他们的日志显示了有问题的服务器与 Tor 出口节点进行的通信。那么，谁在看那些东西？

只有那些简单的安全措施就能防止这种违规行为？是的，我说过。

我能自动完成上述安全操作吗？是的。请使用 Capital One Cloud Custodian！

1. 编写云托管策略，创建该策略标记允许的 AWS Config 安全规则。

2. 使用 Cloud Custodian 创建响应以下 Gurd Duty 发现的策略：“通过启动实例角色，专门为 EC2 例创建凭据管理从外部 IP 地址的滥用。”

3. 编写云托管策略，该策略针对 Tor 出口节点通信的事件可作出安全应急反应。

写在最后

我真的希望看到 Capital One 站出来分享案例细节、知识经验，因为这对整个安全社区都有重要价值，而不是停留在他们的云优先策略上。类似事件可能发生在我们每个人身上，我们能做的就是应对安全挑战，并建立强大的云安全社区。

原文链接：

What’s in Your Bucket?