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

111–120 of 187 posts

Re: Bucketsquatting is finally dead

#111

Post by etothet »

naasking wrote: post #78
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…

> 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. If they aren't actually deleting the account in the background and so no longer have a record of that e-mail address, then they must allow re-activation of the account tied to that e-mail address using the sign…

And in this case, it’s actually less secure for this one user and the account if as a workaround I’m required to create an IAM user for them (even though I can limit their use of the system).

Re: Bucketsquatting is finally dead

#112

Post by shermantanktop »

Twirrim wrote: post #81
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…

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

Re: Bucketsquatting is finally dead

#114

Post by zikduruqe »

NetMageSCW wrote: post #107
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…

What happens when someone loses their phone?

You print the MFA QR code, and give it to an executive that locks it up in a safe or offsite storage.

In a past life, we printed the MFA QR code and the head of finance put it into a safe.

Re: Bucketsquatting is finally dead

#115

Post by etothet »

mixdup wrote: post #91
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…

>Help me understand why you would delete your AWS account if the company and email address are unchanged - I can’t see the motivation. Have you ever worked in a company of any size or complexity before? 1. Multiple accounts at the same company, spun up by different teams (either different departments, regions, operating divisions, or whatever) and eventually they want to consolidate 2. Acquisitions: Company A buys Co…

In our case, this is exactly what happened. An acquisition of a company where their AWS accounts that were inherited were no longer needed.

Re: Bucketsquatting is finally dead

#118

Post by NetMageSCW »

brnt wrote: post #87
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.

I didn’t think it was possible to have a personal TLD - did you mean a personal domain?

Re: Bucketsquatting is finally dead

#119

Post by 8organicbits »

embedding-shape wrote: post #93
8organicbits wrote: post #85

Earlier quoted context omitted.

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

> collected from recursive DNS servers around the world Yes, of course, because those DNS servers are literally receiving the queries, eg "receiving the data". Again, there is nothing "leaking" here, that's like saying you leak what HTTP path you're requesting to a server, when you're sending a HTTP request to that server. Of course, that's how the protocol works!

I think you are hung up on the word "leak".

Putting a secret subdomain in a DNS query shares it with the recursive resolver, who's privacy policy may permit them to share it with others. This is a common practice and attackers have access to the aggregated datasets. You are correct that third-party web servers or CDN could share your HTTP path, but I am not aware of any examples and most privacy policies should prohibit them from doing so. If your web server provider or CDN do this, change providers. DNS recursive resolvers are chosen client side, so you can't always choose which one handles the query. Even privacy-focused DNS recursive resolvers share anonymized query data. They remove the source IP address, since it's PII, but still "leak" the secret subdomain.

Any time you send secret data such that it travels to an attacker visible dataset it is vulnerable to attack. I call that a leak but we can use a different term.

Re: Bucketsquatting is finally dead

#120

Post by UltraSane »

a2tech wrote: post #94
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.…

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…

This is why you never use personal phones for MFA to critical accounts.
Post reply on HN