

Remote Code Execution in Elasticsearch – CVE-2015-1427 - biafra
https://jordan-wright.github.io/blog/2015/03/08/elasticsearch-rce-vulnerability-cve-2015-1427/

======
stygiansonic
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...](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-
scripting.html#modules-scripting)

------
jwcrux
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...](http://jordan-wright.github.io/blog/2015/05/11/60-days-of-watching-
hackers-attack-elasticsearch/)

Let me know if you have any questions!

------
skua
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.

~~~
MichaelGG
How did you have it open to the Internet? Couldn't someone just DELETE
everything? Or what kind of setup/restriction did you have?

~~~
skua
It was served through a proxy script, but actual ES instance was accessible to
anyone and yes anyone could delete documents, groovy dynamic scripting was
also enabled. Stupid setup I know... Our documents were not touched, but our
servers were used to ddos something.

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

[https://gist.github.com/jwpari/3369a537b422ecfa23f5](https://gist.github.com/jwpari/3369a537b422ecfa23f5)

Use with:

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

------
callmeed
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.

------
fiveoak
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...](https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1427)

------
AgentME
This vulnerability sounds similar to the issue I described here:
[https://crashcoherency.net/posts/perils_of_source_based_sand...](https://crashcoherency.net/posts/perils_of_source_based_sandboxing)

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!

------
vorg
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](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.

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

------
616c
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.

~~~
MichaelGG
So there's plenty of bugs in the JS interpreters, and you can use those to do
regular exploits and run arbitrary code.

Separately is escaping the sandbox due to a bug in the verification. JS is
probably far easier to secure, since all the APIs are "safe" to call. That is,
there isn't a huge JS stdlib that needs to be restricted. Like brainfuck-
there's no way to make dangerous calls. Whereas Java has a huge stdlib that's
accessible, so you're fighting an uphill battle to lock it down.

------
timr
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.

