Hey everyone! Exciting times, huh? So, you stumbled upon an LFI vulnerability that unveiled some magical Auth0 credentials. Now, what’s the next move? In this blog post, I’ll guide you through some paths of compromise and, of course, the journey from credential discovery to compromising networks.
Before jumping right into it, let’s quickly talk about what Auth0 is and how its credentials can be leaked.
Auth0 serves as an advanced system for authentication and authorization, ensuring secure access to applications and APIs. It simplifies the login process for developers through features like single sign-on (SSO) and multi-factor authentication (MFA). Compatible with a wide range of technologies and platforms, Auth0 can secure both web and mobile applications. It functions as a unified solution, streamlining identity management and aiding developers in implementing single sign-on (SSO) without hassle.
Discovering Auth0 credentials can be as straightforward as exploiting Local File Inclusion (LFI) vulnerabilities. In this example, we’ll demonstrate how an attacker might leverage a vulnerable PHP script to obtain Auth0 credentials.
Consider a scenario where the application stores Auth0 credentials in a configuration file named config.php:
Now, let’s assume there’s a vulnerable PHP script, say vulnerable.php, that includes files based on user input:
If an attacker manipulates the user input by navigating to vulnerable.php?file=config.php, the code will include the config.php file, exposing the Auth0 credentials.
Now, this is a basic example, but you get the point. LFI, RCE, heck, even SSRF in some cases can leak the Auth0 credentials. Understanding these vulnerabilities sets the stage for the next crucial step: What do you do now that you have these Auth0 credentials?
Now that we have valid Auth0 credentials, its time to perform reconnaissance! First we need to generate a valid JWT token so we can interact with the Auth0 API. Take a look at the following code snippet:
This function will use the client_id and client_secret identified by the LFI bug and return a valid valid JWT token — our golden ticket into the Auth0 API.
Now lets start dumping all the things!
The function above will run through all the Auth0 management API endpoints and dump the information into JSON files. These JSON files encapsulate a wealth of Auth0 information, with the details outlined in the Auth0 management docs.
Lets start diving into a few of these JSON files.
Note: Even through I created a sandbox to perform this research, I'm still redacting the uuids
This JSON file exposes all the information of about 50 users in the org (implement pagination if you want all of them). The information includes full name, IP address and last login:
As remote work is the normal situation today, the exposure of employee IP addresses is a larger privacy risk than it was when everyone shared the same office IP. With the last_ip leaked above, an attacker would be able to dox a company’s employees, location-based spear phish them, or even perform direct denial of service attacks against them!
This JSON file shows the Auth0 logs! Here we can see what clients are authenticating and where from. If you had multiple clients logging into a SaaS product, this is where you would find those logs.
Now we are getting into the fun stuff! Auth0 client grants are a way to delegate permissions or scopes to a client application so that it can request access tokens with specific capabilities. In Auth0, a client grant is essentially a predefined set of permissions that can be assigned to a client
Take this client grant for example. My application (identified by the client_id 7N7HF2987HFSUD79HF) would have the ability to request access tokens with specific scopes when interacting with https://salescrm.prodefense.io.
That being said, this client grant would give an attacker access to read payment methods, clients, and transactions within the specified audience (https://salescrm.prodefense.io). Pretty cool right!? Now lets take it a step further….
If you have made it this far, you are in for a treat. There's a ugly truth about Auth0, if your client_id and client_secret is compromised, so are your connections.
In the realm of Auth0, connections serve as configurations that dictate how users can log in to your applications. Each connection represents either an identity provider (IdP) or a username-password database where user credentials are securely stored. Auth0 offers extensive support for various identity providers including Google Workspace, Microsoft Azure AD, and Ping Federate, not to mention the flexibility of custom databases.
Now, imagine this: What if we could reverse the perspective and explore potential vulnerabilities in the environments of clients who should have authorized access to your own environment? Let’s look at the JSON below to unravel this concept further.
In this scenario, the domain above customer.com functions as a connection of ProDefense. Essentially, any user within the Azure AD environment at customer.com has the green light to log in to my application using the app_domain login.prodefense.io.
Note: The specific applications a connection can login to is dictated by Auth0 configuration settings.
Additionally, this connection gives ProDefense the authority to oversee customer.com users through the api_enable_users. Now, before we dive into the technical weeds, it’s crucial to highlight that these connections come equipped with a client_id and client_secret — an aspect can attacker will exploit.
Now that we’ve found the client_id and client_secret of the connection, let’s take control of the connection’s Azure environment. Here’s my step-by-step process, laying out the exploits and actions an attacker can execute.
To infiltrate the Azure AD environment, we need to generate an access token by logging in with the stolen credentials.
The function above gives us an access token, handy for working with the Microsoft Graph API. Think of the Graph API as Microsoft’s tool belt — it’s a versatile, RESTful web API that lets us connect with a TON of Microsoft 365 services. While there are too many services to list here, if you’re eager to explore and dump all the info (similar to the Auth0 script), check out this API documentation: Microsoft Graph Explorer. And hey, if you create a script, feel free to share it with me! 😊
To gather intelligence on Azure users, we can use the following Python function:
This function fetches all Azure users and stores the data in a JSON file for further analysis like so:
While this data isn't all that useful in terms of escalation, its still pretty impactful that a connections users can be retrieved from a leaked set of Auth0 credentials.
What now? We’ve successfully compromised the connections network, gaining access to Azure resources, sensitive data, and system configurations. The possibilities are vast — we can do anything within the Azure environment. Picture a sysadmin somewhere sweating bullets over a new user being created with administrative privileges. Or the company’s financial information, once securely stored in One Drive, now exposed on BreachForums — potentially leading to insider trading and a cascade of detrimental consequences. Yikes…
To those of you who read this in its entirety, thank you! I hope you find it valuable. Feel free to reach out on LinkedIn or Twitter for a chat. Peace!
We are a team of pentesters, securing the connectivity of devices and the software that controls them.
