发现数千个开放的AWS数据库：我的云安全扫描之旅

概述

在云服务上寻找配置错误的资产是件容易的事，通过扫描托管服务的CIDR块（IP范围）即可，因为这些信息是公开的。仅一天之内，我就发现了数千个ElasticSearch数据库和Kibana仪表板，它们很可能因失误而暴露了敏感信息：

客户敏感信息：电子邮件、地址、当前职业、薪资、私有钱包地址、位置、银行账户等。
由Kubernetes集群写入的生产日志——从应用程序日志到内核和系统日志。
从所有节点、Pod及其上运行的应用程序收集的日志，汇总一处，却向全世界开放。我只是第一个到达那里的人。
部分数据库已被勒索软件破坏。

背景

外部必定有大量资产在其预定范围外监听，等待着被发现。已公布的CIDR块使攻击者更容易找到这些资产，以传播各种恶意软件，或获取真实公司的敏感数据。 DevOps、开发人员和IT从业者经常错误配置以下内容：

将套接字绑定到错误的网络接口。例如，监听来自0.0.0.0/*的连接——这样所有网络接口都可见，而不是仅限于内网接口IP地址（172.x.x.x）。
为集群配置错误的安全组（允许来自宽泛CIDR块的所有TCP和所有UDP）。
有时，安全组被不了解后果的其他人更改。
使用默认网络或子网，子网设置被继承，并且静默分配了公共IPv4地址。

假设

我假设，如果我从云运营商内部（一个实例/VPS）扫描特定的CIDR块，就可以轻松找到配置错误的资产，这主要是由于人为错误。关键在于智能扫描，利用预先已知的网络基础设施（我们所关注软件的已知CIDR块）来查找可达的在线服务器。如果你稍作搜索，可以找到每个云提供商的相关CIDR块。假设我是一名IT技术人员或安全工程师，需要允许来自特定云服务（如AWS的Elastic Container Service (ECS)）的传入连接。这可以通过将服务的CIDR块添加到安全组规则中，允许来自这些CIDR块的连接来实现。所有云提供商都会发布其服务列表以及每个服务的CIDR块（IP地址范围）。

获取AWS上ElasticSearch服务(ES)的CIDR块

部分CIDR块只能从云提供商内部访问。你需要做的就是在你想扫描的云提供商内部启动一个具有互联网连接能力的VPS/实例。

发现它们需要什么？

对网络、IP协议栈、路由和云基础设施的基本理解。
用于端口扫描的轻量级工具（如MasScan或NMap）。
要扫描的CIDR块列表（托管服务——如Kubernetes或ElasticSearch）以及这些IP范围内实例最可能开放的端口。
一个可视化我们收集的所有数据的工具（如ElasticSearch+Kibana）。

端口扫描——收集资产数据

我使用MasScan扫描所选CIDR块上的开放端口。 MasScan是一个TCP端口扫描器，它异步发送SYN数据包。在适当情况下，它可以在5分钟内扫描整个互联网。输入是CIDR块（例如50.60.0.0/16或118.23.1.0/24）以及我们想要扫描的端口（9200, 5600, 80, 443等）。我在实例上使用Docker镜像启动了一个ELK栈。我在同一台机器上启动了MasScan，它开始扫描CIDR块。使用LogStash将MasScan的输出（响应日志）流式传输到ElasticSearch，并通过Kibana可视化所有内容。扫描期间，TCP响应被记录并索引到ElasticSearch中。我让它运行了一段时间，很快就拥有了超过337,000个IP和端口组合的扫描结果。其中许多是开放的。

分析与可视化数据

我已将事件报告给相关方以及AWS。并获得了他们继续发布此文的许可。大多数方在一两天内解决了问题。部分方至今仍无视报告。得益于我创建的管道，我拥有实时日志，并且可以在扫描更多内容的同时立即开始查看服务。我使用Kibana的导出按钮将在线资产从Kibana导出到CSV文件。然后使用pandas（python）加载它。对于每个IP，我发送了一个HTTP HEAD请求，并获得了一个包含资产指纹的HTTP响应。我排除了需要身份验证的响应。然后我从HTTP响应中打印了它们的网页标题。我们可以对ElasticSearch端口或任何服务执行相同的操作。这些IP已经被MasScan扫描过，所以我假设它们在线。

所以，现在我拥有所有资产及其网页名称的列表。我在浏览器中通过地址栏输入来探索这些地址。然后，我仔细地逐一探索这些资产。我搜索了以下内容： /_aliases/<index>/_search 这个ElasticSearch REST API非常方便。很容易获取字段元数据、文档数量以及你想了解的关于ES集群的一切。

我发现的数据示例

整个生产集群的Kubernetes日志（通过日志收集器收集）。
使用私钥成功进行的SSH登录。
完全的云可见性——实例类型、AMI、账户ID，由于K8和ElasticSearch集群的错误配置而向全世界可见。
私有仪表板——一些公司将Jira任务流式传输并发布到他们的ElasticSearch仪表板中——包括客户数据、代码示例、账户名称等。这个Kibana仪表板包含了公司研发的一切信息。该公司正处于尽职调查过程的中期（或高峰期），报告称在我报告此事件几周后他们筹集了大量资金。如果被其他人发现，这对他们来说可能是致命的。
医院/医疗用品——个人的疫苗接种信息。
加密货币交易平台。
银行业——银行转账以及全名和银行账户详情。
实时车队指标（关于每辆车）：- IMEI（唯一蜂窝标识符）- 位置（坐标）- gsm_strength - 燃油状态 - 错误代码 - 电池状态。

这是真实的吗？

有时我难以判断数据库是真实的还是蜜罐。所以，我在谷歌上搜索了在数据库中发现的任何内容。通常，我找到了真实的网站，并通过这种方式知道应该报告给谁。

已被勒索软件入侵的服务器

如果你的集群向全世界开放，运行勒索软件就不需要0day漏洞。如果上面没有身份验证，任何人都可以访问一切。如你所见，我发现的部分资产已经被“黑客入侵”（更准确地说，被勒索软件破坏）。像elasticsearch-dump这样的工具可用于备份（和恢复）数据库。备份后，他们删除了集群中的所有内容，留下这条消息：“您的所有数据都已备份。您必须支付0.16BTC到…”

安全与隐私政策

可以想象，我发现许多组织都符合GDPR。这意味着他们对数据泄露很敏感，他们有DPO（数据保护官）积极搜索和处理此类事件。部分DPO没有回复，部分DPO的邮箱因权限错误拒绝了我的电子邮件（不允许接收组织外部的电子邮件）。对于一些公司，DMARC和SPF记录不允许从公司外部接收电子邮件到他们的邮件服务器。真是一团糟，他们根本无法通过电子邮件联系到。我还向关联公司和其他子公司发送了电子邮件。我尝试通过他们网站的联系表格联系他们。没有任何回应。我不得不通过CEO、CTO和副总裁开始对话。至于那些无视的公司——他们的资产和数据至今仍然暴露，而他们并不在意。

结论

就端口扫描而言，按服务发布CIDR块是一个逻辑问题。我们出于许多原因需要它——但同时也给云提供商带来了巨大风险，使他们的客户容易被扫描。错误配置一直在发生，并且将持续存在，在不知不觉中给公司安全造成许多漏洞。我们经常犯错，在配置实例时使用默认的VPC子网。因此，许多实例自动分配了公共IP地址。问题始于缺乏可见性。据我所知，目前AWS内部没有人积极搜索配置错误的数据库或托管服务。这超出了他们的职责范围。我报告了我发现的那些公司，直到某个限度（数量太多），我无法独自联系所有人。在与AWS的电子邮件对话中，他们声称配置和保护资产是公司的责任，他们没有积极搜索这种错误配置。这说得通，但我发现这异常容易，而且他们无需太多努力就能解决这个问题。我在业余时间自己做得相当不错。目前，我们能做的就是假设错误配置总是可能发生的，无论公司规模大小——并且网络上总有人在看着你。如果你向世界开放服务，至少使用适当的授权和身份验证。

顺便说一句，我是在业余时间做这件事的。我也真的很喜欢咖啡！