Elasticsearch - CVE-2014-3120 Arbitrary Java Code Execution Vulnerability

If you are running an openly accessible instance of Elasticsearch, it may be exploited for root access to your server or may be subject to data loss, theft or interruption in service.

Elasticsearch's default configuration is flawed and allows visitors to execute arbitrary shell code on your server.  You must secure your copy of Elasticsearch so that malicious users cannot use it to gain root access  to your server. Elasticsearch has no access roles or authentication mechanism. This means that you have full control over a cluster the moment you connect to it. The Elasticsearch API is accessible over HTTP and provides no cross-site request forgery protection whatsoever. It also contains a feature which makes it possible to evaluate expressions as part of a query.

Example: Usage of this feature is 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 privileges as the user that runs Elasticsearch. MVEL has no sandboxing at all.

It's important to keep your software instances installed on your server up-to-date and secure. Investigate your server to see if there are any signs of compromise and take the necessary corrective and mitigation actions.

How to check if your instance is vulnerable

nmap -PN -p9200 XXX.XXX.XXX.XXX      (Replace XXX.XXX.XXX.XXX by your server's IP address )

Starting Nmap 6.40 ( http://nmap.org ) at 2014-06-10 09:01 EDT
Nmap scan report for XXX.XXX.XXX.XXX
Host is up (0.038s latency).
PORT     STATE SERVICE
9200/tcp open  wap-wsp
Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds


$ curl -XGET 'XXX.XXX.XXX.XXX:9200'
{
  "ok" : true,
  "status" : 200,
  "name" : "ALEB12",
  "version" : {
    "number" : "0.90.7",
    "build_hash" : "36897d07dadcb70886db7f149e645ed3d44eb5f2",
    "build_timestamp" : "2013-11-13T12:06:54Z",
    "build_snapshot" : false,
    "lucene_version" : "4.5.1"
  },
  "tagline" : "You Know, for Search"

 

Key Components to Securing Elasticsearch:

  1. From version 1.2.0 onwards, dynamic scripting (passing a script as part of a search request) has been disabled by default. On older versions, it is enabled by default. Meaning that any outside user could do anything on your server that the Elasticsearch user can do. If you're running an older version, you have to add this to your config/elasticsearch.yaml: script.disable_dynamic: true 

    See additional measures in the section "How to secure against this vulnerability" of this article http://bouk.co/blog/elasticsearch-rce/

  2. Understand the sometimes tricky configuration is required to limit access controls to indexes.
  3. Consider the performance implications of multiple tenants, a weakness or a bad query in one can bring down an entire cluster!

Summary:

  • Elasticsearch versions 1.3.x and prior have a default configuration for CORS that allows an attacker to craft links that could cause a user’s browser to send requests to Elasticsearch instances on their local network. These requests could cause data loss or compromise.  Users should either set “http.cors.enabled” to false, or set “http.cors.allow-origin” to the value of the server that should be allowed access, such as localhost or a server hosting "Kibana". Disabling CORS entirely with the former setting is more secure, but may not be suitable for all use cases.
  • In Elasticsearch versions 1.1.x and prior, dynamic scripting is enabled by default. This could allow an attacker to execute OS commands.  Disable dynamic scripting (See instructions above).

Detailed information and Reference:

Have more questions? Submit a request

0 Comments

Article is closed for comments.
Powered by Zendesk