Yes, yes, I'm late to the party, I know. Poorly secured Amazon S3 buckets have been a thing for a while now, but recently there's been a large uptick again as some awesome tools were written to help find these misconfigured buckets. Let's chat a little about the problem at hand and show-off some cool tools!
Why all the drama about S3 Buckets?
For the uninitiated, Amazon Web Services offers a service called S3. S3, for lack of a better definition, is a web-based storage solution. It's not a database. It's not a key-value store. It's literally a place to store files (Amazon calls it a cloud object storage). In fact, it's closer to Google Drive and Dropbox than anything else.
So, this leads the question - "So, what?" I'm glad you asked... You see, AWS is a very popular platform to host all sorts of things (servers, applications, storage, you name it and Amazon probably has an AWS service for it). For the longest time, AWS had very poor default permissions on a newly created S3 Bucket (an S3 instance is called a bucket). This meant anyone with a web browser and the ability to guess what you named your S3 Bucket could view, download, and even add new files to your S3 Bucket.
Organizations were hosting all sorts of interesting files in their S3 buckets. We've seen everything from flat-files (CSVs, Documents, Excel Sheets) to full database backup files. The only thing protecting someone from having their files stolen was guessing the name of their bucket. Once people got wind of this, we started seeing a handful of dictionary-based bruteforcers then the intelligent bruteforcers and now tools that detect when a bucket is created due to the HTTPS certificate being created. The InfoSec community really brought their A-Game to this party.
You mentioned tools...?
We'll start basic and move our way up. If you're a bug hunter or just dabble in bug bounties in your spare time, I would highly suggest looking into S3 Bucket problems (especially if the target uses AWS to host their application).
Bruteforce tools. These are nothing out of the ordinary. They take a dictionary and bruteforce if that word has an associated S3 Bucket (and will see if it is configured wrong). I've tried my best to be language agnostic with these tools, so pick the language of your choice.
- https://github.com/gwen001/s3-buckets-finder (PHP?? Yeah, that's still a thing)
- https://github.com/Ucnt/aws-s3-bruteforce (Python)
- https://github.com/nahamsec/lazys3 (Ruby)
Certificate scanning tools. These watch for new HTTPS certificates being created (thank you, CertStream) and filter everything out except for S3 Buckets. They then test if the S3 Bucket is world-readable. They're truly magical.
Obviously, in specific engagements there are upsides to testing a curated dictionary of words, but in other situations, it may be more interesting to see a real-time stream of new insecure buckets being created. I'm willing to bet Threat Intelligence companies will be eating this data and alerting based on keywords in the near future.
Fixing insecure buckets
Like all of my previous posts, I always try to include a section on remediating the discussed risk. So, let's do just that.You will need access to your organization's AWS management console and an account with enough permission to administrate your S3 buckets.
- Sign into your AWS management console
- Navigate to Amazon S3 (using search or the option under the millions of services)
- In the bucket listing, ensure none say Public under Access
- For a bucket you want to remove public access, click the bucket name, then click the Permissions tab
- Under Public Access, ensure there are no permissions granted (refer to image below)
Conclusions
"The cloud" can be truly revolutionary, but we've got to work on better default configurations so it is harder for people to make these mistakes. I have always been a big fan of stricter default security policies - Yes, I know this may make some users frustrated that they need to configure your product instead of just install and go. But consider the security implications of a 3-Letter agency letting classified information be leaked due to a poorly configured S3 Bucket (Source: https://www.upguard.com/breaches/cloud-leak-inscom). Yes, that did indeed happen.
Thanks for making it this far -- Got something to say or wanna correct my inane rambling? Post it below.
Where's S3 Part 2?
ReplyDelete