Just over a year ago, in our post entitled Google OAuth and phantom accounts, we discussed how using the “Sign in with Google” option for corporate services allows employees to create phantom Google accounts that aren’t controlled by the corporate Google Workspace admin, and continue to function after offboarding. Recently, it was discovered that this isn’t the only issue with OAuth. Due to weaknesses in this authentication mechanism, anyone can gain access to data of many defunct organizations by re-registering domains they abandoned. In this article, we explore this attack in more detail.
How authentication works with “Sign in with Google”
Some organizations may believe that “Sign in with Google” provides a reliable authentication mechanism backed by Google’s advanced technology and vast user monitoring capabilities. However, in reality, the Google OAuth authentication check is quite basic. It generally comes down to verifying that a user has access to an email address linked to an organization’s Google Workspace.
Moreover, as mentioned in our previous article on Google OAuth, this doesn’t necessarily have to be a Gmail address — Google accounts can be linked to any email address. Therefore, the security of accessing a corporate service via “Sign in with Google” is only as strong as the security of the email linked to the Google account.
Now let’s get into the details…
When authenticating a user in a corporate service, Google OAuth sends the following information to that service:
In theory, the Google OAuth ID token includes a unique parameter called sub for each Google account. However, in practice, due to issues with its usage, services often only check the domain and email address. Source
Google recommends that services use the sub parameter, claiming that this identifier is unique and constant for the user account — unlike an email address. But in reality, the sub parameter isn’t always constant; for a small number of users, it changes over time, which can cause authentication failures. As a result, services tend not to use it, and instead verify only the domain and email address — contrary to Google’s recommendations.
“Sign in with Google” using an abandoned domain
Thus, an attacker can gain unauthorized access to a company’s services by simply having access to an email within that company’s domain. This is particularly easy to do if the company has ceased operations and abandoned its domain: anyone can register it for themselves.
The attacker can then create any email address under this domain, and use it to log into one of the services the company likely used. Some of these services may display a list of real users linked to the organization’s workspace — even if the address entered by the attacker was never actually used.
With this list — and complete control over all email addresses within the abandoned domain — the attacker can reconstruct the original Google Workspace of the defunct company. In this way, attackers can gain access to the profiles of former employees in services that used Google OAuth for authentication.
How serious a problem is this?
Dylan Ayrey, the researcher who discovered this Google OAuth vulnerability (and the previous issue with phantom accounts), aimed to demonstrate the severity of potential consequences. Using data from Crunchbase, Ayrey compiled a list of over 100,000 terminated startups whose domains are now up for sale.
Ayrey purchased one of these abandoned domains and tested the feasibility of the attack. Among the corporate services he managed to access using this vulnerability were Slack, Zoom, Notion, ChatGPT, and HR systems.
Thus, with this relatively simple attack requiring minimal resources, an attacker can gain access to a wealth of confidential information, ranging from employee correspondence and notes to personal data from HR systems.
According to Ayrey’s estimates, around 50% of startups use Google Workspace. If we suppose that the average defunct startup had about 10 employees, we could be talking about hundreds of thousands of people and millions of vulnerable accounts.
Who’s responsible, and what can be done?
Ayrey dutifully notified Google of this vulnerability through its bug bounty program. He also suggested a long-term solution: creating truly permanent and unique identifiers for Google accounts and Google Workspace. However, his report was initially rejected, with the comment “no fix needed” and labeled as “fraud or abuse”!
However, a few months after Ayrey presented his findings at a hacker conference (!) the report was reopened, and he was awarded $1337. Notably, he received the same minimal reward for his previous discovery of the phantom Google accounts vulnerability.
According to Ayrey, Google promised to fix the vulnerability in Google OAuth, but didn’t specify when or how exactly they plan to do this. Therefore, the problem with the “Sign in with Google” mechanism remains an unresolved issue, for which no one is willing to take responsibility. Potential victims of this attack include former employees of defunct companies who no longer have control over their accounts. Worse still, there’s no one to hold accountable for the security of these accounts anymore.
The wise move here would be for companies to take preventive measures in advance. However, very few startups seriously plan for their own demise — let alone what will happen afterward.
Fortunately, defending against this Google OAuth vulnerability is relatively straightforward. There are two non-mutually exclusive options:
- Use a traditional login-and-password combo instead of “Sign in with Google”, and always enable two-factor authentication.
- If your company ceases operations, don’t abandon workspaces in corporate services; delete them instead. This is quite easy to do; for example, here are the instructions for Slack and Notion.
Kaspersky official blog –
