Unsecured Elasticsearch server breached in eight hours flat

A server left exposed to the public internet with no cyber security protections in place will be discovered and suffer repeated cyber attacks by malicious actors within about eight hours, according to an experiment conducted by Bob Diachenko, a security researcher at Comparitech.

Diachenko and his team specialises in seeking out and tracking down unsecured databases. In January 2020, they hit the headlines after finding the customer service and support records of nearly 250 million Microsoft users after an internal change to a database network security group accidentally contained misconfigured security rules.

Typically, said Diachenko, these databases are left exposed because someone in the organisation has forgotten to set up a password, so unauthorised third parties can find and access the data through a relatively simple scanning process.

In the best-case scenario, the people who uncover exposed databases are security researchers who then disclose their findings to the database owners, who learn a valuable security lesson. In the worst-case scenario, the databases are found by cyber criminals and the owners find themselves at the centre of a high-profile security incident.

“Although we do our best to quickly alert whoever is responsible for exposures we find, the data often sits exposed and vulnerable for anywhere from a few hours up to a few weeks while we hunt down the owner and wait for a response,” said Diachenko. “Time is of the essence in these situations. We wanted to find out how fast data can be compromised if left unsecured. So we set up a honeypot.”

Diachenko and his team created a simulated database on an Elasticsearch instance and filled it up with fake user data. Then they left it completely exposed to see what would happen.

The database was set up on 11 May and was removed on 22 May. In that time, Diachenko reported, 175 unauthorised requests were made, averaging 18 a day. The first came on 12 May, just eight hours and 35 minutes after deployment.

The honeypot was attacked over 36 times in the first five days, but the volume of attacks increased significantly after the database was indexed by Shodan.io, an internet of things (IoT) search engine used by good guys and bad guys alike, on 16 May. Within a minute of being indexed, Diachenko recorded two attacks, and 22 in the following 24 hours.

“It is worth nothing that over three dozen attacks occurred before the database was even indexed by search engines, demonstrating how many attackers rely on their own proactive scanning tools, rather than waiting on passive IoT search engines like Shodan to crawl vulnerable databases,” said Diachenko.

The honeypot drew a variety of distinct cyber attacks, including, on 29 May (after the experiment had concluded), a malicious bot that deleted the contents of the database and left a ransomware demand for 0.06 bitcoin. At that point, the database contained nothing more than an Amazon Web Services (AWS) billing index, the rest of the data having been purged a week earlier.

The ransomware bot’s IP address was registered in the Netherlands, but attackers popped up from around the world, with most, 89, originating in the US. Significant volumes also came from Romania and China, although it is important to note that IP addresses can be changed using a proxy as a fairly mundane obfuscation technique.

Most of the attacks observed seemed to be trying to ascertain information about the database’s status and settings or make configuration changes that would let them delete the data. But the attackers were not just interested in stealing data – others tried to hijack the server to mine cryptocurrency, steal passwords, and even destroy the data.

Diachenko found one of the most common attacks targeted a five-year-old remote code execution exploit particular to Elasticsearch instances – CVE-2015-1427 – with one trying to download and install a cryptomining script after gaining access to the environment by means of Java functions. These attacks came from multiple IP addresses, but always with the same download source for the script itself.

Another common attack sought out password data contained within the server’s /etc/passwd file. This used the same exploit as the cryptominers, blended with another vintage vulnerability, CVE-2015-5531, a directory traversal vulnerability in Elasticsearch before version 1.6.1 which allows remote attackers to read arbitrary files via unspecified vectors related to snapshot API calls.

More information on Comparitech’s experiment can be found at the firm’s website.