Millions of Accounts Vulnerable due to Google’s OAuth Flaw ◆ Truffle Security Co.

Millions of Americans could have their data stolen today due to the lack of Google’s “Sign in with Google” authentication flow. If you’ve worked at a startup before — especially one that’s closed — you might be vulnerable.

I got this error by logging into accounts I don’t own, and Google responded that this behavior was ‘working as intended’.

The Root Cause: How Domain Ownership and OAuth Intersect

Here’s the problem: Google’s OAuth login does not protect against someone buying a failed startup domain and using it to recreate email accounts for former employees. And while you can’t access old email data, you can use those accounts to log into all the different SaaS products the organization uses.

I purchased just one of these defunct domains and discovered that logging into each of the following services gave us access to old employee accounts:

• ChatGPT

• Slack

• think

• Zooming

• HR systems (with social security numbers)

• More…

The most sensitive accounts include the HR system, which contains tax documents, pay stubs, insurance information, social security numbers, and more.

Interview platforms also contain sensitive information about candidate feedback, offers, and rejections.

And of course, chat platforms contain direct messages, and all kinds of sensitive information that an attacker would never have access to.

What is the Scale of this Vulnerability?

Here are some facts:

• 6 million Americans now work for tech startups.

• 90% of tech startups eventually fail.

• 50% of those startups rely on Google Workspaces for email.

I checked the Crunchbase startup database and found over 100,000 domains available today for buying from failed startups.

If every failed startup averaged 10 employees over their lifetime and used 10 different SaaS services, we’re talking about access to sensitive data from more than 10 million accounts.

To understand the issue, let’s take a quick look at Oauth:

When you use the “Sign in with Google” button, Google sends the service (for example, Slack) a set of claims about the user.

An example of a default set of claims.

These claims usually include:

• hd (hosted domain): Specifies the domain, for example, example.com.

• email: The user’s email address, for example, (email protected).

The service provider (eg Slack) will use one or both of these claims to determine if the user can log in.

The HD claim can be useful to say “Anyone at example.com can log into the example.com workspace”

And the email claim is used to log users into their specific account.

Here’s the issue: If a service (for example, Slack) relies only on these two claims, Domain ownership changes are no different than what Slack looks like. If someone buys the domain of a defunct company, they inherit the same claims, giving them access to old employee accounts.

Why Doesn’t SUB Identifier Resolve This?

I am working with some of these downstream providers to find a solution. There is a documented unique user identifier (the sub claim) which in theory can prevent this issue, but in practice, it is not reliable.

According to a staff engineer at a major tech company:

“The sub claim changed to about 0.04% of logins from Log in with Google. For us, that’s hundreds of users last week”.

Because the sub The claim is inconsistent, it cannot be used to uniquely identify users – leaving services that rely on email and hd claim.

Suggested Fixes

To solve this issue, Google can implement two immutable identifiers within its OpenID Connect (OIDC) claims:

1. A unique user ID that does not change over time.

2. A unique workspace ID tied to the domain.

I opened a vulnerability ticket in Google’s security vulnerability disclosure program that outlined the problem, presented a proof of concept account takeover, and suggested adding these claims to the OIDC.

Google immediately closed the issue as “Unfixable”:

They also classified the issue as a “Fraud and abuse” issue, rather than an Oauth/login issue.

I thought this was the end of the story, but 3 months later, they reopened my ticket (after my Shmoocon speech was accepted), paid a $1337 bounty, and said they were working on repairs.

Here’s the timeline:

• Reported by Google – Sep 30, 2024

• Marked by Google as beyond repair – Oct 2, 2024

• Talk accepted at Shmoocon – Dec 9, 2024

• Google reopens issue – Dec 19, 2024

I asked for details on what the fix would look like (for example, will they add two new OIDC claims?), but there was no information they could share.

What can Downstream Providers do to mitigate this?

At the time of writing, there is no fix.

To the best of our knowledge, downstream providers (eg Slack) cannot protect against this vulnerability unless Google adds two proposed OIDC claims.

As an individual, once you are off-boarded from a startup, you lose your ability to protect your data in these accounts, and you are subject to whatever fate happens in the future of startup and domain.

Many providers, which allow you to join the general workspace if the domain matches, regardless of your email, will return the entire list of users.

This list of users can be returned to the Google workspace, and can be used to fill in all old employees, which can be used repeatedly to log in to multiple accounts.

Second Concerns: Resetting the Recovery Password

You may be wondering: What about users who use a username and password instead of Google SSO? Can attackers reset passwords via email from an old domain?

Short answer: Yes, this is another risk, but there are mitigations:

1. Startups should disable password-based authentication and implement SSO over 2FA.

2. Service providers should require additional verification (eg, SMS code or credit card verification) for password resets.

These steps reduce password-based risk, but do not address the issue of domain-based OAuth vulnerabilities.

CONCLUSION

There is a fundamental weakness in Google’s OAuth implementation. Without immutable identifiers for users and workspaces, domain ownership changes will continue to compromise accounts.

Google’s last engagement on this issue is promising, but until a fix is ​​implemented, millions of Americans’ data and accounts remain vulnerable.

Here is a link to the Shmoocon talk (it starts around 5:30:00):