Rapid7 reported this week on finding a ton of sensitive information in Amazon S3. They scanned public buckets (Amazon S3 containers) by enumerating names, and concluded that 1 in 6 had sensitive information in them. People cried, “Amazon should do something about this!!”
S3 buckets are private by default. You have to make them public. Deliberately.
If you leave a bucket public, you eventually get an email like this (I have a public bucket we use for CCSK training):
Dear Amazon S3 Customer,
We’ve noticed that your Amazon S3 account has a bucket with permissions that allow an anonymous requester to perform READ operations, enumerating the contents of the bucket. Bucket READ access is sometimes referred to as “list” access. Amazon S3 buckets are private by default. These S3 buckets grant anonymous list access:
REDACTED
Periodically we send security notifications to all of our customers with buckets allowing anonymous list access. We typically recommend against anonymous list access. We know there are good reasons why you may choose to allow anonymous list access. This can simplify development against S3. However, some tools and scripts have emerged which scan services like Amazon S3 and enumerate objects in publicly listable buckets. With anonymous list access enabled, anyone (including users of these tools) may obtain a complete list of your bucket content. As a result of calls against your bucket, you may see unintended charges in your account.
We’ve included specific steps to remove anonymous list access as well as further information about bucket access considerations.
Use the following steps to immediately remove anonymous access to your bucket. Go to the Amazon S3 console at https://console.aws.amazon.com/s3/home. Right-click on the bucket and click Properties. In the Properties pane, click the Permissions tab. The tab shows a list of grants, one row per grant, in the bucket ACL. Each row identifies the grantee and the permissions granted. Select the row that grants permission to everyone. “Everyone” refers to the Amazon S3 All User group. Uncheck all the permissions granted to everyone (or click x to delete the row). This removes all permissions granted to public. Click Save to save the ACL.
Learn more about protecting your bucket by reading the AWS article on Amazon S3 Bucket Public Access Considerations at http://aws.amazon.com/articles/5050. This article includes alternative options if you need methods for unauthenticated end users to read and write content, as well as detailed information on configuring bucket access for website hosting if you are hosting your site on Amazon S3. It also describes how you can use Bucket Policies if you would like to specify more granular access control on your bucket. Bucket Policies enable you to add or deny permissions across all or a subset of objects within a bucket. You can use wildcarding to define sets of objects within a bucket against which policy is applied, more specifically control the allowed operations, and even control access based on request properties.
For further information on managing permissions on Amazon S3, please visit the Amazon S3 Developer Guide at http://docs.amazonwebservices.com/AmazonS3/latest/dev/Welcome.html for topics on Using ACLs and Using Bucket Policies. Finally, we encourage you to monitor use of your buckets by setting up Server Access Logging. This is described in our Developer Guide under Setting Up Server Access Logging.
Sincerely,
The Amazon S3 Team
My scientific conclusion? 1 in 6 Amazon S3 users can’t read, or don’t care. Seriously, what do you want Amazon to do? Drive to your house if you mess up and then ignore their warnings?
Reader interactions
2 Replies to “1 in 6 Amazon Web Services Users Can’t Read”
I’d go out on a limb and wager a good portion of those open buckets were setup by non-IT groups who used Amazon as an end around governance and process. I’d also wager a fair number just used one of the available tools to manage their S3 because they don’t really understand the technology and that tool set the bucket to public unbeknownst to them. That means even if they received and read the email above, they probably didn’t understand it. Is that Amazon’s fault? Absolutely not. It does highlight the issue of kicking governance down the road to IT rather than dealing with it at a business level so it can be easily avoided, or focusing governance only on dollars so small opex spends fly under the radar. Unless business leaders start caring about governance and process a whole awful lot, nothing is going to get better, it’s not. Sorry, the kids have been watching the Lorax movie non stop lately.
As a wise person once said: “There’s no patch for human stupidity…”