Elasticsearch Vulnerability Puts Bots in Amazon Cloud

When people envision a distributed denial-of-service (DDoS) attack, they often picture hundreds of thousands of desktop computers, controlled by attackers, that bombard websites with Internet traffic. However, attackers have figured out that by harnessing virtual machines in the cloud, they can pull off large attacks with much less effort.

With a piece of Trojan horse malware called Mayday, attackers recently took control of virtual machines in Amazon’s Elastic Compute Cloud 2 (EC2). They used a backdoor in a search engine server called Elasticsearch, which is popular in cloud environments. Affected organizations could have protected themselves by using the most recent versions of Elasticsearch, but they failed to download the latest software updates.

Recently, cloud computing security providersdiscovered Mayday working within an Amazon EC2 environment. Mayday is a Trojan that can launch DDoS attacks and has the ability for intense DNS amplification, which allows attackers to warp queries so that they appear to come from a vulnerable domain. When the technique distributes queries among hundreds of thousands of physical or virtual machines, the attack can become almost unstoppable. As researchers investigated how Mayday got into Amazon EC2 environments, they traced the origin to a backdoor in an early version of Elasticsearch.

Elasticsearch is a real-time search engine designed for distributed and scalable environments. It can host multiple indices within a cloud environment, allowing tenants to be queried individually or in aggregate. Elasticsearch can be deployed in Amazon EC2, Google Compute Engine, Microsoft Azure and other cloud computing platforms. Users can scan documents into Elasticsearch, which can detect document structure and make the data searchable. Admins can also go in and customize indexing using domain-specific knowledge.

When Elasticsearch released Version 1.2.0, it disabled its dynamic scripting function by default. Dynamic scripting in earlier Elasticsearch versions allowed active scripting through API calls, which could execute code on an underlying cloud server. Attackers could execute the scripts without security authentication, and the server didn’t sandbox the script code. Researchers think that this backdoor in older versions of Elasticsearch allowed attackers to execute the Mayday Trojan.

Organizations using an older version of Elasticsearch should check their usage statistics with either Amazon or their current cloud services provider (CSP). If their virtual machines have been harnessed as bots, then they might see higher-than-normal usage charges, which they should discuss with their CSPs.

The next step is to download a newer version of Elasticsearch. After making the upgrade, users should take the following precautions as detailed in an Elasticsearch blog post:

• Disable dynamic scripting. When Elasticsearch releases Version 1.3.0, the company plans to offer sandboxing functionality for its scripting environment. This service would allow users the advantage of dynamic scripting while protecting them from malicious scripts. Until then, any organization using any version of Elasticsearch should make sure that dynamic scripting is disabled.
• Audit servers for unusual loads.If attackers have used Elasticsearch servers to access host systems, then organizations should remove and re-install all affected systems.
• Run Elasticsearch as a dedicated user. Avoid running Elasticsearch as a root user. Running Elasticsearch as a root user enables scripts to have unlimited access to the server.
• Run Elasticsearch behind a firewall.Elasticsearch recommends blocking ports 9200 and 9300 from any machines not in the development environment. Only development applications or servers that run Kibana, Elasticsearch’s analytics program, should be able to communicate with Elasticsearch.

In early 2014, LinkedIn sued a gang of hackers accused of hijacking Amazon’s cloud service. The attackers allegedly used bots to create thousands of false LinkedIn member accounts. Using the accounts, they scraped member information, copying data from LinkedIn profile pages. Researchers speculated that attackers wanted the LinkedIn information for social engineering attacks. Because LinkedIn contains information about employees in many industries, including their job titles, attackers could launch spearphishing attacks directed at well-placed individuals within targeted organizations. After stealing their login credentials, attackers could then steal proprietary or customer data.

LinkedIn’s breach isn’t the only instance of cloud computing platforms serving as attack launch pads. In 2011, Amazon’s Simple Storage Services was used as a command-and-control center for the SpyEye banking Trojan. These attacks prove that any organization, especially if it uses public cloud services, should deploy a cloud securitysolution to prevent costly attacks and breaches.