Since 2017, we've seen an overwhelming number of sensitive data disclosure scenarios and breaches involving misconfigured and publicly available Amazon S3 buckets There are too many to name, but some notable incidents involved Booz Allen Hamilton, Verizon, AWS and GoDaddy.
Defense contractor Booz Allen Hamilton leaked 60,000 files, including employee security credentials and passwords, to a U.S. government system. A Verizon partner leaked the personal records of over 14 million Verizon customers, including names, addresses, account details and even account PINs in several cases. An AWS S3 bucket leaked the personal details of over 198 million American voters. The database contained information from three data mining companies known to be associated with the Republican Party.
Another S3 bucket security breach leaked the personal details of job applications that had top-secret government clearance. Hosting firm GoDaddy exposed sensitive internal server configuration details in S3. And ISP Pocket iNet left 73 GB of incredibly sensitive data in an exposed S3 bucket in late 2018 that included clear-text passwords, AWS keys, network diagrams and more.
According to research from McAfee Skyhigh Networks, 7% of S3 buckets are wide open to the public and another 35% are not encrypted -- a security feature that is built into the service. This is obviously a big issue, and while it's not Amazon's fault -- all S3 buckets are private by default -- the company has worked to help people and organizations with this issue.
In November 2017, Amazon released several new security and encryption features to help organizations lock down their S3 environments, including permissions checking tools, more granular encryption for S3 and a simple banner on the main S3 screen that identifies when buckets are configured as public. Also, all public buckets are displayed at the top of the list of buckets with Amazon's default sorting order. Unfortunately, none of this seemed to work.
At the re:Invent conference in late 2018, AWS announced more new settings that should help users avoid S3 data leaks. These controls, named S3 Block Public Access, can be implemented at both the account level and for individual buckets. In essence, the new controls are a master policy that can be enabled for all the existing storage buckets, and it will also apply to any newly created buckets and objects within an account.
These settings can also be managed and implemented in a number of ways, including the Amazon S3 Management Console, the AWS Command Line Interface, S3-specific APIs, and in AWS CloudFormation templates.
There are four primary options available -- two for managing public access control lists (ACLs) and two for managing bucket policies.
- Block new public ACLs and prevent the uploading of public objects: This policy will prevent future S3 ACLs that permit any public access, but existing buckets will not be affected.
- Remove public access granted through public ACLs: This policy overrides all the existing ACLs that may make S3 public, and it will change any existing buckets to be nonpublic if the current ACLs permit public access.
- Block new public bucket policies: This setting prevents the creation of future IAM policies that permit public access, but existing policies will be left intact.
- Block public and cross-account access to buckets that have public policies: Any and all public access enacted via S3 IAM policies will be blocked except for AWS services and the bucket owner. This setting is intended to help block most access while owners evaluate policies and turn off public access as needed.
AWS recommends enabling all of these configuration options immediately, and any new S3 buckets will automatically have them all turned on. Anyone using AWS Organizations for centralized policy control across accounts can enable these settings there, too.
I think these settings will improve S3 bucket security and aid in preventing simple accidental exposure of data in S3, but it won't entirely stop S3 bucket data exposure. Some organizations will still turn off all the security controls, perhaps while troubleshooting or testing, and forget all about re-enabling them. Hopefully, we'll see the number of S3 bucket security incidents drop significantly, though.