Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Bucket Snipping is a class of AWS integration vulnerabilities that stems from S3 buckets being globally scoped. The idea is to possess readable and writable access to an S3 bucket used by another account then use this control to perform malicious things in the account.

The AWS Cloud Development Kit (CDK) is a framework for infrastructure as code. This allows using programming languages like Python to translate into configurations in AWS. CDK has a one time initialization step called bootstrap. This one time command creates the necessary roles for CloudFormation and CDK in the account, an S3 bucket and other resources.

The bucket named can be changed but has a default format of cdk-{qualifier}-assets-{account-ID}-{Region}. The qualifier has a default value of hnb659fds, the region is guessable and the account Id is the only somewhat secret value but may be learned through other means.

Because the bucket is somewhat predictable and S3 is global, it can be registered ahead of time. They call this out as a DoS which to me is BS - this is like saying that me frontrunning the creation of a domain is a DoS! You can literally just change the name slightly and it's fine.

Sometimes, resources get deleted from AWS accounts, especially with quota limits. If this happens, another user can create the S3 bucket because it's global. By default, the CloudFormationExecuteRole used by CDK has admin privileges to the account, making the ability to overwrite a template very, very bad. Does this work? Yes it does!

The attack assumes that the user has CDK initialized in their account, deleted the S3 bucket and has a predictable qualifier:

1. Attacker recreates the deleted S3 bucket in the account using the predictable name. On this bucket, the attacker sets a permissive resource-level policy.
2. On the S3 bucket, configure a Lambda function to inject the malicious admin role into any CloudFormation template that gets loaded. There are hooks for S3 bucket operations that make this possible.
3. User runs cdk deploy in their account.
4. Upon triggering the build, the template gets written to the attackers S3 bucket, which gets backdoored. Since the template has been updated, it will deploy the resources that the attacker specifies.
5. What does an attacker do with this? They crate a Backdoor IAM role that can be assumed by an account that they control! At this point, they have admin rights in the account.

How likely is this to happen though? This is where I find the article interesting! First, they checked if a particular IAM account existed using a known technique which is surprising to me that it works. They created a scanner that looked for the existence of the S3 bucket name for 38,000 known accounts. If the role existed but the S3 bucket didn't, the attack was on!

From the 38K accounts analyzed, 2% of them used CDK. Of these accounts, 10% of the accounts were found to be vulnerable to this attack vector. According to AWS, about 1% of CDK users were affected by this issue. An account takeover in AWS from simply deleting a bucket is pretty bad news!

To remediate the vulnerability, newer versions of CDK ensure bucket ownership by the account. Additionally, AWS added some docs to not use the default qualifier. Since previously bootstrapped users are still potentially vulnerable to this attack, AWS added messages in the CLI terminal with a big error message that this still affected them.

Overall, a good writeup on a classic AWS bucket snipping vulnerability. It amazes me that these are still being found in AWS products after all of these years.