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

151–160 of 187 posts

Re: Bucketsquatting is finally dead

#151

Post by somat »

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 requirement for unique user names is a little strange, I was putting together a small internal tool recently and after a bit of thought decided to use an opaque internal id for users and let the users pick and change their name and secret at will.

I think for a larger public service it would make sense to expose some sort of internal id(or hash of it. What bob am I talking to?. but people share the same name all the time it is strange that we can't in our online communities.

Re: Bucketsquatting is finally dead

#153

Post by coredog64 »

shermantanktop wrote: post #112
Twirrim wrote: post #81

Earlier quoted context omitted.

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…

V1 never dies. You support it forever, including for customers who desperately want v2-only features but would rather escalate than migrate.

Laughs in CodeCommit and S3 Select

Re: Bucketsquatting is finally dead

#154

Post by coredog64 »

ClaudeFixer wrote: post #47

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

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

Re: Bucketsquatting is finally dead

#155

Post by gamblor956 »

dixie_land wrote: post #128
a2tech wrote: post #94

Earlier quoted context omitted.

AWS support seems to be struggling. I just came to help a new customer who had a rough severance with their previous key engineer. The root account password was documented, but the MFA went to his phone. We've tried talking to everyone we can, opening tickets, chats, trying to talk to their assigned account rep, etc, no one can remove the MFA. So right now luckily they have other admin accounts, but we straight up ca…

I named random Joe as the sole owner of "my" bank account and the bank wouldn't allow me to access "my" money!

Banks have established processes for changing signatories on business bank accounts, including in situations where a past signatory is no longer with the business.

In a nutshell: if a past signatory was a regular employee, it just takes any other signatory to remove them. If there was no other signatory, or if the past signatory was an officer, it takes a current officer (as set forth in the company's AOI or corporate minutes). Usually only the latter 2 situations of the 3 above require an in-person visit to the local branch office, and that only requires a few minutes.

Re: Bucketsquatting is finally dead

#156

Post by themafia »

noahmasur wrote: post #60
etothet wrote: post #55

Speaking 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.…

You can always use plus-addressing if your email provider supports that. AWS considers plus-addressed root emails to be unique.

I create "job function" DLs. "Company-Region-IT Manager". Then give that DL it's own SMTP address. Then use that.

It's really nice when you have to hire someone new for the position. You add them to the DL and they're automatically in control of all those accounts.

I have no idea why more companies don't do this.

Re: Bucketsquatting is finally dead

#157

Post by wrs »

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

Re: Bucketsquatting is finally dead

#158

Post by ethanrutherford »

lcnPylGDnU4H9OF wrote: post #83
xxs wrote: post #44

Earlier quoted context omitted.

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, b…

The "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.

Re: Bucketsquatting is finally dead

#159

Post by CloakHQ »

ethanrutherford wrote: post #158
lcnPylGDnU4H9OF wrote: post #83

Earlier quoted context omitted.

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, b…

The "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 li…

[dead]
Post reply on HN