MongoDB 赎金事件持续发酵,究竟是谁之过?

王练
 王练
发布于 2017年01月12日
收藏 8

数以万计的个人和可能专有的数据库被从网上删除,替换为要求支付赎金才会返还的票据。雪上加霜的是,似乎还几乎没有一个已经支付赎金的受害者的数据,有得到他们丢失的文件。

MongoDB 官方团队的回答是,MongoDB 数据库本身是具有企业级安全性的,受攻击 MongoDB 的实例大都是因为没有遵照生产环境部署手册部署的结果,这些攻击其实完全可以通过 MongoDB 中内置的完善的安全机制来预防。

可以看到,数以万计的组织使用 MongoDB 来存储数据,但从近两年曝出的情况来看,容易配置错误,并且使数据库在线暴露。例如,2016年3月,Verizon 企业解决方案因为一个可公开访问的 MongoDB,泄漏了大约150万客户的联系信息。而且有安全研究人员表示,他发现了一个巨大的开放 MongoDB 数据库,任何人都可以通过 Shodan 搜索所有开放的 MongoDB 数据库。

从下图可以看到,目前在互联网上有将近52,000个可公开访问的 MongoDB 数据库。其中最多的是在美国,其次就是中国。


正常情况下,当在 Shodan 上运行查询以列出所有可用的 MongoDB 数据库时,返回的是一个不同名称的数据库列表,以及许多具有默认文件名(如“local”)的数据库。但是当研究员在本周早些时候进行同样的查询时,他注意到查询返回的数据库列表里多了许多额外的名称,如“readme”、“readnow”、“encrypted”和“readplease”。这里面对应的包括联系人电子邮件地址和/或比特币地址和付款地址等数据库文件。

研究员称目前至少有29,000个之前在线发布的 MongoDB 数据库已被删除。更糟糕的是,几乎没有任何支付了赎金的人有收到他们的文件。

这就像绑架者一直提供赎金票据,但你却不知道谁有真正的原始数据一样,研究员 Merrigan 建议受害者不要支付赎金。如果确实要去付,也最好先从勒索者那里要求提供“生命证明”,即让他们共享一个或两个被删除的文件,以证明他们可以恢复整个缓存。

事情发酵至今,各种说法都有。有人说:

1:如果你连接到互联网,就会有人试图攻击它。

2:如果你放在互联网上的东西有价值,就会有人投入时间和精力去窃取它。

3:组织和个人往往不愿意花费资产中的一小部分来保护的整个资产免受网络攻击者的威胁,让自己安心。

编译整理自:KrebsonSecurity.com

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:MongoDB 赎金事件持续发酵,究竟是谁之过?
加载中

精彩评论

blu10ph
blu10ph

引用来自“游客”的评论

我在刚到上一家公司工作的时候,公司项目的 MongoDB 暴露在外网,而且没有设置密码,可以直接使用 MongoVUE 访问。MySQL 使用的是 root 用户,而且密码是简单的 123456。后来才知道没有运维,MongoDB 和 MySQL 是开发人员部署的。然后我就把 MongoDB 设置了密码,并且把 MySQL 从新授权了用户。结果开发人员就不高兴了,说这样影响了他们的开发,搞的大家很不愉快。
😳设置个数据库连接就能影响开发的话,把这帮人辞了吧~
烽火云烟
烽火云烟
所有数据库本身就是不应该暴露到公网,只有遵从这点,没有密码也没有关系。

最新评论(23

抢小孩糖吃
抢小孩糖吃

引用来自“游客”的评论

我在刚到上一家公司工作的时候,公司项目的 MongoDB 暴露在外网,而且没有设置密码,可以直接使用 MongoVUE 访问。MySQL 使用的是 root 用户,而且密码是简单的 123456。后来才知道没有运维,MongoDB 和 MySQL 是开发人员部署的。然后我就把 MongoDB 设置了密码,并且把 MySQL 从新授权了用户。结果开发人员就不高兴了,说这样影响了他们的开发,搞的大家很不愉快。

引用来自“脆霉公园”的评论

设个密码的事情,开发怎么会不方便?

引用来自“Raphael_goh”的评论

每次查数据要多输一个密码呗,密码记不住,还要翻笔记

引用来自“shijunti”的评论

脑子啊,我都是客户端查的
你们不封装成rest,加个token什么的,直接数据库暴露给客户端?
抢小孩糖吃
抢小孩糖吃

引用来自“游客”的评论

我在刚到上一家公司工作的时候,公司项目的 MongoDB 暴露在外网,而且没有设置密码,可以直接使用 MongoVUE 访问。MySQL 使用的是 root 用户,而且密码是简单的 123456。后来才知道没有运维,MongoDB 和 MySQL 是开发人员部署的。然后我就把 MongoDB 设置了密码,并且把 MySQL 从新授权了用户。结果开发人员就不高兴了,说这样影响了他们的开发,搞的大家很不愉快。
生产环境和测试环境不脱离,哪天程序员写错了,删错数据就好玩了
Feng_Yu
Feng_Yu
准确来说是企业的锅,不肯请运维来维护产品环境,直接让开发部署瞎搞。国内大多数开发根本没有产品环境的安全意识
blu10ph
blu10ph

引用来自“游客”的评论

我在刚到上一家公司工作的时候,公司项目的 MongoDB 暴露在外网,而且没有设置密码,可以直接使用 MongoVUE 访问。MySQL 使用的是 root 用户,而且密码是简单的 123456。后来才知道没有运维,MongoDB 和 MySQL 是开发人员部署的。然后我就把 MongoDB 设置了密码,并且把 MySQL 从新授权了用户。结果开发人员就不高兴了,说这样影响了他们的开发,搞的大家很不愉快。
😳设置个数据库连接就能影响开发的话,把这帮人辞了吧~
脆霉公园
脆霉公园

引用来自“游客”的评论

我在刚到上一家公司工作的时候,公司项目的 MongoDB 暴露在外网,而且没有设置密码,可以直接使用 MongoVUE 访问。MySQL 使用的是 root 用户,而且密码是简单的 123456。后来才知道没有运维,MongoDB 和 MySQL 是开发人员部署的。然后我就把 MongoDB 设置了密码,并且把 MySQL 从新授权了用户。结果开发人员就不高兴了,说这样影响了他们的开发,搞的大家很不愉快。

引用来自“脆霉公园”的评论

设个密码的事情,开发怎么会不方便?

引用来自“Raphael_goh”的评论

每次查数据要多输一个密码呗,密码记不住,还要翻笔记

引用来自“shijunti”的评论

有软件的
没有方便不方便的问题,就是懒的问题。
雨翔河
雨翔河
这种问题跟啥数据库没关系。
shijunti
shijunti

引用来自“游客”的评论

我在刚到上一家公司工作的时候,公司项目的 MongoDB 暴露在外网,而且没有设置密码,可以直接使用 MongoVUE 访问。MySQL 使用的是 root 用户,而且密码是简单的 123456。后来才知道没有运维,MongoDB 和 MySQL 是开发人员部署的。然后我就把 MongoDB 设置了密码,并且把 MySQL 从新授权了用户。结果开发人员就不高兴了,说这样影响了他们的开发,搞的大家很不愉快。
我这的话,测试数据库本地的和这一样,正式库不对外
shijunti
shijunti

引用来自“游客”的评论

我在刚到上一家公司工作的时候,公司项目的 MongoDB 暴露在外网,而且没有设置密码,可以直接使用 MongoVUE 访问。MySQL 使用的是 root 用户,而且密码是简单的 123456。后来才知道没有运维,MongoDB 和 MySQL 是开发人员部署的。然后我就把 MongoDB 设置了密码,并且把 MySQL 从新授权了用户。结果开发人员就不高兴了,说这样影响了他们的开发,搞的大家很不愉快。

引用来自“脆霉公园”的评论

设个密码的事情,开发怎么会不方便?

引用来自“Raphael_goh”的评论

每次查数据要多输一个密码呗,密码记不住,还要翻笔记
有软件的
eechen
eechen
中国是最大的美粉,看到人家美利坚的程序员不设密码开放访问,自己也跟风干,毕竟美利坚是人类希望嘛,哈哈.
shijunti
shijunti

引用来自“游客”的评论

我在刚到上一家公司工作的时候,公司项目的 MongoDB 暴露在外网,而且没有设置密码,可以直接使用 MongoVUE 访问。MySQL 使用的是 root 用户,而且密码是简单的 123456。后来才知道没有运维,MongoDB 和 MySQL 是开发人员部署的。然后我就把 MongoDB 设置了密码,并且把 MySQL 从新授权了用户。结果开发人员就不高兴了,说这样影响了他们的开发,搞的大家很不愉快。

引用来自“脆霉公园”的评论

设个密码的事情,开发怎么会不方便?

引用来自“Raphael_goh”的评论

每次查数据要多输一个密码呗,密码记不住,还要翻笔记
脑子啊,我都是客户端查的
返回顶部
顶部