Introduction to OAuth
Let us assume that you use an application called photoboost to edit your photos. And those photos are hosted on Google cloud application: Google Photos. To be allowed to access your Google Photos, photoboost asks you to authorize it and gives you a prompt to sign in using your Google account. If you are not logged in to your Google Account, you provide your Google account credentials to sign in and photoboost can now access your Google Photos.
Taking a step back, let us think about what happened here. A user authorizes a third party application to access a resource (photos) that she owns on a trusted cloud application (Google) by authenticating herself with Google. The third party application is authorized to access only user's photos and not any other resources like user’s email or any other documents. Also, the user’s account credentials are shared with her trusted cloud provider. All this happens due to a protocol called OAuth.
OAuth is a framework that allows a user to grant limited access to the resources that they own on one website, to another website, without having to expose their credentials. Granting permission, or consent, is referred to as delegated authorization. You authorize one application to access your data, or use features in another application on your behalf, without giving them your password.
OAuth Roles
In any OAuth 2.0 flow we can identify the following roles:
Resource Owner: The entity that can grant access to a protected resource. Typically this is the end-user.
Resource Server: The server hosting the protected resources. This is the API you want to access.
Client: The application requesting access to a protected resource on behalf of the Resource Owner.
Authorization Server: The server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization.
OAuth High Level Flow
The Application (Client) asks for authorization from the Resource Owner in order to access the resources.
Provided that the Resource Owner authorizes this access, the Application receives an Authorization Grant. This is a credential representing the Resource Owner's authorization.
The Application requests an Access Token by authenticating with the Authorization Server and giving the Authorization Grant.
Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application.
The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token.
Provided that the Access Token is valid, the Resource Server serves the Application's request.
Token Types
1.Access Token
An access token is a string representing an authorization issued to the client. Access tokens are granted by authorization server and used by client application to access protected resources. They have limited permissions and are valid for a short time.
2. Refresh Token
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires. Issuing a refresh token is optional at the discretion of the authorization server.
Consent Phishing
Now that we are familiar with what OAuth and Access tokens are, let us talk about their abuse. With increased cloud applications usage and shift to working from home, the attack surface has expanded even more. While we are all aware of the attacks focused on users, such as email phishing and credential compromise, application-based attack such as consent phishing, is another attack vector to look out for.
In consent phishing, attackers trick users into granting a malicious application access to sensitive data or other resources. Instead of trying to steal the user’s password, an attacker is seeking permission for an attacker-controlled application to access valuable data.While each attack tend to vary, the core steps are usually like this:
1. An attacker registers an application with an OAuth 2.0 provider, such as Azure Active Directory.
2. The application is configured in a way that it looks trusted, for example it will contain the name of a product that is popularly used in your environment like Google Docs or Microsoft Onedrive .
3. Attackers distribute the link to his malicious application to the users, which he can do through conventional email-based phishing.
4. When the victim clicks on the link, they will be shown a consent prompt similar to what we see in this image here.
5. As we can see in the image, the user is asked to give an application some high risk permissions like reading user's mail, sending mail on user's behalf and writing user mailbox settings.
6. If the user clicks accept, the attacker controlled application will be granted permissions to access sensitive data on behalf of the user.
7. The applications get an authorization code, which it will redeem for an access token, and potentially refresh token.
8. Access token is then used to make API calls on behalf of the user.
Detection
So, we understand that attackers can use application-based attacks to access sensitive data on behalf of the user, but how do we detect such types of attacks, if and when they happen so that they can be responded quickly and efficiently?
To detect OAuth Access Tokens abuse, there are certain types of events that Security Analysts can monitor.
Monitor for applications that are granted high severity permissions like User.ReadWrite, which will allow the application to not only read and write all users' full profiles but also allows the app to create and delete users as well as reset user passwords on behalf of the signed-in user.
Monitor for applications that are sending permission requests to too many users in a short time, which may not be a very common occurrence.
Monitor for privilege escalation actions such as role creations or policy modifications.
The above event types are usually logged into the audit logs for OAuth providers. In Azure they are called Azure Audit logs - which store all events related to any change done for any resource like users, groups, applications, roles and policies in Azure Active Directory. In Azure Audit logs, following events can be monitored for identifying suspicious activity related to applications:
Add delegated permission grant
Add OAuth2PermissionGrant
Consent to application
Add app role assignment to service principal
Add policy to service principal
Azure Audit Sample Log
This is a sample log of Azure Audit log for Consent to application event type. This event was generated when a user granted a permission to an application. The permission name is listed in the Scope value, which can be extracted from TargetResource field. The username who granted the application is listed in the field: InitiatedBy. The application name to which the permission is granted, is available in TargetResource. Some other important fields include "Time" of the event and the "Result" of operation.
Detection Query
Although the detection query shown here, is written in KQL on Azure Sentinel, but with minor syntax changes it can be written for other SIEM platforms like Splunk and ELK.
In the first statement, we define a list of high risk permissions, which are not usually requested for or granted. That list is given a name as watchedpermissions which contains User.Read.All, User.ReadWrite.All and other sensitive permissions. The next statement in the query defines the table name in which we are interested in searching the events for. In this case, it is AuditLogs.
We then check if the event name is Consent to application, and if the scope or the permission for that application matches the permissions which we have previously defined in our list for high risk permissions.
When you run this query, it should show you all the applications that are granted high risk permissions in your environment. You can either use it for threat hunting or configure a security alert to proactively alert you whenever any application is granted a high risk permission, indicating potential OAuth access token abuse.