Elasticsearch泄露27亿邮件数据，涉及多家知名邮箱

SecurityDiscovery 网站的网络威胁情报总监鲍勃·迪亚琴科（Bob Diachenko）发文称：“我们发现了一个 Elasticsearch 数据库泄露，包括了 27 亿个电子邮件地址，其中 10 亿个密码都是以简单的明文存储的。其中大多数被盗的邮件域名来自中国的邮件提供商，腾讯、新浪、搜狐和网易等都在内，发现了包括 qq.com，139.com，126.com，gfan.com 和 game.sohu.com 等域名。另外，雅虎、Gmail 以及一些俄罗斯的邮件域名也受到了影响。”

该数据泄露的 Elasticsearch 数据库被发现的情况为：

• 2019 年 12 月 1 日：该数据库首先由 BinaryEdge 搜索引擎建立索引，此后公开可用。
• 2019 年 12 月 4 日：Diachenko 发现了数据库，并立即采取措施通知责任方。
• 2019 年 12 月 9 日：禁止访问数据库。

据了解，这次数据泄露的 Elasticsearch 服务器属于美国的一个托管服务中心。2019 年 12 月 9 日，在 Diachenko 发布数据库存储安全报告之后，该托管服务中心关闭了 Elasticsearch 服务器，但是其至少对外开放了一周的时间，并且允许任何人在无密码的情况下访问。

本次泄露的数据除了电子邮件地址和密码，还包括了每个电子邮件地址的 MD5，SHA1 和 SHA256 散列。哈希加密的电子邮件地址文本具有固定的长度，因为存储文本数据风险太大，所以往往会用来安全存储数据，泄露数据库的所有者用每个地址的 MD5、SHA1 和 SHA256 散列对电子邮件地址进行了操作，很大可能是用来简化关系数据库的搜索。

目前，被泄露的 27 亿个电子邮件地址还无法证实是否为有效地址，但可以确定的是其来源违规。Diachenko 表示：“这些电子邮件的泄露往往不会引起企业的重视，但实际上它们受到攻击的可能性很高。”这些电子邮件一旦引发攻击行为，用户往往不会收到警报，因为国内的防火墙阻止了检查电子邮件泄露的服务。

虽然还不清楚是谁公开了数据库，可能是黑客，又或者是安全研究人员。但是确定的是，这种行为都忽略了 Elasticsearch 本来提供的安全性选项，也忽略了云存储安全的重要性。一旦黑客获得了帐户访问权限，他们就可以通过更改密码和关联的电子邮件来劫持该帐户，达到多种目的，包括垃圾邮件、网络钓鱼、欺诈、盗窃等。

Diachenko 称：“单就数字而言，这可能是我所看到的泄露数据最庞大的一次。”

原因分析

事实上，Elasticsearch 数据库泄露事件时有发生，就在不到一个月之前，Bob Diachenko 和 Vinny Troia 发现了一个公开可访问的 Elasticsearch 服务器，其中包含 12 亿用户账户，该服务器被公开在暗网上。

2019 年 1 月，InfoQ 盘点了该月发生的 Elasticsearch 数据泄露事件，据不完全统计，一个月就有 6 起数据泄露事件。通过分析这些事件，我们发现大部分泄露的原因都是 Elasticsearch 服务器没有设置密码保护。

为什么大家不设置密码保护呢？之前我们采访技术专家称：“很有可能是团队忽视了数据安全，再加上服务器防火墙对于端口开放策略过于激进，导致 Elasticsearch 集群只要一部署即可公网访问。另外，不少开发人员及其团队在认知上更多地把 Elasticsearch 看成是与 MySQL 同等的存储系统，所以在部署以后并没有太多地关心其访问控制策略和数据安全。而且 Elastisearch 开箱即用的特点也让开发和运维人员放松了对安全的重视。”

如何预防数据泄露？

如何预防数据泄露呢？首先，Elasticsearch 开源版本是不具备任何数据保护功能的，只有基本的攻击保护，例如防火墙。不过，Elasticsearch 产品的提供商 Elastic 为订阅用户提供了相关的数据保护功能，例如认证和授权、数据加密（通讯加密）、审计合规等。如果自己搞不定安全问题，选择商业版本也是一条不错的路子。

如果只想开源版本，技术专家也给出了几个低成本的防止数据泄露的措施：

1）服务器必须要有防火墙，不能随意对外开放端口；

2） Elasticsearch 集群的端口包括 TCP 和 HTTP，都不能暴露在公网；

3） Elasticsearch 集群禁用批量删除索引功能；

4） Elasticsearch 中保存的数据要做基本的脱敏处理；

5）加强监控和告警，能够在安全事件发生的第一时间感知并启动紧急预案，将损失降到最低。