Chaining Auth0 Misconfigurations for 1-Click Account Takeover

Deep Dive into a Subtle Auth0 Misconfiguration Leading to Full Account Takeover

---

Introduction

This post documents a critical 1-click Account Takeover (ATO) vulnerability discovered in an application using Auth0 for authentication.

By chaining:

• A hidden, enabled Username-Password-Authentication connection,

• A Cross-Origin Authentication configuration, and

• A custom account-merging implementation during token exchange

I was able to gain full access to a victim’s primary account (originally created via social logins or Passwordless) with only one click from the victim.

This vulnerability highlights how subtle misconfigurations in identity providers like Auth0 can lead to serious security risks.

---

Inside Auth0: A Technical Breakdown

Let's understand two important things to grasp how the vulnerability works.

1. Connections and User Profiles

In Auth0, each authentication method (social login, passwordless, username/password, etc.) is represented as a connection.

• Each connection creates a separate profile in the Auth0 tenant, even if the email is the same.

• Profiles are identified by a user_id that includes the connection name.

2. Cross-Origin Authentication

While reviewing the authentication flow of the application, I noticed that the user-facing login options are limited to social logins and passwordless authentication. However, a deeper inspection revealed that the application also leverages Auth0’s Cross-Origin Authentication feature, specifically via the POST /co/authenticate endpoint. This endpoint allows credentials (username and password) to be sent directly to the Auth0 tenant (e.g., auth.nykros.com), and in response, it issues authentication cookies — including the auth0 session cookie, which represents the logged-in user session.

---

Vulnerability Overview

The ATO was made possible by three chained weaknesses:

1. Hidden Username-Password-Authentication Connection

   • The tenant allowed signup via email/password through Username-Password-Authentication, even though this option was not visible in the app’s UI.

     

2. Account Merging Logic

   • During token exchange, the app linked accounts based on email, effectively treating the attacker’s newly created password account as equivalent to the victim’s primary account.

     

3. Cross-Origin Authentication

   • Enabled co/authenticate allowed the attacker to log in using their chosen password, bypassing UI-based restrictions and acquiring a full Auth0 session.

---

Detailed Exploitation Walkthrough

This section demonstrates each step with raw HTTP requests captured in Burp Suite.

Step 1: Discover Hidden Connections

The app had no visible way to register or log in using email and password. However, I discovered an Auth0 endpoint exposing the valid and available database connections — which is required to craft direct API requests.

Step 2: Create an Account with Victim’s Email

Using the /dbconnections/signup endpoint, an attacker creates a password-based account for the victim’s email.

Request:

POST /dbconnections/signup HTTP/2
Host: auth.nykros.com
Content-Type: application/json

{
  "client_id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "email": "vic@nykros.com",
  "password": "AttackerPass123!",
  "connection": "Username-Password-Authentication",
  "user_metadata": {}
}

Response:

{
  "_id": "XXXXXXXXXXXXXXXXXXXXXXX",
  "email": "vic@nykros.com",
  "email_verified": false
}

Auth0 sends a verification email. If the victim clicks the link, the attacker can then log in to their account without being prompted for email verification.

It’s highly likely the victim will click the link because their account was originally created using Passwordless or Social Login methods, neither of which requires email confirmation during signup. When the attacker registers a password-based account with the same email, Auth0 triggers a generic verification email that simply states, “Since you have an account, please verify your email.” Given that the victim has never seen a verification step before and the message appears legitimate, they are very likely to comply and click the link, unknowingly verifying the attacker-controlled account.

---

Step 3: Login via Cross-Origin Authentication

With the victim’s email verified, the attacker sends credentials to /co/authenticate.

Request:

POST /co/authenticate HTTP/2
Host: auth.nykros.com
Origin: auth.nykros.com
Content-Type: application/json

{
  "client_id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "username": "vic@nykros.com",
  "password": "AttackerPass123!",
  "credential_type": "http://auth0.com/oauth/grant-type/password-realm",
  "realm": "Username-Password-Authentication"
}

Response:

{
  "login_ticket":"VkB82KWVEEQ8MYA4I6PQD-kNc0U_1bPx",
  "co_verifier":"leEMJtSeoWf3UHuwLmVUpJKOEl72D86O",
  "co_id":"O4GhzYzSKWQs"
}

The attacker receives an Auth0 session cookie:

Step 4: Full OAuth Authorization Flow

The attacker loads the target login page and uses Burp Suite to intercept and replay login requests, injecting the stolen auth0 session at key points in the login flow (e.g., /authorize, /continue, /authorize/resume requests).
By maintaining the attacker-controlled session through these steps, the application fully authenticates the attacker as the victim.

• Result:
  The attacker gains full access to the victim’s account on the application, despite the victim never setting a password or explicitly enabling password-based login.

---

Finally

Thanks for reading! If anything wasn’t clear or you’d like more details, feel free to reach out — I’d be happy to explain further.