In our previous post, we mentioned that we received an email from Amazon Web Services warning us that “some tools and scripts have emerged which scan services like Amazon S3 to identify publicly accessible buckets.”
The threat posed by inadvertent exposure of sensitive files is not a new concept. Corporate network security experts have long recognized the security risks embedded in uploading files. However, users mistakenly believe that the sheer quantity of uploaded files renders their own files virtually invisible. They believe no one will spend the time necessary to sort through the files. Consequently, users become less vigilant in security.
The decreased vigilance results in inadvertently exposed sensitive information. A 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 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 overall quantity of files.
However, their confidence is misplaced. Dangers arise when scripts surface to automate the task of locating sensitive content on a fileshare or on files uploaded to an S3 bucket. With a little bit of digging, we were able to discover exactly that tool.
“However, their confidence is misplaced. Dangers arise when scripts surface to automate the task of locating sensitive content on a fileshare or on files uploaded to an S3 bucket.”
Robin Wood, a researcher in Leeds, UK who hosts his ethical hacking website at DigiNinja , built a Ruby script that automates the search. His script launches a dictionary attack on the names of S3 buckets and interrogates the bucket for a list of public and private files.
The script loads a file of common words and attempts to find buckets in S3 that match the common words. This automated sorting mechanism clears the field of file camouflage. Once a good sampling of S3 buckets is detected, the buckets can be interrogated for misconfigured security settings.
This attack is fairly effective because of the way S3 works. When an AWS user picks an S3 bucket name, that name is global. This means you can identify other people’s buckets by assuming that they will choose common names. Mr. Woods, in his examples, downloaded a wordlist from Packet Storm Security and proved the possibility.
Corporate names present an even more frightening list. If an attacker was targeting a specific company, they might look at creating a wordlist around the name of the company. For example, someone targeting Bank of America could choose bankofamerica1, bankofamerica2, bankofamerica_hr, bofa_hr, bofa_finance, etc.
The lesson to learn here is that you should be using this script to bolster your own security. You can run it on your own company’s AWS accounts and ensure you don’t have files that are inadvertently exposed. This requires 3 simple steps. First, create a wordlist out of your buckets. Second, run Bucket Finder. Third, review its findings. As an additional check, you might replicate the steps with a wordlist created from company associated words – i.e. the Bank of America example – to insure that you capture your ‘unknown’ company buckets.
To check out the script yourself, visit the Bucket Finder on DigiNinja.
Keep up with the Latest in Cloud
Check out our Resources Center for cloud industry news, research, webinars, and more.