In the world of Infrastructure-as-a-Service, Amazon Web Services have established themselves as a king with their “only pay for what you use” business model. Their affordable services are scale-able to fit any need, from a hobbyist that wishes to create a website all the way up to large multi-national corporations. One of Amazon Web Services most popular services, their S3 Simple Storage Service, when configured improperly, can quickly turn from a valuable asset, into a serious security vulnerability.
According to InfoTransec, starting in April of 2017 they began to notice well known organizations suffering massive data breaches and “These organizations all had one thing in common, and that was the use of poorly secured Amazon Web Service (AWS) Simple Storage Service (S3) buckets that were used to secure their data.”1 Breached organizations included most notably: Scottrade, a financial institution that exposed 20,000 customers’ personal information and login credentials; Booz Allen Hamilton, a defense contractor that exposed 90,000 people’s sensitive information; and Dow Jones, a financial institution that exposed a confirmed 2.2 million users personal information, email addresses, and account information.2 Given the trend of massive data breaches present during 2017, Information Security Expert Lesley Carhart made a chilling, yet hypothetical prediction, that “all those silos of massive breached data? Criminals are going to start hiring data analytics people to put it together in meaningful ways.”3 Lesley did note that threat actors employing data analysts to sort the breached data is “entirely technically plausible. Just depends on who’s buying what.”4 and that “It’s not like all threat actors share data or even sell to the same people.”5 is what is keeping this from moving beyond a hypothetical discussion into reality for now.
Being a person who is naturally curious, I asked myself: “How hard is it to locate an exposed S3 bucket and download its data?” Naturally, I turned to Google to begin my journey. The first information that I found, is that when an S3 bucket is exposed to the internet, it will have a unique hostname address, accessible through any internet browser. I also very quickly found proof-of-concept tools, designed to not only to scan for publicly exposed S3 buckets but also to download data from them. Their method of action is very simple and effective. The tools that I located all operate very similar to a subdomain brute-forcing tool. They parse information from a text file containing common bucket names and from a text file containing keywords, combining them into a hostname and domain name address in the form of a URL, send out HTTP requests for the generated URL, when an HTTP code 200 is received, it then parses the keys from the S3 bucket .xml file, and if downloading is selected, and the files listed by the keys are below the specified size, it will automatically download them for you.
I settled on a tool, written in python, named AWSBucketDump (located at https://github.com/jordanpotti/AWSBucketDump) to test the complexity of an S3 data breach.
The installation of AWSBucketDump was very easy:
The Usage of AWS Bucket seemed very straight-forward:
For the purposes of demonstration, I executed the program, using the default wordlists provided with AWSBucketDump. A targeted attack on a corporation would use crafted wordlists.:
AWSBucketDump began searching for exposed S3 buckets:
In under a minute AWSBucketDump had located an exposed S3 bucket and began downloading its data. I did it! With no previous experience in downloading data from an exposed AWS S3 bucket, I had profited! It was literally that easy!:
In my browser, I navigated to S3 Bucket I had downloaded the data from to verify its contents, here is the .xml file.:
I then decided to navigate to one of the files I had downloaded in my browser to see what it contained. While this is not the most sensitive information that could have been found, I did locate a screenshot of someone’s cell phone bill. I wonder if this belongs to Kamesh, whose name is listed in the bucket key URI’s.:
I decided to briefly return to Google, to see if “Google dorking” techniques would reveal more exposed S3 buckets. I was met with more success!:
A Now that awareness of the gravity of leaving an S3 bucket exposed is more commonplace, we have been seeing a reduction in serious leaks due to S3 misconfigurations. Amazon Web Services now lists the status of an S3 bucket being exposed to the internet in the S3 section of their management console.:
When deploying S3 buckets, please refer to Amazon’s documentation and keep in mind their recommendations for configuration. Depending on what is being stored in the bucket there may be additional Regulatory Standards such as PCI/DSS or HIPAA that require additional security measures other than what Amazon recommends to maintain compliance! Find their guide on ensuring your files are secure at https://aws.amazon.com/premiumsupport/knowledge-center/secure-s3-resources/
References:
1: Infotranec, 2017, http://www.infotransec.com/news/growing-trend-amazon-s3-breaches
2: Data regarding the breaches listed was paraphrased from Infotranec, 2017, http://www.infotransec.com/news/growing-trend-amazon-s3-breaches
3: Twitter, 12/27/2017, https://twitter.com/hacks4pancakes/status/946152648381779969
4: Twitter, 3/17/2018, https://twitter.com/hacks4pancakes/status/975141592972619777
5: Twitter, 3/17/2018, https://twitter.com/hacks4pancakes/status/975141342912417793