A steadily growing phishing trend involves phishing emails which attempt to modify your OAuth permissions. Simply clicking on one Allow button or hitting ENTER by mistake can significantly and semi-permanently allow a whole lot of maliciousness.
This article will discuss phishing emails that attempt to exploit OAuth, explain what OAuth is, and then discuss what you need to do to reduce risk of malicious compromise.
Example Phishing Email
I got this phishing email a few weeks ago (shown below).
After a bunch of subsequent clicks and redirects, eventually I was led to a Microsoft O365 login (shown below):
It’s a real O365 login. It is logging me into my O365 account.
Note that the URL has oauth2 in it (shown larger below).
It is linking to and using OAuth, which I will cover in more detail in the next section below. This is a real, legitimate login and anything I type in there will NOT be stolen by the phisher. But what happens next after I successfully authenticate is what the hacker is really after. After I successfully login, the website/service hosting the phisher’s maliciousness will communicate with my OAuth provider and request more permissions (example shown below), which I will be prompted to approve.
An unwary user might click on Accept or hit ENTER, which would grant the malicious website/service those requested permissions.
The default “allow” is unfortunate. Since the days of Microsoft Vista, Microsoft has strived to make any default security choice the user faces to always default to the safest alternative of the proposed choices. They fail here. Perhaps it’s an issue with OAuth itself; but regardless, any user being tricked into accepting the permission request would be giving the phisher access to every document he or she has access to (stored by the current service and any other services sharing the same OAuth account). This is true for not only their own documents, but documents of others that they have been given access to. Full Access means the phishers can read, copy, delete, and malicious modify the documents at will. They can read the victim’s contacts and send malicious documents pretending to be from the victim and their organization, all because the victim gave them permission to read his or her contacts and change his or her mailbox settings. Well, all the victim did was click the default suggested button or hit ENTER. OAuth automation did the rest.
Note: Microsoft published a warning about OAuth phishing a few weeks ago.
It is important that admins and everyone they help be aware of the dangerous of malicious OAuth misuse.
Intro to OAuth
OAuth stands for Open Authorization. It is a widespread framework and standard which allows a single authenticated sign-on to work across multiple participating apps/sites/services. In the corporate world, we call this single-sign-on (SSO). The average Internet user has nearly 180 websites they authenticate to. That’s a lot of separate login names and passwords for anyone to remember. Since the beginning of the Internet as we know it today, multiple companies and groups have been trying to create a global, pervasive, SSO-experience for Internet users.
Microsoft previously tried multiple times before with Microsoft Passport and Microsoft Account, but much of the world didn’t like trusting a single company to provide global credentials for everyone. An open source group called OpenID tried to create a de-centralized standard where a single user credential could be used to login to multiple participating websites. Microsoft even created an app for that called Microsoft CardSpace that was in Windows for a few editions. It worked well, but each user credential was stored only on a single device and couldn’t be easily moved or shared with additional devices (e.g., laptop, cell phone, etc.).
Everyone was looking for an open, decentralized, multi-device, Internet-SSO standard which the world could rally around. They settled on OAuth and OpenID Connect (an updated version of OpenID). After decades of previous global failures, OAuth and OpenID Connect (usually just consolidated and called OAuth now) finally won the world over, likely because of its early support by Facebook, Twitter, and other 800-lb gorilla firms. Here’s how it works.
You can register an account with one or more OAuth credential/identity providers. These providers tend to be the big vendors, like Google, Facebook, Apple, Twitter, Microsoft, GitHub, etc., but nearly any website or service can become an OAuth credential/identity provider. In most cases, you simply sign up with a provider you like, say Google or Facebook, and they automatically enable you to use their credential with OAuth. There is usually a feature you can turn on and off, although it’s usually not called OAuth (which would make it easier to figure out). Here’s an example of what it is called and described as by Google (see below).
You can create as many OAuth accounts as you like at each OAuth credential/identity provider (usually). Each identity is a separate OpenID Connect account, and the identity, authentication information, and authentication of the account is handled solely by the one provider. OAuth credential/identity providers do not share OAuth accounts and cannot see the other provider or user’s information at other providers. Each OAuth credential/identity provider has its own list of available permissions which can be associated with a particular user’s identity and may be requested and assigned to one or more apps/sites/services.
Then participating websites can register and use a particular OAuth credential/identity provider’s service and allow users to login to their app/site/service using their shared OAuth identity instead of having to create a separate, new identity. You have probably been using OAuth for a long time without being aware that you were using OAuth.
Whenever you go to login to a new website and instead of creating a new account login, you can just “Login with Gmail” (see example below) or “Login with Facebook”, etc. what you are likely using is OAuth. Below is an example of me logging into Dropbox using Google as my OAuth credential/identity provider.
When you click on the Sign up with Google button, you get another prompt (see below) to verify which identity registered with that OAuth provider you want to use (you could have multiple user accounts with that provider).
Usually, the participating app/site/service will list all the available OAuth credential/identity providers it previously registered with, so you may see more than one provider option (as exampled below).
TikTok is a great example of a bunch of possible OAuth providers shown at once (shown below):
Once you select a provider and an active identity, you will get another account confirmation (as shown below).
If you recently authenticated to your OAuth credential/identity provider, the participating app/site/service will NOT ask you to authenticate again. If you haven’t recently authenticated to the selected OAuth provider for the selected account, the app/site/service may take you to the original OAuth credential provider site and have you login again. But you won’t be asked to provide authentication credentials or MFA to the additional participating OAuth sites. OAuth is about delegated access using a single authentication, not re-authenticating again over and over at different sites. An OAuth authenticated login is essentially your verified driver’s license. Once you have it, you (or really an application on your behalf) can hand it over to any participating OAuth app/site/service.
Be careful whenever you login to or register for a new app/site/service for the first time, as they can request permissions related to your account and provider. You need to pay attention any time any app/site/service requests permissions, whether or not the site is intentionally malicious or not. Many times, the permissions they request are insane for what they claim they want to do. For example, many legitimate websites, like Twitch (shown below) request your Facebook Friends list. If you simply say OK, it gives Twitch a list of your friends. Why?
Here’s another example (shown below) of the Nest login prompting me to allow additional access to my Google Home app.
During registration at a new site, sometimes you can modify the requested permissions. They will often request “required” permissions and have “optional” permissions. For example, in the Twitch registration above, you can click on Edit This (reshown below) and modify the requested permissions.
In this example, I choose Edit This and then removed the ability for Twitch to get my email address and list of friends. I recommend always reviewing the list of requested permissions and removing those that you can if you don’t agree with them. Or cancel the registration if you don’t agree with the requested permissions.
The Twitch and Nest permission requests aren’t that bad. But I’ve seen supposedly friendly apps request permissions, like all access to all documents or the ability to send messages on my behalf, that are just crazy for the service I thought I was getting. Pay attention. And if something seems squirrely for the service it is providing, don’t approve the permissions.
If you approve the additional OAuth linking (and permissions), you can see the new app/site/service added to your list of allowed apps/sites/services (see example below) which you have allowed your OAuth credential/identity provider to share when requested.
Managing Your OAuth Settings
It’s important to stay on top of your allowed OAuth dependencies and permissions. You should periodically review your allowed OAuth dependencies and permissions on a regular basis, typically at least once a quarter. How you find your allowed OAuth dependencies and permissions varies by OAuth credential/identity provider. Here’s an example of managing your OAuth settings with Google.
- Sign into Gmail like you normally do.
- Click on your account icon in the upper right menu.
- Select Manage Your Google Account
- Choose Security in the left-hand menu
- Click the Signing in with Google option underneath the Signing in to other sites subsection. You may need to page down a few times to find this section.
- Once you select this, you will see all the apps/sites/services (example shown below) which have been allowed to use your OAuth provider identity account to log you in.
You should periodically review the allowed OAuth apps, sites, and services, and remove those you do not approve. You can do this by clicking on the previously approved app/site/service to expand it, and then click on the Remove Access button (as shown below).
You’ll need to repeat this across all your OAuth credential providers (e.g., Google, Facebook, Twitter, Github, etc.) to be inclusive. This can be complicated by the fact that not everyone knows which OAuth providers they registered with or which apps, sites, or services they linked to which OAuth credential provider. Check all that you can think about.
Note: Not all linked apps, sites, and services are readily understandable. For example, in the figure above, the linked account of project-939659317702 refers to the Grupz rental site. It would be nice if it said Grupz, but it doesn’t. The developer who set up the Grupz rental website registered with another name and didn’t update it. If you don’t recognize the linked app, site, or service, you probably want to remove it. It can possibly cause some service interruption issues (or you may even lose some involved content), so don’t do it lightly. But when in doubt, you can’t take the risk. Remove the linkage.
Summary
Be aware that phishing attacks may use OAuth in an attempt to modify your OAuth provider account permissions and included documents. If you don’t pay enough attention, you may get tricked into allowing malicious access to your OAuth sites and credentials. Maliciousness with OAuth can be used to bypass accounts protected by passwords and multi-factor authentication.
You should periodically check your OAuth provider accounts to ensure that only the sites and services you want to have access to your OAuth provider account have that access and permissions, then remove those you no longer approve of. If you think you may have accidentally previously allowed OAuth permissions to be assigned to a sketchy email/app/site/service, go check your OAuth provider accounts now.
Feel free to share this document with your friends and co-workers to explain the risks and recommendations around OAuth.
Here's how it works:
