Dirty-Frag-CVE-2026-43284

Dirty Frag (CVE‑2026‑43284 & CVE‑2026‑43500) — Laboratorio di Riproduzione e Rilevamento dell'Exploit

Questo repository documenta la riproduzione end‑to‑end, l'ingegneria del rilevamento e la risposta agli incidenti per la catena di escalation dei privilegi locali (LPE) Dirty Frag del kernel Linux. Dirty Frag combina due bug logici deterministici—CVE‑2026‑43284 (xfrm/ESP) e CVE‑2026‑43500 (RxRPC)—per consentire a un utente locale non privilegiato di sovrascrivere la cache delle pagine di file di sola lettura (ad es., /usr/bin/su) e ottenere una shell di root.

Risultati Chiave

• ✅ Sfruttato con successo Dirty Frag su Kali Linux 2026.1 (kernel 6.18.12+kali‑amd64)
• ✅ Implementate regole di rilevamento a livello di syscall con auditd
• ✅ Create regole Sigma e YARA per il rilevamento multipiattaforma
• ✅ Sviluppato un playbook completo di risposta agli incidenti
• ✅ Documentato ogni passaggio con screenshot per uso nel portfolio

Perché è Importante

Dirty Frag è un difetto logico, non una corruzione di memoria. È deterministico, colpisce praticamente ogni distribuzione Linux rilasciata dal 2017, ed è completamente fileless—il tradizionale monitoraggio dell'integrità dei file (AIDE, Tripwire) non può vederlo. Il PoC pubblico è un singolo file C che combina sia i percorsi ESP che RxRPC.

Ambiente di Laboratorio

Passaggi di Riproduzione

1. Verifica Versione Kali e Kernel

Il laboratorio inizia confermando che il target esegue un kernel vulnerabile.

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

📸 screenshots/pre_exploit_id.png — Dettagli della versione di Kali 2026.1 e del kernel. L'output di uname -r mostra il kernel vulnerabile 6.18.12+kali‑amd64.

2. Verifica dei Moduli Vulnerabili

L'exploit richiede i moduli del kernel esp4, esp6 e rxrpc.

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

📸 screenshots/module_mitigation.png — lsmod e modinfo confermano che i moduli vulnerabili sono disponibili.

3. Versione di Python

La variante basata su Python del PoC richiede Python 3.10+. Verifichiamo l'interprete.

python3 --version

Python 3.12 è installato e pronto.

4. Verifica della Vulnerabilità (Non Distruttiva)

Prima di eseguire l'exploit completo, uno script di verifica sicuro conferma che il sistema è vulnerabile.

python3 poc/check_vulnerable.py

Lo script di verifica riporta "potentially vulnerable", aprendo la strada allo sfruttamento.

5. Creazione di un Utente Non Privilegiato

Un account testuser non privilegiato simula un attaccante senza diritti speciali.

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

📸 id mostra UID 1001, confermando l'accesso non root.

6. Clonazione ed Esecuzione dell'Exploit

Il PoC ufficiale di V4bel viene clonato e compilato dall'account non privilegiato.

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

📸 screenshots/exploit_execution.png — L'exploit sovrascrive la cache delle pagine di /usr/bin/su e fa detonare il binario corrotto.

📸 screenshots/post_exploit_root.png — L'output di whoami e id dimostra la piena escalation a root.

7. Verifica della Natura Fileless (Nessuna Modifica al Disco)

L'exploit corrompe solo la cache delle pagine in memoria. Il /usr/bin/su su disco mantiene il suo checksum originale.

sha256sum /usr/bin/su

Lo sha256sum corrisponde all'hash del pacchetto originale anche dopo lo sfruttamento, confermando che non vi è alcuna modifica su disco.

8. Pulizia Post-Exploit (Critica!)

Dopo l'esecuzione dell'exploit, la cache delle pagine è contaminata. Svuotarla sempre:

echo 3 | sudo tee /proc/sys/vm/drop_caches
# Oppure riavviare il sistema

Ingegneria del Rilevamento

Dirty Frag non può essere rilevato dal monitoraggio dell'integrità dei file. Ci concentriamo invece sulle primitive a livello di syscall che utilizza.

Regole auditd

Implementiamo regole auditd personalizzate che si attivano su:

creazione di socket AF_ALG (famiglia 38) e AF_RXRPC (famiglia 21)

utilizzo della syscall splice()

creazione di namespace con unshare(CLONE_NEWUSER | CLONE_NEWNET)

accesso in lettura a binari setuid da parte di processi non privilegiati

# /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

Tutte le regole personalizzate sono attive, verificate con auditctl -l.

Dopo aver eseguito l'exploit una seconda volta, vediamo avvisi per le syscall esatte utilizzate:

ausearch -k dirtyfrag_af_alg mostra un evento di creazione socket AF_ALG dal processo testuser

ausearch -k dirtyfrag_splice mostra un evento splice() dallo stesso PID, una forte correlazione

ausearch -k dirtyfrag_namespace mostra la creazione di namespace

Regola Sigma

Una regola Sigma traduce i risultati di auditd in un formato SIEM indipendente dal fornitore.

File: detection/sigma/dirty_frag_exploit.yml

Regola YARA

Una regola YARA aiuta a identificare il codice dell'exploit Dirty Frag su disco e in memoria.

File: detection/yara/dirty_frag_exploit.yar

Riepilogo della Copertura di Rilevamento

Livello | Cosa Rileva | Stato ---|--- auditd | socket AF_ALG/AF_RXRPC + syscall splice + unshare | ✅ Implementato Sigma | Pattern di syscall tramite SIEM | ✅ Regola pronta YARA | Codice PoC su disco / in memoria | ✅ Regola pronta FIM (AIDE/Tripwire) | Modifiche ai file | ❌ Cieco – non avviene alcuna scrittura su disco

Playbook di Risposta agli Incidenti

Un report completo di risposta agli incidenti è disponibile in reports/incident-dirtyfrag.md. Include:

Executive summary — osservato sfruttamento di Dirty Frag

Indicatori di compromissione (IoC) — avvisi auditd per creazione socket AF_ALG/AF_RXRPC, chiamate splice(), eventi di namespace unshare ed esecuzione di binari SUID da parte di processi non root

Mappatura MITRE ATT&CK — T1068 (Exploitation for Privilege Escalation), T1611 (Escape to Host)

Passaggi di contenimento ed eradicazione — blacklist dei moduli, svuotamento della cache delle pagine, aggiornamento del kernel

Lezioni apprese riguardo agli attacchi fileless e all'importanza del auditing a livello di syscall

Mitigazione

Mitigazione immediata (senza riavvio):

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

⚠️ Impatto: La disabilitazione di questi moduli interrompe le VPN IPsec e la funzionalità del filesystem AFS.

Uno script di mitigazione pronto all'uso è incluso in mitigation/dirtyfrag_mitigation.sh.

Fix permanente: aggiornare il kernel a una versione patchata.