CVE-2024-47077

Executive Summary

CVE-2024-47077 is a critical vulnerability in authentik, an open-source identity provider. The flaw allows an application that legitimately receives an access token to steal and reuse that token to impersonate the user against any other proxy provider application within the same authentik instance. This breaks the intended trust boundary between applications with different trust domains or access control policies. The vulnerability affects all deployments with more than one proxy provider application. The CVSS score is 6.5 (Medium), but the impact is significant due to the potential for lateral movement and privilege escalation within an organization's application ecosystem.

Supply Chain & Package Security

This vulnerability is in the authentik server software itself, not in a specific package manager ecosystem. However, organizations using authentik as a central identity provider should treat this as a critical supply chain risk, as a compromised application can lead to compromise of all other applications protected by the same authentik instance.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
• Base Score: 6.5 (Medium)
• Attack Vector: Network (AV:N) – The attack is performed over the network.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: Low (PR:L) – The attacker needs to be an authenticated user of one application.
• User Interaction: None (UI:N) – No user interaction is required.
• Scope: Unchanged (S:U) – The vulnerability does not cross a trust boundary.
• Confidentiality Impact: High (C:H) – An attacker can access any resource in any application.
• Integrity Impact: Low (I:L) – The attacker can modify data in other applications.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: High. While the base score is Medium, the ease of exploitation and the potential for lateral movement make this a high-priority vulnerability.

Deep Dive & Mechanics

The vulnerability lies in how authentik validates access tokens for its proxy provider feature. The proxy provider allows authentik to act as a reverse proxy, authenticating users and forwarding requests to backend applications. Each proxy provider application is configured with a specific trust domain and access control policies.

When a user authenticates to one application (e.g., app1.example.com), authentik issues an access token. This token is intended to be used only for that specific application. However, due to a flaw in the token validation logic, the token is not properly scoped to the application it was issued for.

An attacker who controls or has access to a malicious application (or a compromised legitimate application) can:

1. Intercept the access token issued to a user for that application.
2. Reuse that token to make requests to any other proxy provider application (e.g., app2.example.com, app3.internal.com).
3. Authentik's proxy provider will accept the token and forward the request, granting the attacker access to the other application as the impersonated user.

The root cause is that the access token's audience claim (or equivalent) is not being checked against the application's identifier. The token is only validated for its signature and expiration, but not for which application it was intended.

Vulnerable vs. Patched Code

The fix involves adding a check to ensure that the access token's audience matches the application being accessed.

Vulnerable Code (Conceptual):

# In the proxy provider's authentication middleware
def authenticate_request(request):
    token = extract_token(request)
    if validate_token_signature(token) and not token_expired(token):
        # No audience check
        user = get_user_from_token(token)
        return user
    return None

Patched Code (Conceptual):

# In the proxy provider's authentication middleware
def authenticate_request(request, application):
    token = extract_token(request)
    if validate_token_signature(token) and not token_expired(token):
        # Check that the token was issued for this application
        if token['aud'] != application.id:
            return None
        user = get_user_from_token(token)
        return user
    return None

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to a proxy provider application (e.g., app1.example.com) that you can either control or intercept traffic from.
• A user account that is authorized to access app1.example.com.
• Knowledge of another proxy provider application (e.g., app2.example.com) that you want to access.

Steps:

1. Authenticate to app1.example.com and capture the access token (e.g., from the Authorization header or a cookie).
2. Make a request to app2.example.com with the stolen token.

   curl -H "Authorization: Bearer <STOLEN_TOKEN>" https://app2.example.com/protected/resource
   

3. If the request succeeds, the vulnerability is confirmed.

No exploit code is publicly available.

Blue Team (Detection & Hardening)

Detection:

• Monitor for access tokens being used across multiple applications within a short time frame.
• Look for requests to app2.example.com that contain a token originally issued for app1.example.com.
• Analyze logs for unusual access patterns, such as a user accessing applications they don't normally use.

Hardening:

• Immediately upgrade to authentik 2024.8.3 or 2024.6.5.
• Implement strict access control policies for each proxy provider application.
• Monitor authentik logs for any suspicious token usage.
• Consider using short-lived tokens to reduce the window of opportunity.

Indicators of Compromise (IOCs)

• Network: HTTP requests to multiple proxy provider applications using the same Bearer token.
• Logs: authentik audit logs showing a single token being used for multiple applications.
• Token: An access token with an aud claim that does not match the application being accessed.

Detection Engineering

YARA Rule

rule Detect_Stolen_Authentik_Token {
    meta:
        description = "Detects access tokens being used across multiple applications"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-47077"
    strings:
        $token_pattern = /Bearer\s+[A-Za-z0-9\-_]+?\.[A-Za-z0-9\-_]+?\.[A-Za-z0-9\-_]+/
    condition:
        #token_pattern > 1
}

Sigma Rule

title: Multiple Application Access with Same Token
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects when the same access token is used to access multiple proxy provider applications
author: Valters IT
date: 2024/10/27
logsource:
    category: application
    product: authentik
detection:
    selection:
        event_type: "access_token_used"
    condition:
        | group-by(token_id)
        | where count(distinct application_id) > 1
falsepositives:
    - Legitimate use of a token across applications (if allowed by policy)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-47077 - Stolen Authentik Token Reuse"; flow:to_server; content:"Authorization"; nocase; content:"Bearer"; distance:0; pcre:"/Bearer\s+[A-Za-z0-9\-_]+?\.[A-Za-z0-9\-_]+?\.[A-Za-z0-9\-_]+/"; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Patch: Upgrade to authentik 2024.8.3 or 2024.6.5 immediately.
2. Token Revocation: Revoke all existing access tokens to force re-authentication.
3. Audit: Review logs for any signs of exploitation.

Long-term:

1. Network Segmentation: Ensure that proxy provider applications are on separate network segments to limit lateral movement.
2. Token Binding: Implement token binding (e.g., using TLS channel binding) to tie tokens to specific client applications.
3. Monitoring: Continuously monitor for anomalous token usage patterns.
4. Least Privilege: Ensure that each application has the minimum necessary access.

Valters IT