1 in 50 Publicly Readable Amazon Buckets Are Also Writable – And That’s a Data Disaster Waiting to Happen

Now is not the time to dilly-dally. If you haven’t already properly secured the Amazon Web Services S3 servers (known as “buckets”) storing your sensitive data in the cloud then your business has no time to lose.

It’s bad enough that easy-to-use tools like Buckhacker made headlines with their ability to act as a search engine for data information left publicly accessible on Amazon S3 buckets.  But newly released research has revealed that an alarming number of companies may even be leaving themselves open to ransomware-like attacks, by leaving their buckets not just publicly readable… but also write-enabled.

A study conducted by French cybersecurity outfit HTTPCS has revealed that 1 in 50 of all Amazon S3 buckets have not been write-protected, opening opportunities for malicious attackers to corrupt data, or even encrypt or wipe it – demanding a ransom be paid for its safe return.

Here are the raw statistics from the more than 100,000 Amazon S3 buckets that the researchers examined: 

• 90% of buckets are private, and therefore not at risk of leaking data or being corrupted by attackers. Of course, that means 10% of buckets are public… 

• 58% of those public Buckets (in other words, 5.8% of the total number of buckets tested) contained readable files, what might allow data leakage. 

• 20% of public Buckets (or, if you prefer, 2% of the total buckets) are not write-protected. 

• Only a tiny 5% proportion of those public, write-enabled buckets (in other words, a mere 0.1% of the total) don’t contain any files. 

And don’t for a second imagine that the threat of attackers wiping Amazon S3 buckets, or leaving ransom demands, is a fanciful one. 

Last year, tens of thousands of unprotected MongoDB databases suffered precisely that fate, hitting small businesses, hospitals, and educational institutions hard.

And, as with Amazon, it wasn’t the case that the security measures weren’t available for MongoDB administrators to properly protect their data – it’s just that some users didn’t bother to configure them properly.

A secure backup could, obviously, help you recover should a malicious hacker decide to attack your Amazon S3 bucket – but wouldn’t it be simpler to make it write-protected in the first place, and even reassess whether it’s wise to make it publicly readable by any internet user at the same time?

After all, you don’t want your business to find itself in the awkward position of trying to explain to your customers and partners why their information has fallen into the hands of hackers or, even worse, been permanently damaged or lost by a hack attack that could so easily have been avoided.