Sign in with Google’s security flaw disclosure.
Update, January 16, 2025: This story, originally published on January 15, now includes a statement from Google and further clarification of the initial response to the researcher’s findings, as well as additional comments from a security expert.
Google is always in the news and, unfortunately, not always for positive reasons when it comes to security issues. It’s great that new security rules are coming down soon to help protect users, and there’s plenty of help for Gmail users who find their accounts have been hacked. However, with users already on high alert as two-factor authentication bypass attacks continue, the last thing Google needs is more bad news about secure account login. Bad news, however, has come with the release of research demonstrating how Google’s OAuth authentication can be exploited by attackers to gain access to sensitive data from potentially millions of accounts. Here’s what you need to know.
Google sign-in vulnerability explained
A January 13 report has revealed how security researchers discovered a rather shocking vulnerability affecting Google’s “Sign in with Google” authentication flow. “I demonstrated this flaw by accessing accounts I didn’t own,” said Dylan Ayrey, CEO and co-founder of Trufflesecurity, “and Google responded that this behavior was working as intended.” Ayrey warned anyone who has ever worked for a startup in the past, especially one that has now ceased trading, that they could be vulnerable to this hacking method.
Ayrey explained that the problem is based on the fact that Google’s OAuth login “doesn’t protect against someone buying a failed startup’s domain and using it to recreate email accounts for former employees,” which leaves the door wide open to open to an attacker using those accounts to access any software as a service product that the organization was using. What kind of services, you might ask? Well, security research showed how just one of these defunct domains opened security doors to access former employee accounts that included ChatGPT, Notion, Slack and Zoom. “The most sensitive accounts included human resources systems,” Ayrey said, “which contained tax documents, payslips, insurance information, social security numbers and more.”
The vulnerability appears to revolve around “claims” that are sent by Google when a user hits the sign in with Google button to access a service. These claims include the likes of specifying the host domain and the user’s email address. The service provider usually uses both of these to determine whether access should be granted. However, Ayrey found that if a service relied on these alone, any change of domain ownership would not be seen differently. “When someone buys a defunct company’s domain,” Ayrey said, “they inherit the same claims, giving them access to old employee accounts.”
“This vulnerability highlights strong concerns about protecting user data and continued reliance on third-party authentication systems,” said Roei Sherman, Mitiga’s chief field technology officer, “to mitigate such risks is vital for companies to put in place rigorous security assessments and ensure that their authentication methods are not only user-friendly, but also resilient to potential exploitation.”
Google’s response to the risk of OAuth hacking
Ayrey said the problem was first reported to Google on September 30, 2024, and marked as “not going to be fixed” on October 2, 2024. After demonstrating the exploit at a major security conference, Shmoocon, in December, Google reopened the ticket and gave researchers a small reward of $1337. The amount is interesting in itself, as 1337 is hacker slang for the elite. Ayrey said Google is now working on a fix, though it will include the approach mentioned in the Trufflesecurity report of implementing two new immutable identifiers of a unique user ID that doesn’t change over time and a unique user ID. domain-related workspace remains to be seen.
I reached out to Google for a statement, and a spokesperson said: “We appreciate Dylan Ayrey’s help in identifying risks stemming from customers forgetting to delete third-party SaaS services as part of their denial of service. As a best practice, we recommend customers to properly terminate domains by following these instructions to make this type of problem unlikely. Additionally, we encourage third-party applications to follow best practices by using unique (sub)account identifiers to mitigate this risk.”
Google also wanted to clarify the initial response to the researcher after telling me it was seeing some confusion about this. During a brief conversation, Google wanted to make it clear that, in its opinion, a fix was not necessary because there is already a strong and adequate protection. The “subdomain” is the immutable identifier the researcher is looking for — and Google said it strongly urged developers to use it to provide additional protection. While happy to examine any further material on the matter, Google told me it had seen no evidence to support the claim that the subdomain is not an immutable, unique identifier. Google also wanted to add that it has now updated its developer documentation to make this guidance even more prominent.
A Google spokesperson also told me that the attack scenario does not identify the risk to data stored by Google, but rather to data stored on third-party platforms, as there is an important distinction to be made here.
Such third-party Google partners have levers to protect against this type of problem, the spokesperson said, including:
- Delete all customer data on the close account to ensure that company-wide accessible data is no longer available.
- Using the subdomain within their application as a unique identifier key for the user to ensure that specific user data can never be accessed by any other entity. This field is unique among all Google accounts and is never reused.
