CVE-2024-32474

Executive Summary

CVE-2024-32474 is a medium-severity information disclosure vulnerability affecting Sentry, an error tracking and performance monitoring platform. The flaw resides in the superuser authentication mechanism. When a superuser authenticates with a username and password, the cleartext password is inadvertently written to application logs under the event auth-index.validate_superuser. An attacker with access to these logs (e.g., through a compromised log aggregator, SIEM, or local file access) can retrieve the superuser credentials and gain full administrative control over the Sentry instance. The vulnerability is present in all self-hosted Sentry versions prior to 24.4.1. The official patch is to upgrade to version 24.4.1 or later. As a temporary mitigation, administrators can configure the logging level to exclude INFO level logs, only generating logs for WARNING and above.

Supply Chain & Package Security

Sentry is a Python-based application. The vulnerability is in the application's own authentication logic, not in a third-party package. However, the exposure of credentials in logs is a classic supply chain risk: if an attacker compromises the logging infrastructure (e.g., a log shipper, log storage, or SIEM), they can harvest credentials. Organizations using Sentry should ensure that their logging pipeline is secured with strict access controls and encryption at rest and in transit.

CVSS Breakdown & Threat Level

• CVSS Score: 7.3 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
• Attack Vector: Network (AV:N) – The attacker can access logs remotely.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: Low (PR:L) – Attacker needs log access, which may be obtained via a separate compromise.
• User Interaction: None (UI:N) – No user action needed.
• Scope: Unchanged (S:U) – The vulnerability does not affect other components.
• Confidentiality Impact: High (C:H) – Superuser credentials are exposed.
• Integrity Impact: High (I:H) – With superuser access, attacker can modify Sentry data and configurations.
• Availability Impact: None (A:N) – The vulnerability does not directly cause denial of service.

Threat Level: High. The combination of low attack complexity and high impact makes this a critical finding for any organization running a self-hosted Sentry instance.

Deep Dive & Mechanics

The vulnerability is a classic case of CWE-532: Insertion of Sensitive Information into Log File. In Sentry's authentication flow for superusers, the application logs the event auth-index.validate_superuser at the INFO level. The log message includes the full authentication payload, which contains the cleartext password. This is likely due to the use of a logging statement that directly interpolates the request data without sanitization.

The vulnerable code path is in the sentry.web.frontend.auth module (or similar). When a superuser submits a login form, the server processes the credentials and, before or after validation, logs the entire request body or a dictionary containing the username and password. The log entry is then written to the standard Sentry log file (e.g., sentry.log) or forwarded to a centralized logging system.

An attacker who gains read access to these logs—whether through a separate vulnerability, misconfigured log permissions, or a compromised log management tool—can extract the password and authenticate as a superuser. Once authenticated, the attacker can view all error data, modify project settings, access user data, and potentially pivot to other systems.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-24.4.1):

# Example of vulnerable logging (conceptual)
import logging
logger = logging.getLogger(__name__)

def validate_superuser(request):
    username = request.POST.get('username')
    password = request.POST.get('password')
    # ... authentication logic ...
    logger.info(f"auth-index.validate_superuser: username={username}, password={password}")
    # ...

Patched Code (24.4.1+):

# Example of patched logging (conceptual)
import logging
logger = logging.getLogger(__name__)

def validate_superuser(request):
    username = request.POST.get('username')
    password = request.POST.get('password')
    # ... authentication logic ...
    logger.info(f"auth-index.validate_superuser: username={username}, password=REDACTED")
    # ...

The fix involves redacting the password field before logging. The exact implementation may use a custom log filter or simply omit the password from the log message.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Access to Sentry application logs (e.g., via a compromised log server, local file read vulnerability, or misconfigured SIEM).
• The target Sentry instance must be version < 24.4.1.

Steps:

1. Gain Log Access: Exploit a separate vulnerability (e.g., LFI, SSRF, or misconfigured log shipper) to read Sentry logs. Alternatively, if you have low-privilege access to the Sentry server, read the log file directly.
2. Extract Credentials: Search for the string auth-index.validate_superuser in the logs. The log entry will contain the cleartext password.

   grep "auth-index.validate_superuser" sentry.log | grep "password="
   

3. Authenticate as Superuser: Use the extracted credentials to log in to the Sentry web interface as a superuser.
4. Post-Exploitation: Once authenticated, you can access all projects, view error data, modify configurations, and potentially pivot to other systems (e.g., by accessing API keys stored in Sentry).

Lab Setup:

• Deploy a vulnerable Sentry instance (e.g., version 24.4.0) using Docker.
• Configure logging to a file.
• Simulate a superuser login.
• Use a separate container to read the log file and extract the password.

Blue Team (Defense & Detection)

Detection:

• Monitor logs for the presence of cleartext passwords. Use a SIEM rule to alert on any log entry containing password= in the auth-index.validate_superuser event.
• Monitor for unusual superuser activity after a log exposure event.

Prevention:

• Upgrade to Sentry 24.4.1 or later immediately.
• If upgrade is not possible, change the logging level to WARNING or higher to suppress INFO logs.
• Implement strict access controls on log files and log management systems.
• Use a log redaction tool (e.g., Fluentd filter, Logstash filter) to automatically mask passwords in logs.

Indicators of Compromise (IOCs)

• Log Entry Pattern: auth-index.validate_superuser containing password=<cleartext>.
• Unusual Superuser Login: Login events from unexpected IP addresses or at unusual times.
• Log Access Anomalies: Unauthorized access to log files or log management systems.

Detection Engineering

YARA Rule

rule CVE_2024_32474_Sentry_Credential_Leak {
    meta:
        description = "Detects cleartext password in Sentry superuser authentication logs"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-32474"
    strings:
        $s1 = "auth-index.validate_superuser"
        $s2 = "password="
    condition:
        all of them
}

Sigma Rule

title: Sentry Superuser Credential Leak in Logs
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects cleartext password in Sentry superuser authentication logs (CVE-2024-32474)
author: Valters IT
date: 2024-10-27
logsource:
    product: sentry
    service: application
detection:
    selection:
        EventID: "auth-index.validate_superuser"
        Message|contains: "password="
    condition: selection
falsepositives:
    - None expected if patched
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Sentry Superuser Credential Leak in Logs (CVE-2024-32474)"; flow:to_server; content:"auth-index.validate_superuser"; http_uri; content:"password="; http_client_body; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Upgrade all self-hosted Sentry instances to version 24.4.1 or later.
2. Log Level Change: If upgrade is not immediately possible, change the logging level to WARNING or higher to suppress INFO logs. This will prevent the vulnerable log entries from being generated.
3. Rotate Credentials: After patching, rotate all superuser passwords. Assume they may have been compromised.
4. Audit Logs: Review existing logs for any signs of credential exposure. If found, investigate for unauthorized access.

Long-Term Measures:

• Implement a log redaction policy for all sensitive data (passwords, tokens, PII).
• Use a centralized logging solution with built-in data masking capabilities.
• Regularly audit log access permissions.
• Enable multi-factor authentication (MFA) for superuser accounts.

Valters IT