{"id":50286,"date":"2024-01-18T12:19:06","date_gmt":"2024-01-18T17:19:06","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=50286"},"modified":"2024-01-18T12:19:06","modified_gmt":"2024-01-18T17:19:06","slug":"vulnerability-in-google-oauth","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/vulnerability-in-google-oauth\/50286\/","title":{"rendered":"Google OAuth and phantom accounts"},"content":{"rendered":"

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.<\/p>\n

Alas, such blind faith is dangerous: the \u201cSign in with Google\u201d option is seriously flawed. In December 2023, researcher Dylan Ayrey at Truffle Security <\/a>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.<\/p>\n

What\u2019s wrong with Google OAuth sign-in<\/h2>\n

The vulnerability exists due to a number of factors. First: Google allows users to create Google accounts using any email \u2014 not just Gmail. To sign in to a company\u2019s 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<\/em>.<\/p>\n

The \"Sign In with Google\" button on slack.slack.com <\/a>

Google OAuth is used by various work platforms in many organizations. For example, here\u2019s the \u201cSign In with Google\u201d button on slack.slack.com<\/p><\/div>\n

Second: Google (along with a number of other online services) supports what is known as <\/a>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.<\/p>\n

For example, when registering an account with an online bank, one could specify the address alanna+bank@example.com<\/em>; when registering with a communication service provider \u2014 alanna+telco@example.com<\/em>. Formally, these are different addresses, but emails will arrive in the same mailbox \u2014 alanna@example.com<\/em>. And because the contents of the \u201cTo:\u201d field differ, incoming messages can be handled differently<\/a> with the use of certain rules.<\/p>\n

\"Signing<\/a>

Example of signing in to Slack with Google using an alias email address with a plus sign<\/p><\/div>\n

Third: in many work platforms such as Zoom and Slack, authorization through the \u201cSign In with Google\u201d button uses the domain of the email address specified when registering the Google account. So, in our example, to connect to Example Inc.\u2019s workspace example.slack.com<\/em>, you need an @example.com<\/em> address.<\/p>\n

Finally, fourth: it\u2019s possible to edit the email address in a Google account. Here, sub-addressing can be employed by changing, say, alanna@example.com<\/em> to alanna+whatever@example.com<\/em>. That done, a new Google account can be registered with the address alanna@example.com.<\/em><\/p>\n

This results in two different Google accounts that can be used to sign in to Example Inc.\u2019s 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\u2019re unable to delete or disable this account. Thus, a laid-off employee could still have access to corporate resources.<\/p>\n

Exploiting the Google OAuth vulnerability and gaining entry without initial access<\/h2>\n

How feasible is all this in practice? Entirely. Ayrey tested the possibility of exploiting the vulnerability in Google OAuth in his own company\u2019s 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.<\/p>\n

\"Exploiting<\/a>

An example of exploiting the vulnerability in Google OAuth to grant Slack access to an account registered to an email sub-address. Source<\/a><\/p><\/div>\n

Note that, besides Slack and Zoom, this vulnerability affects dozens of lesser-known corporate tools that use Google OAuth authentication.<\/p>\n

In some cases, attackers can gain access to an organization\u2019s cloud tools even if they didn\u2019t initially have access to the corporate email of the target company. The Zendesk ticketing system, for example, can be used for this purpose.<\/p>\n

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\u2019s 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\u2019s Zoom and Slack without having initial access to its resources.<\/p>\n

How to protect against the Google OAuth vulnerability<\/h2>\n

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<\/a>). Ayrey additionally reported the problem to some online services, including Slack.<\/p>\n

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 \u201cSign In with Google\u201d option.<\/p>\n

And, naturally, it\u2019s a good idea to guard against possible penetration deeper into the organization\u2019s information infrastructure through platforms like Slack, which means monitoring what\u2019s going on in said infrastructure. If your company\u2019s information security department lacks the resources or expertise for this, deploy an external service such as Kaspersky Managed Detection and Response<\/a>.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Google OAuth allows to create phantom Google accounts \u2014 uncontrollable by corporate Google Workspace administrators.<\/p>\n","protected":false},"author":2726,"featured_media":50290,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3051,3052],"tags":[2672,359,2141,22,639,1146,3933,3744],"class_list":{"0":"post-50286","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-accounts","11":"tag-authentication","12":"tag-business","13":"tag-google","14":"tag-oauth","15":"tag-risks","16":"tag-slack","17":"tag-zoom"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/vulnerability-in-google-oauth\/50286\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/vulnerability-in-google-oauth\/26967\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/vulnerability-in-google-oauth\/22282\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/vulnerability-in-google-oauth\/29636\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/vulnerability-in-google-oauth\/27138\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/vulnerability-in-google-oauth\/36822\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/vulnerability-in-google-oauth\/27368\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/vulnerability-in-google-oauth\/33154\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/vulnerability-in-google-oauth\/32777\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/google\/","name":"Google"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/50286","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=50286"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/50286\/revisions"}],"predecessor-version":[{"id":50291,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/50286\/revisions\/50291"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/50290"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=50286"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=50286"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=50286"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}