无需身份验证的开放式 MongoDB 数据库实例正在遭受多个黑客组织的攻击，被攻破的数据库内容会被加密，受害者必须支付赎金才能找回自己的数据。

攻击者利用配置存在疏漏的开源 MongoDB 数据库展开了一系列勒索行为。此番针对 MongoDB 的勒索行为最早是由 GDI Foundation 的安全研究人员 Victor Gevers 在 2016 年 12 月 27 日发现的，在这之后影响陆续扩大，目前至少有五个不同黑客组织控制了上万个数据库实例。

截至目前，最后一个加入此次 MongoDB 勒索行动的黑客组织是由安全研究人员 Nial Merrigan 在 1 月 6 日发现的。目前，MongoDB 攻击者的身份信息只有用于支付赎金的电子邮件地址，最新加入的黑客组织所用的邮件地址为 3lix1r@mail2tor.com，该地址已攻陷至少 17 个 MongoDB 实例，要求受害者支付 0.25 个比特币才能找回数据。

目前在 Google Docs 上有一个列表，其中列出了参与此次攻击的黑客组织名单，具体数量还在增加中。攻击者所要求支付的金额各异，最低仅 0.15 个比特币，但也有高达 1 个比特币的赎金。2017 年至今，比特币的价值上下波动，截止 1 月 6 日，具体金额约等于 892 美元。

此次针对 MongoDB 的攻击非常简单，利用了配置有误且可公开访问的数据库，无须具备相应的管理员凭据即可展开攻击。一旦攻击者登录到开放的数据库，随后会全面夺取控制权并窃取或加密数据库，被勒索的受害者必须支付赎金才能找回自己的数据。

很多 MongoDB 数据库处于开放状态，这种情况早已存在。2015 年 12 月，安全研究人员 Chris Vickery 就曾使用 Shodan 搜索工具找到了很多端口开放的 MongoDB 服务器。当时 Vickery 甚至找到了一个被 Mac OS X 工具软件 MacKeeper 的开发者 Kromtech 使用的，配置存在疏漏的 MongoDB 数据库。

Shodan 的创始人 John Matherly 跟进了 Vickery 的研究结果，并在 2015 年 12 月称，当时互联网上共有至少 35,000 个可公开访问，无须身份验证的 MongoDB 实例，一年过去了，直到 2017 年 1 月，开放式 MongoDB 数据库的数量不降反增，估计目前共有多达 99,000 个数据库处于风险中。

作为应对此次 MongoDB 安全隐患的有效措施，数据库管理员需要参考 MongoDB 网站上提供的安全清单进行排查。首先需要启用访问控制并强制进行身份验证。

安全研究人员对 eWEEK 表示，MongoDB 被攻击者进行勒索完全在意料之中。

考虑到 MongoDB 的流行度以及在生产环境中的普及率，以开源的数据库作为目标并不会让人惊讶。 Dome9 共同创始人兼首席执行官 Zohar Alon 向 eWEEK 说到：通常来说，数据库部署过程中的配置疏漏和疏忽就会导致可被攻击者利用的弱点。

Alon 还补充说，用户的人为错误与不够强的安全意识也会威胁到云环境中运行的工作负载。他建议在使用开源数据库等第三方软件之前，用户应该自学相关知识，掌握最佳实践和已知弱点等内容。

有趣的是，大部分人认为数据库是足够安全的，因为可以受到防火墙和数据中心的保护， Jean-Franois Dub 首席技术官 RiskVision 告诉 eWEEK ：问题在于攻击者依然可以通过消费者所用的端点和第三方连接访问这些服务器并获取信息。

Dub 建议总的来说，应当定期对数据库进行风险评估。

使用风险评估工具对数据库进行近乎实时监视的企业，会在加密后的数据离开数据库时更清楚地发现这一切，他说。

Mimecast 公司网络安全战略师 Matthew Gardiner 评论说，此次 MongoDB 被攻击完全没有让他感到意外。

一处开放的，无须身份验证的，存有宝贵数据的系统，或其他任何重要的系统，被互联网将规模放大上千倍后，最大的问题在于：攻击者为什么等到现在才开始下手？Gardiner 说。

云栖社区上有人给出了简单的解决方案，建议所有用户立即处理：

不论你有没有中招，有没有在公网，都要配置鉴权，亡羊补牢，避免更多的损失；

关闭公网的访问入口，把门关上；

碰碰运气，看看数据表是不是只是被 rename 了，因为数据 dump 是有时间成本和存储成本的，有监控数据的可以对比下看看容量有没有变化。

济宁IT新闻