Home Exploiting nOAuth Vulnerability in Azure AD Applications
Post
Cancel

Exploiting nOAuth Vulnerability in Azure AD Applications

on Oct 24, 20232023-10-24T00:00:00+01:00
Updated Nov 122024-11-12T13:05:08+00:00 3 min read

image

Introduction

The nOAuth vulnerability was originally discovered by Descope security team and impacts Microsoft Azure AD applications configured to use OAuth.

Essentially the vulnerability is a design flaw that can lead to account takeover when the application has “Login with Microsoft” button. An attacker may forge its own email address to match a victim address and as a consequence, the application will let the attacker sign in and impersonate the victim user.

For instance, Grafana patched this vuln and assigned CVE-2023-3128. In this demo FusionAuth application will be used as a Proof-of-Concept to demonstrate how to exploit the nOAuth vulnerability. FusionAuth is an Identity and Access Management (IAM) platform designed to simplify the implementation of secure authentication and authorization systems for web and mobile applications.

Setup Azure AD

Start by creating 2 distinct tenants in Azure AD.

  1. noauthuser.onmicrosoft.com - Legitimate tenant
  2. noauthattacker.onmicrosoft.com - Attacker’s tenant

image

Create one user on each tenant (victim & attacker respectively):

image

Register an application in Azure legitimate tenant. It will be used to configure a new IdP (OpenID) in FusionAuth.

image

Note that callback URL http:// is only allowed because the hostname is localhost. In reality, it would be mandatory to use TLS/HTTPS. The application is configured as multi-tenant for cross-tenant exploitation. Even though single-tenant apps are less likely to be exploited, they might still be vulnerable. As an exercise, reproduce the steps below and combine all the possible configurations for app types in Azure AD (single-tenant, multi-tenant, multi-tenant + personal accounts) & issuer URL authorities (such as <tenant>, common, organizations and consumers).

Keep the client ID and client secret. Additionally, assign the respective user (victim) to access this application in Azure Enterprise Applications menu. Follow the docs for step-by-step procedure.

Setup the Application

Run the FusionAuth application as a Docker container for convenience. Follow the Docker installation guide.

image

The local FusionAuth app setup will look more or less like this:

image

Admin web interface will be available at http://localhost:9011/admin/setup-wizard once the Docker containers are up and running. Proceed to configure a local administrator and then create a new IdP (will use OpenID in this case).

image

image

image

Once it has been configured, the “Login with Azure AD” button should appear below.

image

image

image

After signing in, the error message indicates the user has been successfully registered but doesn’t have access to FusionAuth administrator web interface.

For demonstration purposes we’ll assign victim@noauthuser.onmicrosoft.com to FusionAuth admins group since we don’t have any 3rd-party application configured in FusionAuth.

image

Going back to the panel as local admin admin@fusionauth.local we can assign the victim user to the admins group.

image

Finally when we login once again as victim, we will be displayed the FusionAuth admin web interface.

image

image

Exploitation

Now we have a working FusionAuth instance configured to authorize users from Azure AD.

The attacker might change his contact email address field in Azure AD to match the victim address. Once he tries to login, the application will merge the account and let the attacker login into the victim account.

To exploit the nOAuth vulnerability:

image

image

image

Vulnerability was successfully exploited and user attacker is now authenticated as victim💥.

Impact

  • Authentication bypass: arbitrary users may log in into the application(s).

  • Account takeover: the attacker can impersonate and compromise accounts of legitimate users.

  • Privilege escalation: a regular user can escalate to a more privileged account.

Mitigation

Microsoft suggests the use immutable fields as user identifier, such as sub (subject) or oid (object id) claims, as they can’t be modified or tampered. The use of upn is discouraged as it might change over time but its use does not leave the application vulnerable. A new optional claim xms_edov was introduced to indicate wheter the email domain owner has been verified.

Also enabling strong authentication mechanisms such as multi-factor authentication (MFA) helps prevent this vulnerability from being successfully exploited. Refer to nOAuth blog by Descope and official Microsoft advisory for more recommendations.

Additionally, FusionAuth already addressed this issue and made security enhacements (#2423 and #2424). You should update your FusionAuth instance to keep up with latest features.

Disclosure Timeline

References

oauth openid noauth vulnerability azure ad microsoft entra fusionauth id auth authentication authorization poc exploit
This post is licensed under CC BY 4.0 by the author.
Recent Update
Contents

Obfuscating Rust Binaries using LLVM Obfuscator (OLLVM)

Pwning a Legacy Enterprise Application Server - Sybase EAServer

© 2024 . Some rights reserved.

Powered by Jekyll with Chirpy theme.