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

91–100 of 297 posts

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

#91

Post by horsawlarway »

placardloop wrote: post #51
stackghost wrote: post #45

Earlier quoted context omitted.

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

So you use email/pass and the reset password email dumps right to the new party as well, because they control the MX records for the domain?

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

#92

Post by mtkd »

rahkiin wrote: post #75
danudey wrote: post #59

Earlier quoted context omitted.

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…

Any domain takeover allows email takeover which allows you to send password reset emails for former employees. Does not matter if it is with oauth or not

And many vendors will send "restart your service today for $x" for months afterwards so data not deleted

Some SaaS ecommerce platforms and email marketing services will likely give a restarted domain entire customer databases ...

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

#93

Post by Ninn »

arnarbi wrote: post #89
danudey wrote: post #59

Earlier quoted context omitted.

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 are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people That is not quite true, the sub field will be different.

But authors does imply that sub will also change in place for users in step #1, without the workspace beeing recreated. And as such the sub is not usable as a general identifier for the user resource differentiation.

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

#94

Post by anon84873628 »

danudey wrote: post #59
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…

It seems there are two possible problems.

The first is whether taking over a lapsed domain allows you to takeover an existing Google Workspace (or Cloud Identity) organization. This it what houses the corporate email accounts and OAuth client registrations. If Google allows this scenario then the linked account takeover is simply one symptom / side effect among many. TFA is not clear on whether this step actually happened... I assume not, since if it were the case we'd be talking about direct access to the Google account data rather than only linked SP accounts.

The second is when an SP doesn't properly use the `sub` claim as a unique identifier. It sounds like some products don't understand this requirement and why it "seems to change 0.04%" of the time. I do agree that a unique identifier for the org itself would be a good addition to the token.

That said, I'm still not clear how the second problem manifests if the old OAuth client creds (housed in the old Workspace org id) are invalid. Presumably attacker can login to the SP admin account using just email based password recovery, then reconfigure the OAuth integration with new secrets. In that case the SP is failing to do MFA on the email login.

Would love to hear if I'm missing something.

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

#95

Post by LocalPCGuy »

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 scenario I was envisioning was a simple as a developer that worked at that startup added DankStartup email to their Github account, committed a bunch of code. Company shut down, but dev doesn't think to disassociate that domain/email. Malicious actor uses this technique to then sign into the Github account, gaining access to that developer's account, not just the DankStartup repos which were probably disabled after non-payment.

Now, obviously some fault in that scenario lay with the person who 1) used the same account, and 2) didn't remove the old email once the startup failed. But I'm just using that as a kind of example - there may be other accounts as others have said that need to be accessible years down the line, like financial records and the like, regardless of whether the company is still around.

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

#96

Post by stackghost »

danudey wrote: post #59
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…

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

Yep I understand the mechanism by which this gets abused; I think we just disagree on the implications. I don't work for Google but it seems from the outside that they're treating the OIDC subject claim as referencing the domain attached to the workspace account, or something similar. I've seen implementations where the `sub` claim is more granular, so to me that indicates the field is underspecified.

Given all that, I suppose TFAuthor's proposed solution is a good way forward.

I still think classifying this as an OAuth vulnerability isn't correct.

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

#97

Post by Pxtl »

andrewstuart2 wrote: post #13

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 disagree. DNS stores enough information in WHOIS to see if ownership has changed, it's not DNS' fault that nobody looks.

Probably the least-wrong thing to do with current DNS is to have authentication servers keep track of the WHOIS UpdatedDate of email domains. If a WHOIS UpdatedDate is newer than the corresponding user's linked email address verification, that user's email address is no longer trusted. Next time they log in ask them to update or re-confirm their email address, and if they try to password reset they can't use an unconfirmed email address.

Yes that's more tricky work. Authentication is hard. Nobody should be DIYing authentication anymore in this day and age, it's just too much.

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

#98

Post by adamc »

danudey wrote: post #65
stackghost wrote: post #45

Earlier quoted context omitted.

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

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?

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

#99

Post by anon84873628 »

Ninn wrote: post #93
arnarbi wrote: post #89

Earlier quoted context omitted.

> They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people That is not quite true, the sub field will be different.

But authors does imply that sub will also change in place for users in step #1, without the workspace beeing recreated. And as such the sub is not usable as a general identifier for the user resource differentiation.

The sub property appearing to change for the same email address is a valid scenario. SPs failing to respect that scenario because they don't understand it, or because it's not what some of their users want, is not a valid excuse.

https://support.google.com/a/answer/33314?hl=en&co=DASHER._F...

To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it. I believe other IdPs like Okta and Entra have equivalent features too.

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

#100

Post by niij »

Pxtl wrote: post #97
andrewstuart2 wrote: post #13

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 disagree. DNS stores enough information in WHOIS to see if ownership has changed, it's not DNS' fault that nobody looks. Probably the least-wrong thing to do with current DNS is to have authentication servers keep track of the WHOIS UpdatedDate of email domains. If a WHOIS UpdatedDate is newer than the corresponding user's linked email address verification, that user's email address is no longer trusted. Next time…

What does this protect against? If the WHOIS changes because someone new buys the domain then they could simply receive this reset emails, no?
Post reply on HN