Remember startups? They're backin OAuth form Startup necromancy: Dead Google Apps domains can be compromised by new owners Improperly winding down a Google Apps domain can leave logins accessible. Kevin Purdy Jan 15, 2025 2:51 pm | 0 Credit: Aurich Lawson | Getty Images Credit: Aurich Lawson | Getty Images Story textSizeSmallStandardLargeWidth *StandardWideLinksStandardOrange* Subscribers only Learn moreLots 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 loopup 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 accountson both Google and other web-based appsbefore 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 allows you to re-activate the Google accounts for former employees if the site's Google account still exists.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 itReached for comment, a Google spokesperson provided a statement:We appreciate Dylan Ayreys 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.Wont fix (intended behavior) Dylan Ayrey's simplified explanation of how Google (or most any) OAuth works when signing in to a third-party service like Slack. Credit: Dylan Ayrey Dylan Ayrey's simplified explanation of how Google (or most any) OAuth works when signing in to a third-party service like Slack. Credit: Dylan Ayrey 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. 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." Dylan Ayrey's talk at ShmooCon 2025: "Taking Over Millions of Accounts." 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.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.Kevin PurdySenior Technology ReporterKevin PurdySenior Technology Reporter Kevin is a senior technology reporter at Ars Technica, covering open-source software, PC gaming, home automation, repairability, e-bikes, and tech history. He has previously worked at Lifehacker, Wirecutter, iFixit, and Carbon Switch. 0 Comments