西海数据丨推荐 一场屠戮MongoDB的盛宴反思：超33000个数据库遭遇入

Posted 2021-05-01 NoSQLt

每天一点小知识：Nosqlt安装好之后起不来，看一看是否有360等安全软件拦截了Nosqlt的服务注册。

许多人没有想到，去年12月一件不起眼的小事，在新年伊始却演变成了一场屠杀。如今，受害的一方似乎正由于自身的疏忽和迟钝而显得愈发无力反抗，一个接一个倒下。

截止本周三（1月11日），已经有20名以上的黑客加入到这场对MongoDB用户一边倒的碾压中来，遭到入侵、勒索的数据库超过了33，000个，并且这一数字还在不断上升中。（源自凯捷咨询的Niall Merrigan提供的数据）MongoDB是目前包括eBay，纽约时报，LinkedIn在内的全世界多家公司广泛采用的数据库。

源于0.2比特币的勒索

去年12月27日，安全专家兼GDI Foundation联合创始人Victor Gevers（@0xDUDE）在Twitter上称由于存在配置漏洞，可不通过任何认证直接访问某些MongoDB数据库，而黑客早已盯上了这些目标。当时，第一波被黑的MongoDB数据库中，Gevers观察到数据内容被清空，黑客还留下了一条“WARNING”信息：

“SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !”

MongoDB屠戮全面开启

当时Gevers暂时只统计到了有近200个MongoDB数据库实例（instance）被黑客入侵当做勒索筹码。FreeBuf安全快讯对此进行了追踪报道，在1月3日，这个数字达到了2，000以上。接下来的日子里，攻击规模不断扩大，受害者数量急剧上升。仅在1月9日早间开始的12小时内，受到黑客勒索的数据库就从12，000个翻倍达到了27，633之多。

参与其中的黑客数量也增加到至少15人以上，其中一位名为“kraken0”的黑客已经入侵了15，482个MongoDB数据库并向每位受害者索取了1比特币（约$921）赎金。尽管安全专家已经告诫众多MongoDB数据库用户不要向黑客支付赎金（很多黑客并不会如宣称的那样保留了数据，多数情况是直接删掉了），但已知仍有至少22个受害机构或个人缴纳了赎金。

之所以会有如此众多的数据库实例被这次冲击迅速收割，主要是因为很多使用者没有遵照生产环境部署手册，缺少安全认证，直接将服务器暴露在公网里以及版本过于老旧。对于攻击者而言，使用在线工具就可以较轻松地发现存在问题的数据库。事实上，黑客还发掘到了另一个商机：他们有人开始贩卖用来攻陷数据库的软件赚钱。这种工具被称作“Kraken Mongodb ransomware”，只要价值$200的比特币就可以买到该程序的C#源码。

产生如此后果的另一个重要原因是部分使用者安全意识淡薄，反应迟钝。作为最初发现者的Gevers就曾对SecurityWeek这样吐槽：

“永远不要低估某些公司的反应有多么愚蠢，有些只是移除了勒索信息，还原了数据，却依旧让服务器门户大开。”

Gevers有所怨言是不无道理的。作为安全专家，他长时间致力于数据库漏洞探测并会向企业提供风险报告。然而，他的预警却被许多公司视而不见，仅在去年一年就有138份相关报告石沉大海。即使他对这波攻击迅速做出了告警，却依然收效甚微。

安全组织“ShadowServer”通过AISI（Australian Internet Security Initiative）每天约提供400个MongoDB数据泄漏预警，服务澳洲90%的网络提供商

暗潮涌动

轻视安全问题是要付出代价的。事实上MongoDB数据库泄漏问题早在2015年就被报导过。当时Shodan（搜索引擎）的负责人John Matherly统计到有30，000个以上的MongoDB数据库实例，近600TB的数据暴露于公网之上，无需任何认证就可访问。很多版本滞后的数据库配置文件里没有做IP捆绑（bind_ip 127.0.0.1），在用户不甚了解的时候留下了安全隐患。虽然MongoDB的开发团队在下一个版本里修复了这个问题，但截止事发，仍然有数量众多的数据库管理者没来得及更新。

这次勒索事件的一个显著后果就是世界范围内存储在MongoDB数据库里数据量的大幅下滑。据Merrigan提供的信息显示，在短短3天内就有114.5TB的数据因此消失。据估计，目前网上约有50，000个开放访问的MongoDB数据库，也许用不了多久所有没做好安全措施的数据库都会被黑客攻陷。这个过程需要多久？据Gevers估算，这个过程可能用不了几周。

毫无疑问，黑客们的疯狂给人们敲响了警钟。现在应该会有很多人后悔了。

现在补救还来得及

Gevers确认，目前已有来自包括IP，医疗，金融服务，旅游等行业在内的多家公司就此次攻击事件求助，但他不愿意透露求助企业的名称。他建议：有时一个数据库会被不同的黑客攻击多次，受害者很有可能把赎金给错了人，这更是一个无底洞。因此不仅不要支付赎金，更要想办法让攻击者证明丢失的数据是否还真实存在。Gevers表示，如果有适当的网络监控程序，可以判断丢失的数据是被转移了还是被直接删掉了。不过这样做需要把出站的数据流量同系统日志里的访问记录做多方面比较才行。

MongoDB官方建议如下：

如何知道自己有没有受到攻击：

1. 如果已经为数据库正确配置了访问控制，攻击者应该访问不到数据，可参考安全手册（https://docs.mongodb.com/manual/security/）

2. 验证数据库和集合。在最近的案例中，攻击者丢弃了数据库和/或集合，并用一个ransom需求的新的替换它们。

3. 如果启用访问控制，请审核系统日志以进行未经授权的访问尝试或可疑活动。

如果已经受到攻击：

1. 如果您是MongoDB企业支持客户，请尽快提交P1订单，我们的技术服务工程师可以指导您完成以下过程。

2. 您的首要任务是保护您的集群以防止进一步的未授权访问。您可以参照我们的安全实践文档。

3. 通过运行 usersInfo 来检查是否有添加，删除或修改的用户。

4. 检查日志以查找攻击的时间。检查是否有删库或者删表，修改用户或创建赎金记录的命令。

5. 如果你有定期对受损数据库进行备份，则可以还原最近的备份。您需要评估最近的备份和攻击时间之间可能已更改的数据量。如果您使用Ops Manager或Cloud Manager进行备份，则可以恢复到攻击之前的时间点。

6. 如果您没有备份或以其他方式无法还原数据，那么您的数据可能会永久丢失。

7. 您应该假设攻击者已经复制了受影响的数据库的所有数据。请按照内部安全流程对数据泄露事件进行恰当处理。

8. 最后，请参阅我们的安全最佳做法和资源，以便将来保护您的数据。

如何防范此类攻击？

1. 做好访问认证。打开你的MongoDB配置文件（.conf），设置为auth=true

2. 做好防火墙设置。建议管理者关闭27017端口的访问。

3. Bind_ip，绑定内网IP访问