CVE-2024-38460

Executive Summary

CVE-2024-38460 is a medium-severity information disclosure vulnerability in SonarQube, a popular open-source platform for continuous code quality inspection. The flaw resides in the Settings Encryption feature, which is used to protect sensitive values such as passwords, tokens, and API keys stored within SonarQube configuration. Due to improper handling of encrypted values in URL parameters, these secrets can be logged in cleartext in various log files, including SonarQube Access Logs and Proxy Logs. An attacker with access to these logs can recover the plaintext secrets, potentially leading to lateral movement, privilege escalation, or compromise of integrated systems.

The vulnerability affects all SonarQube versions prior to 10.4 and the 9.9 LTA series before 9.9.4. The CVSS score is 4.9 (Medium), with a low attack complexity but requiring local access to logs. No public exploit code or proof-of-concept is currently available, and the EPSS score is 0.0%, indicating a low probability of exploitation in the wild. However, the impact is significant due to the potential exposure of critical credentials.

Supply Chain & Package Security

This vulnerability is not directly related to a package manager (NPM, PyPI, Go, Ruby) but affects the SonarQube application itself. However, organizations using SonarQube as part of their CI/CD pipeline should treat this as a supply chain risk, as exposed credentials could compromise the integrity of the software development lifecycle.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
• Base Score: 4.9 (Medium)
• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): Low (L) – An attacker needs access to log files, which may be obtained through other means.
• User Interaction (UI): None (N) – No user action is required.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – Sensitive information is exposed.
• Integrity (I): None (N) – No data modification.
• Availability (A): None (N) – No impact on availability.

Threat Level: Medium. The vulnerability requires access to logs, but once obtained, it can lead to severe credential exposure.

Deep Dive & Mechanics

The SonarQube Settings Encryption feature allows administrators to encrypt sensitive configuration values (e.g., database passwords, API tokens) using a built-in encryption mechanism. When these encrypted values are used in URL parameters (e.g., in webhook calls, API requests, or redirects), the application fails to sanitize the output before logging. As a result, the plaintext value is written to log files instead of the encrypted placeholder.

Root Cause: The flaw lies in the logging framework's handling of URL parameters. When an encrypted setting is passed as a query parameter, the application logs the entire URL, including the decrypted value, rather than masking or encrypting it.

Attack Vector: An attacker who gains access to SonarQube Access Logs, Proxy Logs, or other log files can search for patterns like ?setting=... or ?encrypted=... to extract cleartext secrets. This can be achieved through:

• Compromised log management systems (e.g., ELK stack, Splunk).
• Local file inclusion (LFI) vulnerabilities.
• Insider threats with log access.
• Misconfigured log shipping to public repositories.

Impact: Exposed credentials can be used to access databases, cloud services, or other integrated tools, leading to data breaches or lateral movement.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-10.4 / 9.9.4 LTA):

// Example of vulnerable logging in SonarQube
logger.info("Request URL: {}", request.getRequestURL() + "?" + request.getQueryString());

In this snippet, the entire query string, including encrypted settings, is logged without sanitization.

Patched Code (10.4 / 9.9.4 LTA):

// Patched version with sanitization
String sanitizedQuery = sanitizeQueryString(request.getQueryString());
logger.info("Request URL: {}", request.getRequestURL() + "?" + sanitizedQuery);

private String sanitizeQueryString(String query) {
    // Replace sensitive parameter values with [REDACTED]
    return query.replaceAll("(?<=setting=)[^&]+", "[REDACTED]");
}

The patch introduces a sanitization function that replaces the values of sensitive parameters (e.g., setting) with [REDACTED] before logging.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to SonarQube logs (e.g., via compromised log server or LFI).
• A SonarQube instance with Settings Encryption enabled (versions < 10.4 or < 9.9.4 LTA).

Steps:

1. Identify Log Location: Determine where SonarQube logs are stored (e.g., /var/log/sonarqube/access.log).
2. Extract Logs: Use a command like grep -E '\?setting=|encrypted=' /var/log/sonarqube/access.log to find URLs containing encrypted settings.
3. Decode URL: The plaintext value may be URL-encoded. Use urldecode or a script to decode.
4. Recover Credentials: Parse the output to extract cleartext secrets.

Example Command:

grep -oP 'setting=\K[^&\s]+' /var/log/sonarqube/access.log | while read line; do echo -e "$line\n"; done

Blue Team (Defense)

Detection:

• Monitor logs for unusual access patterns or attempts to read log files.
• Use the Sigma rule below to detect exposure of encrypted settings in logs.

Mitigation:

• Immediately upgrade to SonarQube 10.4 or 9.9.4 LTA.
• Rotate all credentials that may have been exposed.
• Restrict access to log files using strict file permissions and SIEM controls.

Indicators of Compromise (IOCs)

• Log Entries: URLs containing ?setting= followed by a plaintext value (e.g., ?setting=myPassword123).
• Network Traffic: Unusual requests to SonarQube endpoints with setting parameters.
• File Hashes: No specific file hashes; focus on log content.
• IP Addresses: Any IP that accesses log files without authorization.

Detection Engineering

YARA Rule

rule SonarQube_Encrypted_Setting_Exposure {
    meta:
        description = "Detects exposure of encrypted settings in SonarQube logs"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-38460"
    strings:
        $url_pattern = /setting=[^&\s]+/
        $log_pattern = /access\.log/
    condition:
        $url_pattern and $log_pattern
}

Sigma Rule

title: SonarQube Encrypted Setting Exposure in Logs
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects exposure of encrypted settings in SonarQube access logs
author: Valters IT
date: 2024/01/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-38460
logsource:
    category: application
    product: sonarqube
detection:
    selection:
        EventID: 4663
        ObjectName: '*access.log*'
        AccessMask: '0x1'  # ReadData
    condition: selection
falsepositives:
    - Legitimate log analysis
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-38460 SonarQube Encrypted Setting Exposure"; flow:to_server,established; content:"setting="; http_uri; pcre:"/setting=[^&\s]+/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade SonarQube: Update to version 10.4 or 9.9.4 LTA (or later).
2. Rotate Credentials: Change all passwords, tokens, and API keys that were stored using the Settings Encryption feature.
3. Review Logs: Check existing logs for any exposed secrets and take corrective action.

Long-Term Measures:

• Implement log masking for sensitive data using a centralized logging solution (e.g., Logstash, Fluentd).
• Restrict access to log files using the principle of least privilege.
• Enable audit logging and monitor for unauthorized log access.
• Use a web application firewall (WAF) to block requests containing setting= in URLs.

Workaround (if patching is delayed):

• Disable the Settings Encryption feature temporarily.
• Use environment variables or external secret management tools (e.g., HashiCorp Vault) instead.

Valters IT
Securing Your Digital Future