Comment by nodamage

Comment by nodamage 4 days 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 (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.)

rahimnathwani 4 days ago

  If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com

How would they check that?

Reply View 6 replies

nevir 4 days ago

By looking the account up with Google's People API - https://developers.google.com/people
They would have to verify the account is active, AND the id hasn't changed

Reply View | 3 replies
- rahimnathwani 4 days ago
  
  By looking the account up with Google's People API - https://developers.google.com/people They would have to verify the account is active
  If I log in using Google oauth, you already know the Google account is active.
  AND the id hasn't changed
  Yes, but that's an additional check, separate from the one you suggested would eliminate the issue:
  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.
  
  Reply View | 2 replies
  
  nodamage 2 days ago
  
  > If I log in using Google oauth, you already know the Google account is active.
  You know there is an active Google account but (for the public OAuth integration option) it can be any Google account from any workspace, or no workspace.
  "A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." [1]
  > Yes, but that's an additional check, separate from the one you suggested would eliminate the issue:
  If you set up an internal OAuth integration option no separate check is necessary, it will actually restrict access to users of your workspace.
  "An internal application will only allow access to users from your organization (@your-organization.com)." [1]
  You can use the SAML integration option as well. [2]
  [1] https://support.google.com/cloud/answer/6158849?hl=en#zippy=...
  [2] https://support.google.com/a/answer/6357481
  
  Reply View | 0 replies
  
  johnmaguire 4 days ago
  
  Right, this additional check should not be necessary in a typical OAuth or OIDC flow. This workaround is only necessary in this case because the API Google offers to services has a hole in it.
  
  Reply View | 0 replies
okdood64 4 days ago

Either slack or some other third party provider could have a whitelist maintained by IT?
Just spitballing.

Reply View | 1 reply
- johnmaguire 4 days ago
  
  It is certainly an option to pre-provision accounts in your application (e.g. Slack) and then have any users authenticating from the SSO product compared against the list of authorized users. And for some products which sell licenses by seat, this is exactly what they do.
  But for many products which are meant to be available to an entire organization, this is a big part of what SSO was supposed to solve in the first place: IT no longer has to provision (and de-provision) user accounts in every single application. Maintaining an allowlist in each application makes this pointless.
  
  Reply View | 0 replies

johnmaguire 4 days ago

This is a misunderstanding of the problem. See my comment downthread: https://news.ycombinator.com/item?id=42701912

"hd" is Google's solution to this problem, and "hd" is also the source of this vulnerability.

Reply View 5 replies

nodamage 4 days ago

I don't think so, but please go ahead and clarify if that is the case.

Reply View | 4 replies
- johnmaguire 4 days 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.
  
  Reply View | 3 replies
  
  nodamage 4 days ago
  
  If I'm understanding your comment correctly there are three different ways to connect Google SSO to your application:
  1. SAML. This avoids the issue because certificates need to be exchanged between Google and your application, but an attacker that recreates a duplicate workspace using your domain won't have access to those certificates. Only users from your workspace will be allowed to login.
  2. A custom Google OIDC IdP configured for internal access only. This also avoids the issue because a secret key is required to set this up and the attacker won't have access to that key. Again, only users from your workspace will be allowed to login.
  3. The public Google OAuth API which will allow any Google user from any workspace (or non-workspace users) to login to your application.
  Is this correct?
  
  Reply View | 1 reply
  
  nodamage 3 days ago
  
  Assuming the above is correct, if you decide to connect Google SSO to your application using option (3), then it is not a vulnerability that a Google account from a different workspace can connect to your application, because the entire point of option (3) is that users with any Google account (regardless of workspace) can connect to your application.
  If you intended to restrict your application to users of your own workspace then you should have used option (1) or (2).
  
  Reply View | 0 replies
  
  [removed] 4 days ago
  
  [deleted]
  
  Reply View | 0 replies

tsimionescu 4 days ago

First of all, the whole point of SSO is that the only and final source on who are the valid active users is the IdP, in this case Google's public OAuth instance. If the IdP says that the current request is coming from the real user1@example.com, you give them access. And Google's public OAuth instance will confirm this even if the current Google Workspace associated with example.com is a different one than a few months ago (though the "sub" field of the attestation will be different than before, which the service provider is supposed to check).

Second of all, even if it was recognized that this is a different user1@example.com, they'd still have access to all sorts of company internal resources, that may still contain sensitive data, especially for small companies which inherently trust all employees.

Reply View 1 reply

nodamage 3 days ago

Google's public OAuth is intended for situations where you want to allow anyone with a Google account to login to your application, regardless of workspace. Given that, it is not a Google OAuth vulnerability that a user can login to your application using a Google account from a different workspace.
If you want to integrate Google SSO into your application and restrict logins to a specific workspace, there are other options you can use that will actually check if the user belongs to that workspace (SAML or internal OAuth).
To the extent that service providers are using Google's public OAuth and then trying to read the domain name out of the returned ID token in order to restrict logins a specific Google workspace, they are using Google's public OAuth instance for a situation it was not intended for because domain names do not map 1:1 to workspaces. However that is a vulnerability on the service provider's side, not Google's.
To the extent that a service provider offers Google SSO integration via Google's public OAuth but also via workspace restricted options, if a company selects the former instead of the latter then the responsibility for the vulnerability is on the company's side. (Slack, for example, offers both because there are some Slack groups where allowing access from any Google account makes sense, and other groups where you would want to restrict access to Google accounts from a specific workspace.)

Reply View | 0 replies

red_trumpet 4 days ago

If the attacker is in control of company.com, checking against this domain would not help.

Reply View 16 replies

nodamage 4 days ago

I'm not talking about checking against the domain, but checking against a directory of active users.

Reply View | 15 replies
- cortesoft 4 days ago
  
  Where does this “directory of active users” exist? If it is controlled by slack, then you are relying on a failed startup to properly notify ALL the 3rd parties when they shut down. Failed startups don’t always shut down cleanly like that.
  
  Reply View | 1 reply
  
  chavesn 4 days ago
  
  > Failed startups don’t always shut down cleanly like that.
  Agreed, and with the number of services and the "ease" of oauth it's likely impossible to even track. You could make a list of the major ones, but there could be hundreds per user, ultimately thousands of unique services used depending on the breadth of the startup's activities.
  
  Reply View | 0 replies
- johnmaguire 4 days ago
  
  That's what an identity provider (e.g. AD, OneLogin, Okta, Duo SSO, Google OAuth, etc.) is supposed to be, ostensibly.
  
  Reply View | 11 replies
  
  nodamage 4 days ago
  
  Yes. If you've set up your Slack so each login checks against the identity provider to ensure an active user is logging in, that would resolve the issue, no?
  Even if you take over company.com's domain you can't reconfigure company.com's Slack to point to a new identity provider?
  
  Reply View | 10 replies
- batch12 4 days ago
  
  Where would this directory be stored?
  
  Reply View | 0 replies