概述

在云服务中发现配置错误的资产非常简单——只需扫描托管服务的CIDR块（IP范围），因为这些信息由云服务商公开提供。

仅用1天时间，我就发现了数千个意外暴露敏感信息的ElasticSearch数据库和Kibana仪表盘，包括：

• 客户敏感信息：电子邮件、地址、职业、薪资、加密钱包地址、银行账户等
• Kubernetes集群的生产日志：从应用日志到内核系统日志
• 部分数据库已被勒索软件破坏

背景

开发运维人员常犯的配置错误包括：

1. 套接字绑定到错误的网络接口（如监听0.0.0.0/*）
2. 集群安全组配置错误（允许来自宽泛CIDR块的所有TCP/UDP流量）
3. 使用默认网络配置时自动分配公网IPv4地址

技术假设与方法

扫描策略

通过从云服务商内部（实例/VPS）扫描特定CIDR块，利用预知的网络基础设施（如AWS ElasticSearch服务的公开CIDR块）快速定位暴露资产。

工具链

1. 端口扫描：使用MasScan（异步SYN包扫描器），5分钟内可扫描整个互联网
2. 数据分析：通过Docker部署ELK栈（ElasticSearch+LogStash+Kibana）
3. 指纹识别：对开放端口发送HTTP HEAD请求获取服务特征

1
2
3
4
5

# 示例：通过pandas处理扫描结果
import pandas as pd
df = pd.read_csv('scan_results.csv')
# 过滤需要认证的响应
df = df[df['auth_required'] == False]

发现的数据类型

1. Kubernetes生产集群日志：包含实时SSH登录记录、内核日志
2. 企业研发看板：暴露Jira任务、客户数据、代码示例
3. 医疗数据：个人疫苗接种信息
4. 加密货币平台：代币交换记录
5. 银行转账数据：包含全名和银行账号
6. 车载系统实时数据：IMEI、GPS坐标、燃油状态

安全验证方法

通过Google搜索数据库中的关键字确认数据真实性，而非蜜罐：

1
2
3
4
5

// ElasticSearch文档示例
{
  "user": "john.doe@company.com",
  "transaction": "BTC 0.5 → ETH"
}

已遭勒索的服务器

部分开放集群已被勒索软件破坏，攻击者使用elasticsearch-dump工具备份数据后删除原数据，并留下比特币勒索信息。

责任归属问题

AWS回复称资产配置安全属于客户责任，但其公开CIDR块的设计极大降低了攻击者的扫描成本。作者建议：

• 对开放服务实施严格的认证授权
• 避免使用默认VPC子网配置
• 提升内部安全可见性

“如果向公网开放服务，至少应该使用适当的认证机制” —— 作者在邮件中向AWS提出的建议

技术总结

1. 云服务CIDR块的公开是一把双刃剑
2. 配置错误导致的暴露将持续存在
3. 缺乏主动监控机制使问题恶化
4. 现有责任共担模型需要改进

数小时内扫描到的337,000+个AWS ElasticSearch服务开放端口

作者最后强调，任何规模的企业都可能出现配置错误，网络上的"观察者"可能比想象中更多。本文所有发现均已报告相关方，部分问题至今未修复。