Over 34,000 vulnerable MongoDB databases were hit by a ransom attack. Data were erased from these databases and ransoms were requested for returning data. Then on Jan 18th 2017, several hundreds of ElasticSearch servers were hit by a ransom attack within a few hours.
Overview
Data were erased and ransoms were asked for. Though the attacks did not involve ransomware or regular vulnerabilities, ElasticSearch servers still face serious risks of data loss and leakage. The method used to attack ElasticSearch servers is extremely similar to that used to attack MongoDB databases. Security researcher Niall Merrigan (who had been following up the MongoDB database attack) said, till now, over 2711 ElasticSearch servers have been attacked. Most of the victims are located in USA, with a few in Europe, China, and Singapore.
Messages similar to the following can be seen on attacked servers, asking for ransoms in Bitcoin to restore data:
About ElasticSearch
ElasticSearch is a distributed search engine based on Apache Lucene and supporting multi-user, full-text search. It is developed in Java and opens source code under Apache license terms. As the second most popular enterprise-class search engine (behind Apache Solr), ElasticSearch is usually used in information cataloging and data analysis, most in cloud computing. ElasticSearch can provide real-time search, stable performance, and simple configurations.
ElasticSearch Server Deployment
According to John Matherly, founder of Shodan search engine, about 35,000 ElasticSearch servers on the Internet are now facing security risks. Most of them are hosted by Amazon Web Services.
According to ZDNet, 59 servers in China are affected. However, according to NSFOCUS Threat Intelligence (NTI), 1956 ElasticSearch servers in China are exposing to the Internet.
ZDNet provided a ElasticSearch server distribution diagram on Jan 13 2017:
Credit: zdnet.com
However, according to NSFOCUS NTI, 1956 ElasticSearch servers in China are exposing to the Internet:
Detailed distribution is as follows:
NSFOCUS NTI detected that 39,590 ElasticSearch servers in total are exposing to the Internet:
lasticSearch Risk
An improperly configured ElasticSearch server is exposing to serious risks. It can be accessed via TCP (default port 9300) or HTTP (default port 9200). However, an ElasticSearch server’s communication traffic is in plain texts without any encryption. What’s worse, no secure authentication is required to access an ElasticSearch server exposes to 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, including:
- 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 not on any Internet IP addresses or DNS.
- If it is necessary to access an ElasticSearch server via the Internet, you need to add some restriction, including:
- Use Firewall
- Use VPN
- Use proxy to the communication between the client and server. You can also implement authentication and access authorization here.
- DO NOT use the default port.
- Disable HTTP if it is unnecessary. The best way of deploying ElasticSearch is to set a group of servers that play different roles: control nodes, data nodes, and client nodes. HTTP needs to be enabled for client nodes only.
- Disable script unless it is necessary. Besides, ElasticSearch before 2.x uses a script language without any sandbox function. Users of ElasticSearch 1.x and 0.x are advised to upgrade as soon as possible. ElasticSearch 2.x uses Groovy as its default script language, which does not have the sandbox function either. Users of ElasticSearch 2.x are advised to remove the default script language from configurations.
- Use paid official plug-in: ElasticSearch 5.0 can use the X-Path plug-in for protection, and ElasticSearch before 5.0 can use the Shield plug-in.
- Back up all data. You can use Curator snapshots.
Reference Links
| Don’t be ransacked: Securing your ElasticSearch cluster properly | http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly |
| Protecting Against Attacks that Hold Your Data for Ransom | https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom |
About NSFOCUS
NSFOCUS IB is a wholly owned subsidiary of NSFOCUS, an enterprise application and network security provider, with operations in the Americas, Europe, the Middle East, Southeast Asia and Japan. NSFOCUS IB 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 IB, and NSFOCUS, INC. are trademarks or registered trademarks of NSFOCUS, Inc. All other names and trademarks are property of their respective firms.