25 ms·

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 danksta

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.

ajross 2y 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.
- simiones 2y 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.
  - nijave 2y 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
    - ajross 2y 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.
- OkGoDoIt 2y 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.
  - ajross 2y 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.
- ensignavenger 2y 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).
simiones 2y ago
Yes, why the Slack or HR or interview etc. data would still exist while being inaccessible to the original owner is very strange. The article seems to take it as a foregone conclusion that those accounts should all be expected to still exist with all the business data, and I don't know if this is based on the author's experience, or it's just a way to make the vuln sound far more serious than it really is. On the other hand, I don't think people normally expect that OAuth depends strictly on domain ownership like this. I think most would expect that it depends on some kind of secret being stored on the IdP account side, uniquely identifying the IdP account holder beyond the email addresses presented. With regular password-based authentication, with MFA, you would at least get an MFA prompt if someone had gotten access to your email address and was being sent a password reset code. But with this type of SSO, any MFA verification is done on the IdP side, so if the IdP recognizes anyone who controls example.com as the rightful owner of any claims, then there is nothing you can do as the former owner of example.com.
- OtherShrezzing 2y ago
  >why the Slack or HR or interview etc. data would still exist while being inaccessible to the original owner is very strange Ever been in a company that's collapsed before? Nobody hangs around to shut down the WorkDay account when they've been told they're not getting paid for the last 29 days work.
  - simiones 2y ago
    I get that part, but I'm not sure why they would expire even later than the domain registration and the Google Workspace account. I would expect WorkDay or whoever to close/archive a non-paying account much earlier than that.
cosmotic 2y ago
Third parties is google as single sign on. If such an org/domain is abandoned, a malicious person could 'resurrect' the accounts on those third party sites. It's kind of like a similar situation where a user deletes an email account and then someone else creates an new one in its place, and now they have access to all the third party password reset links. Except in the case linked above, the user never had the ability to delete their accounts before off boarding, and the abstraction isn't just an email, but the account itself.
- deleted 2y ago
  [deleted]
- reginald78 2y ago
  In emails case all the larger providers I'm aware of retire addresses to prevent this sort of abuse, probably learned the hard way. Could Google OAuth do something similar here? It now occurs to me that large businesses might have the same issue with emails and former employees (easy to imagine John Smith departing and at a later date John Smith being hired) so I wonder how they typically handle this.
  - scarface_74 2y ago
    Companies generally don’t reuse emails. If you come back, you can sometimes get your old email and access to your old enabled services. I know when interns were at Amazon and left, their accounts were disabled. But when they came back, they got their old accounts back and the related Slack users
chasemiller 2y ago
Yes, it's a failure on DankStartup's part. Not really much different than a user buying dankstartup.net, setting up a catch-all email, observing what comes in, and performing password resets for those accounts, allowing for account takeovers. Calling it a vuln in oauth may be a bit hyperbolic, but Google could help prevent it.
- OkGoDoIt 2y ago
  I have catchall email accounts in every domain name I own (mostly so I can do differentiated emails for every service to track/combat leakage), and you would not believe the amount of emails I get that are intended for previous domain owners (and typos too). I haven’t actually done any reset password flows, but there are a bunch of social media and SaaS accounts I could easily take over if I wanted. I used to try to track down whoever the emails were intended to go to and forward it to them and let them know to change it, but that got to be too tedious so nowadays I just ignore them. Still, I wouldn’t call this a vulnerability on the service provider’s part, it’s just user negligence.
placardloop 2y ago
> 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
- stackghost 2y ago
  >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.
  - placardloop 2y ago
    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.
    - horsawlarway 2y ago
      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?
      - lxgr 2y ago
        That's why allowing account recovery using (exclusively) email is indeed a security problem.
  - danudey 2y ago
    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 payment info, new users, etc. Google knows that these are two different workspaces and that there is effectively no connection between the two other than the domain, but they are not presenting that information through OAuth (which is possible) so other companies are not able to do any sort of diligence in ensuring that the correct people are accessing that data. OAuth provides the capability to make this distinction, but Google is (or was?) refusing to provide data to other companies to allow them to make that distinction. This sounds hyperbolic, but Google is effectively lying to these other services that that someone else is in fact the original person that service expects, even though Google knows full well (or is capable of knowing) that that is almost definitely not the case.
YetAnotherNick 2y ago
And not only that, almost every form of auth has the same vulnerability not just log in with Google. If you own the domain, you own the email IDs as well and you can very likely reset password.
- horsawlarway 2y ago
  Yeah, this is the part I'm struggling with. This is absolutely not unique to google oauth, it genuinely seems like a misunderstanding of how the web manages trust. If you own the domain, you own all the property associated with the domain, including all the old email addresses. Magic links and password resets are all going to give the new owner access. Your best bet as a solution is to be using strict 2fa (ex - a yubikey might help here) but even that is likely just "a conversation with support" away from being circumvented. This is why winding down a company is supposed to have specific stages and policies associated with the dissolution. You don't just abandon the offices and leave all the filing cabinets behind either, for similar reasons...
  - lxgr 2y ago
    > Magic links and password resets are all going to give the new owner access. Which is why you should never exclusively rely on either for sensitive services.
    - YetAnotherNick 2y ago
      It's better than SMS based password recovery or "call support to reset your password". What do you suggest is the best approach.
  - brookst 2y ago
    I don't think the claim is that Google has introduced a totally novel vuln, just that they are a stable, trusted middleman who is failing to mitigate a common vuln where they can. You don't abandon filing cabinets, but given that some percentage of startup failures are sudden and surprising and the people who could do something are unmotivated / unable to, it's not a best practice for a commercial landlord to put abandoned files on the street with a sign "free", files and all. Maybe they have a legal right to, but it's not how I would operate in that situation.
danudey 2y ago
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.
- PKop 2y ago
  Yes but he's saying the data on 3rd-party websites should be deleted by the failed startup when they shutdown not just left to sit there.
  - PeterFBell 2y ago
    He's right, but having failed a number of times, after you've put all your savings into the business, fired all your team, notified and disappointed all of your investors and customers, helped your team find new gigs, filed all the dissolution paperwork, handled all the taxes, disposed responsibly of all of the assets and you now find yourself out of work and often out of cash, occasionally you'll forget to jump through all the hoops to close down all of the SaaS accounts before you stop paying the bill personally to host the email accounts. Of course perfect world you shut down earlier and in a more orderly fashion, but there are so many cases of companies almost failing and then not, it's hard to shutter a company when there is a chance you may go out of business - especially when you feel you're getting close to another raise or becoming default alive :(
VILINBR 2y ago
whats is TFA ?
- deleted 2y ago
  [deleted]
- danudey 2y ago
  "The f___ing article"
  - VILINBR 2y ago
    thanks
  - codetrotter 2y ago
    In polite terms it can also mean “the featured article”. And IMO it makes more sense to read it that way in a top-level comment. Whereas reading it as the f’ing article makes more sense when the word “TFA” is used in a response to another comment like “well, you say that but TFA said such and such”.
    - freedomben 2y ago
      Agreed. I've also seen "The Fine Article"
      - pimlottc 2y ago
        This is the old school “polite” version, as in, “read the fine manual”
- 0xffff2 2y ago
  "The F-ing article" (derived from old internet slang "RTFM", for "Read the F-ing manual", a thing that new users were prone not to do before getting online and asking questions easily answered by RTFM.)
  - 2y ago
riffic 2y ago
it's vital to have extremely skilled and nuanced people managing bug and security report triage because it seems many can overlook the complexities being given.
LocalPCGuy 2y ago
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.
stonemetal12 2y ago
What if DankStartup doesn't fold and just forgot to renew their domain, or lost control of their domain for some reason. OAuth shouldn't let you Auth someone else's account just because you can hijack their domain.
redleader55 2y ago
Besides the github account with a legitimate name, but impostor ownership, I can imagine another case which is problematic. HR SaaS companies might be required by law to maintain the account for a period of time - let's say until the end of the next fiscal year. The account still existing is not a failure on either Google, the SaaS company or DankStartup. The problem, as other posters mentioned is the fact the new account has the same ID in OIDC as the previous one, which is what the author of TFA proposes.
hk1337 2y ago
I don't think it would be 100% on the failed startup considering most of, if not all, of the applications mentioned likely do not actually delete accounts even when you say to delete them. There probably could be some allowance made for the situation but also you're repurposing the domain of a failed startup. I don't think the problem was necessarily with Google though as I believe they create a unique ID for the domain. The problem with be with the other services like ChatGPT, Slack, etc that associate with the domain and create accounts for each user in the domain.
nodamage 2y ago
I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee. If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@company.com was a valid user that should be allowed to login, then this problem would be avoided entirely because the defunct company would no longer report any valid users. This would also avoid further problems with attackers being able to login with unattended email addresses like support@company.com, as was discussed here: https://news.ycombinator.com/item?id=41818459 https://news.ycombinator.com/item?id=41818459 (There's a lot of discussion below about whether the "sub" claim is stable or not but it's a red herring because of this IMO, also the proposed fix in the article wouldn't address it either.)
- radlad 2y ago
  This is a misunderstanding of the problem. See my comment downthread: https://news.ycombinator.com/item?id=42701912 https://news.ycombinator.com/item?id=42701912 "hd" is Google's solution to this problem, and "hd" is also the source of this vulnerability.
  - nodamage 2y ago
    I don't think so, but please go ahead and clarify if that is the case.
    - radlad 2y ago
      Maybe you can clarify what part of the linked comment didn't make sense? It's a bit hard to make out where the confusion is if the above comment didn't help clarify.
      - deleted 2y ago
        [deleted]
      - 2y ago
p_ing 2y ago
> DankStartup's O365, If you wanted to try to re-take over a pre-registered domain in Azure/M365, you would need to involve Microsoft Support who would require you to prove via government documentation that you were the same entity for the now-abandoned Azure/M365 account. Creating a new tenant using the same public domain won't get you access to the Azure/M365 tenant of a previous customer, you would have a different internal domain name (dankstartup2.onmicrosoft.com). At best you could register your domain post-expiration of the previous tenant and impersonate them >90 days out.
tart-lemonade 2y ago
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.)
- tsimionescu 2y ago
  This is very much a critical flaw in systems which rely entirely on email or domain names as the sole security factor. OAuth itself is flawed in that it allows this terrible practice, though to be fair it does discourage it. Google's specific OAuth solution encourages this compromised practice even more, because the only identifier it provides for a user group is the domain name associated with the account (in the "hd" field). For individual users they at least provide a "sub" field with a unique user ID (though per the article, it seems this is possibly flaky, or at least misunderstood) - this could be used to make sure that a new user@example.com doesn't get access to the old user@example.com account. But to check if a new user should have access to the organization account, there is nothing that Google provides that can be used securely: all they tell the service provider is that this is a new valid user for the example.com org, not that this is a completely different example.com org.
  - tart-lemonade 2y ago
    That's a really good point. Perhaps the protocol should be expanded with an explicit identifier unique to an extant legal entity (or string of identifiers, to account for ownership changes like acquisitions), so it would be easy for SSO-enabled applications to keep previous tenants' data safe from someone who just buys the domain later on. Of course, this would still rely on the provider: it might be a great solution for large providers like Google which can implement ironclad formal verification procedures, but if you and the previous company self-hosted SSO, you control the response and can impersonate them completely.
Rebelgecko 2y ago
Is this basically equivalent to registering a domain, setting up email, and getting services to send you password reset emails to recycled addresses?
deepsun 2y ago
> a failure on DankStartup's part, to not shut down their business accounts They seized operations, why should they be responsible for any other assets? I mean ethically yes of course. But there's no law/obligations to make sure domains are closed.
sowbug 2y ago
It's similar to Gmail or Hotmail or Yahoo Mail hypothetically allowing a new user to adopt an abandoned email address. Most email services don't allow this for this very reason.
deleted 2y ago
[deleted]
egberts1 2y ago
It is an "ACL vulnerability ". ACL as in access control list. Bell-LaPalda and multi-level access control systems both required a trusted controller and, And, AND a trusted arbiter of a state machine. It is the state machine that magically got expanded into a couple more states, with the introduction of an imposter admin actor. So yeah, the trusted arbiter and owner of that state machine (Google) did an oops. This is something that Keberos (KRB5) was designed to protect against.

ajross 2y 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.

simiones 2y 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.
- nijave 2y 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
  - ajross 2y 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.
OkGoDoIt 2y 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.
- ajross 2y 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.
ensignavenger 2y 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).

simiones 2y ago

Yes, why the Slack or HR or interview etc. data would still exist while being inaccessible to the original owner is very strange. The article seems to take it as a foregone conclusion that those accounts should all be expected to still exist with all the business data, and I don't know if this is based on the author's experience, or it's just a way to make the vuln sound far more serious than it really is. On the other hand, I don't think people normally expect that OAuth depends strictly on domain ownership like this. I think most would expect that it depends on some kind of secret being stored on the IdP account side, uniquely identifying the IdP account holder beyond the email addresses presented. With regular password-based authentication, with MFA, you would at least get an MFA prompt if someone had gotten access to your email address and was being sent a password reset code. But with this type of SSO, any MFA verification is done on the IdP side, so if the IdP recognizes anyone who controls example.com as the rightful owner of any claims, then there is nothing you can do as the former owner of example.com.

OtherShrezzing 2y ago
>why the Slack or HR or interview etc. data would still exist while being inaccessible to the original owner is very strange Ever been in a company that's collapsed before? Nobody hangs around to shut down the WorkDay account when they've been told they're not getting paid for the last 29 days work.
- simiones 2y ago
  I get that part, but I'm not sure why they would expire even later than the domain registration and the Google Workspace account. I would expect WorkDay or whoever to close/archive a non-paying account much earlier than that.

cosmotic 2y ago

Third parties is google as single sign on. If such an org/domain is abandoned, a malicious person could 'resurrect' the accounts on those third party sites. It's kind of like a similar situation where a user deletes an email account and then someone else creates an new one in its place, and now they have access to all the third party password reset links. Except in the case linked above, the user never had the ability to delete their accounts before off boarding, and the abstraction isn't just an email, but the account itself.

deleted 2y ago
[deleted]
reginald78 2y ago
In emails case all the larger providers I'm aware of retire addresses to prevent this sort of abuse, probably learned the hard way. Could Google OAuth do something similar here? It now occurs to me that large businesses might have the same issue with emails and former employees (easy to imagine John Smith departing and at a later date John Smith being hired) so I wonder how they typically handle this.
- scarface_74 2y ago
  Companies generally don’t reuse emails. If you come back, you can sometimes get your old email and access to your old enabled services. I know when interns were at Amazon and left, their accounts were disabled. But when they came back, they got their old accounts back and the related Slack users

chasemiller 2y ago

Yes, it's a failure on DankStartup's part. Not really much different than a user buying dankstartup.net, setting up a catch-all email, observing what comes in, and performing password resets for those accounts, allowing for account takeovers. Calling it a vuln in oauth may be a bit hyperbolic, but Google could help prevent it.

OkGoDoIt 2y ago
I have catchall email accounts in every domain name I own (mostly so I can do differentiated emails for every service to track/combat leakage), and you would not believe the amount of emails I get that are intended for previous domain owners (and typos too). I haven’t actually done any reset password flows, but there are a bunch of social media and SaaS accounts I could easily take over if I wanted. I used to try to track down whoever the emails were intended to go to and forward it to them and let them know to change it, but that got to be too tedious so nowadays I just ignore them. Still, I wouldn’t call this a vulnerability on the service provider’s part, it’s just user negligence.

placardloop 2y ago

> 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

stackghost 2y ago
>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.
- placardloop 2y ago
  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.
  - horsawlarway 2y ago
    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?
    - lxgr 2y ago
      That's why allowing account recovery using (exclusively) email is indeed a security problem.
- danudey 2y ago
  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 payment info, new users, etc. Google knows that these are two different workspaces and that there is effectively no connection between the two other than the domain, but they are not presenting that information through OAuth (which is possible) so other companies are not able to do any sort of diligence in ensuring that the correct people are accessing that data. OAuth provides the capability to make this distinction, but Google is (or was?) refusing to provide data to other companies to allow them to make that distinction. This sounds hyperbolic, but Google is effectively lying to these other services that that someone else is in fact the original person that service expects, even though Google knows full well (or is capable of knowing) that that is almost definitely not the case.

YetAnotherNick 2y ago

And not only that, almost every form of auth has the same vulnerability not just log in with Google. If you own the domain, you own the email IDs as well and you can very likely reset password.

horsawlarway 2y ago
Yeah, this is the part I'm struggling with. This is absolutely not unique to google oauth, it genuinely seems like a misunderstanding of how the web manages trust. If you own the domain, you own all the property associated with the domain, including all the old email addresses. Magic links and password resets are all going to give the new owner access. Your best bet as a solution is to be using strict 2fa (ex - a yubikey might help here) but even that is likely just "a conversation with support" away from being circumvented. This is why winding down a company is supposed to have specific stages and policies associated with the dissolution. You don't just abandon the offices and leave all the filing cabinets behind either, for similar reasons...
- lxgr 2y ago
  > Magic links and password resets are all going to give the new owner access. Which is why you should never exclusively rely on either for sensitive services.
  - YetAnotherNick 2y ago
    It's better than SMS based password recovery or "call support to reset your password". What do you suggest is the best approach.
- brookst 2y ago
  I don't think the claim is that Google has introduced a totally novel vuln, just that they are a stable, trusted middleman who is failing to mitigate a common vuln where they can. You don't abandon filing cabinets, but given that some percentage of startup failures are sudden and surprising and the people who could do something are unmotivated / unable to, it's not a best practice for a commercial landlord to put abandoned files on the street with a sign "free", files and all. Maybe they have a legal right to, but it's not how I would operate in that situation.

danudey 2y ago

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.

PKop 2y ago
Yes but he's saying the data on 3rd-party websites should be deleted by the failed startup when they shutdown not just left to sit there.
- PeterFBell 2y ago
  He's right, but having failed a number of times, after you've put all your savings into the business, fired all your team, notified and disappointed all of your investors and customers, helped your team find new gigs, filed all the dissolution paperwork, handled all the taxes, disposed responsibly of all of the assets and you now find yourself out of work and often out of cash, occasionally you'll forget to jump through all the hoops to close down all of the SaaS accounts before you stop paying the bill personally to host the email accounts. Of course perfect world you shut down earlier and in a more orderly fashion, but there are so many cases of companies almost failing and then not, it's hard to shutter a company when there is a chance you may go out of business - especially when you feel you're getting close to another raise or becoming default alive :(

VILINBR 2y ago

whats is TFA ?

deleted 2y ago
[deleted]
danudey 2y ago
"The f___ing article"
- VILINBR 2y ago
  thanks
- codetrotter 2y ago
  In polite terms it can also mean “the featured article”. And IMO it makes more sense to read it that way in a top-level comment. Whereas reading it as the f’ing article makes more sense when the word “TFA” is used in a response to another comment like “well, you say that but TFA said such and such”.
  - freedomben 2y ago
    Agreed. I've also seen "The Fine Article"
    - pimlottc 2y ago
      This is the old school “polite” version, as in, “read the fine manual”
0xffff2 2y ago
"The F-ing article" (derived from old internet slang "RTFM", for "Read the F-ing manual", a thing that new users were prone not to do before getting online and asking questions easily answered by RTFM.)
- 2y ago

riffic 2y ago

it's vital to have extremely skilled and nuanced people managing bug and security report triage because it seems many can overlook the complexities being given.

LocalPCGuy 2y ago

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.

stonemetal12 2y ago

What if DankStartup doesn't fold and just forgot to renew their domain, or lost control of their domain for some reason. OAuth shouldn't let you Auth someone else's account just because you can hijack their domain.

redleader55 2y ago

Besides the github account with a legitimate name, but impostor ownership, I can imagine another case which is problematic. HR SaaS companies might be required by law to maintain the account for a period of time - let's say until the end of the next fiscal year. The account still existing is not a failure on either Google, the SaaS company or DankStartup. The problem, as other posters mentioned is the fact the new account has the same ID in OIDC as the previous one, which is what the author of TFA proposes.

hk1337 2y ago

I don't think it would be 100% on the failed startup considering most of, if not all, of the applications mentioned likely do not actually delete accounts even when you say to delete them. There probably could be some allowance made for the situation but also you're repurposing the domain of a failed startup. I don't think the problem was necessarily with Google though as I believe they create a unique ID for the domain. The problem with be with the other services like ChatGPT, Slack, etc that associate with the domain and create accounts for each user in the domain.

nodamage 2y ago

I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee. If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@company.com was a valid user that should be allowed to login, then this problem would be avoided entirely because the defunct company would no longer report any valid users. This would also avoid further problems with attackers being able to login with unattended email addresses like support@company.com, as was discussed here: https://news.ycombinator.com/item?id=41818459 https://news.ycombinator.com/item?id=41818459 (There's a lot of discussion below about whether the "sub" claim is stable or not but it's a red herring because of this IMO, also the proposed fix in the article wouldn't address it either.)

radlad 2y ago
This is a misunderstanding of the problem. See my comment downthread: https://news.ycombinator.com/item?id=42701912 https://news.ycombinator.com/item?id=42701912 "hd" is Google's solution to this problem, and "hd" is also the source of this vulnerability.
- nodamage 2y ago
  I don't think so, but please go ahead and clarify if that is the case.
  - radlad 2y ago
    Maybe you can clarify what part of the linked comment didn't make sense? It's a bit hard to make out where the confusion is if the above comment didn't help clarify.
    - deleted 2y ago
      [deleted]
    - 2y ago

p_ing 2y ago

> DankStartup's O365, If you wanted to try to re-take over a pre-registered domain in Azure/M365, you would need to involve Microsoft Support who would require you to prove via government documentation that you were the same entity for the now-abandoned Azure/M365 account. Creating a new tenant using the same public domain won't get you access to the Azure/M365 tenant of a previous customer, you would have a different internal domain name (dankstartup2.onmicrosoft.com). At best you could register your domain post-expiration of the previous tenant and impersonate them >90 days out.

tart-lemonade 2y ago

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

tsimionescu 2y ago
This is very much a critical flaw in systems which rely entirely on email or domain names as the sole security factor. OAuth itself is flawed in that it allows this terrible practice, though to be fair it does discourage it. Google's specific OAuth solution encourages this compromised practice even more, because the only identifier it provides for a user group is the domain name associated with the account (in the "hd" field). For individual users they at least provide a "sub" field with a unique user ID (though per the article, it seems this is possibly flaky, or at least misunderstood) - this could be used to make sure that a new user@example.com doesn't get access to the old user@example.com account. But to check if a new user should have access to the organization account, there is nothing that Google provides that can be used securely: all they tell the service provider is that this is a new valid user for the example.com org, not that this is a completely different example.com org.
- tart-lemonade 2y ago
  That's a really good point. Perhaps the protocol should be expanded with an explicit identifier unique to an extant legal entity (or string of identifiers, to account for ownership changes like acquisitions), so it would be easy for SSO-enabled applications to keep previous tenants' data safe from someone who just buys the domain later on. Of course, this would still rely on the provider: it might be a great solution for large providers like Google which can implement ironclad formal verification procedures, but if you and the previous company self-hosted SSO, you control the response and can impersonate them completely.

Rebelgecko 2y ago

Is this basically equivalent to registering a domain, setting up email, and getting services to send you password reset emails to recycled addresses?

deepsun 2y ago

> a failure on DankStartup's part, to not shut down their business accounts They seized operations, why should they be responsible for any other assets? I mean ethically yes of course. But there's no law/obligations to make sure domains are closed.

sowbug 2y ago

It's similar to Gmail or Hotmail or Yahoo Mail hypothetically allowing a new user to adopt an abandoned email address. Most email services don't allow this for this very reason.

deleted 2y ago

[deleted]

egberts1 2y ago

It is an "ACL vulnerability ". ACL as in access control list. Bell-LaPalda and multi-level access control systems both required a trusted controller and, And, AND a trusted arbiter of a state machine. It is the state machine that magically got expanded into a couple more states, with the introduction of an imposter admin actor. So yeah, the trusted arbiter and owner of that state machine (Google) did an oops. This is something that Keberos (KRB5) was designed to protect against.