If you leave a database unsecured on the web, how long does it take hackers to find and steal it?
Comparitech’s security research team regularly uncovers unsecured or misconfigured servers that leak sensitive user data on the web. In a typical scenario, unauthorized third parties can find, access, and even modify the data that organizations have left exposed without a password or any other authentication, putting user privacy and security at risk.
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.
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.
Our research team, headed by cybersecurity expert Bob Diachenko, created a simulation of a database on an Elasticsearch instance—a type of cloud server in which data is often stored—and put fake user data inside of it. Then we left it publicly exposed to see who would connect to it and how they would try to steal, scrape, or destroy the data.
Here’s what we found:
175 attacks beginning just 8 hours after deployment
We left the data exposed from May 11, 2020 to May 22, 2020. During that time, 175 unauthorized requests were made. We broadly refer to these requests as “attacks”. Our honeypot averaged 18 attacks per day.
The first attack came on May 12, just 8 hours and 35 minutes after deployment.
To find vulnerable databases, many attackers use an internet-of-things (IoT) search engine like Shodan.io or BinaryEdge. Shodan indexed our honeypot on May 16, which means it was then listed in search results.
Within just one minute of being indexed by Shodan, two attacks took place. The largest number of attacks in a single day occurred on the same day the database was indexed: 22 attacks in total.
It’s 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.
BinaryEdge indexed the database on May 21.
Search engine bots indexing the database were excluded from results. Some of the attackers could have plausibly been security researchers similar to our own team, but we often can’t distinguish between a malicious attacker and a benign one.
Ransomware bot destroyed the data
On May 29, 2020, a malicious bot discovered the honeypot. It launched an attack that deleted the contents of the database and left a message with contact information and request for payment (redacted by Comparitech):
“If you want recover your data send 0.06 BTC to [redacted] and you must send email to [redacted] with your IP. If you need a proof about your data just send email. If you don’t do a payment all your data may be used for our purposes and/or will be leaked/sold”
Because our research had already concluded at the time of attack, researchers already removed most of the data from the database and only an Amazon Web Services billing index still existed. However, the honeypot server was still open and vulnerable.
The attack started by looking at the list of indexes with the command /_cat / indices?v. After the list of indexes was received, the attacker reviewed the contents of the default index with the command /index/_search?. The attacker then created an index, where he left the document with the ransom note.
All requests took place between 9:10:27 and 9:10:32 EEST, which means the attack lasted five seconds. The attacker used GET methods to obtain index information, DELETE to delete, and POST to leave request messages.
The attacker’s IP address is registered in the Netherlands, as is their time zone.
Attacks originated in the USA, Romania, and China
Locations were determined using attackers’ IP addresses. The highest numbers of attacks originated from three countries:
- 89 came from the USA
- 38 came from Romania
- 15 came from China
IP addresses can be changed using a proxy to mask the attacker’s true location, so take these results with a grain of salt.
What attack methods were used?
The majority of requests aimed to get information about the status of the database and its settings.
- 147 attacks used the GET request method
- 24 attacks used the POST method, which was particularly popular for attacks originating in China
- 1 attack used the PUT method with the intent to change the server configuration
- 1 attack used the OPTIONS method to get information about the connection
- 1 attack used the HEAD method to get the headers of requests without receiving the responses
Other types of attacks
Attackers weren’t just interested in stealing data. Some wanted to hijack servers to mine cryptocurrency, steal passwords, and destroy data.
Cryptojacking
One of the most common attacks targeted a remote code execution exploit on Elasticsearch servers (CVE-2015-1427). One tried to install a cryptomining script. The goal of the attack is to gain access to the Elasticsearch environment by means of java functions and download the bash script miner using a wget command.
Attacks came from different IP addresses, but the download source of the script was always the same. The attack was performed by using two requests: one with source code and one that had been obfuscated.
Credential theft
Another common attack targeted passwords contained within the server’s /etc/passwd file. The attack exploits the same vulnerability as the cryptominer attack plus another path traversal vulnerability (CVE-2015-5531).
The attacker used a path traversal attack using two request methods, GET and POST. The first one contained the path in the request address and the second used java functions to retrieve files.
Configuration changes
One attacker attempted to change the server configuration in a way that would allow them to delete all the data stored inside. The attacker tried to turn off the server’s firewall by disabling iptables.