Why using Google OAuth in work applications is unsafe
Credit to Author: Alanna Titterington| Date: Thu, 18 Jan 2024 17:19:06 +0000
Organizations sometimes rely on Google OAuth to authenticate users. They tend to assume that Google is all-powerful and wise, so its verdict on whether to grant access to a user is taken as read.
Alas, such blind faith is dangerous: the “Sign in with Google” option is seriously flawed. In December 2023, researcher Dylan Ayrey at Truffle Security discovered a rather nasty vulnerability in Google OAuth that allows employees to retain access to corporate resources after parting company with their employer. There are also ways for a total stranger to exploit this bug and gain access.
What’s wrong with Google OAuth sign-in
The vulnerability exists due to a number of factors. First: Google allows users to create Google accounts using any email — not just Gmail. To sign in to a company’s Google Workspace, email addresses with the domain name of the company are commonly used. For instance, an employee of the hypothetical company Example Inc. might have the email address alanna@example.com.
Google OAuth is used by various work platforms in many organizations. For example, here’s the “Sign In with Google” button on slack.slack.com
Second: Google (along with a number of other online services) supports what is known as sub-addressing. This lets you create alias addresses by appending a plus sign (+) to an existing mail address, followed by whatever you like. One use for this could be for managing email flows.
For example, when registering an account with an online bank, one could specify the address alanna+bank@example.com; when registering with a communication service provider — alanna+telco@example.com. Formally, these are different addresses, but emails will arrive in the same mailbox — alanna@example.com. And because the contents of the “To:” field differ, incoming messages can be handled differently with the use of certain rules.
Example of signing in to Slack with Google using an alias email address with a plus sign
Third: in many work platforms such as Zoom and Slack, authorization through the “Sign In with Google” button uses the domain of the email address specified when registering the Google account. So, in our example, to connect to Example Inc.’s workspace example.slack.com, you need an @example.com address.
Finally, fourth: it’s possible to edit the email address in a Google account. Here, sub-addressing can be employed by changing, say, alanna@example.com to alanna+whatever@example.com. That done, a new Google account can be registered with the address alanna@example.com.
This results in two different Google accounts that can be used to sign in to Example Inc.’s work platforms (like Slack and Zoom) through Google OAuth. The problem is that the second address remains invisible to the corporate Google Workspace administrator, so they’re unable to delete or disable this account. Thus, a laid-off employee could still have access to corporate resources.
Exploiting the Google OAuth vulnerability and gaining entry without initial access
How feasible is all this in practice? Entirely. Ayrey tested the possibility of exploiting the vulnerability in Google OAuth in his own company’s Slack and Zoom, and found that it is indeed possible to create such phantom accounts. Non-expert, regular users could take advantage of it too: no special knowhow or skills are needed.
An example of exploiting the vulnerability in Google OAuth to grant Slack access to an account registered to an email sub-address. Source
Note that, besides Slack and Zoom, this vulnerability affects dozens of lesser-known corporate tools that use Google OAuth authentication.
In some cases, attackers can gain access to an organization’s cloud tools even if they didn’t initially have access to the corporate email of the target company. The Zendesk ticketing system, for example, can be used for this purpose.
The idea is that the service allows submitting requests via email. An email address with the company domain is created for the request, and the request creator (that is, anyone) is able to view the contents of all correspondence related to this request. It turns out that it’s possible for a user to register a Google account with this address and, through the request, get an email with a confirmation link. They can then successfully exploit the vulnerability in Google OAuth to sign in to the target company’s Zoom and Slack without having initial access to its resources.
How to protect against the Google OAuth vulnerability
The researcher notified Google about the vulnerability several months ago through its bug bounty program; the company recognized it as an issue (albeit of low priority and severity) and even paid out a reward (of $1337). Ayrey additionally reported the problem to some online services, including Slack.
However, no one is rushing to fix the vulnerability, so protection against it seems to be on the shoulders of company employees who administer work platforms. Fortunately, in most cases, this poses no particular problem: it suffices to disable the “Sign In with Google” option.
And, naturally, it’s a good idea to guard against possible penetration deeper into the organization’s information infrastructure through platforms like Slack, which means monitoring what’s going on in said infrastructure. If your company’s information security department lacks the resources or expertise for this, deploy an external service such as Kaspersky Managed Detection and Response.