Comment by ajross

Comment by ajross 4 days ago

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 owner of the domain to impersonate Sally in the context of that relationship.

Obviously the root cause here is that someone misused an account to do something not related to the business. And the actual impact is probably low since high value services tend strongly not to take tiny email domains as identity roots (i.e. sally@dankstartup.com clearly doesn't have a Vanguard account to steal).

So... like most security announcements it's oversold and spun. But it's real enough as I read it.

OkGoDoIt 4 days ago

Why do you assume sally@dankstartup.com doesn’t have a vanguard account? I’ve absolutely had similar retirement account logins that became difficult to access once I left that employer. Had to contact HR and get them to help me log into my account. If the company had folded during that timeframe I would’ve been screwed. Of course for financial institutions you can probably recover your account through some identity proving process, and generally money transfers require a second factor sms auth, but a domain takeover would probably have been sufficient to at least get someone logged in and able to see my account balance.

Reply View 1 reply

ajross 4 days ago

> I’ve absolutely had similar retirement account logins that became difficult to access once I left that employer.
Yes, but your employer's email domain wasn't repurposed. It's still an operating business, and the account is still there, and still yours. And for accounting reasons they still remember who you are and can recover your important information for creditors, etc... The fact that it's difficult for you to access that account is a feature and not a bug, because it means it's difficult for others too. But you can, and people do all the time.
The case here is failed businesses who have abandoned their domains and employee account history. Almost by definition that's a violation of financial regulation already. And this, btw, is the reason why DankStartup employees couldn't use their work emails to open Vanguard accounts.

Reply View | 0 replies

simiones 4 days ago

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

Reply View 2 replies

nijave 4 days ago

Even then (in my experience) it's pretty common to setup an email based account and it will auto link to an oauth one that already exists. Even if Google revoked oauth, many platforms let you use the email directly to login

Reply View | 1 reply
- ajross 4 days ago
  
  Yes, but that's not a bug with Google OAuth. If Taskrabbit (in the example) decides to trust dankstartup.com emails as a root of trust for identity even though the business failed, that's on them[1], and certainly nothing Google can have prevented.
  The contention in the article is that dankstartup.com's new owners can leverage their control of the domain to get access to existing OAuth-based sessions that will look to the service providers as if Google has authenticated the account holder.
  [1] And just to repeat: that risk is precisely why serious businesses (Vanguard in the example) don't allow obscure email domains as authentication anymore.
  
  Reply View | 0 replies

ensignavenger 4 days ago

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

Reply View 0 replies