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, since they're providing service to a defunct business entity who can't pay its bills?
To describe this as a vuln in oauth doesn't really make sense to me.
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 error that lead to a reprovisioning of the user, etc.
I also fail to see how the proposed solution of having a 'A unique user ID that doesn’t change over time' is different from the `sub` claim. However, the new ID associated to the domain could make sense to enforce a strong 'Everyone from the @domain.com has access' statement.
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 and that's what we use it for, but beyond that links will be saved, email addresses will be added to databases and address books alike, and that's more or less a reality of most systems. For example, my snail mail (and occasionally packages) is still mistakenly delivered to my former addresses from time to time just because it's hard to track who has that address, and update it everywhere. The same goes for internet infrastructure.
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 OAuth, or any OAuth at all.
Nearly a decade ago, there was a website called thehunt.com that basically ran out of money and some employees were acqui-hired by pinterest.
All of the assets were left to rot and at the time the company was a good match for another startup of mine. So I reached out to the investors I found on crunchbase and asked if I could acquire everything. We worked out a deal and I did. The issue was the complete lack of people from the old company willing to assist and the complete lack of data for alot of things. There was 1 or 2 people who we could ping from the old company to ping who were super helpful, but the big thing was many things were just lost to time- passwords, history, code repos, etc..
Simply creating a new google apps account allowed us to get full access back to everything - We could even read old slack messages (even DMs!) by resetting each accounts password. The whole thing was shocking to say the least, but with that access we got back into literally every service they used and managed to get it up and running again within a week, which was a good thing because nearly every service it was using was threatening to shut it down every day for lack of payment.
I think the solution here is actually way simpler than most make it out to be and could easily be a startup for someone:
Create a startup that lets customers simply enter in domains. If the domain EVER goes into the "pendingDelete" status, inform the customer. The customer would be random SAAS's that want to protect against this type of attack and could simply choose to disallow access to any account that has had their domain go into that status.
> 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.
In both, the details around the `sub` field, the field that should actually be used to identify the user, is poorly described. I would say that both of these feel a bit sensationalist, but then again, if relying parties are NOT using the sub field to validate users, they should be called out.
It seems to be that a good way to make some money is find every such situation where RPs are not using sub, and submit vuln bugs.
> According to a staff engineer at a major tech company:
> “The sub claim changes in about 0.04% of logins from Log in with Google.
I've had a staff SWE also claim to me that they generated colliding UUIDv4s, and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection.
Neither's attention to quality, or rather, lack thereof, could cash those outlandish claims.
There is a simple explanation here: Your staff SWE is wrong. `sub` is the claim you're looking for.
Extraordinary claims require at least a trifling of proof. Or, what can be asserted without evidence can also be dismissed without evidence.
And this alleges to be a security blog. As a writer with that target audience, you should know this is going to be the objection to the thesis that your reader will have, and you attempt to just handwave it away…?
Is this really an issue? Back when I implemented Google OAuth I used the "sub" that Google gave me as well as the email. I'd wager that Google does not re-use a sub for the same E-Mail so if the account is deleted and then somebody grabs the domain and re-created the account they'd have the same E-Mail but a different sub which would make the login fail. Seems to not be an issue in Google's OAuth Flow but rather the implementation on services like ChatGPT and so on?!
EDIT: Just read that they claim that “The sub claim changes in about 0.04% of logins from Log in with Google” - never had this happen in the past years but if this is true then I guess thats a bad thing.
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.
> They also classified the issue as a “Fraud and abuse” issue, rather than an Oauth/login issue.
I can _kinda_ see that, I agree they should mitigate it as best as possible too though, especially since they're Google after all.
> I thought this would be the end of the story, but 3 months later, they re-opened my ticket (after my Shmoocon talk was accepted), paid a $1337 bounty, and said they were working on a fix.
Sad how the only way to get Google's attention to make enough noise about something...
This actually happened to me a few years ago when I closed my consulting company. My bad, I know. My domain was taken over by someone in Vietnam. Back then, he was actually able to see my old emails via the Google Apps. Grandfathered free Apps accounts was a big part of the value proposition. He demanded $500 to delete my emails and docs. I offered $50 for his trouble since I recognized that I was at least partially at fault but he refused. To his bad luck, one of my main clients was Google itself. I reported him via my internal connections and the next day got the following email: "Oh my G-d, all forty of the domains I bought got Google Apps cancelled".
> “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`.
In iSCSI, there are a few options for addressing the block storage devices, with one being the iSCSI Qualified Name (IQN) that uses the domain name. But it includes a timestamp:
- A date code, in yyyy-mm format. This date MUST be a date
during which the naming authority owned the domain name used in
this format, and SHOULD be the first month in which the domain
name was owned by this naming authority at 00:01 GMT of the
first day of the month. This date code uses the Gregorian
calendar. All four digits in the year must be present. Both
digits of the month must be present, with January == "01" and
December == "12". The dash must be included.
Seems like we need a chain of custody for domains, not just current ownership. Kinda like real estate. And then accounts are tied not just to the ownership state, but also the ownership instance ID.
Just don't tell the web 3.0 folks cause I don't necessarily mean a blockchain.
This isn't anything new, or exclusive to Google, or exclusive to OAuth.
My workmate hadn't used Facebook for many years and it was associated to an email on a custom domain. Said domain expired and somehow hackers/script kiddies/bots must have an email list, run a whois, buy the domain if expired, setup email, and do password resets across social media and common websites. His Facebook was stolen.
I'm not sure I agree that it's a flaw in Google's OAuth implementation. Domain ownership is the source of truth for many systems and, as the article alludes to, expired domains can be abused in a variety of ways.
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
I fail to see how this is Google's problem and as much as it pains me to say this, I agree with Google.
I believe it is more the downstream providers fault for not terminating inactive accounts, and the failed startup's for not properly deleting their Google accounts.
Google can mitigate this as the author mentioned, but this is not their responsibility. They shouldn't be held liable because failed startups were stupid to not delete their data.
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.
It seems like there have been a number of security stories lately that essentially amount to. "no tech companies ever does cleanup" Which everyone on HN with a couple years or more experience should know is the norm. I expect a lot more of this to keep happening since companies will never really care about security without consequences ie a $10 fine for making $100 literally incentivies lack of security.
For the people not understanding the security risk, or how this would be something Google needs to solve, have a look at the claims of Microsoft Id token claims, and how their use of multiple guid claims completely eliminates this problem:
Assuming most of the problem is that federated services only rely on email address from OidC login, I wonder if Google could start offering user+unique-workspace-id@company.domain as the email address for any new workspace/user/federated login? Obviously, Google needs to control "unique-workspace-id".
Does not solve it for existing customers and any federated service they logged into, though if included alongside the simple email, federated services could gradually move to it and announce once they are "ready" so workspace admins can configure them to start accepting only new, safe email addresses.
Okay, this made me curious if there was a technical solution to this that people could be providing using the existing tools available, and I think there is.
RDAP and WHOIS will return the creation date of a domain. These fields are controlled by the registrar not the registrant. That creation/registration date gets reset when the domain is lapsed and picked up by somebody new.
So, when doing any domain-name-based authentication (like email password resets) authenticators should look up the registration date of the domain name. If it's newer than the last time the user logged in using the domain name auth? That might be somebody who snatched the domain name.
This feels similar in spirit to some service providers (*cough* Atlassian -- especially bad when they acquire other companies and push that bullshit on previously functional authentication systems) using ownership of a domain to assert ownership of an account using that domain.
E.g.:
1. You create an account using an email associated with a domain.
2. The domain owner coughs up their protection money to Atlassian and proves ownership of the domain.
3. Your password-protected account is assigned to the domain owner. Your password and 2FA invalid. The domain owner can access your private data without your password and 2FA.
Both TFA and the thing I described rely on broken, simplistic views of "domain ownership == account ownership".
It sounds like there’s a bug with the “sub” field. The author is stating that they can’t use it as a unique identifier for the user. Isn’t that the root of the problem?
A new domain owner could try to reuse email addresses, but since the domain is now in a new workspace the sub should be different and downstream services shouldn’t second guess that. Am I wrong about this?
I would be curious if any other Identity Providers that implement OAuth have mitigations for this issue. If you used sign in with Microsoft or Okta or PingFederate, would those provide different claims to the service?
If oauth makes an authenticity claim, it should be true. Saying it's the same user when it's not is bad, clearly.
in other words: Google could make a more accurate authenticity claim than they currently do.
This problem would be worse without oauth, though, right? With plain email login, all they would need to do is "forgot password" and there wouldn't even be a way to tell.
in other words: Email login would never be able to make a more accurate authenticity claim.
We take the OAuth2 token and make a call to the People API [0] to get the Person resourceName. Not sure if this is more stable than "sub" but we completely ignore that.
I don't think this has anything to do with Google's OAuth. This issue is literally with every single expired domain name out there. All one has to do is register the expired domain and look at all the emails sent to that domain.
Granted, Google "could" do something, but I don't think it's Google's responsibility to police expired domain names. What am I missing here?
I have worked with a few of these downstream providers to look for a solution. There is a documented unique user identifier (the sub claim) that could theoretically prevent this issue, but in practice, it's unreliable ... According to a staff engineer at a major tech company: “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.
The real solution is to use the sub claim, and not hd/email. If sub is unreliable, let's fix that. That said, I'm surprised sub is documented as unreliable here; I wonder if there is perhaps something else going on. I've done a lot of work with oauth and I haven't found sub to be so mutable, but then again, who knows maybe I just missed it?
And yeah, lapsed domains => domain takeover => email takeover and impersonation will always be a baseline problem, independent of oauth.
The email returned by OAuth providers is not always verified and thus cannot be trusted, anyone relies on the email as the ID is open to compromise. The sub claim should always be used as the ID, if you can prove that "the sub claim changes in about 0.04% of logins" then it's Google flaw and they should fix it, otherwise it isn't and there is no need to add another ID to the claim.
Well they have kind of known about this kind of problem for 14 years https://issuetracker.google.com/issues/35889152?pli=1
although this is not a domain issue it is one where people can't unlink from company project ownership.
Does anyone here know more about the unreliability of Google's sub claim? I am using it, and have never had issues with it, but this post seems to just dismiss it without more details.
When does Google change the subject of a token for a given user account?
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
How many recovery processes would depend on email. And it coming from right domain? Or changes in DNS. Or some other factor that domain holder could do. I don't think possible alternative scenarios would go down too well.
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?
If you think this is bad, wait until you move physical addresses and don’t notify all your creditors!
Literally ANYONE who moves into your old house will have access to your bank statements, credit card bills, tax forms, auto registration and who knows what else. And it will all come plaintext and unencrypted!
> 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.
Google’s OAuth login doesn’t protect against purchasing a failed startup domain
(trufflesecurity.com)497 points by simiones 14 January 2025 | 285 comments
Comments
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, since they're providing service to a defunct business entity who can't pay its bills?
To describe this as a vuln in oauth doesn't really make sense to me.
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 error that lead to a reprovisioning of the user, etc.
I also fail to see how the proposed solution of having a 'A unique user ID that doesn’t change over time' is different from the `sub` claim. However, the new ID associated to the domain could make sense to enforce a strong 'Everyone from the @domain.com has access' statement.
[1] https://developers.google.com/identity/gsi/web/reference/js-...
It's great for "do they own this right now" validation and that's what we use it for, but beyond that links will be saved, email addresses will be added to databases and address books alike, and that's more or less a reality of most systems. For example, my snail mail (and occasionally packages) is still mistakenly delivered to my former addresses from time to time just because it's hard to track who has that address, and update it everywhere. The same goes for internet infrastructure.
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 OAuth, or any OAuth at all.
Nothing in that write-up makes sense.
All of the assets were left to rot and at the time the company was a good match for another startup of mine. So I reached out to the investors I found on crunchbase and asked if I could acquire everything. We worked out a deal and I did. The issue was the complete lack of people from the old company willing to assist and the complete lack of data for alot of things. There was 1 or 2 people who we could ping from the old company to ping who were super helpful, but the big thing was many things were just lost to time- passwords, history, code repos, etc..
Simply creating a new google apps account allowed us to get full access back to everything - We could even read old slack messages (even DMs!) by resetting each accounts password. The whole thing was shocking to say the least, but with that access we got back into literally every service they used and managed to get it up and running again within a week, which was a good thing because nearly every service it was using was threatening to shut it down every day for lack of payment.
I think the solution here is actually way simpler than most make it out to be and could easily be a startup for someone:
Create a startup that lets customers simply enter in domains. If the domain EVER goes into the "pendingDelete" status, inform the customer. The customer would be random SAAS's that want to protect against this type of attack and could simply choose to disallow access to any account that has had their domain go into that status.
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.
In both, the details around the `sub` field, the field that should actually be used to identify the user, is poorly described. I would say that both of these feel a bit sensationalist, but then again, if relying parties are NOT using the sub field to validate users, they should be called out.
It seems to be that a good way to make some money is find every such situation where RPs are not using sub, and submit vuln bugs.
> “The sub claim changes in about 0.04% of logins from Log in with Google.
I've had a staff SWE also claim to me that they generated colliding UUIDv4s, and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection.
Neither's attention to quality, or rather, lack thereof, could cash those outlandish claims.
There is a simple explanation here: Your staff SWE is wrong. `sub` is the claim you're looking for.
Extraordinary claims require at least a trifling of proof. Or, what can be asserted without evidence can also be dismissed without evidence.
And this alleges to be a security blog. As a writer with that target audience, you should know this is going to be the objection to the thesis that your reader will have, and you attempt to just handwave it away…?
EDIT: Just read that they claim that “The sub claim changes in about 0.04% of logins from Log in with Google” - never had this happen in the past years but if this is true then I guess thats a bad thing.
I can _kinda_ see that, I agree they should mitigate it as best as possible too though, especially since they're Google after all.
> I thought this would be the end of the story, but 3 months later, they re-opened my ticket (after my Shmoocon talk was accepted), paid a $1337 bounty, and said they were working on a fix.
Sad how the only way to get Google's attention to make enough noise about something...
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`.
* https://en.wikipedia.org/wiki/ISCSI#Addressing
* https://datatracker.ietf.org/doc/html/rfc3721Clever idea to note change of ownership situations.
Just don't tell the web 3.0 folks cause I don't necessarily mean a blockchain.
My workmate hadn't used Facebook for many years and it was associated to an email on a custom domain. Said domain expired and somehow hackers/script kiddies/bots must have an email list, run a whois, buy the domain if expired, setup email, and do password resets across social media and common websites. His Facebook was stolen.
-- Probably someone else already mentioned this in the comments here, I just couldn't see.
I believe it is more the downstream providers fault for not terminating inactive accounts, and the failed startup's for not properly deleting their Google accounts.
Google can mitigate this as the author mentioned, but this is not their responsibility. They shouldn't be held liable because failed startups were stupid to not delete their data.
https://learn.microsoft.com/en-us/entra/identity-platform/id...
Does not solve it for existing customers and any federated service they logged into, though if included alongside the simple email, federated services could gradually move to it and announce once they are "ready" so workspace admins can configure them to start accepting only new, safe email addresses.
RDAP and WHOIS will return the creation date of a domain. These fields are controlled by the registrar not the registrant. That creation/registration date gets reset when the domain is lapsed and picked up by somebody new.
So, when doing any domain-name-based authentication (like email password resets) authenticators should look up the registration date of the domain name. If it's newer than the last time the user logged in using the domain name auth? That might be somebody who snatched the domain name.
E.g.:
1. You create an account using an email associated with a domain.
2. The domain owner coughs up their protection money to Atlassian and proves ownership of the domain.
3. Your password-protected account is assigned to the domain owner. Your password and 2FA invalid. The domain owner can access your private data without your password and 2FA.
Both TFA and the thing I described rely on broken, simplistic views of "domain ownership == account ownership".
A new domain owner could try to reuse email addresses, but since the domain is now in a new workspace the sub should be different and downstream services shouldn’t second guess that. Am I wrong about this?
in other words: Google could make a more accurate authenticity claim than they currently do.
This problem would be worse without oauth, though, right? With plain email login, all they would need to do is "forgot password" and there wouldn't even be a way to tell.
in other words: Email login would never be able to make a more accurate authenticity claim.
[0] https://developers.google.com/people/api/rest/v1/people/get
Granted, Google "could" do something, but I don't think it's Google's responsibility to police expired domain names. What am I missing here?
I have worked with a few of these downstream providers to look for a solution. There is a documented unique user identifier (the sub claim) that could theoretically prevent this issue, but in practice, it's unreliable ... According to a staff engineer at a major tech company: “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.
The real solution is to use the sub claim, and not hd/email. If sub is unreliable, let's fix that. That said, I'm surprised sub is documented as unreliable here; I wonder if there is perhaps something else going on. I've done a lot of work with oauth and I haven't found sub to be so mutable, but then again, who knows maybe I just missed it?
And yeah, lapsed domains => domain takeover => email takeover and impersonation will always be a baseline problem, independent of oauth.
> 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.
When does Google change the subject of a token for a given user account?
Literally ANYONE who moves into your old house will have access to your bank statements, credit card bills, tax forms, auto registration and who knows what else. And it will all come plaintext and unencrypted!
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.
anyway, if you use SSO on a domain and then let the domain drop, you're an idiot and there will be bad consequences for your data.
Same should apply to OAuth, you would think.