Your Identity Is Mine: Techniques & Insights From OS Identity Providers Research

Your Identity Is Mine: Techniques & Insights From OS Identity Providers Research

Speakers: Aul, Vulnerability Researcher, Cyber clubs

Conference: Nullcon

YouTube: https://www.youtube.com/watch?v=FtoaQHYmUD0

Overview

In this compelling Nullcon presentation, "Your Identity Is Mine: Techniques & Insights From OS Identity Providers Research," Aul, a vulnerability researcher at Cyber clubs, unveils critical security vulnerabilities discovered in two widely-used open-source identity providers (IDPs): Keycloak and Authentik. The talk delves into the intricacies of web race conditions, object-relational mapper (ORM) exploitation for information leakage, and privilege escalation techniques that could allow an attacker, or even another authenticated user, to seize control over digital identities and the IDP itself.

Aul’s research highlights the profound impact such vulnerabilities can have on an organization's security posture, given the central role IDPs play in managing user authentication and authorization across numerous integrated systems. By dissecting both successful exploits and "rabbit holes" — failed attempts that offered valuable learning — the presentation offers a candid look into the often-complex world of vulnerability research. This talk is crucial for developers, security professionals, and system administrators who rely on or manage identity infrastructure, providing actionable insights into securing these foundational components against sophisticated attacks.

The core message underscores a chilling reality: an attacker, or even a malicious insider, could potentially compromise vast swathes of an organization's digital landscape by exploiting weaknesses in its identity provider. Aul's work serves as a stark reminder of the continuous need for rigorous security testing and a deep understanding of underlying architectural patterns to prevent identity theft and unauthorized system access at scale.

Background

▶ Watch: Introduction: Your identity could be mine (0:00)

The talk begins by establishing a foundational understanding of Identity Providers (IDPs). An IDP is a system responsible for managing digital identities, encompassing everything from user creation and authentication to enforcing password policies. By integrating with an IDP, developers offload the complex task of user management, password hashing, and policy enforcement, thereby streamlining application development and enhancing security.

A significant portion of the presentation focuses on web race conditions, a common class of vulnerability in multi-threaded web environments. Web servers often process multiple requests concurrently, using multiple threads to handle simultaneous user interactions. A race condition occurs when these concurrent threads interact with shared data in an unintended sequence, leading to unexpected application behavior. A well-known type is the limit overrun race condition, where an attacker can bypass a business logic limit, such as redeeming a gift card multiple times or exceeding a transfer balance. Aul illustrates this with a "check-then-update" logic: if a system checks a condition (e.g., "is discount code used?") and then updates the state ("set code to used"), a race window exists where two concurrent requests could both pass the check before the update is committed, thus bypassing the intended limit.

To test for these race conditions, Aul introduces the single packet attack, a technique pioneered by PortSwigger. This method involves encapsulating multiple HTTP requests within a single TCP packet. While seemingly counter-intuitive for HTTP/1.1 (where data is streamed), it is made possible by HTTP/2's multiplexing feature. HTTP/2 frames messages into binary data and assigns a unique stream ID to each frame, allowing multiple requests and responses to be sent simultaneously over a single connection. The single packet attack leverages this by sending multiple request frames in one go, increasing the likelihood of hitting a race window on the server. Tools like Burp Repeater and Turbo Intruder facilitate this attack by allowing users to group requests and send them in parallel within a single TCP packet.

The second major technical area explored is Object Relational Mappers (ORMs). ORMs are programming techniques that bridge the gap between relational databases and object-oriented programming languages. They allow developers to interact with database records as programming objects, abstracting away raw SQL queries. Aul uses Django, a Python framework, as an example, where models define the structure of stored data. While ORMs simplify development, their improper use can introduce vulnerabilities, particularly ORM-based information leaks, akin to SQL injection but exploiting ORM-specific patterns.

Key Findings

▶ Watch: Practical: Using Burp Repeater for single packet attacks (5:58)

Aul's research led to several significant findings across both Keycloak and Authentik, demonstrating diverse vulnerability classes and their potential impact.

In Keycloak, the primary finding revolved around web race conditions. While an initial attempt to bypass email verification during user registration failed due to database transactions, Aul successfully demonstrated a limit overrun race condition in the API key client creation functionality. This allowed an attacker to bypass an administrator-imposed limit on the number of clients an API token could create, enabling the creation of multiple unauthorized clients beyond the set threshold. This vulnerability highlights how critical business logic, even when seemingly protected, can be circumvented under concurrent conditions.

For Authentik, the discoveries were twofold and particularly severe. The first was a sensitive information leak allowing any user, without authorization, to download private keys associated with certificates configured in Authentik. These certificates are crucial for the IDP's HTTPS server and for signing user tokens. The only prerequisite was knowing the internal UUID of the certificate, which Aul found could be leaked through an ORM-based information leak. This ORM vulnerability allowed an attacker to use a regex oracle against the event log API to extract the certificate's UUID character by character, effectively leading to the full compromise of the IDP's signing capabilities.

The second Authentik finding was a privilege escalation vulnerability. A non-admin user could create and edit their own API tokens. By manipulating the token update request, specifically by injecting and modifying the user object within the JSON payload, an attacker could change the token's associated user ID to an administrative ID (e.g., 6). This resulted in the user gaining an admin API key and subsequently full administrative control over the Authentik system. Both Authentik vulnerabilities were confirmed, assigned CVEs, and subsequently fixed by the Authentik security team.

Technical Deep Dive

▶ Watch: HTTP/2 streams and multiplexing for single packet attacks (7:55)

The technical deep dive into Keycloak and Authentik illuminates the specific mechanisms of the discovered vulnerabilities.

Keycloak: Web Race Conditions and Transactional Integrity

Aul's investigation into Keycloak began by analyzing the database structure, noting that user creation and email verification flags were maintained in separate tables. This separation initially suggested a potential race window: register a user and immediately log in before the required_action table is updated with an email verification flag. The code snippet for user creation first creates the user, then later updates the required_action table, defining a clear race window.

To exploit this, Aul attempted a single packet attack with concurrent registration and login requests. However, this attempt failed. Debugging with breakpoints and ORM logs revealed the crucial missing piece: database transactions. Keycloak explicitly disabled auto-commit for user creation, encapsulating the INSERT INTO users and INSERT INTO required_action statements within a single atomic transaction. This meant the database was updated in one shot; either both operations succeeded, or neither did. This transactional integrity effectively prevented the race condition from being exploited for unauthorized user creation and login.

Despite this initial failure, the understanding of race conditions proved valuable. A successful race condition was demonstrated in Keycloak's client creation API. An admin can create an API key, limiting the number of clients a developer can create (e.g., two clients). The developer uses this token to create clients via the Keycloak API. The vulnerability here was a classic "check-then-update" race. When a client creation request arrived, the system checked the remaining client count, allowed creation if within the limit, and then decremented the count. By sending multiple client creation requests simultaneously using the single packet attack (via Burp Repeater's "send group in parallel" feature), Aul could bypass the limit. The demo showed creating five clients with a token limited to two, resulting in a negative remaining count in the API response. This confirmed the race window existed because the check and update were not atomic for this specific business logic.

Authentik: ORM Leaks and Privilege Escalation

The Authentik research started with certificates, which serve two critical functions: securing the HTTPS server and signing tokens. Admin users could upload, generate, and download certificates and their private keys. The initial speculation was whether a non-admin user could download a private key. Aul discovered that any user, without authorization, could download a private key if they knew its internal UUID.

The challenge then became how to leak this UUID. After exploring various API endpoints, Aul encountered research by Elam on ORM-based information leaks. This vulnerability class exploits insecure use of ORMs, particularly when user-supplied data is passed to methods like filter using the unpacking operator (**). This can lead to data leakage similar to SQL injection but through the ORM layer.

A promising instance was found in the event log API, accessible by any user. This API stores timestamps and values representing event occurrences. Crucially, when an admin uploaded a certificate, the certificate's UUID was logged in the event log (though the key data was masked). This provided an oracle: if a log entry was found matching a query, a non-zero value was returned. Aul exploited this by crafting a regex query within the API request. By systematically testing characters in the regex, it was possible to leak each successive character of the certificate UUID. Once the full UUID was obtained, the private key could be downloaded, allowing an attacker to impersonate the Authentik server or sign arbitrary user tokens, granting access to systems trusting Authentik.

The privilege escalation in Authentik was equally impactful. As a non-admin user, Aul observed the functionality to create and edit API tokens. When inspecting the token update request, an interesting JSON key, user, was noticed in the response. This led to the hypothesis: what if the user attribute could be modified during a token update? By sending a PUT request to update the token and including "user": 6 (where 6 was identified as the administrator user ID in the system), Aul successfully updated the token. The demo showed that the modified token then granted full admin access to the system, allowing actions like setting an admin password and logging in with elevated privileges. This vulnerability stemmed from insufficient validation and authorization checks on sensitive attributes within the token update API endpoint.

Demo / Proof of Concept

▶ Watch: Keycloak: Race condition attempt on user creation (failed) (9:50)

Aul provided demonstrations for the successful exploits, showcasing the practical implications of the vulnerabilities.

For the Keycloak race condition, the demo illustrated the API key client limit bypass.

1. An admin user created an access token with a strict limit: only two clients could be created using this token.
2. The token was provided to a "developer" (the attacker).
3. The attacker used Burp Proxy to intercept a legitimate client creation request.
4. This request was sent to Burp Repeater.
5. Within Repeater, the single client creation request was duplicated four times, resulting in five identical requests.
6. These five requests were grouped and sent "in parallel" using Burp's single packet attack feature.
7. Upon inspecting the Keycloak system, five new clients were found to have been created, despite the token's limit of two. The API response for the token also showed a negative remaining client count, confirming the successful bypass.

The Authentik sensitive information leak demo focused on the UUID extraction via the ORM regex oracle:

1. A standard API request to the event log endpoint was shown, which typically returns a non-zero value if a log entry exists for a given timestamp.
2. The request was modified to include a regex query targeting the key_data field within the event log.
3. By iteratively adjusting the regex to guess characters (e.g., ^a, ^b, ^c, then ^ab, ^ac, etc.), Aul demonstrated how a non-zero response indicated a correct character match.
4. This process, though not shown in its entirety due to time constraints, effectively allows an attacker to leak the full UUID character by character. Once the UUID is known, the private key download (which was confirmed to be unauthorized) becomes trivial.

The Authentik privilege escalation demo was particularly impactful:

1. A normal, non-admin user logged into Authentik.
2. The user's session cookies were extracted to make API calls.
3. The user created an API token for themselves, which normally has an expiration date and description.
4. The request to update this token was intercepted.
5. The intercepted PUT request's JSON payload was modified to include "user": 6, where 6 represented the admin user ID.
6. The modified request was sent, and a valid response indicating the token update was received.
7. To verify the escalated privileges, the API token was then used to call the set_password API endpoint for the user ID 6.
8. Finally, logging in with the user ID 6 and the newly set password granted full admin access to the Authentik system, demonstrating complete control.

Defensive Implications

▶ Watch: Debugging and understanding race condition failures (11:00)

The vulnerabilities uncovered in Keycloak and Authentik highlight several critical areas where defenders must focus their efforts to secure identity providers and related systems.

1. Atomic State Changes for Business Logic: For developers, it is paramount to ensure that any API endpoints making state changes, especially those tied to business logic limits (like client creation counts or discount redemptions), are atomic. This often involves using database transactions to group related operations (check and update) so they either fully succeed or fully fail. If database transactions are not feasible, critical sections with proper locking mechanisms in the application code can prevent race conditions. The Keycloak user creation failure due to transactions serves as a prime example of effective defense.

1. Rigorous Access Control on Sensitive Endpoints: The Authentik private key leak underscores the need for stringent access restrictions on sensitive endpoints. Any API that allows downloading or accessing critical assets like certificates, private keys, or configuration files must enforce robust authorization checks, ensuring only genuinely authorized administrators can perform such actions. Simply requiring an internal ID (like a UUID) is insufficient if that ID can be leaked.

1. Secure Handling of API Tokens and User Attributes: The Authentik privilege escalation demonstrates the danger of direct manipulation of token objects or related user attributes via API calls. Developers should avoid directly exposing or allowing modification of sensitive user identifiers (like the user ID associated with a token) through API endpoints unless absolutely necessary and with meticulous validation. Input validation must be comprehensive, rejecting unexpected or unauthorized fields in update requests. Tokens should be treated as opaque identifiers, and their internal attributes should be immutable or strictly controlled by the IDP itself.

1. Awareness of ORM Vulnerable Patterns: The ORM information leak in Authentik highlights a lesser-known but potent class of vulnerabilities. Developers using ORMs must be aware of patterns that can lead to data exposure, especially when user-supplied input is used in dynamic query construction (e.g., filter with unpacking). Secure coding practices for ORMs involve sanitizing and validating all user input** before it's passed to ORM methods, and avoiding dynamic query construction with untrusted data where possible. Security teams should scan for and educate developers on these ORM-specific insecure patterns.

1. Careful Logging Practices: While logging is crucial for security monitoring, the Authentik UUID leak showed that even masked data in logs can be a source of information leakage if an oracle exists. Organizations should review their logging policies to ensure that highly sensitive identifiers, even if seemingly obscured, are not logged in a way that allows for character-by-character extraction.

Key Takeaways

• HTTP/2 and the Single Packet Attack: HTTP/2's multiplexing and streaming capabilities enable the single packet attack, a powerful technique for testing web applications for race conditions by sending multiple requests concurrently within a single TCP packet.
• Atomic Operations are Crucial: To prevent race conditions, ensure that state-changing operations, especially those involving business logic limits, are atomic. Database transactions are an effective mechanism to guarantee that multiple database operations succeed or fail as a single unit.
• Strict Access Control for Sensitive Assets: Double-check access restrictions on all endpoints handling sensitive resources like private keys, certificates, or configuration files. Unauthorized access to such assets can lead to severe compromise, including server impersonation and token forging.
• ORM Vulnerabilities for Information Leaks: Insecure use of Object Relational Mappers (ORMs), particularly when user-supplied data is used in query filters, can lead to information leaks, allowing attackers to extract sensitive internal data through side-channel attacks like regex oracles.
• Secure API Token Handling: When designing API token functionalities, avoid allowing direct manipulation of sensitive user attributes or identifiers associated with tokens. Robust input validation and authorization checks are essential to prevent privilege escalation via token modification.
• Beware of Built-in Impersonation: Be aware of powerful built-in functionalities in IDPs, such as Authentik's admin impersonation feature. While useful for support, it underscores the catastrophic impact if an admin account is compromised, as it grants immediate access to any user's identity.

About the Speaker(s)

Aul is a dedicated vulnerability researcher at Cyber clubs, bringing eight years of experience in the security research domain. Having transitioned from an engineering background, Aul's expertise lies in uncovering and dissecting vulnerabilities. At Cyber clubs, Aul's team primarily focuses on open-source and identity-related systems, conducting in-depth research to enhance product security internally and contribute back to the wider security community through public blog posts and conference presentations. Aul's passion for research is evident in the detailed analysis of both successful exploits and "rabbit holes," emphasizing learning opportunities from all research outcomes.