Live data from Hacker News

Google’s OAuth login doesn’t protect against purchasing a failed startup domain

trufflesecurity.com

21–30 of 297 posts

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#21
> To resolve this issue, Google could implement two immutable identifiers within > its OpenID Connect (OIDC) claims: > 1. A unique user ID that doesn’t change over time. > 2. A unique workspace ID tied to the domain.

1. is the OIDC `sub` claim! I strongly suspect that in those 0.04% of accounts where the anonymous quoted engineer reports that the `sub` claim changed, what actually happened was some provisioning/onboarding/offboarding system resulted in the account being deleted and recreated.

2. is sensible, and is just a versioned version of the `hd` claim.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#22
post #9

> Shmoocon talk accepted - Dec 9, 2024, Google re-opens issue - Dec 19, 2024 Wondering what the internal process there was at Google? Is someone's job to cruise around the various conferences and dev events to look for any Google mentions and report back. Did Google really consider it an issue or just wanted it avoid looking bad in public after the talk was accepted.

> Is someone's job to cruise around the various conferences and dev events to look for any Google mentions and report back.

Someone in Google's security team likely saw the talk, or the original blog post, and pushed internally for them to award something.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#23
post #10

It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…

The contention isn't that you can impersonate DankStartup, that's obviously not a vulnerability since you are indeed the domain owner. It's that former entities with DankStartup accounts might have used OAuth to create relationships of their own. And when the startup folds, they don't magically disappear. Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the own…

> Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship.

I don't think this is the issue, unless someone went to some pretty extreme lengths. Configuring OAuth such that the company Google Workspaces account is recognized by Taskrabbit as a valid SSO option is not as simple as signing up to Taskrabbit with your company email instead of personal email.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#24

This is more of a fundamental issue with the way we rely on DNS to secure *gestures wildly* all the things. The fact that domains can expire and be registered by someone new allows the new owner to do almost anything the old owner could have done when it comes to anything trusting email addresses, or anything else relying on DNS (ACME certs) for authentication. It's great for "do they own this right now" validation a…

I was able to take over an Instagram account because I received a password reset email to a domain catch all address that I'd set up years ago. Turns out it was a whole brand, but they refuse to change the email address and don't understand that I'm going to shut it all down. It totally makes my site look bad (it was an adultish brand and I was working on a community project) and I now have the power (and ability to do whatever with the account and any other that I happen upon with an email at that domain.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#25
> “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.

What I don't understand is why the `sub` claim is not consistent for those users at Google. To my understanding of the OIDC protocol the `sub` should be unique for a specific user.

Additionally as far as I understand if you take over a defunct domain and create a new google workspace with new users those new user account should get assigned a new `sub`.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#26
post #9

> Shmoocon talk accepted - Dec 9, 2024, Google re-opens issue - Dec 19, 2024 Wondering what the internal process there was at Google? Is someone's job to cruise around the various conferences and dev events to look for any Google mentions and report back. Did Google really consider it an issue or just wanted it avoid looking bad in public after the talk was accepted.

> Is someone's job to cruise around the various conferences and dev events to look for any Google mentions and report back. Someone in Google's security team likely saw the talk, or the original blog post, and pushed internally for them to award something .

Yea. The leet amount of payout seems like this was someone saying that the classification was technically correct, but it's worth fixing either way and it'd be nice to pay an amount.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#27

It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…

Yes, it's a failure on DankStartup's part.

Not really much different than a user buying dankstartup.net, setting up a catch-all email, observing what comes in, and performing password resets for those accounts, allowing for account takeovers.

Calling it a vuln in oauth may be a bit hyperbolic, but Google could help prevent it.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#28

This is more of a fundamental issue with the way we rely on DNS to secure *gestures wildly* all the things. The fact that domains can expire and be registered by someone new allows the new owner to do almost anything the old owner could have done when it comes to anything trusting email addresses, or anything else relying on DNS (ACME certs) for authentication. It's great for "do they own this right now" validation a…

At least it counts as a new category on the "It's DNS fault" list.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#29

It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…

> Suppose DankStartup folds … Isn't that a failure on DankStartup's part, to not shut down their business accounts?

Expecting an entity that has already failed* to not fail again isn’t an effective security control, unfortunately.

* - not every startup that folds has “failed”, but the point still stands

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#30

The "millions of accounts" is highly speculative, is it not? It relies on the idea that failed startups keep their SAAS accounts enabled, rather than offboarding correctly.

You would think that because you're a reasonable person. However at my previous startup, which no longer exists, the new CEO failed to save the company and parachuted out so fast that the company who later acquired the startup couldn't get the domain name transferred to them because the CEO and CTO were both gone. They had to bring back the predecessor CEO because he was still able to log into the registrar to transfer the domain.

In the case of a fire, some less than conscientious people will fend for themselves first and don't give a second thought to anyone else.

Post reply on HN