MongoDB事件之后，再起波澜
经过在MongoDB各服务器间长达数日的肆虐，一群恶意分子又开始将其劫持矛头指向ElasticSearch服务器，并要求受害者支付类似的赎金。
第一波针对ElasticSearch服务器所有者的打击发生于1月12日，其中部分受害者通过ElasticSearch论坛反映了相关情况。
与此前曾经出现的MongDB劫持活动类似，如今新一波指向ElasticSearch集群的恶意入侵再次袭来。目前全球各地的ElasticSearch集群正受到大范围劫持，其中仅留下一条与赎金要求相关的索引定义，具体如下所示：
根据已经报告的勒索说明，攻击活动似乎全部源自同一黑客组织，名为P1l4tos。留言中写明：
如果希望恢复你的数据库，向以下钱包中发送0.2比特币：1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r！在比特币发送完成后，向p1l4t0s@sigaint.org邮箱发送你的服务器IP。
截至撰稿之时，以上列出的比特币地址仅收到一笔赎金款项。
关于此次ElasticSearch劫持更多细节
已有超过800台服务器遭受劫持
作为持续关注此前MongoDB攻击活动的安全研究人员之一，Niall Merrigan已经开始追踪本轮ElasticSearch攻击活动。截至本文撰稿时，Merrigan在twitter上的最新报告称已经有超过800台服务器遭受劫持。
ElasticSearch是一套基于Java的搜索引擎，主要用于在各类大型Web服务及企业网络当中进行信息检索。
据称，攻击者利用低强度、易猜出的密码对暴露在互联网当中的各ElasticSearch服务器发起入侵。
目前，仍有约35000台ElasticSearch服务器在线运行
根据Shodan查询结果显示，目前仍有约35000个ElasticSearch实例可通过互联网进行接入。2015年8月，来自BinaryEdge公司的安全专家们发现当时在线运行的ElasticSearch实例仅为8990个，而其时个中包含的信息总量为531199 TB。
安全界早有预警
2015年12月，AlienVault通过实验发现，攻击者能够利用两项不同的安全漏洞对ElasticSearch服务器进行劫持，并将其添加至僵尸网络当中。
MongoDB也有相同的境遇，在MongoDB事件发生前，其实业界已经告知很多MongoDB数据库处于令人不安的开放状态。2015年12与，Shodan经过调查之后发现当时互联网上共有至少35,000个可公开访问，无须身份验证的MongoDB实例。（悲伤的是，一年多之后，开放式MongoDB数据库的数量不降反增，估计共有多达99,000个数据库有被劫持风险。）
技术反思 and“一语成谶”
随着此前针对MongoDB服务器之攻击活动的出现，业内人士考虑其需要花费多长时间才会将恶意矛头指向其它技术方案。
Bleeping Computer的安全观察员Catalin Cimpanu曾经在2017年1月9日公开表示其担忧：
我在考虑这些MongoDB劫持者需要多长时间来发现其它互联网可访问目标，包括Redis、CouchDB以及ElasticSearch服务器。
问题的答案是三天。
其它可能的潜在攻击目标还包括Apache CouchDB、Redis以及Memcached，其皆可通过互联网轻松访问且在安全水平上甚至不及MongoDB。
Elastic公司官方：正确配置，防止数据丢失
ES的劫持事件发生第二天，2017年1月13日，Elastic公司撰写了一篇博客“保护您的数据免受勒索攻击侵扰”。文中表示此次事件对Elastic Cloud的客户影响甚微，其中安全产品X-Pack 会随机分配彼此独立密码的配合。而对于其他用户，Elastic公司不建议将ElasticSearch实例暴露在互联网中；对于已有的非安全且面向互联网的Elasticsearch，Elastic公司同样给出了六条建议。
附文章地址为： https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom 。
下面为全文译文：
上周末，一轮恶意攻击的大规模来袭导致数千台开源数据库中的数据遭遇复制、删除及勒索性加密等严重问题。尽管上述攻击活动中并未使用任何恶意软件或者“勒索软件”，且与产品安全漏洞并无关联，但最终仍然造成了严重的数据丢失甚至数据泄露安全事故。不过好消息是，我们完全可以通过正确配置轻松防止类似攻击行为造成的数据丢失后果。
因此，让我们以此为鉴高度关注Elasticsearch实例的安全保护工作，特别是保护那些可通过互联网加以接入的实例。
选择使用Elastic Cloud的客户可以放心，其使用随机分配的彼此独立密码配合X-Pack安全产品对集群加以保护。客户为这些集群选择对应的AWS服务区，而集群本身亦被部署在冗余防火墙及代理之后。默认配置提供来自互联网的加密TLS通信内容，且Elastic每七天对集群数据进行一次备份。
对于其它部署选项，我们强烈建议大家确保那些可能存在安全问题的Elasticsearch实例不会直接暴露在互联网当中。具体请参阅我们2013年发布的博文。我们还将相关建议以localhost内默认安装绑定的形式加以实施。尽管如此，面对各类互联网可访问实例，我们已经意识到其中存在的安全隐患。
如果大家拥有一套非安全且面向互联网的Elasticsearch实例，那么我们强烈建议您立即采取以下措施以保护您的数据：
- 对全部数据备份至安全位置，并考虑使用Curator快照。
- 对您的环境进行重新配置，从而将Elasticsearch运行一套隔离型不可路由网络当中。
- 如果您必须通过互联网访问对应集群，请通过防火墙、VPN、反向代理或者其它技术手段限制来自互联网的集群访问请求。
- 而作为最佳实践原则，我们始终建议您：
- 升级至Elastic Stack的最新版本。
- 如果您运行的是v2.x版本，请检查您的scripting设置; 在新的v5.x版本中则请检查Painless脚本设置。
- 利用X-Pack安全工具添加TLS加密、验证、授权以及IP过滤等功能，从而保护您Elasticsearch实例。
发表评论