CVE-2024-27917

Executive Summary

CVE-2024-27917 is a session fixation vulnerability in Shopware, an open-source e-commerce platform. The flaw arises from the caching of 404 error pages, which inadvertently includes a session cookie in the cached response. When a browser without an existing session cookie accesses a 404 page, it receives a cached response containing a session cookie set by the Symfony Session Handler. An attacker can exploit this by tricking a victim into visiting a crafted 404 URL, causing the victim's browser to use a session known to the attacker. This can lead to session hijacking and unauthorized access to the victim's account. The vulnerability affects Shopware versions 6.5.8.0 through 6.5.8.6. The patch is included in version 6.5.8.7, and a workaround is to use Redis for session handling, which bypasses the vulnerable code path.

Supply Chain & Package Security

This vulnerability is specific to the Shopware platform, which is distributed as a PHP application via Composer. The affected component is the Symfony Session Handler integration within Shopware's HTTP cache layer. No direct supply chain compromise is involved, but users should ensure they are using a trusted source for updates.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R) - Victim must visit a crafted URL
• Scope: Unchanged (S:U)
• Confidentiality Impact: Low (C:L) - Session data exposure
• Integrity Impact: Low (I:L) - Potential session manipulation
• Availability Impact: None (A:N)

Threat Level: High. The vulnerability is easily exploitable with low complexity and no privileges required. Successful exploitation can lead to session hijacking, allowing an attacker to impersonate a legitimate user and perform actions on their behalf.

Deep Dive & Mechanics

The vulnerability is rooted in the interaction between Shopware's 404 page caching mechanism and the Symfony Session Handler.

1. Caching of 404 Pages: Starting with Shopware 6.5.8.0, 404 error pages are cached to improve performance. This is done by the HTTP cache layer (likely Symfony's HttpCache or a custom reverse proxy).

2. Session Cookie Assignment: The Symfony Session Handler is responsible for managing session cookies. When a request is processed, the handler pops the session cookie from the request and assigns it to the response. This is standard behavior for session management.

3. The Flaw: When a browser without any cookies (e.g., a first-time visitor or a user in a private browsing session) requests a URL that results in a 404 error, the following occurs:

   • The request reaches the server.
   • The Symfony Session Handler, seeing no session cookie, creates a new session and sets a Set-Cookie header in the response.
   • The response (including the Set-Cookie header) is cached by the 404 page cache.
   • Subsequent requests to the same 404 URL from any browser without a session cookie will receive the cached response, which includes the Set-Cookie header for the session that was created during the first request.

4. Exploitation Scenario:

   • An attacker crafts a URL that will trigger a 404 error on the target Shopware instance (e.g., https://shop.example.com/nonexistent-page).
   • The attacker visits this URL first, causing the server to create a new session and cache the 404 response with the session cookie.
   • The attacker then sends the same URL to the victim (e.g., via phishing email or social media).
   • The victim, who has no existing session with the Shopware instance, visits the URL.
   • The victim's browser receives the cached 404 response, which includes the Set-Cookie header for the attacker's session.
   • The victim's browser now uses the attacker's session ID.
   • If the victim then logs in or performs any action, the attacker can hijack that session by using the same session ID.

5. Redis Workaround: The vulnerability is only exploitable when the default Symfony Session Handler (which uses file-based or native PHP sessions) is in use. If Redis is configured for session storage (using the PHP Redis extension), the session handling code path is different and does not trigger the vulnerable behavior.

Vulnerable vs. Patched Code

The vulnerable code is within the Symfony Session Handler's interaction with the HTTP cache. The exact code is not publicly available, but the patch in version 6.5.8.7 likely modifies the caching logic to prevent session cookies from being cached in 404 responses.

Vulnerable Behavior (Conceptual):

// In the HTTP cache layer (e.g., Symfony HttpCache)
public function onKernelResponse(ResponseEvent $event) {
    $response = $event->getResponse();
    if ($response->getStatusCode() === 404) {
        // Cache the response, including all headers
        $this->cache->store($event->getRequest()->getUri(), $response);
    }
}

Patched Behavior (Conceptual):

// In the HTTP cache layer (e.g., Symfony HttpCache)
public function onKernelResponse(ResponseEvent $event) {
    $response = $event->getResponse();
    if ($response->getStatusCode() === 404) {
        // Remove session cookie before caching
        $response->headers->removeCookie('session');
        $this->cache->store($event->getRequest()->getUri(), $response);
    }
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A Shopware instance running version 6.5.8.0 to 6.5.8.6.
• The instance must be using the default Symfony Session Handler (not Redis).
• The 404 page caching feature must be enabled (default in affected versions).

Exploitation Steps:

1. Identify a 404 URL: Find any URL on the target Shopware instance that will return a 404 error. This could be a non-existent product, category, or any arbitrary path.

2. Prime the Cache: As the attacker, send a request to the 404 URL to trigger caching of the response with a session cookie.

   curl -v http://target-shop.example.com/nonexistent-page
   

   Note the Set-Cookie header in the response. This is the session ID that will be used.

3. Send the URL to the Victim: Craft a phishing email or social media message containing the same 404 URL. The victim must not have an existing session with the Shopware instance.

4. Victim Visits the URL: The victim's browser will receive the cached response, including the Set-Cookie header, and will now use the attacker's session.

5. Hijack the Session: Once the victim logs in or performs any action, the attacker can use the same session ID to access the victim's account.

   curl -v --cookie "session=<SESSION_ID>" http://target-shop.example.com/my-account
   

Blue Team (Detection & Prevention)

Detection:

• Monitor for multiple requests to the same 404 URL from different IP addresses within a short time frame.
• Look for Set-Cookie headers in cached 404 responses.
• Analyze web server logs for unusual patterns of 404 requests followed by authenticated actions.

Prevention:

• Immediate: Apply the patch by upgrading to Shopware version 6.5.8.7 or later.
• Workaround: Configure Redis for session storage. This bypasses the vulnerable code path.
• Mitigation: Disable caching of 404 pages if possible, or configure the cache to strip Set-Cookie headers from cached error responses.
• Long-term: Implement a Web Application Firewall (WAF) rule to block requests that appear to be exploiting session fixation.

Indicators of Compromise (IOCs)

• Network:
  • Multiple requests to the same non-existent URL (e.g., /nonexistent-page) from different source IPs.
  • HTTP responses with status 404 that include a Set-Cookie header.
• Host:
  • Unusual session IDs in web server logs that are associated with 404 requests.
  • Cached 404 responses in the HTTP cache that contain session cookies.
• Logs:
  • Web server access logs showing a pattern of: GET /nonexistent-page 404 followed by GET /my-account 200 with the same session ID.

Detection Engineering

YARA Rule

rule CVE_2024_27917_Shopware_Session_Fixation {
    meta:
        description = "Detects cached 404 responses containing session cookies in Shopware"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-27917"
        hash = "d41d8cd98f00b204e9800998ecf8427e"
    strings:
        $s1 = "Set-Cookie: session=" ascii wide nocase
        $s2 = "HTTP/1.1 404" ascii wide nocase
        $s3 = "Shopware" ascii wide nocase
    condition:
        all of ($s1, $s2, $s3)
}

Sigma Rule

title: CVE-2024-27917 - Shopware Session Fixation via Cached 404 Pages
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects multiple requests to the same 404 URL from different IPs, indicating potential session fixation exploitation.
author: Valters IT
date: 2024-10-27
references:
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27917
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-uri-query|contains: 
            - 'nonexistent'
            - '404'
        sc-status: 404
    condition: selection
    timeframe: 5m
    aggregation:
        - field: cs-uri-query
          type: count
          condition: gt 5
        - field: c-ip
          type: distinct
          condition: gt 3
falsepositives:
    - Legitimate users hitting the same broken link
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-27917 - Shopware Session Fixation via Cached 404 Pages"; flow:to_server,established; content:"404"; http_stat_code; content:"Set-Cookie"; http_header; pcre:"/Set-Cookie:\s*session=/i"; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action:

   • Upgrade Shopware to version 6.5.8.7 or later. This is the official patch that fixes the vulnerability.

2. Workaround:

   • If immediate upgrade is not possible, configure Redis for session storage. This bypasses the vulnerable code path entirely.
   • In config/packages/framework.yaml or environment variables, set:

     framework:
         session:
             handler_id: 'session.handler.native_file'
             # Change to Redis:
             # handler_id: 'snc_redis.session.handler'
     

3. Mitigation:

   • Disable caching of 404 pages if the feature is not critical.
   • Implement a WAF rule to strip Set-Cookie headers from cached error responses.
   • Monitor for anomalous 404 request patterns.

4. Long-term:

   • Review and audit all caching mechanisms to ensure they do not cache sensitive headers like Set-Cookie.
   • Implement security headers such as Strict-Transport-Security and X-Content-Type-Options to reduce the impact of session hijacking.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert