CVE-2023-30312

Executive Summary

CVE-2023-30312 is a critical vulnerability in OpenWrt, a popular Linux-based operating system for embedded devices (routers, access points, etc.). The flaw lies in the default configuration of the nf_conntrack_tcp_no_window_check kernel parameter, which is set to true. This setting disables TCP window tracking in the connection tracking subsystem (nf_conntrack). An off-path attacker can exploit this to hijack existing TCP sessions without needing to be on the direct network path between the client and server.

The impact is severe: an attacker can impersonate a client to a server (e.g., to access files over FTP) or impersonate a server to a client (e.g., to deliver false information from a finance website). This can lead to data theft, session hijacking, and denial of service. The vulnerability affects all OpenWrt versions from 18.06 through 22.03 and likely beyond, as the default configuration has not been changed.

No supply chain or package security implications are directly associated with this CVE.

CVSS Breakdown & Threat Level

While a CVSS score is not officially assigned, based on the technical details, a reasonable assessment is:

• Attack Vector (AV): Network (N) - The attack is performed over the network.
• Attack Complexity (AC): Low (L) - The attack does not require special conditions.
• Privileges Required (PR): None (N) - No authentication is needed.
• User Interaction (UI): None (N) - No user action is required.
• Scope (S): Unchanged (U) - The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) - Session hijacking can lead to data exposure.
• Integrity (I): High (H) - An attacker can inject malicious data into the session.
• Availability (A): High (H) - Session hijacking can lead to denial of service.

Estimated CVSS Score: 9.8 (Critical)

Threat Level: Critical. The vulnerability is easy to exploit, requires no authentication, and has a high impact on confidentiality, integrity, and availability.

Deep Dive & Mechanics

The core issue is the Linux kernel's nf_conntrack module, which tracks network connections for stateful firewalling and NAT. TCP window tracking is a security feature that validates TCP sequence and acknowledgment numbers against the expected window. When nf_conntrack_tcp_no_window_check is set to true, this validation is bypassed.

How the Attack Works:

1. Prerequisite: The attacker must be able to observe the TCP sequence numbers of an existing connection. This can be achieved through various means, such as:

   • Being on the same local network (e.g., Wi-Fi) and passively sniffing traffic.
   • Exploiting a separate vulnerability to leak sequence numbers.
   • Using a side-channel attack (e.g., timing analysis).

2. Session Hijacking: Once the attacker knows the sequence numbers, they can craft a TCP packet with a spoofed source IP address (matching the client) and a sequence number that falls within the receiver's window. Because window checking is disabled, the kernel will accept this packet as valid, even if the sequence number is far outside the expected range.

3. Impact:

   • Client Impersonation: The attacker can send data to the server as if they were the legitimate client. For example, they could send FTP commands to download or upload files.
   • Server Impersonation: The attacker can send data to the client as if they were the server. For example, they could inject malicious JavaScript into a web page or alter financial data.
   • Denial of Service: The attacker can send a TCP RST (reset) packet to terminate the connection.

Why this is dangerous: The attack is "off-path," meaning the attacker does not need to be a man-in-the-middle. They only need to be able to send packets to the client or server and observe the initial sequence numbers.

Vulnerable vs. Patched Code

Vulnerable Configuration (Default):

# /etc/sysctl.conf or /etc/sysctl.d/ directory
# This line is either present or the default kernel parameter is set to 1
net.netfilter.nf_conntrack_tcp_no_window_check = 1

Patched Configuration:

# /etc/sysctl.conf or /etc/sysctl.d/ directory
# Set to 0 to enable window checking
net.netfilter.nf_conntrack_tcp_no_window_check = 0

Verification:

# Check current value
sysctl net.netfilter.nf_conntrack_tcp_no_window_check

Exploitation & Lab Setup

Red Team (Exploitation)

Lab Setup:

• Attacker Machine: Kali Linux (or any Linux with scapy or hping3)
• Victim Client: OpenWrt router (e.g., a TP-Link router running OpenWrt 22.03)
• Target Server: An FTP server or a web server (e.g., a simple Python HTTP server)

Exploitation Steps:

1. Identify a Target Connection: The attacker needs to know the IP addresses and ports of the client and server, and the initial TCP sequence number (ISN) of the client. This can be obtained by sniffing the network (e.g., using tcpdump).

2. Craft a Spoofed Packet: Use a tool like scapy to create a TCP packet with a spoofed source IP (the client's IP) and a sequence number that is within the receiver's window.

   #!/usr/bin/env python3
   from scapy.all import *
   import sys
   
   # Replace with actual values
   client_ip = "192.168.1.100"
   server_ip = "10.0.0.1"
   client_port = 12345
   server_port = 80
   seq_num = 1000  # This must be within the server's window
   ack_num = 2000  # This must be within the client's window
   
   # Craft a packet that appears to come from the client to the server
   ip = IP(src=client_ip, dst=server_ip)
   tcp = TCP(sport=client_port, dport=server_port, flags="PA", seq=seq_num, ack=ack_num)
   payload = "GET /malicious.html HTTP/1.1\r\nHost: example.com\r\n\r\n"
   packet = ip / tcp / payload
   
   send(packet, verbose=0)
   print(f"Sent spoofed packet from {client_ip}:{client_port} to {server_ip}:{server_port}")
   

3. Execute the Attack: Run the script. The server will accept the packet as valid and process the request, potentially serving malicious content or performing unauthorized actions.

Blue Team (Defense & Detection)

Detection:

• Monitor for Anomalous TCP Packets: Look for TCP packets with sequence numbers that are far outside the expected window. This is a strong indicator of an off-path attack.
• Enable TCP Window Checking: The primary mitigation is to set net.netfilter.nf_conntrack_tcp_no_window_check = 0.
• Network Segmentation: Isolate critical servers from untrusted networks.
• Use TCP Authentication Option (TCP-AO): This cryptographic option prevents session hijacking by authenticating TCP segments.

Honeypot Strategy:

• Deploy a honeypot that mimics a vulnerable OpenWrt device. Monitor for spoofed TCP packets and log the attacker's IP address.

Indicators of Compromise (IOCs)

• Network Traffic:
  • TCP packets with sequence numbers that are not within the expected window (e.g., a large jump in sequence numbers).
  • Multiple TCP RST packets from a single source IP to multiple destinations.
  • Unusual data in TCP payloads that does not match the expected application protocol.
• System Logs:
  • Kernel messages related to nf_conntrack (e.g., nf_conntrack: expectation table full).
  • Firewall logs showing dropped packets with invalid TCP window sizes (if logging is enabled).
• Configuration:
  • The presence of net.netfilter.nf_conntrack_tcp_no_window_check = 1 in /etc/sysctl.conf or /etc/sysctl.d/.

Detection Engineering

YARA Rule

rule Detect_OffPath_TCP_Hijack_Attempt {
    meta:
        description = "Detects TCP packets with anomalous sequence numbers indicative of off-path hijacking"
        author = "Valters IT"
        date = "2024-05-24"
        reference = "CVE-2023-30312"
    strings:
        $tcp_header = { 45 00 ?? ?? ?? ?? 40 00 ?? 06 }  // IPv4 header with TCP
        $seq_anomaly = { ?? ?? ?? ?? ?? ?? ?? ?? 00 00 00 00 }  // Placeholder for sequence number check
    condition:
        // This is a simplified example; real detection requires deep packet inspection
        // and analysis of sequence numbers relative to the expected window.
        $tcp_header at 0 and filesize < 1500
}

Sigma Rule

title: Off-Path TCP Session Hijacking Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects TCP packets with sequence numbers outside the expected window, indicating a potential off-path hijacking attack (CVE-2023-30312).
author: Valters IT
date: 2024/05/24
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2023-30312
logsource:
    category: network
    product: suricata
detection:
    selection:
        event_type: alert
        alert.signature_id: 20230312
    condition: selection
falsepositives:
    - Legitimate TCP retransmissions
    - Network congestion
level: high

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2023-30312 - Off-Path TCP Session Hijacking Attempt"; flow:to_server; content:"|00 00 00 00|"; depth:4; offset:4; within:4; reference:cve,2023-30312; classtype:attempted-admin; sid:20230312; rev:1;)

Note: The Suricata rule above is a simplified example. A real-world rule would need to track TCP windows and compare sequence numbers against them, which is complex. The rule above looks for a specific pattern (all zeros in the sequence number field) which is a common indicator of a crafted packet.

Remediation & Mitigation

Immediate Actions:

1. Disable the Vulnerable Setting: On all OpenWrt devices, set net.netfilter.nf_conntrack_tcp_no_window_check = 0 in /etc/sysctl.conf or a file in /etc/sysctl.d/. Apply the change with sysctl -p.
2. Reboot or Restart Services: After applying the change, reboot the device or restart the firewall service to ensure the new setting takes effect.

Long-Term Mitigations:

• Firmware Updates: Monitor OpenWrt for a patch that changes the default value. Apply updates as soon as they are available.
• Network Segmentation: Place critical servers behind a firewall that performs stateful inspection and enforces TCP window checking.
• Use VPNs: Encrypt traffic between clients and servers using a VPN (e.g., WireGuard, OpenVPN). This prevents an attacker from observing sequence numbers.
• Implement TCP-AO: For critical connections, use TCP Authentication Option (TCP-AO) to cryptographically authenticate TCP segments.

Valters IT Signature

This report was generated by Valters IT DevSecOps & CTI Division. For further analysis or remediation support, contact your Valters IT representative.