6 ms·

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 exist

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]
    - nodamage 2y 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?
      - nodamage 2y 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).
rahimnathwani 2y 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?
- nevir 2y ago
  By looking the account up with Google's People API - https://developers.google.com/people https://developers.google.com/people They would have to verify the account is active, AND the id hasn't changed
  - rahimnathwani 2y 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.
    - radlad 2y 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.
    - nodamage 2y 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=%2Cpublic-and-internal-applications https://support.google.com/cloud/answer/6158849?hl=en#zippy=... [2] https://support.google.com/a/answer/6357481 https://support.google.com/a/answer/6357481
red_trumpet 2y ago
If the attacker is in control of company.com, checking against this domain would not help.
- nodamage 2y ago
  I'm not talking about checking against the domain, but checking against a directory of active users.
  - batch12 2y ago
    Where would this directory be stored?
  - radlad 2y ago
    That's what an identity provider (e.g. AD, OneLogin, Okta, Duo SSO, Google OAuth, etc.) is supposed to be, ostensibly.
    - nodamage 2y 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?
      - radlad 2y ago
        I think you may be a bit confused about the players here. When you use Google OAuth to login, it _is_ your identity provider, and it is reporting to Slack that the user exists. Google is reporting the user exists because it exists in the Google Workspace directory. You use this as your source of truth for provisioning users, and they automatically get access to all of your company's apps. The problem is that even though the user has the same email (joe@example.com), and the same Google Workspace domain ("hd": example.com), this is actually a _new_ Google Workspace account. But nothing Google provides to Slack allows them to detect this. Slack, et al can fix this by _not_ using the public Google OAuth integration, and forcing every use to configure an individual internal Google OAuth integration. But they use the public one because Google has said it is a safe and secure way to operate their service.
tsimionescu 2y 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.
- nodamage 2y 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.)

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]
  - nodamage 2y 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?
    - nodamage 2y 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).

rahimnathwani 2y 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?

nevir 2y ago
By looking the account up with Google's People API - https://developers.google.com/people https://developers.google.com/people They would have to verify the account is active, AND the id hasn't changed
- rahimnathwani 2y 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.
  - radlad 2y 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.
  - nodamage 2y 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=%2Cpublic-and-internal-applications https://support.google.com/cloud/answer/6158849?hl=en#zippy=... [2] https://support.google.com/a/answer/6357481 https://support.google.com/a/answer/6357481

red_trumpet 2y ago

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

nodamage 2y ago
I'm not talking about checking against the domain, but checking against a directory of active users.
- batch12 2y ago
  Where would this directory be stored?
- radlad 2y ago
  That's what an identity provider (e.g. AD, OneLogin, Okta, Duo SSO, Google OAuth, etc.) is supposed to be, ostensibly.
  - nodamage 2y 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?
    - radlad 2y ago
      I think you may be a bit confused about the players here. When you use Google OAuth to login, it _is_ your identity provider, and it is reporting to Slack that the user exists. Google is reporting the user exists because it exists in the Google Workspace directory. You use this as your source of truth for provisioning users, and they automatically get access to all of your company's apps. The problem is that even though the user has the same email (joe@example.com), and the same Google Workspace domain ("hd": example.com), this is actually a _new_ Google Workspace account. But nothing Google provides to Slack allows them to detect this. Slack, et al can fix this by _not_ using the public Google OAuth integration, and forcing every use to configure an individual internal Google OAuth integration. But they use the public one because Google has said it is a safe and secure way to operate their service.

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

nodamage 2y 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.)