More Data May be Lost Through Misconfigured Public Cloud Databases Than We Are Led to Believe
Misconfigured cloud databases left exposed to the internet are a huge, but largely unquantified problem. New discoveries are found and reported by security researchers on a weekly basis. What hasn’t been clear is whether bad actors can find them as easily as the researchers. The answer is Yes.
Databases — usually in Elasticsearch or AWS S3 buckets, and often containing sensitive data — are frequently left in public Cloud storage without access controls. The problem is so great that in January 2020, the NSA warned, “misconfiguration of cloud resources remains the most prevalent cloud vulnerability.” Such databases can be accessed, downloaded, or manipulated by anyone who finds them.
When researchers find them, they immediately report their findings to the database owners and the fault is often corrected within hours. Sometimes, however, the owner isn’t clear, and it can take up to several weeks for the researchers to find who to report to. Nor is it always evident how long the database had been online before the researchers found it. There is invariably a period of varying length where the database is exposed to bad actors.
The big question is how often bad actors find such databases. If we listen to the database owners, the impression is ‘not often’. Where a database owner acknowledges the issue, the usual comment is, “We have no reason to believe that any third party accessed the data.”
Researchers Paul Bischoff and Bob Diachenko from Comparitech have attempted to verify this belief by establishing an Elasticsearch honeypot containing fake user data. “We wanted to find out how fast data can be compromised if left unsecured,” they say in a report on the exercise.
Their data was exposed for just eleven days between May 11, 2020 and May 22, 2020. During that period, 175 unauthorized requests were made, beginning less than nine hours after deployment.
Both researchers and attackers use specialized search engines, such as Shodan, to discover misconfigured databases. Shodan indexed the honeypot on May 16. Within one minute of being indexed, it received two attacks — and more attacks occurred on that day than on any other day of the research.
Despite this, the researchers point out that three dozen attacks occurred before the Shodan indexing, and conclude that “many attackers rely on their own proactive scanning tools rather than waiting on passive IoT search engines like Shodan to crawl vulnerable databases.” They also accept that some of the attacks may have been via other researchers.
Most of the attacks came from IP addresses located in the U.S. (89), Romania (38), and China (15). The majority were seeking information about the status of the database and its settings. However, three types of attack stand out: cryptojacking, credential theft, and ransomware. The cryptojacking attempts targeted a remote code exploitation vulnerability (CVE-2015-1427) in order to gain access by Java functions and download the bash script miner.
Learn More About Cloud Security at SecurityWeek’s Cloud Security Summit Virtual Event
“Another common attack,” say the researchers, “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 most surprising attack was perhaps the ransomware. This occurred after the active honeypot research had concluded, but while the server was still open and vulnerable. A malicious bot discovered the honeypot and launched an attack that deleted content and left a message with contact information and a demand for payment. This attack lasted just five seconds.
The clear implication of Comparitech’s honeypot research is that misconfigured public cloud databases are rapidly discovered and attacked by bad actors. It is likely that more data is stolen from these databases than we currently believe. “Our analysis indicates that more data is lost from unsecured databases than what is reported or admitted,” Bischoff told SecurityWeek. “The same goes for ransomware attacks.”
The lack of reporting from the data owners could have two causes. The first more cynical reason could be the disincentive to admit anything for compliance purposes — any loss of EU personal data through a misconfigured cloud database would most certainly attract the ire of European GDPR regulators. Logs would settle the argument, but logs seem to be sparse.
Less cynically, but no more excusably, there may be a lack of logs for the same reason that most of these databases exist. “Many of the misconfigured databases we find are set up for temporary test purposes,” explains Bischoff, “so logging might be an afterthought or isn’t set up correctly.” The users who set up the databases without understanding the need to establish access control are also likely to ignore, or not understand, the need for logging. But Bischoff adds, “When the organization says there was no indication that any data was exfiltrated, remember that the absence of evidence is not evidence of absence.”
Comparitech’s honeypot experiment would suggest that more data may be being lost through misconfigured public cloud databases than we are led to believe.
Related: AppOmni Launches Solution to Protect SaaS Applications for Remote Workers
Related: Zscaler to Acquire Cloudneeti to Solve Cloud Misconfiguration Problems
Related: Virtualized Cloud Visibility Firm Orca Security Raises $20.5 Million
Related: Microsoft Exposed 250 Million Customer Support Records
