Are millions of accounts vulnerable due to Google's OAuth Flaw?

This article is a rebuttal to Truffle Security's post on Millions of Accounts Vulnerable due to Google's OAuth Flaw. (Alt link) Even more ridiculous might be that their post got picked up by no small number of news outlets that all should be ashamed of themselves, far too many to actually link in this post.

Are millions of accounts vulnerable due to Google's OAuth Flaw?

In a true Betteridge's law of headlines fashion, the answer is a resounding No. Which explains why Google ignored this vulnerability in the first place:

The TL;DR of the source article claims that due to the nature of how Google OAuth works, "Millions of Americans' data and accounts remain vulnerable". It relies on the nature of Domain Ownership.

The Claim

Google’s OAuth login doesn’t protect against someone purchasing a failed startup’s domain and using it to re-create email accounts for former employees.

Domains are the root of trust* for many businesses. At Authress we rely on authress.io to establish trust with our customers, just as at your business you rely on your domains for your customers. This is "Root of Trust" with an asterisk because in reality the root of trust lies with the domain authority, the domain registrar, and the issuer of your TLS certificates for HTTPS encryption. But that is outside of the scope of this article.

The claim in the original article is that it is OAuth and specifically Google's OAuth that is at fault and nothing else. And that somehow domain ownership is linked to the exposure of customer data.

Background

Gaining access to your trusted domain is one way in which attackers attempt to circumvent your security strategy and compromise your users. If malicious attackers can utilize your domain to trick your users, then they can impersonate your business and steal their personal information, bank accounts, and credit card numbers. This is the basis for why phishing is popular today. As a matter of fact phishing is so popular because compromising a domain is incredibly hard, and is usually executed through a DNS Poising attack. The strategy behind phishing is to purchase alternative domains that look and feel like the valid domain as the next best thing (Typosquatting). These facsimiles exist for exactly that reason.

Besides using separate domains attackers will often also attempt Subdomain takeovers which is a mesh between domain compromise and using an alternative domain.

However, in this case, attackers cleverly will attempt to use your existing corporate domain after you believe you are done with it. The expected flow involving Google Workspace's OAuth looks something like this:

1. You buy a domain for your company, let's call it yourcompany.com.
2. Sign up for an Employee Identity Solution (IdP) that provides OAuth, there are actually many solutions here, Google Workspace, Okta, Microsoft Entra ID, Ping Identity
3. Then your employees use that identity solution to sign into to a third party product such as Stripe, AWS, PostHog, etc...
4. Lastly you give critical data to that product, business sensitive information, like your pets' birthdays.
5. That third part applications saves that data because they like data very much.

Identity

When you log into your favorite third part application, there needs to be an identifier sent from the Employee Identity Solution to that third party. The Third Party trusts your chosen identity solution as well as that identifier. Here is an example token generated by Google Workspace:

{
      "iss": "https://accounts.google.com",
      "sub": "210169484474386",
      "iat": "1736946817",
      "exp": "1736996817",

      "email": "[e-mail]",
      "hd": "yourcompany.com",
      "name" : "Warren Parad",
      "given_name": "Warren",
      "family_name": "Parad",
      "locale": "en"
}

The identifier in the token is the sub claim with the value 210169484474386. This is my User ID (Note: this is not actually my user ID, feel free to do with it as you wish, but I made it up for the purposes of this post.)

Your third party application uses this sub property to uniquely identify you, and then authorize you to your company's sensitive cat photos.

The Vulnerability

Now, imagine that you close your Google Workspace account, because your company goes bankrupt (This frequently happens because as much as we want to believe companies are successful through hard work, the truth is that it is actually luck). Along with your Google Workspace Account will likely be your expired domain yourcompany.com, unless you have some secret prayers that one day you will be able to sell it instead of expiring worthless. Let's assume that yourcompany.com domain is now available for anyone to purchase. By purchasing that domain, an attacker can create a new Google Workspace account, in hopes to gain access to those exact same third parties you had used for your business.

This actually isn't even the first time something like this has been attempted, and frequently it works due to hard-coded solutions in many applications. In a cruel twist of fate, here is a great example of being able to compromise the attackers themselves because they had a used a application which relied on expired trusted malicious domains.

This actually doesn't happen with Google OAuth. When you close the google workspace account, the User ID with the value 210169484474386, ceases to exist. This is what Google is confirming by closing the original bug report. An attacker recreating the Google Workspace account is unable to generate the same sub again. So that even if an attacker attempted to create a new Google Workspace from the expired and unclaimed domain yourcompany.com, the sub would be different and your third party application would reject access.

What's the problem?

The issue is some third party applications decided not to use the sub claim. The author of the Truffle Security post suggests that this is due to some bug in the Google OAuth implementation, but the reality is OAuth has nothing to do with this problem. The failure to use the sub claim stems from this shiny property in the identity token called email. In the original token above you can see the users email there [e-mail].

A third party that utilizes this email address to uniquely identify users means that they are allowing malicious attackers who compromise employee identity providers through expired domains to take over your account. There are lots of reasons they do this, but primarily it is because they like the way the @ looks in their database.

That means this is actually a vulnerability on the third party application side. Any third party application that allows users to log in with just an email are inherently creating a vulnerability in their own platform and setting themselves up to expose their (ex-)users data.

Vulnerability review

So, actually this has nothing to do with Google Workspace at all. And an attacker can actually use any email provider to perpetrate this attack:

1. Buy an expired domain and register your domain in a new email provider
2. ...
3. Profit

Although in this case the ... is simply: Attempt a password reset or magic-link authentication for that third part application. In a similar attack a vulnerability was utilized by attackers through an email support system.

1. The real vulnerability

This shows us that OAuth and Google Workspace aren't actually the source of the issue here, it's the third party application. I've frequently condemned Magic-Link based Authentication, and while there are some areas where it unfortunately still provides value, it isn't worth it if you care about security. The fact that the email is provided by Google is just unfortunate. Emails are helpful for identify where to send messages to users who want emails, but it should never be used anywhere related to security.

2. Dismantling the solution

The original article suggests that adding yet two more additional claims/properties to the User Identity Token, will solve the problem. One claim isn't good enough, let's have three!

Given that the problem is that third party applications are ignoring the already existing sub claim. I find it to be quite the naïve suggestion. No amount of additional claims will prevent third parties for incorrectly substituting in their beliefs where actual security is necessary. This is just an unfortunate truth. We see this every day and it is one of the reasons we built Authress in the first place. The defaults that exist in SDKs, frameworks, protocols, and standards, are just not enough for people to do the right thing, explicit investment had to be made in prevention of doing the wrong thing.

3. Third Party Application responsibility

The last part of the problem is that the author in the original article claims

What can Downstream Providers do to mitigate this? At the time of writing, there is no fix.

Which just isn't true. Third part applications that allow email based authentication, must delete user data after account deactivation. Once you stop paying for a third part application, that data must be deleted and never exposed again unless you resume access and the third party verifies identity. I prefer taking guidance from the NIST 800-63A.

As a user you too, can do something to. If you have sensitive data, you could decide not to use any third party applications, unless of course you actually pay for it and ensure that you delete your account before your company stops using that application. If you give someone your data, they have it, assume the worst. We can and should put more responsibility onto these third party application services who are utilizing unsafe email addresses and often SMS numbers of authentication. As long as you treat email auth as a valid solution, everyone will forever be just as culpable as third parties who rely on it. Use OAuth and SAML for your business authentication and make sure to provide sufficient secure options to the users of the products and services you build.

Consumer exposure

The original article also seems to conflate risks to consumers directly. There is nothing about this vulnerability that directly affects consumers. Sure there are impacts to consumers regarding data privacy, but the vulnerability discussed in this article doesn't include them.

That's because as a consumer when you use an application, that application stores data in their primary databases. When the company that manages that application fails, both their databases and their bank accounts are empty. You don't have to worry about that data. But you do have to worry about who they gave your data to. You have to worry about that irrespective of the company, or its state. Many companies out there have started to be investigating because of just that. This is the whole premise of the Facebook's Cambridge Analytica scandal. Facebook gave user personal data to Cambridge Analytica when they should not have access to it. Facebook didn't even need to be bankrupt for there to be a problem.

The core of the issue isn't the data you have given to the company, the problem is data the they have shared to others. But no amount of praying or technological solutions is going to fix that. The problems proposed in this article regarding the domain vulnerability in question are related to the data given to the third party applications secured with by the company's corporate domain. The data that is most vulnerable in these circumstances is the business-to-business relationships. Billing information, strategic partnerships, invoices, business strategies, these are at risk.

For example, at Authress we use Stripe, sometimes. In stripe we have customer account information, including customer emails for sending invoices. If you are using Stripe or another payment provider, then chances are you too are storing some sort of customer data in Stripe. If your company goes bankrupt, and attacker uses the domain vulnerability to do a password reset on your Stripe account, they will now have access to your old company's customer invoice and email data. You probably don't care, but you should.

Conclusion

So I think we can say definitely, no there aren't millions of people at risk with this vulnerability. Sure your data is at risk, it always had been at risk, it always will be at risk, but Google's OAuth implementation, while problematic, honestly doesn't change anything at all. You can continue to file your data deletion requests with your third party application providers when you don't think they are doing too well. But if they aren't doing that well, I sincerely doubt they are deleting your data, let alone deleting your data from their third party providers. I don't know what will become of the original published articles or Google's response, but I had felt strongly to first educate regarding the problem rather than lambast Google Workspace over their responses. The claim by the original author that millions of accounts vulnerable due to Google's OAuth Flaw is just irresponsible.

Curious about this and worth discussing more:

Join the community