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

阅读数:1531 2019 年 8 月 9 日

前段时间,我们报道了前 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?

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论