Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bucketsquatting is finally dead

onecloudplease.com

Post reply on HN
Print view View original

81–90 of 187 posts

Re: Bucketsquatting is finally dead

#81

Post by Twirrim »

vhab wrote: post #9

> 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 frust…

S3 was well aware of the pain when I was there ~10 years ago, just considered themselves handcuffed by the decisions made before the idea of a cloud was barely a twinkle in a few people's eyes, and even the idea of this kind of scale of operation wasn't seen as even remotely probable. The namespace issue is one of a whole long list of things S3 engineers wish they could change, including things like HTTP status code behaviour etc.

I've never really understood S3's determination not to have a v2 API. Yes, the V1 would need to stick around for a long time, but there's ways to encourage a migration, such as having all future value-add on the V2, and maybe eventually doing marginal increases in v1 API costs to cover the dev work involved in maintaining the legacy API. Instead they've just let themselves, and their customers, deal with avoidable pain.

Re: Bucketsquatting is finally dead

#83

Post by lcnPylGDnU4H9OF »

xxs wrote: post #44
alemwjsl wrote: post #26

Earlier quoted context omitted.

Ok; salt, and then hash your bucket names

that 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.

If 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.

Re: Bucketsquatting is finally dead

#84

Post by tosti »

xxs wrote: post #44
alemwjsl wrote: post #26

Earlier quoted context omitted.

Ok; salt, and then hash your bucket names

that 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.

Random pepper. Or just, y'know, randomly generate the effing string. Can't be that hard.

Re: Bucketsquatting is finally dead

#85

Post by 8organicbits »

embedding-shape wrote: post #80
8organicbits wrote: post #79

Earlier quoted context omitted.

No man-in-the-middle is needed, DNS queries are often collected into large datasets which can be analyzed by threat hunters or attackers. Check out passive DNS https://www.spamhaus.com/resource-center/what-is-passive-dns... You'd need to check the privacy policy of your DNS provider to know if they share the data with anyone else. I've commonly seen source IP address consider as PII, but not the content of the query.…

> No man-in-the-middle is needed [...] Check out passive DNS How does one execute this "passive DNS" without quite literally being on the receiving end, or at least sitting in-between the sending and receiving end? You're quite literally describing what I'm saying, which makes it less of a "leak" and more like "others might collect your data, even your ISP", which I'd say would be accurate than "your DNS leaks".

There's a lot of online documentation about passive DNS. Here's one example

> Passive DNS is a historical database of how domains have resolved to IP addresses over time, collected from recursive DNS servers around the world. It has been an industry-standard tool for more than a decade.

> Spamhaus’ Passive DNS cluster handles more than 200 million DNS records per hour and stores hundreds of billions of records per month, providing you with access to a vast lake of threat intelligence data.

https://www.spamhaus.com/resource-center/what-is-passive-dns...

Re: Bucketsquatting is finally dead

#87

Post by brnt »

josephg wrote: post #30

Sometimes 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 al…

The .NL gTLD used to work like that for personal registrations (ie individuals without a business registration). $name.NNN.nl where you were allowed to choose the number.

It won't surprise you the scheme never caught on and has been decommissioned (you can now register any available domain as an individual as well). The difference is probably few people use a personal TLD, but many use a name on some social media.

Re: Bucketsquatting is finally dead

#89

Post by otterley »

zenoprax wrote: post #76
nawgz wrote: post #59

Earlier quoted context omitted.

Help 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 s…

> email addresses are immutable 1. Use "admin@domain.com" 2. Let the domain registration lapse 3. Someone else registers the domain and now can't create an AWS account. Rare but not impossible.

Sure they can. Use any other email address at domain.com to register.

Re: Bucketsquatting is finally dead

#90

Post by otterley »

alemwjsl wrote: post #27

I take it advertising your account id isn't a security risk?

AWS 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...

Post reply on HN