{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2023-009",
  "link": "https://tailscale.com/security-bulletins/#ts-2023-009",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2023-009",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Fri, 22 Dec 2023 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: \u003ca href=\"https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/\"\u003eThe OAuth implementation of Google Workspace\u003c/a\u003e allows for the creation of Google accounts associated with a given Workspace domain that are not actually controlled by that workspace, e.g. alice+foo@example.com. As a result, these accounts may be used to retain access to systems that use Google Workspace SSO login even after the original account has been deactivated or removed.\u003c/p\u003e\n\u003ch5\u003eWhat happened?\u003c/h5\u003e\n\u003cp\u003eTailscale uses Google as one of the possible identity providers for creating and joining a tailnet. Users who have emails with the same domain name can automatically sign in using SSO and be added to the corresponding tailnet (unless \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser approval\u003c/a\u003e is turned on for the tailnet)\u200b\u200b. The OAuth vulnerability reported by Truffle Security means that it is possible for an attacker to create a new personal Google Account that is attached to an alias of their legitimate Workspace account. This new account will not register as being part of the domain\u0027s Workspace, and thus cannot be removed by its admins. However, if the attacker then uses the new, spoofed Google Account to log into Tailscale, we would have treated it as a legitimate user in the tailnet. Thus, users could remain connected to a tailnet using this spoofed account even if their primary Workspace account has been disabled, e.g. after employee termination.\u003c/p\u003e\n\u003cp\u003eWe became aware of the vulnerability on 2023-12-21 when its disclosure by Truffle Security was circulated widely. We deployed a remediation that prevents personal Google accounts from logging into tailnets associated with Workspace accounts on 2023-12-21.\u003c/p\u003e\n\u003ch5\u003eWho is affected?\u003c/h5\u003e\n\u003cp\u003eEveryone who uses Google Workspace to sign in.\u003c/p\u003e\n\u003ch5\u003eWhat is the impact?\u003c/h5\u003e\n\u003cp\u003eTailnets that use Google Workspace as their SSO provider may have Tailscale users that do not have a corresponding user in the Google Workspace. Prior to 2023-12-21, this would have made it possible for those users to retain access to Tailscale after their SSO account was deleted. Following the remediation, these users can no longer login to Tailscale.\u003c/p\u003e\n\u003ch5\u003eWhat do I need to do?\u003c/h5\u003e\n\u003cp\u003eTailscale admins should visit \u003ca href=\"https://login.tailscale.com/admin/users\"\u003ethe Users page of the Tailscale admin console\u003c/a\u003e and audit the list of users to see if there are unknown addresses that should not be there. Admins can also \u003ca href=\"https://tailscale.com/kb/1229/export-user-list\"\u003eexport this list of users\u003c/a\u003e as a CSV file to examine offline.\u003c/p\u003e\n\u003cp\u003eFor extra security, you can turn on \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser approval\u003c/a\u003e for your Tailnet so that every new user of Tailscale has to be manually approved by an admin. Note: this does not mitigate against situations where the attacker is themselves an admin of Tailscale.\u003c/p\u003e",
  "summary_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/html",
    "value": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: \u003ca href=\"https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/\"\u003eThe OAuth implementation of Google Workspace\u003c/a\u003e allows for the creation of Google accounts associated with a given Workspace domain that are not actually controlled by that workspace, e.g. alice+foo@example.com. As a result, these accounts may be used to retain access to systems that use Google Workspace SSO login even after the original account has been deactivated or removed.\u003c/p\u003e\n\u003ch5\u003eWhat happened?\u003c/h5\u003e\n\u003cp\u003eTailscale uses Google as one of the possible identity providers for creating and joining a tailnet. Users who have emails with the same domain name can automatically sign in using SSO and be added to the corresponding tailnet (unless \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser approval\u003c/a\u003e is turned on for the tailnet)\u200b\u200b. The OAuth vulnerability reported by Truffle Security means that it is possible for an attacker to create a new personal Google Account that is attached to an alias of their legitimate Workspace account. This new account will not register as being part of the domain\u0027s Workspace, and thus cannot be removed by its admins. However, if the attacker then uses the new, spoofed Google Account to log into Tailscale, we would have treated it as a legitimate user in the tailnet. Thus, users could remain connected to a tailnet using this spoofed account even if their primary Workspace account has been disabled, e.g. after employee termination.\u003c/p\u003e\n\u003cp\u003eWe became aware of the vulnerability on 2023-12-21 when its disclosure by Truffle Security was circulated widely. We deployed a remediation that prevents personal Google accounts from logging into tailnets associated with Workspace accounts on 2023-12-21.\u003c/p\u003e\n\u003ch5\u003eWho is affected?\u003c/h5\u003e\n\u003cp\u003eEveryone who uses Google Workspace to sign in.\u003c/p\u003e\n\u003ch5\u003eWhat is the impact?\u003c/h5\u003e\n\u003cp\u003eTailnets that use Google Workspace as their SSO provider may have Tailscale users that do not have a corresponding user in the Google Workspace. Prior to 2023-12-21, this would have made it possible for those users to retain access to Tailscale after their SSO account was deleted. Following the remediation, these users can no longer login to Tailscale.\u003c/p\u003e\n\u003ch5\u003eWhat do I need to do?\u003c/h5\u003e\n\u003cp\u003eTailscale admins should visit \u003ca href=\"https://login.tailscale.com/admin/users\"\u003ethe Users page of the Tailscale admin console\u003c/a\u003e and audit the list of users to see if there are unknown addresses that should not be there. Admins can also \u003ca href=\"https://tailscale.com/kb/1229/export-user-list\"\u003eexport this list of users\u003c/a\u003e as a CSV file to examine offline.\u003c/p\u003e\n\u003cp\u003eFor extra security, you can turn on \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser approval\u003c/a\u003e for your Tailnet so that every new user of Tailscale has to be manually approved by an admin. Note: this does not mitigate against situations where the attacker is themselves an admin of Tailscale.\u003c/p\u003e"
  },
  "title": "TS-2023-009",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2023-009"
  }
}