Remote Code Execution in Elasticsearch – CVE-2015-1427

Great article.

One feature of the _search API endpoint is to allow users to submit Groovy code in the search query itself. The server will then execute the code in a sandboxed environment, returning the result to the user. This way, the elasticsearch code can be used to execute… more code.

Quite a dangerous feature indeed. Thankfully, according to the documentation[0], this feature is disabled by default since v1.4.3. (Hindsight is 20/20, but this probably should have been the case from the get-go)

0. https://www.elastic.co/guide/en/elasticsearch/reference/curr...

Hey there! Author here - thanks for posting this!

In response to this, I made an open-source honeypot (in Go!) called Elastichoney. I recently released every single log I collected in nice JSON form:

http://jordan-wright.github.io/blog/2015/05/11/60-days-of-wa...

Let me know if you have any questions!

This is old. There are bots that scan servers for ES and try to exploit this vulnerability. Our servers were hacked through this hole before we upgraded to a newer version of ES. Now we don't allow remote access to ES directly. We use a proxy script that parses HTTP requests from users, interacts with local ES instance and serves users with transformed data.

I created an Nmap script to find this on your own networks:

https://gist.github.com/jwpari/3369a537b422ecfa23f5

Use with:

  nmap -T5 -p 9200 -Pn --script=+elasticsearch-cve-2015-1427 10.0.0.0/8

I had a Digital Ocean VPS shut down because of the previous exploit (mentioned in the article). I was just testing an open-source project of my own and did a standard/stock install.

I don't really understand why a project like this would default to having such vulnerable settings turned ON.

FYI, it looks like this was released ~3 months ago on Feb 17th of this year: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-14...

This vulnerability sounds similar to the issue I described here: https://crashcoherency.net/posts/perils_of_source_based_sand...

tl;dr: If you're doing sandboxing by blacklisting specific strings in your input, you're doing it wrong. Java actually has good sandboxing capabilities. Use them!

The author of that sandboxing feature of Groovy recently wrote a blog article on improving sandboxing of Groovy scripts that are executed at runtime, see http://melix.github.io/blog/2015/03/sandboxing.html

His conclusion says that using Groovy for scripting on the JVM comes at the price of security, and that the customizers in the Groovy distribution and those in the wild aren't enough to guarantee security of execution of scripts in the general case, but if you loosen some of the dynamic features of Groovy, you can work around those limitations through type checking extensions, though that solution isn't available in Groovy's core distro. He adds he'll have less time to work on Groovy, probably refering to how he and the other full-timer building Groovy had their funding pulled beginning the following week (end March 2015). There's now noone working fulltime building Groovy.

If you have Elasticsearch open to arbitrary inputs, isn't it a given anyone can mess you up?

I have always followed CouchDB from a distance, so I am curious, has anyone been able to pull the same crap writing Erlang or Javascript? This is more relevant to the latter bc of the sandbox, but this NoSQL architecture decision sounds very familiar.

I swore I read something about attempting to break the JS sandbox but found nothing with my weak Googlefu.

Don't expose elasticsearch to the public. You wouldn't expose your database to the public (or would you?), and this isn't any different.

At the very least, limit the set of IPs that can connect to your server.