{"id":23868,"date":"2025-02-28T08:54:49","date_gmt":"2025-02-28T13:54:49","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/google-oauth-abandoned-domains-attack\/23868\/"},"modified":"2025-02-28T18:22:22","modified_gmt":"2025-02-28T14:22:22","slug":"google-oauth-abandoned-domains-attack","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/google-oauth-abandoned-domains-attack\/23868\/","title":{"rendered":"Attack on Google OAuth using abandoned domains"},"content":{"rendered":"

Just over a year ago, in our post entitled Google OAuth and phantom accounts<\/a>, we discussed how using the \u201cSign in with Google\u201d option for corporate services allows employees to create phantom Google accounts that aren\u2019t controlled by the corporate Google Workspace admin, and continue to function after offboarding. Recently, it was discovered<\/a> that this isn\u2019t 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.<\/p>\n

How authentication works with \u201cSign in with Google\u201d<\/h2>\n

\nSome organizations may believe that \u201cSign in with Google\u201d provides a reliable authentication mechanism backed by Google\u2019s 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\u2019s Google Workspace.<\/p>\n

Moreover, as mentioned in our previous article on Google OAuth, this doesn\u2019t necessarily have to be a Gmail address\u00a0\u2014 Google accounts can be linked to any email address. Therefore, the security of accessing a corporate service via \u201cSign in with Google\u201d is only as strong as the security of the email linked to the Google account.<\/p>\n

Now let\u2019s get into the details\u2026<\/p>\n

When authenticating a user in a corporate service, Google OAuth sends the following information to that service:<\/p>\n

\"Description<\/a>

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<\/a><\/p><\/div>\n

Google recommends that services use the sub<\/em> parameter, claiming that this identifier is unique and constant for the user account \u2014 unlike an email address. But in reality, the sub<\/em> parameter isn\u2019t 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 \u2014 contrary to Google\u2019s recommendations.<\/p>\n

\u201cSign in with Google\u201d using an abandoned domain<\/h2>\n

\nThus, an attacker can gain unauthorized access to a company\u2019s services by simply having access to an email within that company\u2019s domain. This is particularly easy to do if the company has ceased operations and abandoned its domain: anyone can register it for themselves.<\/p>\n

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\u2019s workspace\u00a0\u2014 even if the address entered by the attacker was never actually used.<\/p>\n

With this list \u2014 and complete control over all email addresses within the abandoned domain \u2014 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.<\/p>\n

How serious a problem is this?<\/h2>\n

\nDylan Ayrey, the researcher who discovered this Google OAuth vulnerability (and the previous issue with phantom accounts<\/a>), 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

According to Ayrey\u2019s 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.<\/p>\n

Who\u2019s responsible, and what can be done?<\/h2>\n

\nAyrey 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 \u201cno fix needed\u201d and labeled as \u201cfraud or abuse\u201d!<\/p>\n

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.<\/p>\n

According to Ayrey, Google promised to fix the vulnerability in Google OAuth, but didn\u2019t specify when or how exactly they plan to do this. Therefore, the problem with the \u201cSign in with Google\u201d 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\u2019s no one to hold accountable for the security of these accounts anymore.<\/p>\n

The wise move here would be for companies to take preventive measures in advance. However, very few startups seriously plan for their own demise \u2014 let alone what will happen afterward.<\/p>\n

Fortunately, defending against this Google OAuth vulnerability is relatively straightforward. There are two non-mutually exclusive options:\n<\/p>\n