ElasticSearch Hit by Ransom Attack
Overview
Last week, over 34,000 vulnerable MongoDB databases fell victim to a recent ransom attack. Data residing on these databases was erased or encrypted and bitcoin payment was demanded in lieu for data return. Moreover, on Jan 18th 2017, several hundred ElasticSearch servers were hit by a ransom attack within a few hours and data housed on those servers were erased with ransom requirements. The methods that were used to attack the ElasticSearch servers where extremely similar to the exploit that was used in the MongoDB attack. Security researcher Niall Merrigan (who had been following up the MongoDB database compromise) stated, “till now, over 2711 ElasticSearch servers have been attacked.” Many of the victims reside in the USA, with a few outliers in Europe, China, and Singapore.
Messages similar to the following can be seen on the compromised servers asking for ransoms in the form of Bitcoin payment:
About ElasticSearch
ElasticSearch is a distributed search engine operating on Apache Lucene and supports multi-user, full-text search ability. It is written in Java and is currently an open source code applicable to Apache licensing terms. Additionally, it is recognized as the second most popular enterprise-class search engine (behind Apache Solr), and is often employed for information cataloging and data analysis within cloud computing environments. ElasticSearch supports real-time search functionality, stable performance benchmarks, and seamless configurations operability.
ElasticSearch Server Deployment
As per John Matherly, founder of the Shodan search engine, about 35,000 ElasticSearch servers on the Internet are now facing serious security risks, of which the majority are being hosted by Amazon Web Services.
According to ZDNet, there are approximately 59 servers in China currently compromised due to this active exploit. Although, NSFOCUS Threat Intelligence (NTI) states that the number is in fact quite higher. A suspected 1956 ElasticSearch servers operating out of China are at risk through internet exposure.
ZDNet provides the following diagram illustrating the current ElasticSearch server distribution as of Jan 13 2017:
Credit: zdnet.com
ElasticSearch Distributions by Region
ElasticSearch Distributions by Province
In addition, NSFOCUS NTI detected 39,590 ElasticSearch servers distributed globally, that are exposed to the Internet as shown below.
ElasticSearch Risk
An improperly configured ElasticSearch server exposes itself to serious vulnerabilities. The server is often accessed via TCP (default port 9300) or HTTP (default port 9200). Unfortunately, an ElasticSearch server’s communication traffic is in plain text without any encryption capabilities. Moreover, there isn’t any secure authentication protocols required to access an ElasticSearch server that is accessible via the Internet. Anyone connecting to a port on the server can call related APIs’ to delete, modify, and query arbitrary data on the server.
Protection Measures
The articles, “Don’t be ransacked: Securing your ElasticSearch cluster properly” by ElasticSearch consultant Itamar Syn-Hershko, and “Protecting Against Attacks that Hold Your Data for Ransom” by ElasticSearch engineer Mike Paquette, respectively describe how to configure and deploy ElasticSearch servers to prevent ransom attacks:
- Redeploy ElasticSearch servers on isolated networks: It is strongly recommended NOT to expose ElasticSearch servers to the Internet. You can use network.bind_host or network.host to configure a server to listen on private or local IP addresses and strongly advise to not host on any public Internet IP addresses or DNS servers.
- If a requirement exists to access an ElasticSearch server via the Internet, it will be necessary to guarantee the following:
- Firewall integration
- VPN connectivity
- Use proxy servers to the communication between the client and server. Moreover, implementation of (AAA) authentication, authorization, and auditing is highly recommended.
- DO NOT use the default ports.
- Disable HTTP if the capability is not needed. The recommended deployment of ElasticSearch is to configure server groups that support specific roles such as control nodes, data nodes, and client nodes. Clients nodes are the only nodes that demand HTTP ability.
- Disable scripting unless it is necessary. Users of ElasticSearch 1.x and 0.x are advised to upgrade as soon as possible. ElasticSearch 2.x uses Groovy as its default scripting language and does not support sandbox functions. Users of ElasticSearch 2.x are advised to remove the default scripting language from configurations.
- Employ official plug-ins: ElasticSearch 5.0 uses the X-Path plug-in for protection and ElasticSearch before 5.0 can use the Shield plug-in.
- Back up all data via Curator snapshots.
References
Syn-Hershko, I. (2017). Don’t be ransacked: Securing your ElasticSearch cluster properly. Retrieved from:http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly
Paquette, M. (2017). Protecting Against Attacks that Hold Your Data for Ransom. Retrieved from: https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom
Download WhitePaper
About NSFOCUS
NSFOCUS IBD is a wholly owned subsidiary of NSFOCUS, an enterprise application and network security provider with operations in the Americas, Europe, Middle East, Southeast Asia, and Japan. NSFOCUS IBD has a proven track record of combatting the increasingly complex cyber threat landscape through the construction and implementation of multi-layered defense systems. The company’s Intelligent Hybrid Security strategy utilizes both cloud and on-premises security platforms built on a foundation of real-time global threat intelligence to provide unified, multi-layer protection from advanced cyber threats.
For more information about NSFOCUS, please visit:
http://www.nsfocusglobal.com.
NSFOCUS, NSFOCUS IBD, and NSFOCUS, INC. are trademarks or registered trademarks of NSFOCUS, Inc. All other names and trademarks are property of their respective firms.
