8 ms·
Bucketsquatting is finally dead
- A7OM 6mo ago[flagged]
- lijok 6mo agoHuh? Hash your bucket names
- Maxion 6mo agoI don't think that'd prevent this attack vector.
- alemwjsl 6mo agoOk; salt, and then hash your bucket names
- xxs 6mo agothat doesn't help either. 'Salt' is public and usually different/unique per entry/name. If you mean to use a "secret" prefix (i.e. pepper) then, that would generate effectively globally unique names each time (and unpredictable too) but you can't change the pepper and it's only a matter of time it'd leak.
- lcnPylGDnU4H9OF 6mo agoIf they can't make the bucket before you do then they are not "bucket squatting", and they can't do so for a salted and hashed bucket name without knowing the salt at runtime. The public/private distinction seems moot here, too: the salt is a throwaway since you just need the bucket name. Even if you do need to keep track of the salt, it should be safe for the attacker to know, at least with respect to this attack, because you already own the bucket which the attacker would otherwise hoard.
- ethanrutherford 6mo agoThe "squatting" part of "bucket squatting" is a bit of a misnomer here. The attack vector is actually in the opposite direction. 1. You set up an aws bucket with some name (any name whatsoever). 2. You have code that reads and/or writes data to the bucket. 3. You delete the bucket at some later date, but miss some script/process somewhere that is still attempting to use the bucket. For the time being, that process lies around, silently failing to access the bucket. 4. The bucket name is recycled and someone else makes a bucket with the same name. Perhaps it's an accident, or perhaps it's because by some means an attacker became aware of the bucket name, discovers that the name is available, and decided to "squat" the name. 5. That overlooked script or service is happy to see the bucket it's been trying to access all this time is available again. You now have something potentially writing out private data, or potentially reading data and performing actions as a result, that is talking to attacker-owned infrastructure.
- CloakHQ 6mo ago[dead]
- nulltrace 6mo agoSeen this happen with Terraform. One team tears down a stack, bucket gets deleted, but another stack still has the name hardcoded in an output. Next CI run uploads artifacts to a bucket name that's now up for grabs. You only notice when deploys start failing. Or worse, succeeding against someone else's bucket.
- tosti 6mo agoRandom pepper. Or just, y'know, randomly generate the effing string. Can't be that hard.
- xxs 6mo agoOf course, any UUIDv4 would do it (or any random stuff in general). I suppose the idea was having a naming scheme, instead of sharing the paths explicitly (and having an internal mapping for them)
- why_only_15 6mo agoif your bucket name is ever exposed and you later delete it, then this doesn't help you.
- lijok 6mo agoThe entire article talks about “guessing” the bucket name as being the attack enabler, not the leaking of it. What does the landscape look like once you start doing the basics like hashing your bucket names? Is this still a problem worth engineering for?
- ChrisMarshallNY 6mo ago[flagged]
- DonHopkins 6mo agoIt sounds like a sensitive subject, very delicate, and of no concern to law enforcement, for private videos of an artistic nature. https://www.youtube.com/watch?v=KaQ-s_P5mwM https://www.youtube.com/watch?v=KaQ-s_P5mwM
- iknownothow 6mo agoI'd ask politely to refrain from such comments :) This is not me criticising you. I totally understand the urge to say it. We're all thinking the thing you're thinking of. It takes effort not to give into it ;) The reason I personally would refrain from making such comments is that they have the potential to end up as highest ranked comment. That would be a shame. Topic of S3 bucketsquatting is rather important and very interesting.
- calmworm 6mo agoThat took a decade to resolve? Surprising, but hindsight is 20/20 I guess.
- icedchai 6mo agoTwo. S3 has been around since 2006!
- AmbroseBierce 6mo agoIt can of really took off in 2012 tho: https://trends.google.com/explore?q=%2Fm%2F025tp88&date=all&geo=Worldwide https://trends.google.com/explore?q=%2Fm%2F025tp88&date=all&...
- thih9 6mo ago> If you wish to protect your existing buckets, you’ll need to create new buckets with the namespace pattern and migrate your data to those buckets. My pet conspiracy theory: this article was written by bucket squatters who want to claim old bucket names after AI agents read this and blindly follow.
- shablulman 6mo ago[flagged]
- vhab 6mo ago> For Azure Blob Storage, storage accounts are scoped with an account name and container name, so this is far less of a concern. The author probably misunderstood what "account name" is in Azure Storage's context, as it's pretty much the equivalent of S3's bucket name, and is definitely still a large concern. A single pool of unique names for storage accounts across all customers has been a very large source of frustration, especially with the really short name limit of only 24 characters. I hope Microsoft follows suit and introduces a unique namespace per customer as well.
- ryanjshaw 6mo agoI recall being shocked the first time I used Azure and realizing so many resources aren’t namespaced to account level. Bizarre to me this wasn’t a v1 concern.
- mwalser 6mo agoAnd the naming restrictions and maximum name lengths are all over the place: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules https://learn.microsoft.com/en-us/azure/azure-resource-manag... Storage accounts are one of the worst offenders here. I would really like to know what kind of internal shenanigans are going on there that prevent dashes to be used within storage account names.
- xmcqdpt2 6mo agoI wonder if it's related to the fact that Windows as such weird rules about allowed file names. Like not directly obviously, more like culturally inside microsoft.
- throwaway173738 6mo agoI’m pretty sure Azure was built out with Hyper-V, which was built into the Windows kernel. So everything that relied on virtualization would’ve had bizarre case insensitivity and naming rules. I’ve lost track of servers in Azure because the name suddenly changed to all uppercase ave their search is case sensitive but whatever back-end isn’t.
- Aardwolf 6mo agoWhy all that stuff with namespaces when they could just not allow name reuse?
- deleted 6mo ago[deleted]
- CodesInChaos 6mo agoI'd allow re-use, but only by the original account. Not being able to re-create a bucket after deleting it would be annoying. I think that's an important defense that AWS should implement for existing buckets, to complement account scoped bucket.
- wiether 6mo agoThen they should allow bucket ownership transfer...
- iknownothow 6mo agoPotential reasons I can think of for why they don't disallow name reuse: a) AWS will need to maintain a database of all historical bucket names to know what to disallow. This is hard per region and even harder globally. Its easier to know what is currently in use rather know what has been used historically. b) Even if they maintained a database of all historically used bucket names, then the latency to query if something exists in it may be large enough to be annoying during bucket creation process. Knowing AWS, they'll charge you for every 1000 requests for "checking if bucket name exists" :p c) AWS builds many of its own services on S3 (as indicated in the article) and I can imagine there may be many of their internal services that just rely on existing behaviour i.e. allowing for re-creating the same bucket name.
- dwedge 6mo agoI can't accept a) or b). They already need to keep a database of all existing bucket names globally, and they already need to check this on bucket creation. Adding a flag on deleted doesn't seem like a big loss. As for c), I assume it's not just AWS relying on this behaviour. https://xkcd.com/1172/ https://xkcd.com/1172/
- INTPenis 6mo agoI started treating long random bucketnames as secrets years ago. Ever since I noticed hackers were discovering buckets online with secrets and healthcare info. This is where IaC shines.
- XorNot 6mo agoI just started using hashes for names. The deployment tooling knows the "real" name. The actual deployment hash registers a salt+hash of that name to produce a pseudo-random string name.
- Galanwe 6mo agoThis is all good and we'll on the IaC side,yes. But at the end of the day, buckets are also user facing resources, and nobody likes random directory / bucket names.
- amluto 6mo agoIt would be nice if the other end of this could be addressed: a configurable policy to limit resolution of bucket names within an account namespace. Ideally, if someone doesn’t have permission to resolve a bucket name, they shouldn’t even be able to detect whether it exists.
- INTPenis 6mo agoThat's a contradiction, a bucket name being treated as a secret in IaC, while being a user facing resource. So no, they're not user facing resources. If anyone wants them to be user facing resources, then treat them as such, and ensure they're secure, and don't store sensitive info on them. Otherwise, put a service infront of them, and have the user go through it. The S3 protocol was meant to make the lives of programmers easier, not end users.
- deleted 6mo ago[deleted]
- 8organicbits 6mo ago
- sriramgonella 6mo ago[dead]
- alemwjsl 6mo agoI take it advertising your account id isn't a security risk?
- aduwah 6mo agoIt is not hygienic, but with only the account-id you are fine. In the IAM rules the attacker can always just use a * on their end, so it does not make a difference. You have to be conscious to set proper rules for your (owner) end tho.
- Cthulhu_ 6mo agoArmchair opinion, but shouldn't be too bad - it's identification, not authentication, just like your e-mail address is. But probably best to not advertise it too much.
- deleted 6mo ago[deleted]
- otterley 6mo agoAWS does not consider it one. “While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.” https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html https://docs.aws.amazon.com/accounts/latest/reference/manage...
- thenickdude 6mo agoIf you ever produce and share a signed link for e.g. S3, this link contains your access key ID in it. Turns out you can just slice and decode your Account ID out of that access key, it's in there in base32: https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489 https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f...
- iknownothow 6mo agoThank you author Ian Mckay! This is one of those good hygiene conventions that save time by not having to think/worry each time buckets are named. As pointed out in the article, AWS seems to have made this part of their official naming conventions [1]. I'm excited for IaC code libraries like Terraform to incorporate this as their default behavior soon! The default behavior of Terraform and co is already to add a random hash suffix to the end of the bucket name to prevent such errors. This becoming standard practice in itself has saved me days in not having to convince others to use such strategies prior to automation. [1] https://aws.amazon.com/blogs/aws/introducing-account-regional-namespaces-for-amazon-s3-general-purpose-buckets/ https://aws.amazon.com/blogs/aws/introducing-account-regiona...
- josephg 6mo agoSometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names. This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can also be used to prevent squatting and reuse attacks - just burn the full account name if the corresponding user account is ever shut down. And it prevents early users from being able to snap up all the good names.
- donmcronald 6mo agoI just want to be able to use a verified domain; @example.com everywhere.
- Cthulhu_ 6mo agoThat still has "squatting" risks as described in the original article though, domains expire and / or can be taken over.
- fc417fc802 6mo agoBut you already have a domain for whatever you're doing so presumably that's going to be a threat either way. For particularly high risk activities if circumstances permit you can sidestep the entire issue by adding a layer of verification using a preshared public key. As an arbitrary example, on android installing an app with the same name but different signing key won't work. It essentially implements a TOFU model to verify the developer.
- rithdmc 6mo agoI like it for buckets, but adding a four digit code won't help with the package hijacking side of things - in fact might just introduce more typo/hijack potential. It'll just be four more characters for people to typo.
- jorams 6mo ago
- ClaudeFixer 6mo agoGood riddance. The number of production deploys I've seen pointing at bucket names that could've been claimed by anyone was wild. Glad this is finally getting closed off at the platform level instead of relying on everyone to not make the mistake.
- coredog64 6mo agoThere are other mitigations though: You can pass expected owner accountId on S3 operations and you can create SCPs that restrict the ability of roles to write to buckets outside the account. Unless you have an account that does many cross-account S3 writes, the latter is a simple tool to prevent exfiltration. Well, simple assuming that you're already set up with an Organization and can manage SCPs. [0] https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-owner-condition.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket...
- bulbar 6mo agoA name shouldn't be the same as the thing it names. When a name becomes free and somebody else uses it, it points to another thing. What that means for consumers of the name depends on the context, most likely it means not to use it. If you yourself reassign the name you can decide that the new thing will be considered to be identical to the old thing.
- etothet 6mo agoSpeaking of unique names within AWS, I learned the other day that even after you delete an AWS account, you can’t reuse the root user email addresses (it’s documented, but I wasn’t aware). Someone at my org used their main company email address for a root user om an account we just closed and a 2nd company email for our current account. We are past the time period where AWS allows for reverting the account deletion. This now means that he isn’t allowed to use SSO via our external IdP because the email address he would use is forever attached to the deleted AWS account root user! AWS support was rather terrible in providing help.
- jakobobobo 6mo agoGood for them. It's amazing how pointless most security is when a 10/10 rating to some commodity communication service's support from a phisher is all it will take.
- nawgz 6mo agoHelp me understand why you would delete your AWS account if the company and email address are unchanged - I can’t see the motivation. And on the flip side I can easily see why not allowing email addresses to be used again is a reasonable security stance, email addresses are immutable and so limiting them only to one identity seems logical. Sounds quite frustrating for this user of course but I guess it sounds a bit silly to me.
- dec0dedab0de 6mo agowhat if you stopped using AWS for a while, then came back?
- clickety_clack 6mo agoIt’s not hard to imagine a case where maybe there’s 2 offices that had their own separate aws accounts and they closed one. AWS has been around for quite a while now. It’s also not impossible to believe that there are companies out there that might have moved from aws to gcp or something, and maybe it’s time to move back.
- 6mo ago
- perunamies 6mo ago[flagged]
- lsaferite 6mo agoI mean, why isn't this just the mandatory default going forward? Globally shared, unique bucket names always struck me as a horrible idea.
- ian_d 6mo agoThe _really_ fun bucket squatting attacks are when the cloud providers themselves use deterministic names for "scratch space" buckets. There was a good DC talk about it at DC32 for AWS, although actual squatting was tough because there was a hash they researchers couldn't reverse (but was consistent for a given account?): https://www.youtube.com/watch?v=m9QVfYVJ7R8 https://www.youtube.com/watch?v=m9QVfYVJ7R8 GCP, however, has does this to itself multiple times because they rely so heavily on project-id, most recently just this February: https://www.sentinelone.com/vulnerability-database/cve-2026-1727/ https://www.sentinelone.com/vulnerability-database/cve-2026-...
- equinumerous 6mo agoThat was an amazing talk, thanks for sharing! I could see the writing on the wall as soon as I saw the bucket names were predictable. Bucket squatting + public buckets + time of check/time of use in the CloudFormation service = deploying resources in any AWS account with enough persistence. I'm surprised this existed in AWS for so long without being flagged by AWS Security.
- CafeRacer 6mo agoWhile I understand where it's coming from I always had something like <bucket_tag>-<9_random_\d\w>
- PunchyHamster 6mo agodecision to make bucket (and not bucket + account id surrogate) a sole key for access was one of most annoying mistakes in S3 design
- amne 6mo agoI hope nobody wanted "ecommerce-admin". sorry
- saurik 6mo agoAWS buckets still offer special features if and only if the name of the bucket matches your hostname. https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/Virtua...
- peanut-walrus 6mo agoWhy the hell is this a name suffix instead of just using subdomains? myapp-123456789012-us-west-2-an vs myapp.123456789012.us-west-2.s3.amazonaws.com The manipulations I will need to do to fit into the 63 char limit will be atrocious.
- Bridged7756 6mo agoI think I'm not getting it. What's the problem if someone else can claim that bucket name? If it's deleted wouldn't the data be deleted too? Or is it there something I'm missing.
- echoangle 6mo agoI think you can put malicious data in the bucket and „impersonate“ the deleted bucket, so old code referencing the bucket uses your data instead of throwing an error (?).
- returningfory2 6mo agoOr old code referencing the bucket _writes_ data to it, and the attacker can now read it.
- tekla 6mo agohttps://www.aquasec.com/blog/bucket-monopoly-breaching-aws-accounts-through-shadow-resources/ https://www.aquasec.com/blog/bucket-monopoly-breaching-aws-a...
- useftmly 6mo ago[flagged]
- pooplord69 6mo agoDoes it still take like an hour to rename one?
- GuinansEyebrows 6mo agothis seems nice but it's a little annoying if you've been using terraform's `bucket_prefix` to create buckets. i wonder if/when they'll update that or if they'll add a new bucket_name argument that uses the new namespacing.
- deleted 6mo ago[deleted]
- SoftTalker 6mo agoDNS names have the same problem. Once they are not renewed, they eventually become available again. Then anyone can re-register them, set up an MX record, and start receiving any emails still being sent to recipients in that domain. This could include password reset authentications for other services, etc.
- icedchai 6mo agoYup. You can get control of valuable assets this way, like legacy IPv4 blocks.
- arjie 6mo agoGood solution. Thanks for popularizing it. * Backwards compatible * Keeps readability * Solves problem
- wrs 6mo agoOnce again AWS waits an inexplicably long time to fix an obvious deficiency that the other providers solved long ago, and then does it in an inexplicably hacky way. See also their recent innovation of letting you be logged into the console with up to five (???) of the many accounts their bizarre IAM system requires, implemented with a clunky system of redirections and magic URL prefixes. As opposed to GCP just having a sensible system in the first place of projects with permissions, and letting you switch between any of them at will using the same user account.
- emddudley 6mo agoWhy is x-amz-bucket-namespace header needed when creating a new bucket in the account regional namespace? Is an account blocked from creating a bucket in its own namespace if it doesn't specify that header?
- robutsume 6mo ago[dead]
- benguild 6mo agoIf you try to create a new iOS/macOS software project and sign it with a "com.apple." prefix in the bundle ID, Apple's system blocks it… for example. It's pretty clear this type of ID'ing is an issue in general, unfortunately. Companies often protect themselves as a band-aid but not others in the same situations since the problems aren't frequent enough to warrant a design change. So, when it does become a problem, it could end up being a deep one.
- wparad 6mo agoI really don't understand why everyone is jumping up and down over this. I doesn't really feel like a real solution. But I couldn't contain myself and wanted to a write a response: https://authress.io/knowledge-base/articles/2026/03/14/how-aws-can-fix-s3 https://authress.io/knowledge-base/articles/2026/03/14/how-a...
- StacyRawls 6mo ago[dead]
- Cribkind 6mo ago[dead]