据外媒 ZDNet 报道,2.29 万在网上暴露的 MongoDB 数据库被黑客勒索。据悉,这名黑客利用一个自动化脚本扫描配置错误的 MongoDB 数据库,删除数据库中的内容,然后留下一条勒索信息,要求用户支付 0.015 比特币(相当于 140 美元)。
这名攻击者给数据库所有者两天时间来支付赎金。如果不支付赎金,攻击者还有“Plan B":威胁受害者泄露他们的数据,并且联系受害者本地的 GDPR 监管机构,向其报告数据泄露事件。
这样一来,即使受害者不支付赎金,也将面临GDPR监管机构所带来的压力。
据了解,这 2.29 万被勒索的 MongoDB 数据库占网上全部暴露的 MongoDB 数据库的 47%。
攻击者植入的勒索信息最早于 2020 年 4 月被发现。Victor Gevers 是 GDI 基金会的一名网络安全研究者,其部分职责是向公司报告在网上暴露的服务器。他表示,最初的攻击行动并不包括删除数据库中的数据。
攻击者继续连接到同一数据库,留下赎金记录,几天后再次返回以留下赎金记录的另一个副本。Gevers 称,攻击者似乎意识到它们在脚本中犯了错。不久之后,攻击者修正了它们的脚本,现在实际上是在清除 MongoDB 数据库。
尽管这些数据库中的一部分看似是测试用例,但是 Gevers 表示,一些生产系统也受到冲击。
MongoDB 勒索事件
黑客们侵入用户的 MongoDB 数据库,把数据全部删掉,然后留下一条消息,要求用户用比特币支付价值几千美元的赎金。这种攻击行动被称为“MongDB 勒索事件”。
事实上,MongoDB 勒索事件曾在几年前数次上演。
2016 年 12 月底,MongoDB 遭黑客勒索,此事在 2017 年 1 月达到顶峰。攻击者利用配置存在纰漏的 MongoDB 展开勒索行为,自称 Harak1r1 的黑客组织将网络上公开的 MongoDB 资料库中的资料汇出,并将 MongoDB 服务器上的资料移除。起初两百个 MongoDB 数据库实例的数据被非法清除,几天之内,受感染的 MongoDB 数据库实例已经增长至一万多台。开始攻击者要求受害人支付 0.2 个比特币 (当时的价值约为 184 美金) 作为数据赎金,随着被感染的数据库越来越多,攻击者将勒索赎金提升至 1 个比特币 (价值约为 906 美金)。此次事件被称为“MongoDB 启示录”。
这种攻击行动让黑客意识到,它们可以通过清除 MongoDB 服务器并留下勒索信息,诱骗那些迫切希望取回文件的服务器所有者,最后赚取更多的钱。
2017 年 9 月,MongoDB 数据库再次遭到黑客勒索攻击,三个黑客团伙劫持了 2.6 万余台服务器。与“MongoDB 启示录”相比,此次攻击者的数量有所下降,但每次攻击的破坏性(受害者)数量上升。
在 2017 年,MongoDB 产品安全资深主管 Davi Ottenheimer 谴责这种行为,并指出发生此事的原因之一是数据库所有者未能给数据库设置密码,并将没有配置防火墙的服务器暴露在网上。
近 3 年后,这一切几乎没有任何变化。
2017 年初,有 6 万台 MongoDB 服务器在网上暴露,而现在,还有 4.8 万台服务器暴露于网上,关键是其中大多数没有启用身份验证。
安全问题的背后原因
MongoDB 为何如此易受攻击?
在这篇文章中,作者指出:MongoDB 的最大的安全问题来源于 MongoDB 的默认配置。在默认部署情况下,MongoDB 无需身份验证,即可登录,不法分子只要在互联网上发现 MongoDB 的地址和端口就可以通过工具直接访问 MongoDB,并拥有 MongoDB 的全部权限,从而进行任意操作。之所以会如此设计,原因在于:
MongoDB 默认通过最简单部署方式,最大限度提高运行速度,以在虚拟机(低配机)上运行而定制的,并未充分考虑 MongoDB 的安全性。
MongoDB 官方文档,如针对身份验证,传输加密,网络配置的文档、指南并不规范,容易误导 MongoDB 管理员。
一些 MongoDB 环境是为了单一项目或者是测试环境搭建,搭建者并不关心 MongoDB 的安全问题。
对于 MongoDB 勒索事件,MongoDB 中文社区发起人、MongoDB 官方大中华区首席架构师唐建法在《“没有一个技术是完美的”: MongoDB十年发展全纪录》总结道:
MongoDB,为了最大程度上方便程序员快速开发应用,默认方式下不需要设置用户名密码登录。这样一来,很多粗心的程序员,特别是创业公司,往往在系统正式上线时候也没有启用鉴权。就譬如你买了一套房子却没有使用门锁一样。
在笔者看来,对任何使用 MongoDB 的人来说,安全至关重要。一旦疏忽,MongoDB 暴露于网上,遭遇勒索是小事,如果数据被删除,那么损失是无限的。
评论 7 条评论