These insecure S3 accounts have been linked to a vast number of breaches from 2016-2017, cumulatively leaking the information of nearly 218 million individuals. The largest of these is a data breach affecting a number of Republican-affiliated political consultants, which exposed voting information for 198 million US citizens. Other known breaches include:
- Security credentials belonging to Booz Allen Hamilton
- Over three million WWE fans
- Records for 14 million Verizon customers
This information is of varying seriousness, as far as illegal exploits are concerned. Some of the information, like the 198 million records on voters, is relatively anodyne – it’s not of use in situations like identify theft, while other information is much more worrying. Regardless of these breaches severity, it’s clear that administrators have a lot to answer for. What’s going on here?
Security by Obscurity is not Security
There’s a reason why some administrators appear to be okay with leaving their S3 buckets open for the public to find. It’s because although in theory anyone with a web browser can access the information available in these databases, in practice, you need to know a very specific URL. Since the only people who know this URL are the people it’s shared with, administrators can rationalize that they have in fact secure databases.
Unfortunately, establishing a secret URL in no way guarantees that it will stay secret. To find out the location of these supposedly-secret and secure databases, hackers really only need two things:
- The knowledge that undefended databases exist on Amazon S3
- Time and patience
Amazon S3 URLs are made in a standard format, and are generated automatically. Creating the tools to detect open S3 buckets is relatively easy once you know the format, and if you’re not technically savvy, there’s already a number of pre-built tools on Github. In other words, cloud security may be difficult, but obscurity was never really a secure option.
This Has Happened Before, and Will Happen Again
This pattern of incident – files in the cloud being set public, only to be plundered by the unscrupulous – has a long and tiresome history.
For example, another popular cloud service – an online database app known as MongoDB – also has its default configuration set to public. This has led to a predictable result. In September 2017, tens of thousands of MondoDB servers – all left in their default public configuration – were encrypted by attackers who demanded hundreds of dollars to decrypt them.
This attack, however, was just a more sophisticated iteration of another incident, in January of 2017, in which an equal number of MongoDB servers – again, all in their default public configuration – were also encrypted by ransomware. This cyberattack was arguably worse, because each database was encrypted by so many people that there was no way for anyone to get their data back.
What’s most frustrating is that you can actually trace this same warning about Amazon S3 implementations back to the beginning of the service itself. Back in 2013, when S3 was still new, researchers from Rapid7 performed a similar investigation and found 2,000 servers suffering from the same problem, containing over 120 billion files. This problem is not new, and it’s barely getting better.
Lock Down Your Amazon S3 Server with Safe-T
Administrators, don’t let yourselves live with unencrypted public servers. Safe-T Software-Defined Access helps administrators by isolating applications from the network without disabling their connectivity. This Zero-Trust network segmentation model lets your authorized users access applications as easily as if they were set to “public,” without opening any ports in the firewall. For more information, contact Safe-T today and ask for a free trial.