Attack on Google OAuth using abandoned domains

[harlan4096]

A vulnerability in Google OAuth allows attackers to access accounts of defunct organizations through abandoned domains.
 
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.

Continue Reading...