CVE-2024-28860
Executive Summary
CVE-2024-28860 is a critical vulnerability in Cilium's IPsec transparent encryption implementation. The flaw allows a man-in-the-middle (MITM) attacker to perform chosen plaintext attacks, key recovery, and replay attacks due to the reuse of the same IPsec ESP (Encapsulating Security Payload) key across multiple nodes. This key reuse leads to sequence number collisions, which undermines the cryptographic guarantees of IPsec. The vulnerability has a CVSS score of 8.0, indicating high severity. The attack vector is adjacent network (AV:A), meaning the attacker must be on the same network segment as the targeted Cilium nodes. No public proof-of-concept (PoC) or exploit code is currently available, and the EPSS score is 0.0%, suggesting low exploitation activity in the wild. The fix involves generating unique keys for each IPsec tunnel between nodes, which is implemented in Cilium versions 1.13.13, 1.14.9, and 1.15.3.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
Cilium is a Go-based project distributed as container images and binaries. The vulnerability affects the core IPsec implementation within the Cilium agent. Organizations using Cilium for Kubernetes networking should verify their deployment version and update to the patched releases. The supply chain risk is moderate, as the vulnerability is in the application logic rather than a dependency, but the impact on network security is significant.
CVSS Breakdown & Threat Level
- CVSS Score: 8.0 (High)
- Attack Vector (AV): Adjacent Network (AV:A) – The attacker must be on the same network segment.
- Attack Complexity (AC): Low (AC:L) – No special conditions required.
- Privileges Required (PR): None (PR:N) – No authentication needed.
- User Interaction (UI): None (UI:N) – No user action required.
- Scope (S): Unchanged (S:U) – The vulnerability does not cross trust boundaries.
- Confidentiality (C): High (C:H) – Full disclosure of encrypted traffic.
- Integrity (I): High (I:H) – Attacker can modify traffic.
- Availability (A): High (A:H) – Attacker can disrupt communications.
Threat Level: High. The vulnerability allows a MITM attacker to completely bypass IPsec encryption, leading to full compromise of network traffic confidentiality, integrity, and availability.
Deep Dive & Mechanics
Cilium uses IPsec in transport mode with ESP to encrypt traffic between nodes in a Kubernetes cluster. The vulnerability arises from the use of a single, shared IPsec key for all tunnels between nodes. When multiple nodes use the same key, the ESP sequence number (a 32-bit counter) can collide across different tunnels. This collision enables several cryptographic attacks:
- Chosen Plaintext Attack: An attacker who can inject packets into the network can observe the encrypted output and deduce the key.
- Key Recovery: By analyzing multiple encrypted packets with the same sequence number, the attacker can recover the encryption key.
- Replay Attack: The attacker can capture and replay valid encrypted packets, as the sequence number check is bypassed due to collisions.
The root cause is in the IPsec key management logic, where a single key is derived and reused for all Security Associations (SAs). The fix ensures that each node pair gets a unique key, preventing sequence number collisions.
Vulnerable vs. Patched Code
Vulnerable Code (Conceptual):
// In the IPsec key setup, a single key is used for all tunnels
func setupIPsec() {
key := generateKey()
for _, node := range nodes {
createSA(node, key) // Same key for all nodes
}
}
Patched Code (Conceptual):
// In the patched version, a unique key is generated per node pair
func setupIPsec() {
for _, node := range nodes {
key := generateUniqueKey() // Unique key per tunnel
createSA(node, key)
}
}
The actual fix involves changes to the pkg/datapath/linux/ipsec package in Cilium, where the key derivation function is modified to include the node identity.
Exploitation & Lab Setup
Red Team (Attacker)
Prerequisites:
- Access to the same network segment as the Cilium nodes (e.g., via a compromised pod or physical access).
- Ability to sniff and inject packets (e.g., using
tcpdumpandscapy).
Exploitation Steps:
- Sniff IPsec ESP packets between two Cilium nodes to capture encrypted traffic.
- Identify sequence number collisions by monitoring the ESP sequence number field across multiple tunnels.
- Perform a chosen plaintext attack by injecting known plaintext packets and observing the ciphertext.
- Recover the key using cryptanalysis (e.g., linear or differential cryptanalysis).
- Decrypt and modify traffic at will, or replay captured packets.
Lab Setup:
- Deploy a Kubernetes cluster with Cilium (vulnerable version) and IPsec enabled.
- Use a separate machine on the same network to run
tcpdumpandscapyfor packet manipulation.
Example Scapy Script (Conceptual):
from scapy.all import *
# Sniff ESP packets
def analyze_esp(pkt):
if ESP in pkt:
print(f"SPI: {pkt[ESP].spi}, Seq: {pkt[ESP].seq}")
sniff(prn=analyze_esp, filter="esp")
Blue Team (Defender)
Detection:
- Monitor for unusual ESP sequence number patterns (e.g., repeated sequence numbers across different SPIs).
- Use network anomaly detection to flag potential MITM activity.
Mitigation:
- Immediately upgrade Cilium to a patched version (1.13.13, 1.14.9, or 1.15.3).
- If upgrade is not possible, disable IPsec encryption temporarily and use alternative encryption (e.g., WireGuard).
- Implement network segmentation to limit attacker access to the same network segment.
Indicators of Compromise (IOCs)
- Network IOCs:
- ESP packets with identical sequence numbers but different SPIs (Security Parameter Indexes).
- Unusual patterns of ESP packet retransmissions or replays.
- Host IOCs:
- Cilium agent logs showing IPsec key generation errors or warnings.
- Unexpected changes in IPsec Security Association (SA) configurations.
- File IOCs:
- Modified Cilium configuration files related to IPsec key management.
Detection Engineering
YARA Rule
rule CVE_2024_28860_IPsec_Key_Reuse {
meta:
description = "Detects Cilium IPsec key reuse vulnerability indicators"
author = "Valters IT"
date = "2024-10-27"
reference = "CVE-2024-28860"
strings:
$key_reuse = "ipsec-key" nocase
$shared_key = "shared-key" nocase
condition:
any of them
}
Sigma Rule
title: Cilium IPsec Key Reuse Detection
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects potential exploitation of CVE-2024-28860 by monitoring for ESP sequence number collisions
author: Valters IT
date: 2024/10/27
logsource:
category: network
product: suricata
detection:
selection:
event_type: alert
alert.signature_id: 3000001
condition: selection
falsepositives:
- Legitimate IPsec traffic with low sequence numbers
level: high
Suricata Rule
alert ip any any -> any any (msg:"CVE-2024-28860 - Cilium IPsec Key Reuse - ESP Sequence Number Collision"; ip_proto:esp; content:"|00 00 00 01|"; depth:4; offset:4; sid:3000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Upgrade Cilium to version 1.13.13, 1.14.9, or 1.15.3.
- Verify the upgrade by checking the Cilium agent logs for IPsec key generation messages.
- If upgrade is not possible, disable IPsec encryption and use an alternative like WireGuard or Calico with encryption.
Long-term Measures:
- Implement network segmentation to limit the attack surface.
- Use network monitoring tools to detect anomalous ESP traffic.
- Regularly audit Cilium configurations for security best practices.
Workaround:
- For clusters that cannot be upgraded, consider using a different CNI plugin that supports encryption, or use application-level encryption (e.g., mTLS).
Valters IT