Startup necromancy: Dead Google Apps domains can be compromised by new owners

Lots of startups use Google's productivity suite, known as Workspace, to handle email, documents, and other back-office matters. Relatedly, lots of business-minded webapps use Google's OAuth, i.e. "Sign in with Google." It's a low-friction feedback loop—up until the startup fails, the domain goes up for sale, and somebody forgot to close down all the Google stuff. Dylan Ayrey, of Truffle Security Co., suggests in a report that this problem is more serious than anyone, especially Google, is acknowledging. Many startups make the critical mistake of not properly closing their accounts—on both Google and other web-based apps—before letting their domains expire. Given the number of people working for tech startups (6 million), the failure rate of said startups (90 percent), their usage of Google Workspaces (50 percent, all by Ayrey's numbers), and the speed at which startups tend to fall apart, there are a lot of Google-auth-connected domains up for sale at any time. That would not be an inherent problem, except that, as Ayrey shows, buying a domain with a still-active Google account can let you re-activate the Google accounts for former employees. With admin access to those accounts, you can get into many of the services they used Google's OAuth to log into, like Slack, ChatGPT, Zoom, and HR systems. Ayrey writes that he bought a defunct startup domain and got access to each of those through Google account sign-ins. He ended up with tax documents, job interview details, and direct messages, among other sensitive materials.

You have to close up shop, not just abandon it

Reached for comment, a Google spokesperson provided a statement:

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.

Google's instructions note that canceling a Google Workspace "doesn't remove user accounts," which remain until an organization's Google account is deleted. Notably, Ayrey's methods were not able to access data stored inside each re-activated Google account, but on third-party platforms. While Ayrey's test cases and data largely concern startups, any domain that used Google Workspace accounts to authenticate with third-party services and failed to delete their Google account to remove its domain link before selling the domain could be vulnerable.

“Won’t fix (intended behavior)”

Ayrey writes that he disclosed his findings to Google on September 30, 2024. Google responded on October 2 that it had "made the decision not to track it as an abuse bug" and set its status to "Won't Fix (Intended Behavior)," according to Ayrey's screenshots. A Google spokesperson wrote that the company's initial response was based on "a strong and appropriate protection," the "sub" field, already existing (more on that further on). Ten days after Ayrey had a talk on this topic accepted at the Shmoocon hacker conference, Google re-opened the issue, paid him a $1,337 reward, and stated at the time that "exploitation likelihood is low" but that it was an "abuse-related methodology with high impact."

In Google's domain close-out instructions and API documentation, Google points to a unique user identifier, "sub," as a value that is "never changed" and which should be used as a key for user identification. Ayrey's post quotes an unnamed staff engineer at a major tech company who disagrees, suggesting that the sub value varies in "about 0.04% of logins" using Google OAuth. At certain audience sizes, that could be hundreds of logins any given week. Faced with such an issue, larger services likely do not use "sub" for unique user verification, Ayrey suggests. A Google spokesperson said the company would "happily examine any materials on this," but had seen "no evidence to support the assertion that the sub field is not an immutable and unique identifier." Google has also updated its OAuth developer documentation to further emphasize the use of "sub" as a protection. In a chat conversation with Ars, Ayrey noted that, had "sub" been enforced by any of the major services he tested with his purchased domains and re-activated accounts, he should not have been able to get in. But his account reuse ruse worked on "100 percent of the ones I tested," Ayrey told Ars. This would suggest that the use of "sub" was either not implemented or did not work to prevent such domain-takeover access. Ayrey's proposed fix, which he suggested to Google, is to include two new immutable identifiers inside its OpenID Connect claims: one tied to the user that never changes and one tied to the domain. As of Tuesday, January 14, Ayrey had not heard from Google as to potential fixes or progress. This post was updated at 3:50 p.m. with further response from Google.