BOOK THIS SPACE FOR AD
ARTICLE ADDuring our comprehensive testing of the application, my friend Kareem AlSadeq (https://kareemelsadek.github.io) and I discovered and exploited this vulnerability.
In the realm of application security, authentication mechanisms play a pivotal role in safeguarding user data. Leveraging robust authentication services like Auth0 can significantly enhance security. However, misconfigurations within these services can introduce critical vulnerabilities. In this article, we delve into a recent discovery of a severe vulnerability related to Auth0 misconfiguration in an application we were testing. This write-up aims to shed light on the issue, the steps taken to identify and exploit it.
Auth0 is a widely used authentication and authorization platform that simplifies the implementation of secure login systems. It supports various authentication methods, including social logins like Google, Facebook, and others. Social logins offer users the convenience of signing up and logging in using their existing social media accounts, reducing the friction of creating new credentials.
However, the integration of social logins requires meticulous configuration to ensure that user data is handled securely. Misconfigurations can lead to vulnerabilities such as account linking issues, where multiple accounts inadvertently reference the same user data.
The application in question limited user registration exclusively to Google accounts through the “Signup with Google” option. This singular authentication pathway streamlined the user experience but also concentrated the authentication process within a single framework — Auth0.
During testing, we identified a significant vulnerability stemming from a misconfiguration in Auth0. The application exhibited unintended behavior when users attempted to create accounts using the same email address through different authentication methods. Specifically, creating an account via Google and then attempting to register with the same email using email and password led to unexpected account linking or data retrieval issues.
There are two primary reasons for this behavior:
1. User Data Retrieval Based on Email:
The application fetches user data based on the email present in the Access_token or Id_token. Consequently, when a user attempts to create a new account with an existing email, the system retrieves and returns data from the original account.2. Account Linking
Developer Misconfiguration:The unintended account linking occurs due to misconfigurations made by the developers within the Auth0 setup. Specifically, when a user attempts to register multiple accounts using the same email address through different authentication methods (e.g., signing up with Google and then with email and password), the system erroneously links these accounts as one. This linkage happens because the developers did not implement the necessary safeguards or utilize the appropriate tools to manage account associations correctly.Auth0 Extension for Account Linking:
Auth0 provides an Account Linking extension designed to handle the association of multiple authentication methods to a single user profile securely. This extension ensures that account linking is performed intentionally and securely, preventing accidental or unauthorized linking of user accounts. By leveraging this extension, developers can manage how and when accounts are linked, thereby mitigating the risk of data conflicts and enhancing the overall security of the authentication system.
Detailed Steps to Identify and Exploit the Vulnerability
We began by creating an account using the available “Signup with Google” option. This established the initial user profile within the application’s authentication system.
Next, we attempted to create a new account using the same email address (testacc2399@gmail.com) and a password (testA@123) through the public sign-up endpoint associated with Auth0. However, encountered an issue where the dbconnection parameter was either incorrect or not linked to the application, preventing successful account creation.
To bypass the misconfiguration, I employed a technique to identify the correct dbconnection tied to the application under test. Once I obtained the dbconnection name, we crafted a specific HTTP POST request using Burp Suite:
POST /dbconnections/signup HTTP/2Host: auth.test.ai
Content-Length: 224
Content-Type: application/json
Origin: https://auth.test.ai
Referer: https://auth.test.ai/
{
"client_id": "XXXXXXXXXXXXXXXXXXXX",
"email": "testacc2399@gmail.com",
"password": "testA@123",
"connection": "app-prod-users",
"credential_type": "http://auth0.com/oauth/grant-type/password-realm"
}
Important Note: For the request to be successful, both the Host and client_id must be accurate.
Using the identified dbconnection, we submitted the above request. The application accepted the request, creating a new account associated with the same email (testacc2399@gmail.com). This indicated that the system allowed multiple accounts with the same email across different authentication methods, leading to potential data conflicts.
To confirm whether the two accounts were linked or if the system fetched data based on the email, we performed the following actions:
Accessing the Account via Email and Password:Initial Challenge: Initially, we faced a challenge: the application did not provide a direct page or interface to log in using email and password. The only available option was to log in via Google.Overcoming the Challenge: To overcome this, we manipulated the authorization endpoint URL to force the authentication method to email and password:https://{auth.app.xx}/authorize?client_id={Clientid}&response_type=token&connection={dbconnection}&prompt=login&scope=openid%20profile%20phone&redirect_uri={redirect-uri}