Held to Ransom: 1,200 Unsecured Elasticsearch Databases | #cloudsecurity | #hacking | #aihp

Memo to IT administrators: If you store data in the cloud in an unsecure manner, expect extortionists to come calling.

See Also: Live Panel Discussion I Security First: Cyber Readiness in a Changing World

To wit, security researchers at Secureworks Counter Threat Unit recently found more than 1,200 cloud-based Elasticsearch databases that had been forcibly encrypted. Attackers left behind this calling card: a ransom note stored in the message field of an index inside many of those databases that demands the victim remit a bitcoin payment to one of two designated bitcoin addresses.

The Secureworks CTU researchers say in a report that across the 1,200 databases, whose owners they have not been able to trace, they identified over 450 individual requests for ransom payments, totaling over $280,000, with the average ransom demand equaling $620, payable to one of two different bitcoin wallets being used by attackers.

Because only one of the wallets had received a single, low-value payment, “we concluded that this campaign was not successful at all,” says Josh Feather, a senior for adviser information security research at Secureworks. “However, the success or otherwise of this campaign is not really the point. There are significant risks to exposing databases publicly outside of the ramifications of this specific activity.”

Data exposure is one obvious risk, not least if the information being stored is sensitive or might be subject to compliance requirements – for example, personal private information that’s protected by the EU’s General Data Protection Regulation.

Data integrity and continuity is another risk. “The threat actor probably used an automated script to identify the vulnerable databases, wipe the data, and drop the ransom note,” Secureworks says. Accordingly, it’s likely that the data is gone and the ransom now amounts to only being a scam.

“While the threat actor could have used a tool like Elasticdump to exfiltrate the data, the cost of storing data from 1,200 databases would be prohibitively expensive,” Secureworks says. “It is therefore likely that the data was not backed up and that paying the ransom would not restore it.”

Repeat Problem

This is hardly the first time that data being stored in the cloud has been found to be inadvertently exposed. Just this week, for example, researchers warned that 6.5TB of sensitive electronic flight data belonging to Turkey’s Pegasus Airlines had been exposed via a misconfigured Amazon S3 bucket. Beyond S3 buckets, numerous data-exposure incidents continue to trace to unsecured Elasticsearch, MongoDB and other cloud-based databases.

“Discovering the exposed databases would be trivially easy, using a tool like Shodan to identify data strings that would only be present on open, unsecured instances of Elasticsearch,” Secureworks’ Feather tells Information Security Media Group. “Writing a script to run those searches automatically, systematically delete indices and replace them with ransom notes is obviously harder, but still not particularly challenging technically.”

Such data exposure comes despite many of these tools, by default, never internet-exposing any data they store. In other words, administrators must disable built-in protections for this type of data exposure to have happened (see: Cloud Security: ‘Big Data’ Leak Prevention Essentials).

Cloud Database Essential: Access Controls

If cloud database administrators enable public access to the data, experts say they should never assume any access controls will be in place.

“Free Elasticsearch instances do not come with any preconfigured basic authentication capability,” Feather says. “Enterprise Elasticsearch licenses do come with preconfigured security features, but they still have to be enabled by the user.”

Likewise, he says, while there are a range of plugins that can increase security – “including encryption, role-based access controls, Lightweight Directory Access Protocol support and auditing/logging” – all such add-ons “need to be configured by the user” to be added, made active and also effective.

“It would be advisable not to store any important or sensitive information on an Elasticsearch instance that does not have sufficient security controls in place,” Feather says. To enforce such security policies, he recommends establishing frameworks that apply access controls “commensurate with the sensitivity of the data being protected.”