How to combat bucket squatting in five steps

The cloud storage bucket has long been an appealing target for threat actors. By claiming buckets you no longer use, or guessing names you’re likely to use in the future, attackers can intercept, modify, or delete your data, and even impersonate your business. Fortunately, there are ways to secure your cloud usage against bucket squatting.

The squatting risk starts with globally unique bucket names: As long as a bucket exists, its name can not be used by anyone else using the same cloud provider.

Once a bucket is deleted, its name can be claimed by anyone. Threat actors can register bucket names that a company has used before, or names that they are likely to register in the future, and use that bucket to gain access to data they can manipulate, delete, and use to impersonate the company for further attacks, such as phishing.

These attackers often use a company’s own information to find the buckets they want to exploit.

Digital squatting has a long history, including bitsquatting, DNS squatting, and URL squatting. But bucket squatting can be much harder to catch than a typo in a URL because the attack takes place deep inside the cloud architecture, and there isn’t widespread awareness about this kind of attack.

The real risk of bucket squatting

Bucket squatting can be difficult to spot, but easy to execute. Organizations unintentionally tell attackers where to look by using a predictable pattern to name buckets. An attacker only needs to guess the name of a bucket you’re likely to use, hoping that you’ll store data there in the future.

Your technical documentation can also become a treasure map for an attacker. When cloud users delete buckets, they often fail to revisit their technical documentation or reference code and remove the names of those deleted buckets. Those dangling buckets are ripe for attack.

As with many cloud capabilities, bucket squatting attacks can happen at an incredible scale. Recently, researchers at watchTowr Labs demonstrated the scale of bucket squatting’s impact. They were able to establish control of roughly 150 abandoned cloud buckets.

Over two months, these buckets received over 8 million requests from military networks, government agencies, Fortune 500 companies, banks, and other organizations that handle sensitive data. The requests sought critical files like software updates and unsigned binaries, meaning a malicious actor could have easily initiated widespread attacks.

How to prevent bucket squatting

Our many guardrails are part of what makes Google Cloud the most secure cloud, and we’re always innovating to strengthen defenses against bad actors. This is part of our commitment to the shared fate model of security.

There are also powerful steps you can take to mitigate the risk of bucket squatting. One step is making an inventory of your existing buckets, which can help alert you to dangling buckets. Although this is fairly standard advice, it’s a step that can easily be overlooked.

Better naming practices and effective technical communications can also help prevent bucket squatting. Since predictable naming and dangling buckets are easy to attack, we recommend avoiding predictable bucket names.

It’s vital that developers and engineers communicate clearly when deleting buckets. A regular and rigorous review of technical documentation, including a hunt for references to deleted buckets, can also strengthen your bucket security.

Here are five simple bucket-securing steps you can take to improve your security posture.

When you add a bucket:

1. Use domain-named buckets for your critical data stores. This ensures only verified and delegated owners of the domain can create bucket names with the domain.
2. Explore tools for randomization, such as Terraform, to disrupt patterns or predictability in your bucket names.

When you no longer need a bucket:

1. Remove all references to deleted buckets. Check internal code, systems, and workflows, and review external documentation regularly. Consider whether your clients and users may need to remove references as well.
2. Delete a bucket’s contents, but not the bucket itself, if you are not able to update all the public references to a bucket you no longer need. This way, you retain control over the names of empty buckets and prevent squatting by an attacker.
3. Make a list of buckets you’ve already deleted, and keep it current. This practice makes it much easier to have discussions with other stakeholders about the risk deleted buckets may create, and how you’ll mitigate that risk.

Learn more about protecting buckets

At Google Cloud, we offer customers the Cloud Asset Inventory tool at no extra cost. It can help you identify all of your buckets, so that you can set up a monitoring practice for any dangling buckets.

You can get started with the Cloud Asset Inventory tool here.