Security researchers often discover misconfigured public cloud databases. Wrong configurations that cause cloud data exposure may be because of insufficient knowledge of cloud security or guidelines, inadequate oversight to track down errors, or negligent conduct by insiders. The latest Trend Micro report pointed out that the top cause of cloud security issues is cloud misconfigurations.
Security researchers at Comparitech frequently find unsecured cloud assets, typically Elasticsearch cases and unprotected AWS S3 buckets. Whenever the unprotected cloud databases are identified, security researchers identify the owners and notify them to make sure to secure data quickly. Upon identifying the owners, it usually only takes a few hours to secure the databases. However, there are many instances where it is impossible to contact the database owner.
In these instances, data may be exposed on the internet for a few days or weeks. At this time, the databases stay at risk and accessible to anyone who knows where they are. Comparitech experts are well trained in searching for unprotected Elasticsearch databases and AWS S3 buckets. However, the question is how fast can malicious actors find an unprotected database? Comparitech found out that it doesn’t take a long time.
To find out how fast can unsecured data be identified, Comparitech’s security staff did an exercise. They simulated Elasticsearch instances just like the Elasticsearch instances they found unprotected. They filled it with phony user information and left it open to the public. From May 11, 2020 to May 22, 2020, the database was exposed.
In the latest blog post of Comparitech, security researcher Paul Bischoff explained the exercise saying that the initial access request happened 8 hours and 35 minutes after creating the database. In the 11 days that the database remained exposed, 175 access requests were identified. There was an average of 18 requests per day.
Open databases are typically found by using an IoT search engine like Shodan. Search engines take time to index the data. Shodan indexed the database, in this case, on May 16, which is five days after its creation. Even if Shodan did not index the database until May 16, at that time there were already 3 dozen data access attempts. The moment the database was indexed, there’s a surge of attacks. The minute the database was indexed, there were two access attempts noted, with 20 more access requests that day.
There are a number of reasons for finding unsecured cloud resources. Databases frequently consist of sensitive information, which hackers can use for identity theft and scams or sell on underground forums. Hackers could also hijack databases and demand ransom money from the owners of data. However, not all attacks were interested in getting data. In a number of attempts, hackers hijack the servers and get crypto mining scripts. In one particular case, a hacker tried to shut off the firewall and erase the database.
Though the test was done on May 22, 2020 and most of the data was deleted, another attack happened on May 29. A malicious bot found the honeypot, erased the database, and in 5 seconds left a message asking 0.06 BTC ransom to get back the data.
The exercise revealed that even though databases are just exposed for a while, it is very possible that they are going to be found. Although a lot of companies claim their data wasn’t exposed for long, it is likely that data has been compromised except if data was just publicly open for a couple of hours.
Comparitech mentioned that in case the person configuring an Elasticsearch instance neglects to set access controls, it is fair to think that logging was also not enabled. When firms state that there is no evidence that suggests data accessed or exfiltration, that doesn’t mean data was not accessed and stolen, there’s just no evidence. A 2019 McAfee report suggested that 99% of cloud misconfigurations are not reported upon discovery.