How long does it take hackers to find exposed Elasticsearch servers and exposed S3 Buckets? Just a few hours according to Comparitech.
Comparitech researchers are no strangers to exposed cloud data. They commonly find unprotected databases and report the lack of protections to the data owners. In many cases, exposed Elasticsearch servers are secured quickly, although it is often not clear for how long data has been exposed.
The Comparitech security team is quick to find unprotected data, but it was not clear how long it takes hackers to find exposed AWS S3 buckets and unprotected Elasticsearch instances, so the set up a test to find out. The Security team, led by Bob Diachenko, created an Elasticsearch server honeypot, uploaded data, and left it exposed between May 11 and May 22, 2020.
The Search engine Shodan indexed the system on May 16, with the search engine BinaryEdge indexing the server on May 21. Once indexed it made it much easier to find the system, but hackers found it long before the search engines did. The Comparitech team recorded more than three dozen attempts to access the system before it had been indexed by Shodan, with the first attempt made just 8 hours and 35 minutes after the system had been created.
Within a minute of the system being indexed by Shodan, two attempts were made to access the data, with 22 in total occurring on that day. Over the duration of the test there were 175 unauthorized requests to access the system, averaging 18 attempts per day.
While it was clear that some attempts were made by malicious actors, in many cases it was not possible to determine the reason for the access attempt. It is possible that some of the attempts were from security researchers. Most of the attempts to access the system came from the United States (89), Romania (38), and China (China), although it is possible that proxies were used, so the location of the IP address does not necessary indicate where the attacker is located.
The majority of requests attempted to find out the status and settings and it was clear that some attempts were made to steal data. There were also attempts to hijack the server to install cryptocurrency mining code, there was one extortion attempt, attempted password theft, and an attack that tried to destroy data.
Several of the attempts to install a cryptocurrency miner involved the exploitation of the vulnerability CVE-2015-1427. These attempts all used the same source for the mining script, although different IP addresses were used.
Several attempts were made to steal passwords by exploiting the vulnerability CVE-2015-5531 to achieve directory traversal and obtain the passwd file. One attempt was made to delete the data and, after the exercise had ended and most of the data in the system had been deleted, a malicious bot attack occurred and the attacker issued a ransom demand of 0.06 BTC for the return of data.
The test showed that it really doesn’t take long for exposed data to be found and there are many people searching for exposed Elasticsearch instances and AWS S3 buckets. Given the number of requests to access the instance, it is probable that a great many cloud server misconfigurations result in data breaches, even though many are not reported as such.
