S3 Bucket Security

The security concerns over misconfigured AWS services in general and S3 buckets in particular are not new. Network security experts have long recognized the security risks associated with uploading files to the public cloud, but users mistakenly believe that the obscurity of individual naming and the sheer quantity of uploaded files renders their own sensitive information effectively invisible. They believe that no one will be able to “guess” their bucket names or spend the time required to sort through the files. Consequently, users become less vigilant in security and, often, set permissions to “Everyone”. We found exactly that decrease in vigilance in our March 2013 AWS/CloudCheckr user survey.

“They believe that no one will be able to ‘guess’ their bucket names or spend the time required to sort through the files.”

 
Simply put, we saw customers with a large amount of inadvertently exposed sensitive information. A bucket or file might be uploaded without understanding that the directory is publicly exposed to the world. Or, the directory might be properly secured when the files are uploaded, but then security is relaxed by someone else that doesn’t understand that sensitive files are in the bucket. Even when these issues occur, users feel confident that their files remain camouflaged by the anonymity of bucket naming and the overall quantity of files; however, their confidence is misplaced. Scripts that automate the task of locating buckets, sensitive content on a fileshare, and/or on files uploaded to an S3 bucket are readily available.
AWS has recognized the issue and sent emails warning customers about S3 settings, but the warnings are intermittent and often ignored. The simple reality is this: the combination of AWS users adjusting to an unfamiliar architecture and the general complexity of AWS configurations results in users leaving information unintentionally exposed.
Before we delve into mitigation steps, it might be worthwhile to address some key configuration choices and the implications of setting them to “Everyone.”
 

4 Key Bucket Configuration Choices

• READ ACL – This permission, although not a huge security issue, is still unwise. It allows everyone to know who controls your files. It is akin to broadcasting your username, but not your password. The hacker still needs the password, but you have removed one more obstacle in his path and made the journey to your data easier. For this reason, setting this permission to Everyone is not recommended.
• READ – This allows the outside world to list the objects within your bucket. It does not provide permission to view the files, but it is still unwise. Again, you are providing a hacker with information – and information is power. With the list, a hacker can more easily identify any files that may have misconfigured S3 object permissions. Consequently, we also recommend against setting this permission to Everyone.
• WRITE – This allows everyone to upload and delete files. The problem with these permissions being set to Everyone is that, along with the intended users, an attacker has the capability to modify or delete files within your bucket(s). If there is data that should not be modified, that’s a big problem. Less obvious, perhaps, is the fact that you could be leaving yourself open to a potential “economic denial-of-service attack”. Someone can upload massive files to your bucket(s) that could cause you to incur crippling financial costs that would damage an application or organization. Buckets should never be configured with this setting to Everyone.
• WRITE ACL – This allows user to edit permissions. It is the most dangerous setting as hacker can give themselves READ and WRITE permissions. This allows hackers to grant themselves unfettered access. Buckets should never be configured with this permission set to Everyone.

6 Core Steps to Mitigation

• Check for folders or objects granted the permission “Open/Download” to Everyone. This permission allows anonymous users to read a file but does not allow them to update the file. Review all cases in which this permission is granted to verify that it is appropriate.
• Check for folders or objects granted “View Permissions” and “Edit permissions” to Everyone. This permission allows anonymous users to edit or delete a file.  Review all cases in which this permission is granted to verify that it is appropriate.
• Check that logging is enabled for S3 buckets. This creates a log file of all accesses to the objects and bucket. Without this option, you will be unable to track and identify who has accessed a file/object in S3.
• Check that notifications have been enabled for S3 buckets. There is a property for each S3 bucket: “Enabling notifications causes a message to be published to an Amazon Simple Notification Service (SNS) Topic when Amazon S3 detects that a Reduced Redundancy Storage object stored in this bucket is lost.” If you do not enable this option, you will not be notified when an S3 object is corrupt or lost.
• Check for S3 buckets that have a website endpoint enabled. Verify the permissions and content within the directory to verify that no sensitive data has been exposed.
• Continually review your deployment to insure that you remain properly configured. This is probably the most difficult of all the required mitigation steps. The reality is that AWS is a dynamic environment and it is unrealistic to expect users to devote the time required to perform checks every day. However, failing to continually review will almost guarantee users that their ‘fixed’ vulnerabilities soon reappear.

CloudCheckr Automates the Review

CloudCheckr automatically scans user deployments on a daily basis and reports back that information so that rather than spending hours checking, users can identify issues in seconds.

Above is a screen shot of CloudCheckr with the relevant S3 best practices enabled and reported upon. The issues surrounding S3 exposure are all checked and reported on a daily basis.

Of course, as the screen shot below shows, CloudCheckr’s Security reports on far more than just S3. CloudCheckr reports in areas of Availability, Cost, and Usage as well.
 
We encourage you to sign up for a free trial, scan your deployment, improve your security, and compare your results to our March survey results.