We have seen attacks on misconfigured databases and containers from time to time. In July, more than 20,000 MongoDB databases were impacted after a ransomware campaign that wiped out data and asked admins to send a ransom. In many cases, the databases were found to be without security protocols in place, and even without passwords. 

In the recent incident, the hackers used an automated script which continuously scans for exposed databases on the internet and launches the attacks. A bot script attacks a site by probing for known vulnerabilities such as unsecured ports and vulnerable files. In the case of attacks on MongoDB databases, the script from malicious entities uploaded a ransom note asking for 0.015 Bitcoin to get back the information along with a warning that if the ransom is not paid the attacks would leak out the information and report it to the local GDPR enforcement. 

Bitcoin is the default payment of ransomware attackers due to its anonymous nature. With a small ransom of 0.015 Bitcoin payment, the intent was to make companies pay for their data and also prevent massive GDPR fines. 

Improper Security Configuration and Lack of Authorised Access Leads To Such Attacks 

Users of paid services like MongoDB Enterprise Advanced or MongoDB Atlas instances were not impacted, whereas only the users of the ‘free to download’ and ‘free to use’ Community version got affected due to improper security configuration and authentication. It is to be noted that MongoDB Community has more than 110 million downloads worldwide, and not every installation may follow best practices. As a result, some are improperly configured.

Attackers have tried many times to make money off exposed MongoDB databases via remote ransomware scripts. In fact, similar to the July 2020 incident, attacks were observed in January 2017 against MongoDB servers which affected more than 50% of all web-facing MongoDB databases back then. It is, therefore, critical that companies protect their internet-facing databases with the highest security methods. But this does not happen many times, leading to attacks. 

To prevent misconfigured databases, MongoDB had made changes in 2018 to secure the open-source community product’s default settings, due to which the overall exposure of public MongoDB instances has drastically decreased. These changes included adding localhost binding by default, which limits access to the database to only the system on which the database is first installed, and upgrading from SHA-1 to SHA-256 for database authentication systems.

An experiment from security firm Comparitech also proved the agility of hackers in attacking databases. In a MongoDB honeypot experiment, researchers found that exposed databases on the web are fast scanned within hours of deployment as hackers use automated scripts. In this case, the first attack on the bogus database came after just 7 hours and 31 minutes, where hackers accessed, stole and destroyed the exposed data using unauthorised requests remotely. 

According to Comparitech, 428 unauthorised connections were recorded over three months, between 6th December 2019 and 7th March 2020. Out of that, many were benign, but 137 unauthorised requests attempted to view, scrape, and download data without authorisation; and also 34 destructive requests, which modified or destroyed data on the server.

The Meow Attacks & ElasticSearch Bot Attack Were Based On Authentication Issues

In another incident recently, more than 1,000 exposed databases on the internet were wiped by unknown attack vectors in a series of security attacks that deleted data and left with the word “meow,” to announce themselves. The “meow” attacks impacted databases operating on ElasticSearch and others. This time, the attacks did not ask for ransom.

“New ElasticSearch bot attack does not include any ransom or threats, just ‘meow’ with a ransom set of numbers. It is quite fast and searches & destroys new clusters very effectively,” cybersecurity researcher Bob Diachenko, who first detected the meow attack wrote. 

According to a TechTarget report, soon after researchers began detecting large-scale results for “meow” in Shodan — a search engine which tracks connected devices and systems on the public internet — it was found that more than a thousand ElasticSearch databases had been attacked. In the Meow attacks, Zimbabwe’s leading online payments platform got impacted. Bob further explained what the attack means for all companies dealing with internet-facing databases without adequate security. 

Apart from Elasticsearch, other platforms which were affected included 50 Redis databases, two Jenkins servers and one Hadoop instance, reported Victor Gevers, a cybersecurity researcher. “I think it will not be long before all the other unauthenticated services with write access are wiped. We have seen this before,” Victor said. “It would be catastrophic if certain data got lost forever.” 

A similar incident happened when researchers found that Honda’s unsecured Elasticsearch database exposed 134 million documents with 40GB worth of information. The database, according to reports, was without any authentication and contained sensitive information related to the company’s internal systems, device data, and the staff.

According to Elasticsearch’s vice president of product management, he told TechTarget that Elasticsearch clusters affected by the Meow attacks did not have any of their free or paid security features enabled, and none of the clusters that had Elasticsearch’s security features enabled had been impacted. 

Conclusion

Attacks on unsecured web-facing databases are frequent and typically encrypt files for ransom. In the case of meow, the malware deleted indexes and inserted random characters followed by the word “meow”. The motive for this particular attack is relatively unknown.

Apart from misconfigured databases, misconfigured Amazon S3 buckets have also been exposed as sensitive. In the past, ethical hackers have even warned businesses who use Amazon S3 cloud storage if they have left data exposed for anyone to access, and left friendly warnings on the servers. 

Continuous attacks on enterprise data assets show that businesses need to become more aware to protect sensitive databases from unauthorised users on unsecured public cloud storage servers. Database minds need to protect their data and use the through instructions from MongoDB’s Security Checklist.