UPDATED with additional comment from Google.Millions of accounts with Slack, ChatGPT, Zoom and other online service providers can be taken over without a password using the Sign in with Google single-sign-on feature that comes with Google Workspace, security researcher Dylan Ayrey said at the ShmooCon hacker conference in Washington, D.C., this past Saturday (Jan. 11).Also apparently vulnerable, Ayrey said, are accounts with software-as-a-service (SaaS) companies such as workplace-management platform provider Asana; Gusto, which runs an HR software platform; productivity software provider Notion; and network security and reliability provider Cloudflare. Countless others may be susceptible.The vulnerable accounts, he said, were created by employees of companies that used Google Workspace and then later went out of business, leaving their expired domain names available for sale."The most eye-opening were probably HR systems, which allowed you to log in and see the W-2's and Social Security numbers and bank routing numbers of the old employees," Ayrey said to cheers and claps from the audience."I don't know if I'd clap for that," he added. "It's bad. It's as bad as you can imagine it." [You can watch his entire ShmooCon presentation starting at 5:33:00 here.]One important point: At no point is any data held by Google itself compromised, such as Gmail, Google Drive, Google Calendar or Google Docs. Instead, this applies only to some third-party services that accept logins using Sign in with Google, aka Join with Google or Log in with Google, and it depends on whether the services use the default OAuth configuration or add extra authentication factors.
How these account takeovers can happen
Many companies use Google Workspace as an inexpensive and flexible office and email provider, and Sign in with Google is a reliable and easy-to-use SSO format.Key to Google Workspace and Sign in with Google is each client company's domain name, which Google uses to authenticate users. Let's use "failedstartup.com" as an example.A user named, say, Jack Ferguson could use Google's SSO and the email address "[email protected]" to create multiple online accounts with third-party services. He would need only to log into his Google Workspace account to access those third-party accounts.By default, on each login attempt from Sign in with Google, the third-party provider queries Google to see if that user and domain name exist and are registered with Google Workspace. If Google confirms the information, the third-party service grants access to the user.Yet if a company goes under and the "failedstartup.com" domain registration expires, Ayrey discovered, anyone can buy the domain name, enroll in Google Workspace using the domain name, and then use Sign in with Google to create new online accounts based on "failedstartup.com".Ayrey did exactly that, looking on CrunchBase for a list of expired domain names that had belonged to failed companies. He found 116,481 of them and self-published a book with Amazon containing 10,000 of them, each with a name, location and brief description. (You can buy a copy for $34.)He chose a random domain name from the book, bought it, set up Google Workspace and tried to create new third-party accounts using Sign in with Google.But, Ayrey said, instead of creating new accounts, the third-party services would sometimes log him into existing accounts created by users employed by the previous owner of the domain name.If you're the legitimate new owner of "failedstartup.com" and you decide to create a new Slack account using "[email protected]," you might find yourself looking at Jack Ferguson's old workplace Slack account.Even if only half of those 116,000 listed failed startups used Google Workspace, Ayrey pointed out, and each of those startups had an average of 10 employees, and each employee signed up to 10 third-party services, that's several million dormant accounts that might be vulnerable to passwordless takeover.The potential fallout
What's so bad about this? Who cares about the internal Slack chats of an extinct company?Well, as Ayery pointed out, there's plenty of personally identifiable information tied up in online HR platforms. Project-management accounts can reveal proprietary data that may have been passed on or sold to other companies.Zoom logs can show which external contacts the failed company's employees met with. Even old Slack chats can reveal a lot about a firm and its employees.Furthermore, "what an attacker could do is take a look at all the other users in the public channels, go back into Google Workspace, and add all those users," Ayrey told us in an online chat following his presentation.So if the Slack account for "[email protected]" reveals that there are other internal users named "jill," "fred" and "wilma," you could create email addresses for them and try to access their Slack accounts too."That would allow the attacker to log into all the specific accounts, and access the direct messages, private channels, etc.," Ayrey added.Even accounts at online services that don't use Google SSO might be vulnerable to fraudulent password resets, Ayrey said during his presentation."If you click 'Password Reset' and the Password Reset just sends an email to reset the password," he said, "because you have access to that email inbox, you can also take over those accounts."He recommended that online services add a "speed bump" to password-reset procedures, such as confirming a one-time texted code or entering part of a known credit-card number."But for the logins, nobody implements a speed bump when someone's trying to Google Single Sign On," he added. "And you can't. A product person will kill you for adding friction to the login."Google has recommendations, but they may not work
Ayrey said he contacted Google about his findings in October 2024 but was told that the system was working as intended. What he found was not a bug, Google told him, but instead an instance of fraud.After Ayrey's ShmooCon talk was accepted and posted on the online ShmooCon schedule in December, Google reopened the issue, paid Ayrey a bug bounty of $1,337, and told him it would re-examine the problem.We reached out to Google regarding Ayrey's findings and were given this statement, attributable to a Google spokesperson:"We appreciate Dylan Ayrey's help identifying the risks stemming from customers forgetting to delete third-party SaaS services as part of turning down their operation. As a best practice, we recommend customers properly close out domains following these instructions to make this type of issue impossible. Additionally, we encourage third-party apps to follow best practices by using the unique account identifiers (sub) to mitigate this risk."That "sub" identifier is an ID number that Google assigns each user of Google Workspace, and it's supposed to be immutable. Google's own documentation states that the sub ID is "unique among all Google accounts and never reused" and that "the sub value is never changed."Google recommends, but does not require, that third-party services ask for the sub ID number as part of the OAuth token in addition to the username and domain name when logging in users who use Sign in with Google. It also recommends that third-party services delete all account data when an account is closed.And, in fact, after Ayrey discovered the login flaw with Google Workspace and reactivated domains, he began reaching out to vulnerable service providers to suggest that they add "sub" as a required authentication field.But, Ayrey said, he found that the sub ID may not in fact be immutable. He found several Stack Overflow posts — here's one — from IT administrators complaining that the Google Workspace sub ID sometimes changes arbitrarily, without a corresponding change in username, email address or domain name.One admin at a service provider to which Ayrey reached out told him that in a given week, 0.4% of the sub IDs in their Google Workspace environment would change."For them, that was hundreds of users per week, so they couldn't implement this protection," Ayrey said.Google told us that "we've seen no evidence to support that assertion. The sub field is the immutable unique stable identifier."UPDATE: After this story was posted online, Google reached out to us to again to state that it had updated its official documentation regarding Google SSO, OpenIDConnect and OAuth.The page now states in highlighted red type:"When implementing your account management system, you shouldn't use the email field in the ID token as a unique identifier for a user. Always use the sub field as it is unique to a Google Account even if the user changes their email address."Our Google contact also reiterated: "We’ll happily examine any materials on this, but we've seen no evidence to support the assertion that the sub field is not an immutable and unique identifier."Presumably, the next step would be to require the sub field by default as a form of authentication, instead of just suggesting it as a best practice. We'll ask Google if it has plans to make the sub field a requirement for OAuth tokens.
