我在AWS上发现数千个开放数据库的技术探索

我在寻找和报告包含敏感数据数据库的过程中，发现了财富500强公司、医院、加密平台、初创企业尽职调查期间的数据等。

概述

通过扫描托管服务的CIDR块（IP范围），很容易在云服务上找到配置错误的资产，因为这些信息是已知且公开的。

在短短1天内，我发现了数千个ElasticSearch数据库和Kibana仪表板暴露了敏感信息，很可能是由于配置错误：

客户敏感信息：电子邮件、地址、当前职业、薪资、私人钱包地址、位置、银行账户等
Kubernetes集群生成的生产日志：从应用程序日志到内核和系统日志
从所有节点、Pod和运行在其上的应用程序收集的日志集中在一处，向全世界开放
部分数据库已被勒索软件破坏

背景

肯定有大量资产在其范围外监听，等待被发现。已发布的CIDR块使攻击者更容易找到这些资产，传播各种恶意软件，或获取真实公司的敏感数据。

DevOps、开发人员和IT从业者经常错误配置以下内容：

在错误的网络接口上绑定套接字
集群安全组配置错误（允许来自广泛CIDR块的所有TCP和UDP流量）
使用默认网络或子网，子网设置被继承，公共IPv4地址被静默分配

假设

我假设如果我从云运营商内部（实例/VPS）扫描特定的CIDR块，可以轻松找到配置错误的资产，主要原因是人为错误。

关键是智能扫描，利用预先已知的网络基础设施（我们想要扫描的软件的已知CIDR块）来查找可达的实时服务器。

扫描过程

获取AWS ElasticSearch服务的CIDR块

所有云提供商都会发布其服务及其每个服务的CIDR块（IP地址范围）列表。

需要什么来找到它们？

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

端口扫描 - 收集资产数据

我使用MasScan扫描所选CIDR块上的开放端口。MasScan是TCP端口扫描器，它异步发送SYN数据包。

输入是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响应中打印其网页标题。

发现的数据示例

Kubernetes整个生产集群的日志

通过fluentd流式传输的K8集群日志，包含实时URL和内核日志。

使用私钥成功SSH登录

SSH守护进程日志 - 集群机器的实时日志。

完整的云可见性

实例类型、AMI、账户ID对世界可见，这要归功于配置错误的K8和ElasticSearch集群。

私有仪表板

一些公司将Jira任务流式传输并发布到其ElasticSearch仪表板中，包括客户数据、代码示例、账户名称等。这个Kibana仪表板包含了公司研发的一切信息。

医院/医疗供应 - 个人疫苗接种信息

疫苗接种日期和电子邮件地址。

加密交易平台

加密代币交换。

银行业

银行转账以及全名和银行账户详细信息。

实时车队指标

关于每辆车的信息：

IMEI（唯一蜂窝标识符）
位置（坐标）
gsm信号强度
燃油状态
错误代码
电池状态

已被勒索软件攻击的服务器

如果您的集群向世界开放，则不需要0-day来运行勒索软件。如果您没有身份验证，任何人都可以访问所有内容。

像elasticsearch-dump这样的工具可用于备份（和恢复）数据库。备份后，他们从集群中删除所有内容，留下此消息：“所有数据都已备份。您必须支付0.16BTC到…”

结论

按服务发布CIDR块在端口扫描方面存在逻辑问题。我们出于多种原因需要它，但同时它对云提供商构成了如此巨大的风险，使其客户可以轻松被扫描。

错误配置一直在发生，并且会持续存在，在不知情的情况下导致公司安全出现许多漏洞。

我们经常在配置实例时使用默认VPC子网。因此，许多实例会自动分配公共IP地址。

问题始于缺乏可见性。据我所知，AWS内部目前没有人积极搜索配置错误的数据库或托管服务。这超出了他们的范围。

我报告了我发现的公司，直到某个限制（有太多），我无法独自联系所有公司。

在与AWS的电子邮件对话中，他们声称配置和保护其资产是公司的责任，他们没有积极搜索这种错误配置。这有道理，但我发现这异常容易，他们可以毫不费力地解决它。

我在业余时间自己完成了这项工作，做得相当好。

目前我们能做的就是假设错误配置总是可能的，无论公司规模如何，并且总有人从网络中看到您。如果您向世界开放服务，至少使用适当的授权和身份验证。