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

161–170 of 297 posts

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

#161

Post by danudey »

adamc wrote: post #98
danudey wrote: post #65

Earlier quoted context omitted.

I register a Google Workspace and add CorpDomain.com to it. I then use that to OAuth to other companies (e.g. Slack, payroll companies, etc.). Then my company goes under or closes up and the domain lapses. Someone else comes along, registers a completely different Google Workspace but attaches that same domain to it. The e-mail address is the same, but it's obviously a new Google Workspace with new people, new paymen…

Seems like relying on domain alone is a design flaw of OAuth?

OAuth allows you to provide information above and beyond just the domain, and the article describes examples of how this could be done. This is just a flaw in how Google presents an identity to OAuth clients.

In other words, right now it's basically "user@domain", but it could be ("user@domain", "unique workspace ID") which would prevent these sorts of attacks as well as make logical sense.

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

#162

Post by jorams »

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

0.04% is a few times higher than I'd expect it to be, but if it were actually that bad I'd expect some form of previous report about it to be findable on the internet. I did some searching but couldn't find anything. It would be a significant bug on Google's part, but stranger things have happened.

What's astonishing to me is that apparently all these big service providers did notice, and then they decided to disregard the one identifier Google tells them to use? Fundamentally that's the security bug being reported here, it's just being reported to Google instead of those service providers.

A stable alternative for the hd claim would of course be a good idea. It would provide a more complete way to deal with the inherent security issue of allowing domain-based signup without further authorization steps. But given the above I'm not convinced these service providers wouldn't start ignoring it after the first time somebody re-registers a domain with Google Workspace.

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

#163

Post by nodamage »

radlad wrote: post #155
nodamage wrote: post #143

Earlier quoted context omitted.

Yes. If you've set up your Slack so each login checks against the identity provider to ensure an active user is logging in, that would resolve the issue, no? Even if you take over company.com's domain you can't reconfigure company.com's Slack to point to a new identity provider?

I think you may be a bit confused about the players here. When you use Google OAuth to login, it _is_ your identity provider, and it is reporting to Slack that the user exists. Google is reporting the user exists because it exists in the Google Workspace directory. You use this as your source of truth for provisioning users, and they automatically get access to all of your company's apps. The problem is that even tho…

What I'm suggesting is if you were able to pre-configure Slack to only allow logins for valid users from Google Workspace X, then even if someone creates a new workspace Y with the same domain, Slack would still be checking against workspace X. (And similar for non-Google based identity providers.)

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

#164

Post by chis »

paxys wrote: post #113

It's crazy just how little effort it takes to get a "Google = bad" article to the top of HN. There is no vulnerability in Google OAuth. This is exactly how every OAuth server is supposed to work. If you take over a domain, you automatically own every email address in that domain, and thus whatever external account relies on that email for login. Heck the result would be the same even if that service didn't use Google…

Is this really just google=bad, though? I work at a startup and this seems like a legit security risk that I'm happy to learn about.

It seems like the only mitigation would be to let your HR SAAS know when your company shutters and ask them to delete the records. Or just squat the domain yourself as an ex-employee.

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

#165

Post by DrillShopper »

cortesoft wrote: post #146
patmcc wrote: post #125

Earlier quoted context omitted.

>>>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". Google is telling other sites that it's bob@DankStartup.com - isn't that true? Isn't this on DankStartup to close down operations cleanly?

Sure, but DankStartup failed and doesn’t exist anymore. If I am just a lowly employee, I can’t force the failed startup owners to properly shutdown, and now my payroll information is available to hackers. What is my remedy?

In a rational world the remedy would be to sue Google for exposing your payroll information.

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

#166

Post by commterch1 »

This is a stupid article. 1. It starts with “Millions of Americans”. How does this relate in any way to Americans? 2. Gmail is not the problem 3. Consider registering a domain for 10 years. When the startup fails, delete all dns entries

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

#167

Post by zahlman »

One of the unintended side effects of Noscript is this sort of unintended hilarity:

> These claims usually include:

> hd (hosted domain): Specifies the domain, e.g., example.com.

> email: The user's email address, e.g., [email protected].

The placeholder, hypothetical email address is being "protected" from web scraping.

In the context of an article on a security website about identities being spoofed through email accounts.

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

#168

Post by commterch1 »

This is a stupid article. 1. It starts with “Millions of Americans”. How does this relate in any way to Americans? 2. Gmail is not the problem 3. Mitigation: Consider registering a domain for 10 years. When the startup fails, delete all dns entries

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

#169

Post by danudey »

horsawlarway wrote: post #90
danudey wrote: post #65

Earlier quoted context omitted.

I register a Google Workspace and add CorpDomain.com to it. I then use that to OAuth to other companies (e.g. Slack, payroll companies, etc.). Then my company goes under or closes up and the domain lapses. Someone else comes along, registers a completely different Google Workspace but attaches that same domain to it. The e-mail address is the same, but it's obviously a new Google Workspace with new people, new paymen…

I'm not entirely clear on what you expect in this case? You're registering with those 3rd parties using a property (the email address under corpdomain.com) that is now owned by the new party. This feels a lot like complaining that you hired a lawn service and told them to mow at your address, and then didn't update the address or cancel service after you moved. You've sold the domain. Assets associated with the domai…

The other reply to this comment kind of nailed it, but in short:

Right now Google, via OAuth, attests that someone's identity is "user@domain" as a unique global key, even if they know that that user@domain is controlled by a new Google workspace (i.e. it is not the same people/organization/legal entity).

All Google has to do is attest that someone's identity is ("user@domain", "unique workspace ID") as a unique global key and all of this will go away.

> This feels a lot like complaining that you hired a lawn service and told them to mow at your address, and then didn't update the address or cancel service after you moved.

I think it's more like hiring a lawn service through a third party, and then, after you move, a second person moves into your house and calls the lawn service asking for a copy of all of the credit card receipts from your payments and they give it to the person because the third party assures them it's the same person, even though it's not, just because the address is the same.

> Email resets will also dump right into their hands (They control the MX records for corpdomain.com now...).

Well yes, and people shouldn't use e-mail/password authentication for that and many other reasons (unless 2FA is involved).

The difference is that, in this case, we are outsourcing authentication to Google under the assumption that Google will handle authentication better than just a username/password combination; I'm relying on Google to say "yes, this is who that person claims to be and we have verified that". The problem is that Google knows that they is not who they claim to be, that they just have the same e-mail address but a different workspace, but they're still telling the other site that yep, it's him for sure, absolutely, and the other site has no way of validating that any of that is true so they have to go with it.

> Legally speaking, it's not even clear you're right - the new person might well be the person actually entitled and expressly supposed to be accessing that service as that account (if the domain was sold as part of an acquisition or sale).

Potentially yes, but if that were the case then they would have transferred ownership/control of the workspace itself, including all of the accounts, email, google drive data, and so on, and not deleted the entire workspace and created a new one from scratch. In a case where they did want to do that (e.g. to migrate off of Google workspaces or consolidate) that seems like something they should do via customer support to ensure continuity.

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

#170

Post by tart-lemonade »

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

My father changed careers and dissolved his business over a decade ago, at which point he let his old domain lapse.

A couple years ago, I began to wonder if anyone was still trying to reach him, so I bought the domain (domain squatters weren't even interested in it anymore) and setup an inbox for his old email address. In less than a week, the unread count was in the triple digits. It was basically all marketing and spam so I closed the inbox within the month, but multiple years with a 100% bounce rate is apparently not enough to deter LexisNexis & friends from trying to win him back.

This is a corporate planning/governance problem, not a vulnerability in Oauth, and I bet the problem is even bigger than TFA describes since any previous domains of a company that were almost-but-not-completely migrated away from could easily be taken advantage of, possibly to even greater effect since the company likely has a bunch of systems still up which have the domains whitelisted. (Which makes me wonder if there are hacking groups who use domain squatting as a front or side-gig while they take advantage of lapsed corporate domains.)

Post reply on HN