By: Dr. Richard Zhao, SVP of Global Threat Research, NSFOCUS
Overview
During the week of January 21, 2017, over 34,000 vulnerable MongoDB databases fell victim to a ransom attack. Data residing on these databases was erased or encrypted and bitcoin payment was demanded in lieu for return of the data. Moreover, on January 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 demands. 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 like 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) shows that the number is in fact quite higher. A suspected 1956 ElasticSearch servers operating out of China are at risk due to being exposed to the Internet
ZDNet provides the following diagram illustrating the current ElasticSearch server distribution as of January 13, 2017:
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, and it is not encrypted. Moreover, there are no secure authentication protocols in use 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 only, but no on any Internet IPaddresses
- If a requirement exists to access an ElasticSearch server via the Internet, it is recommended to ensure the following:
- Ensure Firewall integration
- Use 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
