超 2 亿中国用户简历曝光！MongoDB 又一重大安全事故

近日，外网安全研究人员偶然发现一个没有被很好保护的 MongoDB 数据库服务器，整个实例包含 854GB 数据，共有 202,730,434 条记录，其中大部分是中国用户简历，内容非常详细，包括中文全名、家庭住址、电话号码、电子邮件、婚烟状况、政治关系、期望薪水等内容。Hacken Proof 网络风险研发主管 Bob Diachenko 认为，这应该是服务器数据在线泄露。

该信息对整个互联网开放，因此追踪信息来源几乎是不可能的，但经过 Twitter 上一位用户的努力，已确定大致来源为一个已经删除的 GitHub 存储库，该存储库包含 Web 应用程序的源代码，此应用程序具有与泄露数据库中数据结构完全相同的数据，这清楚表明该程序应该是一个收集用户简历的第三方应用。

据此用户查证，该已删除应用的简历主要来源之一是 bj.58.com ，当 Diachenko 与 bj.58.com 工作人员联系时，他们也给出了初步评估，确定数据来自第三方应用泄露，并非官方泄露。

由于 Diachenko 在 Twitter 上寻求帮助的行为引起了数据库所有者的注意，因此，目前该数据库已经得到保护。据悉，该安全研究员上个月也曾发现一个类似的 MongoDB 服务器，暴露了超过 6600 万条记录，似乎最初来自于 LinkedIn。

2017 年，58 也曾发生一起数据泄露事件，当时只需支付 700 元购买一种爬虫软件，用卖家提供的账号登录后就能不断采集应聘者相关信息，该软件每小时可以采集数千份用户数据。58 方面当时给出的回应是：非官方泄露，黑客攻击所致。

MongoDB 安全门事件

此前，MongoDB 也多次出现安全问题。无需身份验证的开放式 MongoDB 数据库曾遭到多个黑客组织的攻击，被攻破的数据库内容会被加密，受害者必须支付赎金才能找回自己的数据。

• 2016 年 12 月底,MongoDB 遭黑客攻击，事情在 2017 年 1 月达到顶峰。攻击者利用配置存在纰漏的 MongoDB 展开勒索行为，自称 Harak1r1 的黑客组织将网络上公开的 MongoDB 资料库中的资料汇出，并将 MongoDB 服务器上的资料移除。起初两百个 MongoDB 数据库实例的数据被非法清除，几天之内，受感染的 MongoDB 数据库实例已经增长至一万多台。开始攻击者要求受害人支付 0.2 个比特币 (当时的价值约为 184 美金) 作为数据赎金，随着被感染的数据库越来越多，攻击者将勒索赎金提升至 1 个比特币 (价值约为 906 美金)。此次事件被称为“MongoDB 启示录”。

• 2017 年 9 月，MongoDB 数据库再次遭到黑客勒索攻击，三个黑客团伙劫持了 2.6 万余台服务器。与“MongoDB 启示录”相比，此次攻击者的数量有所下降，但每次攻击的破坏性（受害者）数量上升。

MongoDB 为何如此易受攻击

MongoDB 出现时，凭借简单的部署方式，高效的扩展能力、多样化的语言接口，并借着云蓬勃发展的势头，一度在全球数据库市场占据第四名。但是，MongoDB 也存在安全风险。在 一篇文章 中，作者分析了 MongoDB 的最大的安全问题来源于 MongoDB 的默认配置。在默认部署情况下，MongoDB 无需身份验证，即可登录，不法分子只要在互联网上发现 MongoDB 的地址和端口就可以通过 工具 直接访问 MongoDB，并拥有 MongoDB 的全部权限，从而进行任意操作。之所以会如此设计，原因在于：

• MongoDB 默认通过最简单部署方式，最大限度提高运行速度，以在虚拟机（低配机）上运行而定制的，并未充分考虑 MongoDB 的安全性。

• MongoDB 官方文档，如针对身份验证，传输加密，网络配置的文档、指南并不规范，容易误导 MongoDB 管理员。

• 一些 MongoDB 环境是为了单一项目或者是测试环境搭建，搭建者并不关心 MongoDB 的安全问题。

徐飞博士在极客时间的专栏 《技术与商业案例解读》 中也总结过，MongoDB 作为一个文档数据库，在开发策略上把绝大部分注意力都放在提高产品易用性上，也花了不少功夫来打开市场，但是在安全方面投入的精力相对很少。

如何防范隐私数据被泄漏

随着隐私数据泄漏的情况变得越来越普遍，组织应该认识到正确保护第三方数据库服务器的重要性，并采取必要的步骤来加密数据，以确保在恶意目的下无法使用。去年 8 月底华住集团泄露 2 亿多开房记录的事件闹得沸沸扬扬，InfoQ 在对事件的报道中也向大家提供了防范数据泄漏的建议：

• 更换端口：不使用默认端口虽然无法杜绝黑客的入侵，但可以相对增加入侵难度；

• 公网屏蔽：只监听内网端口屏蔽公网端口的请求，通过该策略继续增加黑客的入侵难度；

• 使用普通用户启动：建议大家维护的所有 db 都使用禁止登录的非 root 用户启动；

• 开启验证：这虽然是复杂、痛苦的一步，但却是明智的选择；

• 权限控制：建议大家针对自己维护的数据库设置一套适合对应业务的权限控制、分配方案；

• 备份策略：一套可靠的本地备份逻辑 + 远程备份存储方案可以解决被黑、误删、机房漏水、服务器报销，甚至机房被核弹炸毁的场景；

• 恢复策略：建立一套能够覆盖多数灾难场景的恢复策略来避免手忙脚乱是非常必要的；

• 敏感数据加密存储：我们建议大家一定对任何敏感信息加密后再入库，例如：密码、邮箱、地址等等。

此类事件频发也表明，安全是个不容忽视的问题，希望各厂商、开发者能够重视安全问题，避免造成不必要的损失。