• United States



CSO Senior Writer

Elasticsearch clusters face attacks from multiple hacker groups

Feb 28, 20193 mins

If you are running an older version of Elasticsearch, make sure you've patched its known vulnerabilities or consider upgrading.

skull and crossbones in binary code
Credit: Thinkstock

Security researchers have recently detected an increased number of attacks against Elasticsearch clusters running older versions with known vulnerabilities. At least six different groups of attackers are searching for and exploiting insecure deployments to abuse servers.

Elasticsearch is a distributed search engine platform written in Java designed for processing large data sets. It is commonly used in companies and organizations that work with big data.

“Through ongoing analysis of honeypot traffic, Talos detected an increase in attacks targeting unsecured Elasticsearch clusters,” researchers from Cisco’s Talos group said in a report this week. “These attacks leverage CVE-2014-3120 and CVE-2015-1427, both of which are only present in old versions of Elasticsearch and exploit the ability to pass scripts to search queries.”

Attackers use the Elasticsearch exploit for multiple purposes

The exploits affect Elasticsearch 1.4.2 and lower, and the malicious scripts deliver different payloads depending on the actor using them. One group appears to consistently install cryptocurrency mining programs, but also downloads an additional payload with exploits for vulnerabilities in other technologies including CVE-2018-7600 in Drupal, CVE-2017-10271 in Oracle WebLogic, and CVE-2018-1273 in Spring Data Commons.

“The [additional] exploits are sent, typically via HTTPS, to the targeted systems,” the researchers said. “As evidenced by each of these exploits, the attacker’s goal appears to be obtaining remote code execution on targeted machines. Detailed analysis of the payload sample is ongoing, and Talos will provide pertinent updates as necessary.”

The rogue bash scripts do more than deliver exploits, though. They disable security protections, kill competing malicious processes and add the attackers’ SSH key to the authorized_keys list so they get continued remote access.

Another group of hackers that target Elasticsearch clusters using the CVE-2014-3120 exploit to deploy a malicious program designed to launch distributed denial-of-service (DDoS) attacks. This malware is a custom version of an older DDoS program called Bill Gates.

A third group exploits Elasticsearch deployments to install a Trojan program called Spike that has variants for x86, MIPS and ARM CPU architectures. Artifacts left behind by this group point to a QQ account belonging to a Chinese user who has a history on hacking forums.

The three other groups that Talos has observed hitting its Elasticsearch honeypots did not deliver any malware. However, two of them were seen issuing commands to fingerprint servers and one issued the rm * command, which on Linux systems is used to delete all files.

Potential impact of Elasticsearch breach is huge

“Given the size and sensitivity of the data sets these clusters contain, the impact of a breach of this nature could be severe,” the Talos researchers warned. “Talos urges readers to patch and upgrade to a newer version of Elasticsearch if at all possible. Additionally, Talos highly recommends disabling the ability to send scripts through search queries if that ability is not strictly necessary for your use cases.”

Destructive attacks against Elasticsearch clusters have also been observed back in 2017, when hackers used to destroy all data and leave ransom notes behind. Those were fake ransomware attacks though, because there were no indications that attackers could actually recover the deleted data.

At that time, distributed systems architect Itamar Syn-Hershko published a blog post with recommendations for securing Elasticsearch deployments that is still relevant today. Those recommendations include not exposing Elasticsearch clusters to the internet, disabling HTTP on Elasticsearch clients, using other ports than the default one, restricting access to internal IP addresses only and disabling scripting.