Hackers target patched remote code execution vulnerability in ElasticSearch
Get a powerful Linux Dual-Core dedicated server for less than $2.67 a day!Tweet Share on Twitter.
March 10, 2015
It's been revealed this morning that hackers are targeting a patched remote code execution security vulnerability in ElasticSearch that grants unauthenticated individuals with nasty intentions to access through a buggy API.
Known as CVE-2015-1427, the security flaw lies within the world's number two enterprise search engine, and was patched just in mid-February.
It apparently relates to the 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.
Those fixes disable the so-called 'Groovy Sandboxing' and dynamic script execution which ElasticSearch developer Clinton Gormley says is a blow to Elasticsearch.
Texas hacker Jordan Wright explained the security vulnerability reported by Cisco and Elasticsearch security spokesperson Cameron Morris after he was targeted in a few attacks.
In a blog post written to alert users, he says the security patch could be reversed to find hints about how to exploit the vulnerability.
"This security hole was not heavily advertised, but it is absolutely critical," Wright says. "In fact, I had one of my own Elasticsearch instances compromised in the same manner, showing this vulnerability is heavily being exploited in the wild."
He added-- "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."
To be sure, system developer David Davidson published on GitHub what he says is a functioning proof of the concept.
There is lots of publicly-accessible Elasticsearch instances, Wright says. He recommends that users check /tmp folders to ensure it is not accessible over that folder from the internet.
"I've been seeing several attempts to download 'kiddie' DDoS bots via wget to /tmp in the past week or so," he says.
Gormley says the company is examining a few ways to improve Expressions to become a more-powerful mini-language that would offer better security.
"Unfortunately, after discussing the security issue with the team, we have come to the conclusion that the so-called '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," he added.
"While Expressions are fast, they are currently very limited-- they operate only on numeric fields and don’t support loops," he said.
System admins in the field should read Wright's post for full technical details, and to fully understand the impact and the severity of this security issue on various systems.
Source: The ElasticSearch Development Team.
Get a powerful Linux Dual-Core dedicated server for less than $2.67 a day!