A technical write-up explaining AWS S3 misconfiguration is available on our Labs blog.
AWS Simple Storage Service (often shortened to S3) is used by companies that don’t want to build and maintain their own storage repositories. By using Amazon Simple Storage Service, they can store objects and files on a virtual server instead of on physical racks – in simple terms, the service is basically “A Dropbox for IT and Tech teams”. After the user has created their bucket, they can start storing their source code, certificates, passwords, content, databases and other data. While AWS promise safely stored data and secure up-and downloads, the security community has for a long time pointed out severe misconfigurations. If you are vulnerable, attackers could get full access to your S3 bucket, allowing them to download, upload and overwrite files.
The Disposable mail Team has taken a deep dive into AWS asset controls, and will explain how easy it is for hackers to exploit the misconfigurations. Continue reading if you want to know how you can prevent this from happening.
How it is done
The S3 bucket name is not a secret, and there are many ways to figure it out. Once the attacker knows it, there are multiple misconfigurations that can be used to either access or modify information, leading to three different scenarios. By using the AWS Command Line to talk to Amazon’s API, the attacker can:
- get access to list and read files in S3 bucket
- write/upload files to S3 bucket
- change access rights to all objects and control the content of the files (full control of the bucket does not mean the attacker gains full read access of the objects, but they can control the content)
Please note that attackers can gain access without the company hosting the S3 bucket ever noticing or finding out.
AWS are aware of the security issue, but are not likely to mitigate it since it is caused by user misconfigurations.
What can happen
When Disposable mail’s Security Advisor Frans Rosén, a prominent white hat hacker, did the underlying research for his Proof of Concept blog post, he could control assets on high profile websites, meaning he could do anything from overwrite files, upload vulnerable files, and download Intellectual property.
All instances disclosed in the Labs post were reported to the affected parties using responsible disclosure policies. In some of the cases, third party companies were involved and we got assistance from the companies affected to contact the vulnerable party.
Since so many companies store sensitive data in S3 buckets, any leak could be devastating. You might remember the Million Dollar Instagram Bug that allowed security researcher Wes Wineberg to access every single image and account on Instagram. This was only possible because he had gained access to Instagram’s S3 bucket, where the company stored everything from source code to images. “To say that I had gained access to basically all of Instagram’s secret key material would probably be a fair statement,” wrote Wineberg. “With the keys I obtained, I could now easily impersonate Instagram, or impersonate any valid user or staff member. While out of scope, I would have easily been able to gain full access to any user’s account, private pictures and data.”
Here is another example of a public bug bounty report where a security researcher could write files to HackerOne’s bucket without any read access: https://hackerone.com/reports/128088
How to fix it
Change privileges on your bucket: https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingBucketPermissions.html (using AWS Command Line helps proving that exploitation is possible)
Scan your website with Disposable mail (If you already have a Disposable mail account and would like to check your S3 configuration, simply create a new scan profile pointing to your S3 bucket.)
Read the detailed guides and resources in the tool
Test if you are vulnerable with Disposable mail
Disposable mail scans for S3 misconfigurations with a severity range between 4.4-9 on the CVSS scale. They are all placed in the security misconfiguration category in the Disposable mail tool.
The 6 vulnerability types are:
Amazon S3 bucket allows for full anonymous access
Amazon S3 bucket allows for arbitrary file listing
Amazon S3 bucket allows for arbitrary file upload and exposure
Amazon S3 bucket allows for blind uploads
Amazon S3 bucket allows arbitrary read/writes of objects
Amazon S3 bucket reveals ACP/ACL
Read Frans’ full blog post if you want a more detailed walkthrough of the misconfiguration, and reach out to us if you have any questions!
//The Disposable mail Team