从 MongoDB “赎金事件” 看安全问题
今天上午(2017年1月7日),我的微信群中同时出现了两个MongoDB被黑掉要赎金的情况,于是在调查过程中,发现了这个事件。这个事件应该是2017年开年的第一次比较大的安全事件吧,发现国内居然没有什么报道,国内安全圈也没有什么动静(当然,他们也许知道,只是不想说吧),Anyway,让我这个非安全领域的人来帮补补位。
事件回顾
这个事情应该是从2017年1月3日进入公众视野的,是由安全圈的大拿 Victor Gevers (网名:0xDUDE,GDI.foundation 的Chairman),其实,他早在2016年12月27日就发现了一些在互联网上用户的MongoDB没有任何的保护措施,被攻击者把数据库删除了,并留下了一个叫 WARNING 的数据库,这张表的内容如下:
{
"_id" : ObjectId("5859a0370b8e49f123fcc7da"),
"mail" : "[email protected]",
"note" : "SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !"
}
基本上如下所示:
说白了就是黑客留下的东西——老子把你的MongoDB里的数据库给转走了,如果你要你的数据的话,给我0.2个的比特币(大约USD200)。然后,他的twitter上不断地发布这个“赎金事件”的跟踪报道。与此同时,中国区的V2EX上也发现了相关的攻击问题 《自己装的 mongo 没有设置密码结果被黑了》
然后,在接下来的几天内,全球大约有1800个MongoDB的数据库被黑,这个行为来自一个叫 Harak1r1 的黑客组织(这个组织似乎就好黑MongoDB,据说他们历史上干了近8500个MongoDB的数据库,几乎都是在祼奔的MongoDB)。
不过,这个组织干了两天后就停手了,可能是因为这事已经引起了全球科技媒体的注意,产生了大量的报道(如果你在Google News里查一下“mongodb ransom”,你会看到大量的报道(中文社区中,只有台湾有相关的报道)),他们也许是不敢再搞下去了。
不过,很快,有几个copycats开始接着干,
马上跟进的是 own3d ,他们留下的数据库的名字叫 WARNING_ALERT,他们至少干掉了 930个MongoDB,赎金0.5个比特币(USD500),至少有3个用户付费了
然后是0704341626asdf,他们留下的数据库名字叫PWNED,他们至少干掉了740个MongoDB,赎金0.15个比特币(USD150),看看他们在数据库里留下的文字——你的MongoDB没有任何的认证,并且暴露在公网里(你TMD是怎么想的?)……
就在这两天,有两个新的黑客也来了
- 先是kraken0,发现到现在1天了,干了13个MongoDB,赎金 0.1个比特币。
- 然后是 3lix1r,发现到现在5个小时,干了17个MongoDB,赎金0.25比特币。
BBC新闻也于昨天报道了这一情况——《Web databases hit in ransom attacks》,现在这个事情应该是一个Big News了。
关于MongoDB的安全
安全问题从来都是需要多方面一起努力,但是安全问题最大的短板就是在用户这边。这次的这个事,说白了,就是用户没有给MongoDB设置上用户名和口令,然后还把服务公开到了公网上。
是的,这个安全事件,相当的匪夷所思,为什么这些用户要在公网上祼奔自己的数据库?他们的脑子是怎么想的?
让我们去看一下Shodan上可以看到的有多少个在暴露在公网上而且没有防范的MongoDB?我了个去!4万7千个,还是很触目惊心的(下图来自我刚刚创建的 Shodan关于MongoDB的报表)
那么,怎么会有这么多的对外暴露的MongoDB?看了一下Shodan的报告,发现主要还是来自公有云平台,Amazon,Alibaba,Digital Ocean,OVH,Azure 的云平台上有很多这样的服务。不过,像AWS这样的云平台,有很完善的默认安全组设置和VPC是可以不把这样的后端服务暴露到公有云上的,为什么还会有那么多?
这么大量的暴露在公网上的服务是怎么回事?有人发现(参看这篇文章《It’s the Data, Stupid!》 ),MongoDB历史上一直都是把侦听端口绑在所有的IP上的,这个问题在5年前(2011年11月)就报给了MongoDB (SERVER-4216),结果2014年4月才解决掉。所以,他觉得可能似乎 MongoDB的 2.6之前的版本都会默认上侦听在0.0.0.0 。
于是我做了一个小试验,到我的Ubuntu 14.04上去 apt-get install mongodb
(2.4.9版),然后我在/etc/mongodb.conf
文件中,看到了默认的配置是127.0.0.1,mongod启动也侦听在了127.0.0.1这台机器上。一切正常。不过,可能是时过境迁,debain的安装包里已加上了这个默认配置文件。不管怎么样,MongoDB似乎是有一些问题的。
再到Shodan上看到相关的在公网裸奔的MongoDB的版本如下,发现3.x的也是主流:
虽然,3.x的版本成为了主流,但是似乎,还是有很多人把MongoDB的服务开到了互联网上来,而且可以随意访问。
你看,我在阿里云随便找了几台机器,一登就登上去了。
真是如那些黑客中的邮件所说的:WTF,你们是怎么想的?
后续的反思
为什么还是有这么多的MongoDB在公网上祼奔呢?难道有这么多的用户都是小白?这个原因,是什么呢?我觉得可能会是如下两个原因:
1)一是技术人员下载了mongod的软包,一般来说,mongodb的压缩包只有binary文件 ,没有配置文件 ,所以直接解开后运行,结果就没有安全认证,也绑在了公网上。也许,MongoDB这么做的原因就是为了可以快速上手,不要在环境上花太多的时间,这个有助于软件方面的推广。但是,这样可能就坑了更多的人。
2)因为MongoDB是后端基础服务,所以,需要很多内部机器防问,按道理呢,应该绑定在内网IP上,但是呢,可能是技术人员不小心,绑在了0.0.0.0的IP上。
那么,这个问题在云平台上是否可以更好的解决呢?
关于公网的IP。一般来说,公有云平台上的虚拟主机都会有一个公网的IP地址,老实说,这并不是一个好的方法,因为有很多主机是不需要暴露到公网上的,所以,也就不需要使用公网IP,于是,就会出现弹性IP或虚拟路由器以及VPC这样的虚拟网络服务,这样用户在公有云就可以很容易的组网,也就没有必要每台机器都需要一个公网IP,使用云平台,最好还是使用组网方案比较好的平台。
关于安全组。在AWS上,你开一台EC2,会有一个非常严格的安全组——只暴露22端口,其它的全部对外网关闭。这样做,其实是可以帮用户防止一下不小心把不必要的服务Open到公网上。按道理来说,AWS上应该是帮用户防了这些的。但是,AWS上的MongoDB祼奔的机器数量是最多的,估计和AWS的EC2的 基数有关系吧(据说AWS有千万台左右的EC2了)
最后,提醒大家一下,被黑了也不要去付赎金,因为目前来说没有任何证据证明黑客们真正保存了你的数据,因为,被黑的服务器太多了,估计有几百T的数据,估计是不会为你保存的。下面也是Victor Gevers的提示:
(全文完)
(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)
《从 MongoDB “赎金事件” 看安全问题》的相关评论
之前 Redis 也出过这样的问题,默认绑定 0.0.0.0。现在应该都改成 localhost 了。
http://antirez.com/news/96
说真的我接触服务环境差不多有6年,还没见过几个不裸奔的,尤其是不设密码的缓存数据库(MongoDB和Redis为代表),其次是root/root的SQL数据库(MySQL和PSQL为代表)。
曾经见过一个做产品的,我偶然瞟见他redis的监听就是0.0.0.0:6379,我跟他说你加一条iptables,或者监听127.0.0.1或者内网IP。人家说没事,谁会入侵。产品上线一小时后,redis数据库只剩一条String:Hacked.
业余开发者一枚,搭建MongoDB的时候都会把auth启用,默认是不会启用的…可能是因为要多设置密码太麻烦吧…
“我在阿里云随便找了几台机器”
好奇这个怎么找,是密码吗——
现在看起来3.x的mogodb,可能原本安装了2.4.14之前的旧版本,配置文件是0.0.0.0,然后后来升级,配置文件保存没变
黑客们是怎样发现这些暴露的数据库的,技术含量高吗?和绑定到0.0.0.0有什么关系,小白求科普
全网扫描,先扫特定端口27017,然后在扫特征码
话说尼玛阿里云里的redis和mongo也有这问题
友情提示一下,大家不要乱搞这些裸奔的数据库,如果把别人生产数据搞没了是要付法律责任的,是可以反向定位出是谁搞的。
“到我拉Ubuntu 14.04上去” –> “到我的Ubuntu 14.04上去” ?
谢谢,已更改。
实验室的被黑了,查历史日志,登录后就直接删除了,没有任何拷贝操作,所以不要付款
一般都会连历史日志也删除的。难道还要留下操作记录等着被抓么……
有点意思。。。
安全问题重来都是需要多方面一起努力
——> 从来
觉得主要原因是:
1. 没有专业运维人员
2. 开发人员的安全意识太差了(或者说是没有这方面的知识)
我觉得没有专业运维人员这个不妥,开发人员最基本的安全意识还是要有的,不能说明都指望运维人员,不设密码,起码默认端口要改一下吧。。。像很多人都没有这个习惯
我的是内网的哈哈.更重要的是根本没数据
监控所有 IP address 作为默认值没问题啊,只想说 AWS 的 Security Group 是个好东西,为啥就不用呢
你看到的 3.2.8 版本是你本地的 MongoDB Shell 版本,不是所连接的数据库版本,看数据库版本要用 db.version()
哦,是我乌龙了。谢谢
耗子叔总是不忘记顺便黑一下阿里,嘿嘿~~
【因为目前来说没有任何证据证明黑客们真正保存了你的数据,因为,被黑的服务器太多了,估计有几百T的数据,估计是不会为你保存的】
不用额外保存啊,只要他把你的数据库加上密码,就行了
你连接上去会发现,上面的DB都空了。
不知道mongodb的机制。。。。
按常理说,黑客没必要删除db,给用户的db或系统 置一个强密码,用户就无法使用了,黑客自己又能随时恢复或通知付赎金者密码(即使骗用户也多点依据)
mangodb进场出问题阿
到底能搞多少层阿
mongo 45.32.72.8
db.CONTACTME.find()
{ “_id” : ObjectId(“5871c42ab5f3814b92d5679d”), “mail” : “[email protected]”, “note” : “SEND 0.25 BTC TO THIS ADDRESS 17w8EBkCgTQJQAQZ9Bzdf2rZeR5xxfCanV AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER AND PROOF OF PAIEMENT TO RECOVER YOUR DATABASE !” }
阿里云扫一圈27017就知道了
http://dwz.cn/51TzHv
真实的故事,被攻击的教训,愿受害者共勉。
以前一直不理解Shodan的用法,现在才明白……
不错,学习了.感谢分享!
跑个题,
第一次试用Shodan的搜索引擎,建了一个report,
https://www.shodan.io/report/cmSKSGFa
然后跟你的一比,
https://www.shodan.io/report/h0bgF6zM
发现数据多出很多,是因为过去一周多了很多mongoDB exposure? 还是Shodan收集了更多数据?还是耗哥加了什么过滤?
求指教
后续的反思里面列出的第二条原因:需要很多内部机器防问
『访问』
好文章,顶一下,学习不少知识!
谢谢楼主!
看标题吓了我一身冷汗,赶紧点进去看了一下。我去,原来是没有密码的裸鸡,心里舒了一口气。
因为mongodb创建账号超级麻烦,大多数人用默认配置。
当时看到这篇文章怎么没有想到比特币要涨价呢 哎 三个月的囤货时间 今天突然惊醒 可惜反应太慢 博主关注你公众号新文章微信能收到提醒吗?⋯⋯
http://cheapgogenvia.com/ viagra generic date