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

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

trufflesecurity.com

Post reply on HN
Print view View original

51–60 of 297 posts

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

#51

Post by placardloop »

stackghost wrote: post #45
placardloop wrote: post #29

Earlier quoted context omitted.

> 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

>Expecting an entity that has already failed* to not fail again isn’t an effective security control, unfortunately. Sure, I'm sympathetic to that, but again I don't see how that's within the scope of oauth.

If a security mechanism doesn’t account for failure cases, it’s a failure of the security mechanism.

It’s a hard problem to solve and I don’t have a solution, but it’s a core goal of every security tool to account for edge cases and failure cases like this. If you tell me that OAuth is completely insecure due to a security issue, it’s not going to make me feel any better if you say “but it’s totally not OAuths fault” - I don’t care who’s fault or scope it is, the end result of a security issue is the same, and to avoid it I’m just not going to use OAuth.

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

#52

Post by loginatnine »

Timshel wrote: post #44
loginatnine wrote: post #40

I really don't understand here, the proper way to use Google's OpenID implementation to authenticate someone is to use the `sub` claim. Don't use the email, don't verify it yourself, use the `sub` claim. It's a known fact and is properly documented[1]. If the `sub` changes, it's because it's not necessarily the same person so have a flow ready for that. It could be an employee left and came back, a domain change, an…

It all depends on how true this statement is: > “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.

I've been working with an app that uses Google to login for the past 10 years, and I've had problems with sub changing when these situations happened : - Domain change - Company being bought by another one and being integrated in their Google Workspace - Employee leaving and coming back

To us, it's very very far from the quoted 0.04% which is to me very high. I had to deal with it 5-6 times in the past 10 years but of course that number will vary depending on the usage of your app and I'm not gonna venture and put a percentage on it.

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

#53

Post by riffic »

Google may have quickly closed the original report because a company like that is soooo overwhelmed with garbage security reports and at first glance it is noise, not an actionable item to fix. there's a term for this that I can't quite recall off the top of my head. Bug Bounty Trolling?

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

#55

Post by saguntum »

loginatnine wrote: post #40

I really don't understand here, the proper way to use Google's OpenID implementation to authenticate someone is to use the `sub` claim. Don't use the email, don't verify it yourself, use the `sub` claim. It's a known fact and is properly documented[1]. If the `sub` changes, it's because it's not necessarily the same person so have a flow ready for that. It could be an employee left and came back, a domain change, an…

Yeah, I'm not really clear on the vuln. It sounds like clients don't validate sub claims because they are unstable? Google's docs say they should.

When I first read the post, I thought that maybe Google was reusing sub claims when they shouldn't, but on a closer read, maybe it's the opposite problem - that the sub claim is changing when it should not change?

From the article -

“The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week ... Because the sub claim is inconsistent, it cannot be used to uniquely identify users - leaving services reliant on the email and hd claims."

So maybe clients aren't using the sub claim because validating "email matches && sub matches" breaks real users who are not actually changing accounts? AKA, Google is changing Google Account IDs unpredictably? That would be a bug on Google's part IMO.

If those account IDs in the sub claim are changing, at the very least that's a bug in the doc you linked IMO.

I'd have to read the full OIDC spec [0] to see if the sub must remain constant for the same end user, and if clients are required to validate the sub claim before processing a login. If so, and it's changing without the end user's identity changing, that is a bug in Google's implementation and client implementations for anyone using Google as an IDP.

If it's allowed to change, though, and validating sub claim is not required in the spec, maybe clients are correct in not relying on it.

[0] https://openid.net/specs/openid-connect-core-1_0.html#rfc.se...

Edit: from reading the sign in with google overview, it's unclear if they claim to be OIDC compliant: https://developers.google.com/identity/gsi/web/guides/overvi...

it says it's "based on OAuth" rather than "implements OAuth+OIDC" so I guess not being fully spec compliant wouldn't necessarily be a "bug."

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

#56

Post by robertlagrant »

hangonhn wrote: post #30
robertlagrant wrote: post #4

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

I agree there will some number of companies doing this, between 1 and $number_of_companies. I'm just saying it's pretty unlikely it's all candidate companies, which the article seems to be saying.

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

#57

Post by swframe2 »

Related maybe, I got a new phone number and I was able to use it to sign into the previous owner's account at a site that uses 2FA. I noticed it when I tried to setup a new account for myself. The website wouldn't allow it but it happily allowed to me access the previous owner's account. It was inconsistent, removing the phone from their account required their password but changing many other important fields didn't.

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

#58

Post by ensignavenger »

ajross wrote: post #10
stackghost wrote: post #7

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…

That sounds like a TaskRabbit vulnerability (in your example), not a Google vuln? It is also a vulnerability in any email based sign in, which relies on email alone without a password to demonstrate account ownership. (Including password resets that rely on email).

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

#59

Post by danudey »

stackghost wrote: post #7

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

Well, think about it this way:

1. I create DankStartup and my company uses Google workspaces and Google auth for a bunch of stuff, like payroll.

2. DankStartup goes under and we close our Google accounts/let our domain lapse.

3. Someone else buys DankStartup.com, sets up a Google workspace, and attempts Google auth to log into stuff, and it works.

The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y".

Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are therefore the same people as far as they're concerned and is asserting that to other companies. They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people, so those other companies aren't even capable of doing their due diligence of extra validation if they want to.

It's similar to looking at a driver's license and just matching the name rather than the actual ID number; it's possible for someone else to have the same name as you, and identity documents have unique identifiers for specifically that reason.

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

#60

Post by banger180 »

caleblloyd wrote: post #38
banger180 wrote: post #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…

I agree, in my limited experience the sub remains consistent even when changing the Google Workspace domain. So the email changes but sub remains the same. The issue seems to be clients matching on email/hd claim instead. I wonder what action is causing the sub to change like the author suggests is happening.

> I wonder what action is causing the sub to change like the author suggests is happening.

Indeed this would be very interesting.

This issue is also very similar to CVE-2024-25618.

What we did to mitigate this is the following: - Federated login with OIDC - Look for a user based on the sub claim - If they are found: authenticate that user and optionally update their profile (email, name, ...) based on then new id claims. - Else look for a user matching on the `email` claim and link the `sub` to that user - If no user is found create a new one

Post reply on HN