This post outlines six of the most common techniques, commonly used by attackers and how they were utilized over the last few years.
Not till long ago, getting user credentials by an attacker was equivalent to getting access to all their data, so cred-theft was a thing. Now with MFA and SSO, an admin should sleep better at night… But an attacker needs access more than she needs the creds themselves, and now, with the common use of OAuth apps and SaaS-based platform integrations, they can actually have it without stealing end-users passwords.
Github recently reported that data was downloaded from dozens of organizations as an attacker was using stolen third-party OAuth integrations tokens to access GitHub customers’ repos.
Stealing an OAuth token will get an attacker the exact access a user or an admin granted to a third-party app. For an attacker this makes an access token more lucrative than a user/password set: stealing a token bypasses multi-factor authentication, as it was already satisfied.
There are several ways an app token may be compromised – Phishing for OAuth code grant, using Open Redirects, using client-side or browser attacks, or good old malware stealing it directly off an endpoint. An in-depth review is a subject for its own post. But here is a good read on how token theft is researched and conducted with excellent historical attack references, along with some funny dirty dancing references.
Device Authorization Grant is defined in RFC 8628 as follows:
“The OAuth 2.0 Device Authorization Grant (formerly known as the Device Flow) is an OAuth 2.0 extension that enables devices with no browser or limited input capability to obtain an access token”
The Device Flow enables devices with no browser or limited input capability to obtain an access token. Apps for Smart TVs and media streamers often use it to authenticate.
A user trying to authenticate with Netflix for example will get a QR code on his TV or a short URL to go to and enter a code the device got from the identity platform such as Azure AD or Apple to prove he is authenticating and Authorizing the device App from his mobile device.
This flow is easier for an attacker to execute a token theft as several protections are missing from the flow. Auth Grant works without entering the app client secret, as it is meant for devices whose code is exposed publicly and can be extracted from the device. Without a client secret, anyone can ask for a device authorization code on behalf of any app that allows this flow.
Another protection missing is the redirect URL approval by the identity platform. In the standard OAuth flow, an attacker would need to get an OAuth token from the user who is redirected after the authentication succeeds. In Auth Grant flow, the attacker is polling the identity platform for authentication approval after the real user is authenticated.
The missing protections make it easy for an attacker to phish the user to authenticate using an attacker-generated code and obtaining the access token from the identity platform.
In July 2019, Amnesty reported human rights defenders in the Middle East and North Africa were being targeted by a similar attack. The subsequent demo was illustrated in-depth at DEFCON 2021
Phishing a user to install a malicious App is the most straightforward way of obtaining OAuth access tokens. Malicious apps are created by an attacker who lures the target to click the consent link and approve the app's access to the user's data. This attack gives complete control to the attacker and doesn’t require the malicious infrastructure that common phishing attacks demand. The attacker tricks the user to consent to the app's permission and redirects back to the attacker with the access token. As the attacker created the phishing app, the attacker controls the allowed redirect links and the permission scopes requested.
Attackers are advertising tools to automate such attacks:
These types of attacks target hundreds of enterprises and recently compromised high-profile users running across multiple campaigns. consent phishing emails is on the rise according to Microsoft:
So, to mitigate the risk, on Oct 2020 Microsoft started verifying Apps publishers, marking verified publishers in the consent page.
Sending the OAuth token from the identity platform to the app is defined in RFC 6749 as follows:
“After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client. The authorization server redirects the user-agent to the client's redirection endpoint previously established with the authorization server during the client registration process or when making the authorization request the redirection endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3.”
OAuth Redirect URL flow allows different types of redirect attacks in which users click a legitimate URL of identity platform domains like https://login.microsoftonline.com/ but after login, they are redirected to a malicious page on an attacker-controlled domain.
A straightforward implementation of this attack would be to create an App on Microsoft and register the OAuth redirect link to an attacker-controlled domain. The link should be legitimate at first until the publisher is verified and can be changed later. The attacker then should send the user a phishing link to the App consent page on https://login.microsoftonline.com, after a user approves the new App the user will be redirected automatically to the attacker-controlled page without this malicious URL ever being present in the phishing email, which effectively bypasses typical email security filters….
Different implementations by identity platforms are vulnerable to other redirect scenarios even without user consent for the App, for example by redirecting on consent cancellation or error in the parameters of the App.
In the notorious Solarigate attack, which was a nation-state supply chain attack involving multiple stages and implants, novel methods were used to keep stealthy persistence in the organization network. One of the interesting observations was the need to log in to O365 without maintaining mobile device access to bypass multi-factor authentication.
“The threat actor managed to bypass MFA through the theft of Chrome browser cookies. The threat actor accomplished this by using administrative accounts to connect via SMB to targeted users, and then copy their Chrome profile directories as well as data protection API (DPAPI) data”
https://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/
Furthermore, to bypass the future need for MFA validation, the attackers added their own x509 keys as secrets to previously authenticated applications to allow a remote connection that completely bypasses the application and doesn’t require MFA. This was also down to newly created service principals with high privileges. The attacker logging in using this application secret is very hard to detect and distinguish from standard app authentication and behavior.
Throughout 2021 the attack continued in a campaign named StellarParticle. In this campaign, the threat actor connected to the victim’s Office 365 tenants, gathered information on existing apps (Service Principals), and compromised built-in Azure AD Applications, company-created Applications, and created their own applications.
Google Scripts is a scripting platform developed by Google for lightweight application development in the Google Workspace platform. While under the hood these are really Apps that are automatically created for each of these scripts and authenticated and authorized using Google’s Identity Platform and OAuth.
A very effective worm was developed using the allowed capabilities of the scripts and infected 1 million users. The worm asked for consent with a few randomized apps confusingly named “Google Docs”, while the user consented to permissions of this App the App queried all the contacts and sent them the same phishing email requesting to open the phishing script, posing as a shared document sent by a contact.
While Google has since added different levels of protection including warning of unverified apps that are using sensitive scopes, some of these protections were later bypassed as was recently demonstrated on defcon 29 by Snapchat red team lead Matthew Bryant.
To sum up, we have gone over the top OAuth attacks from account take over by token theft and a couple of phishing attack types and moved to a use case of an OAuth app as a persistent point inside the organization post-attack. We ended with an abuse sample of OAuth to bypass security protections and malicious use of app scripts to create a worm.
