This article is more than 1 year old
Attackers targeting Elasticsearch remote code execution hole
Devs ring patch alarm bells, drop shell code
Attackers are targeting a patched remote code execution vulnerability in Elasticsearch that grants unauthenticated bad guys access through a buggy API.
The flaw (CVE-2015-1427) within the world's number two enterprise search engine was patched last month.
It relates, for folks at Mitre say, to the Groovy scripting engine in Elasticsearch before versions 1.3.8 and 1.4.3 in which sandbox protections could be bypassed, allowing the execution of arbitrary shell commands with a crafted script.
The fixes disable Groovy sandboxing and dynamic script execution which ElasticSearch developer Clinton Gormley says is a "blow" to Elasticsearch.
Texas hacker Jordan Wright (@jw_sec) explained the vulnerability reported by Cisco and Elasticsearch security bod Cameron Morris after he was targeted in attacks.
In a post written to alert fellow users he says the patch could be reversed to find hints about how to exploit the flaw.
"This vulnerability was not heavily advertised, but it is absolutely critical," Wright says.
"In fact, I had one of my own Elasticsearch instances compromised this way, showing this vulnerability is heavily being exploited in the wild.
"I won’t provide a full proof-of-concept, but all the pieces are here ... it is pretty straightforward to run whatever commands you want."
Developer David Davidson published overnight to GitHub what he says is a functioning proof of concept.
There is a "tonne" of publicly-accessible Elasticsearch instances, Wright says. He recommends on Reddit that users check /tmp folders to ensure it is not accessible over the internet.
"I've been seeing a ton of attempts to download skiddie DDoS bots via wget to /tmp in the past week or so," he says.
Gormley says the company is in the long term examining ways to improve Expressions to become a more-powerful safe "mini-language".
Unfortunately, after discussing the issue with the Groovy team, we have come to the conclusion that the Groovy language is too dynamic to be properly contained by a sandbox. This leaves us with the Lucene Expressions language as the only dynamic scripting language available by default. While Expressions are fast, they are currently very limited: they operate only on numeric fields and don’t support loops.
Admins should read Wright's post for full technical details. ®