CVE-2024-44575

Executive Summary

CVE-2024-44575 identifies a critical security flaw in RELY-PCIe firmware versions v22.2.1 through v23.1.0. The vulnerability arises from the failure to set the Secure attribute for sensitive cookies during HTTPS sessions. This omission allows a user agent (browser) to transmit these cookies in cleartext over an unencrypted HTTP session, exposing session tokens, authentication credentials, or other sensitive data to potential interception via man-in-the-middle (MITM) attacks.

The vulnerability is classified under CWE-614 (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute). Although the CVSS score is listed as 0.0 in the NVD data, the vector indicates a high confidentiality impact with low attack complexity, making it a significant threat in environments where HTTPS and HTTP traffic coexist. The vendor has not released a patch, and no public exploit code or proof-of-concept is available at this time.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It affects embedded firmware for RELY-PCIe hardware, which is typically deployed in industrial or critical infrastructure environments. Supply chain risks include the distribution of unpatched firmware images through vendor channels or third-party integrators.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
• Base Score: 7.5 (High)
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – The attack does not require user action.
• Scope: Unchanged (S:U) – The impact is confined to the affected component.
• Confidentiality Impact: High (C:H) – Sensitive cookies can be exposed.
• Integrity Impact: None (I:N) – No data modification.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: High. The lack of the Secure attribute on cookies in HTTPS sessions enables passive interception of sensitive data. In mixed-content environments, an attacker on the same network can downgrade connections or capture cookies transmitted over HTTP.

Deep Dive & Mechanics

The vulnerability stems from improper cookie attribute configuration in the RELY-PCIe web interface. When a user accesses the device over HTTPS, the server sets session cookies without the Secure flag. According to RFC 6265, the Secure attribute instructs the user agent to only send the cookie over encrypted connections. Without it, the browser may transmit the cookie over unencrypted HTTP if the user navigates to an HTTP page or if an attacker forces a protocol downgrade.

Attack Scenario:

1. An attacker on the same network (e.g., via ARP spoofing or rogue Wi-Fi) intercepts traffic.
2. The victim accesses the RELY-PCIe web interface over HTTPS, receiving a session cookie without the Secure flag.
3. The attacker forces the victim to make an HTTP request (e.g., via a malicious link or HTTP redirect).
4. The browser sends the session cookie in cleartext over HTTP, allowing the attacker to capture it.
5. The attacker replays the cookie to gain unauthorized access to the RELY-PCIe interface.

Root Cause: The server-side code does not include Set-Cookie: ...; Secure in HTTP response headers for sensitive cookies.

Vulnerable vs. Patched Code

Vulnerable Code (v22.2.1 to v23.1.0):

# Example of vulnerable cookie setting (pseudo-code)
response.set_cookie('session_id', session_token, httponly=True)
# Missing: secure=True

Patched Code (Hypothetical):

# Patched version with Secure attribute
response.set_cookie('session_id', session_token, httponly=True, secure=True)

Key Difference: The patched version adds secure=True to the set_cookie call, ensuring the cookie is only transmitted over HTTPS.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to the same network as the target RELY-PCIe device.
• Ability to perform MITM attacks (e.g., using bettercap, mitmproxy, or arpspoof).

Steps:

1. Network Reconnaissance: Identify the RELY-PCIe device IP and confirm it serves HTTPS.
2. MITM Setup: Use arpspoof to redirect traffic through the attacker machine.

   arpspoof -i eth0 -t <target_ip> <gateway_ip>
   arpspoof -i eth0 -t <gateway_ip> <target_ip>
   

3. Traffic Capture: Run tcpdump or Wireshark to capture HTTP traffic.

   tcpdump -i eth0 -w capture.pcap port 80 or port 443
   

4. Trigger Cookie Transmission: Send a crafted HTTP request to the RELY-PCIe device (e.g., via a malicious link or by exploiting mixed content).

   curl -v http://<rely_ip>/login --cookie "session_id=test"
   

5. Extract Cookie: Analyze the captured pcap for cookies sent in cleartext.

   tshark -r capture.pcap -Y "http.cookie" -T fields -e http.cookie
   

No public exploit code is available.

Blue Team (Defense & Detection)

Detection:

• Monitor for HTTP requests to RELY-PCIe devices that include cookies.
• Alert on any cookie transmission over HTTP from HTTPS-only interfaces.

Mitigation:

• Implement a Web Application Firewall (WAF) rule to block HTTP traffic to the RELY-PCIe interface.
• Enforce HSTS (HTTP Strict Transport Security) on the device to prevent protocol downgrades.
• Manually patch by configuring the device to set the Secure attribute on all cookies (if possible via firmware settings).

Indicators of Compromise (IOCs)

• Network Traffic:
  • HTTP requests containing session_id or other sensitive cookies in cleartext.
  • Unencrypted HTTP traffic to RELY-PCIe IP addresses on port 80.
• Logs:
  • Web server logs showing Set-Cookie headers without the Secure attribute.
  • Browser console warnings about insecure cookies (e.g., "Cookie will be soon rejected because it has the 'SameSite' attribute set to 'None' or an invalid value, without the 'Secure' attribute").
• File Hashes:
  • Firmware images for versions v22.2.1 to v23.1.0 (specific hashes not provided).

Detection Engineering

YARA Rule

rule CVE_2024_44575_Insecure_Cookie {
    meta:
        description = "Detects HTTP responses with Set-Cookie headers missing the Secure attribute"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2024-44575"
    strings:
        $set_cookie = /Set-Cookie:\s*[^;]+/ nocase
        $secure_flag = /;\s*Secure/ nocase
    condition:
        $set_cookie and not $secure_flag
}

Sigma Rule

title: CVE-2024-44575 - Missing Secure Attribute on Cookie
id: 8a3f2c1e-5d7b-4a9f-8c2e-1b3d4e5f6a7b
status: experimental
description: Detects HTTP responses where a Set-Cookie header lacks the Secure attribute, indicating potential exposure of sensitive cookies over HTTP.
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: generic
detection:
    selection:
        http.response.header|contains: 'Set-Cookie'
    filter:
        http.response.header|contains: 'Secure'
    condition: selection and not filter
falsepositives:
    - Non-sensitive cookies intentionally set without Secure attribute
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-44575 - Missing Secure Attribute on Cookie"; flow:to_client; content:"Set-Cookie"; nocase; pcre:"/Set-Cookie:\s*[^;]+(?!;\s*Secure)/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable HTTP Access: Configure the RELY-PCIe device to only accept HTTPS connections and redirect all HTTP traffic to HTTPS.
2. Enforce HSTS: Add the Strict-Transport-Security header with a long max-age to prevent protocol downgrades.
3. Manual Cookie Fix: If possible, modify the device configuration to include Secure attribute in all Set-Cookie headers.

Long-Term Fix:

• The vendor must release a firmware update that sets the Secure attribute on all sensitive cookies. Until then, apply network-level controls (e.g., firewall rules blocking HTTP to the device).

Workarounds:

• Use a reverse proxy (e.g., Nginx) in front of the RELY-PCIe device to strip cookies from HTTP responses and re-add the Secure attribute.
• Implement client-side certificate authentication to reduce reliance on cookies.

Valters IT Signature This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.