Google OAuth vulnerability can expose sensitive data of failed startups

In December 2023, researcher Dylan Ayrey at Truffle Security uncovered a vulnerability in the “Sign in with Google” flow. This made the news again last week due to a new report by Truffle Security. The vulnerability can affect the employees of all failed startups that used Google SSO.

The attack can unfold as follows:

1. Purchase a failed startup’s domain.
2. Re-create email accounts for former employees.
3. Use these accounts to log into all the different SaaS products the organization used.

While re-creating an old employee e-mail account does not provide access to the data stored by Google, it might provide access to certain SaaS products, some of which (e.g., HR systems) may contain sensitive data like social security numbers, tax documents, insurance information, and more.

How the vulnerability works

When you use “Sign in with Google” to log in an app, Google sends a set of claims about the user, based on which the app can decide if the user should be allowed to log in or not.

These claims look something like this:

	
{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926
}
	

This JSON object tells us several things:

• The user’s email is jsmith@example.com
• The user’s email has been verified
• This information has been issued by Google - https://accounts.google.com
• The user’s unique ID is 10769150350006150715113082367
• The user belongs to a Google Cloud organization with the domain example.com
• And more

When a service provider relies only in the hd and email claims to allow access, then if the domain changes hands they won’t realize it. And that’s when the problems begin.

‍Google’s documentation is very clear that the email claim should never be used to uniquely identify users, and that sub should be used instead.

However, according to Truffle Security, the sub claim is unreliable since “it changes in about 0.04% of logins from Log in with Google”. According to Google, there is no evidence to support this claim and developers should use sub as a unique and immutable identifier.

The proposed fix

Truffle Security’s recommendation to Google is to introduce two new immutable OIDC claims:

• A unique user ID that doesn’t change over time.
• A unique workspace ID tied to the domain.

According to Google, the sub claim is the immutable identifier that the Truffle Security is calling for and developers should use that instead of the email. They also urge service providers to wipeout all customer data when an account is closing, and the owners of failed startups to properly close their domains.

Conclusion

Google is working on a fix but we don’t know what that is or when it will be available.

According to Google, any data leaks that may occur in this situation are the result of data not being erased by the startups when shutting down operations. Customers, they say, should properly close their domains following these instructions to make this type of issue impossible.

While this holds some merit it’s also clear that we cannot base our security practices on the expectation that people will be thorough (especially when going through a devastating event like a failed startup) and do always what they are supposed to do. In fact more often than not, they will do things they shouldn’t and won’t do things they should. Regardless, we all have a responsibility and must do whatever we can to keep our users safe.