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

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

图片来源：https://blog.hackenproof.com/industry-news/202-million-private-resumes-exposed

该信息对整个互联网开放，因此追踪信息来源几乎是不可能的，但经过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 用户启动；

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

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

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

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

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

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