Dirty-Frag-CVE-2026-43284

Dirty Frag (CVE‑2026‑43284 & CVE‑2026‑43500) — Laboratorio de Reproducción y Detección de Exploits

Este repositorio documenta la reproducción de extremo a extremo, la ingeniería de detección y la respuesta a incidentes para la cadena de escalada de privilegios local (LPE) del kernel de Linux Dirty Frag. Dirty Frag encadena dos errores de lógica deterministas —CVE‑2026‑43284 (xfrm/ESP) y CVE‑2026‑43500 (RxRPC)— para permitir que un usuario local sin privilegios sobrescriba la caché de páginas de archivos de solo lectura (p. ej., /usr/bin/su) y obtenga una shell de root.

Hallazgos Clave

• ✅ Explotamos con éxito Dirty Frag en Kali Linux 2026.1 (kernel 6.18.12+kali‑amd64)
• ✅ Desplegamos reglas de detección de auditd a nivel de llamadas al sistema
• ✅ Creamos reglas Sigma y YARA para detección multiplataforma
• ✅ Desarrollamos un playbook completo de respuesta a incidentes
• ✅ Documentamos cada paso con capturas de pantalla para uso en portafolio

Por qué es importante

Dirty Frag es un defecto lógico, no una corrupción de memoria. Es determinista, afecta a prácticamente todas las distribuciones de Linux lanzadas desde 2017 y es completamente fileless —las soluciones tradicionales de monitorización de integridad de archivos (AIDE, Tripwire) no pueden verlo. El PoC público es un único archivo C que encadena las rutas de ESP y RxRPC.

Entorno de Laboratorio

Pasos de Reproducción

1. Verificar la versión de Kali y el kernel

El laboratorio comienza confirmando que el objetivo ejecuta un kernel vulnerable.

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

📸 screenshots/pre_exploit_id.png — Detalles de la versión de Kali 2026.1 y del kernel. La salida de uname -r muestra el kernel vulnerable 6.18.12+kali‑amd64.

2. Comprobar los módulos vulnerables

El exploit requiere los módulos del kernel esp4, esp6 y rxrpc.

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

📸 screenshots/module_mitigation.png — lsmod y modinfo confirman que los módulos vulnerables están disponibles.

3. Versión de Python

La variante del PoC basada en Python necesita Python 3.10+. Verificamos el intérprete.

python3 --version

Python 3.12 está instalado y listo.

4. Comprobador de vulnerabilidad (no destructivo)

Antes de ejecutar el exploit completo, un script comprobador seguro confirma que el sistema es vulnerable.

python3 poc/check_vulnerable.py

El comprobador informa de "potentially vulnerable", allanando el camino para la explotación.

5. Crear un usuario sin privilegios

Una cuenta testuser sin privilegios simula un atacante sin derechos especiales.

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

📸 id muestra el UID 1001, confirmando el acceso sin root.

6. Clonar y ejecutar el exploit

El PoC oficial de V4bel se clona y compila desde la cuenta sin privilegios.

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

📸 screenshots/exploit_execution.png — El exploit sobrescribe la caché de páginas de /usr/bin/su y detona el binario corrupto.

📸 screenshots/post_exploit_root.png — la salida de whoami e id demuestra la escalada completa a root.

7. Verificar la naturaleza fileless (sin modificación en disco)

El exploit solo corrompe la caché de páginas en memoria. El /usr/bin/su en disco conserva su checksum original.

sha256sum /usr/bin/su

El sha256sum coincide con el hash del paquete original incluso después de la explotación, lo que confirma que no hay modificación en disco.

8. Limpieza posterior al exploit (¡Crítico!)

Después de ejecutar el exploit, la caché de páginas queda contaminada. Vacíala siempre:

echo 3 | sudo tee /proc/sys/vm/drop_caches
# Or reboot the system

Ingeniería de Detección

Dirty Frag no puede detectarse mediante la monitorización de integridad de archivos. En su lugar, nos centramos en las primitivas a nivel de llamadas al sistema que utiliza. Reglas de auditd

Desplegamos reglas de auditd personalizadas que se activan cuando:

Creación de socket(AF_ALG) de la familia 38 y socket(AF_RXRPC) de la familia 21

Uso de la llamada al sistema splice()

Creación de namespace con unshare(CLONE_NEWUSER | CLONE_NEWNET)

Acceso de lectura a binarios setuid por parte de procesos sin privilegios

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

Todas las reglas personalizadas están activas, verificado con auditctl -l.

Después de ejecutar el exploit una segunda vez, vemos alertas para las llamadas al sistema exactas utilizadas:

ausearch -k dirtyfrag_af_alg muestra un evento de creación de socket AF_ALG del proceso testuser

ausearch -k dirtyfrag_splice muestra un evento splice() del mismo PID, una correlación sólida

ausearch -k dirtyfrag_namespace muestra la creación de namespace

Regla Sigma

Una regla Sigma traduce los hallazgos de auditd a un formato SIEM neutral respecto al proveedor.

Archivo: detection/sigma/dirty_frag_exploit.yml

Regla YARA

Una regla YARA ayuda a identificar código de exploit de Dirty Frag en disco y en memoria.

Archivo: detection/yara/dirty_frag_exploit.yar

Resumen de Cobertura de Detección Capa Lo que ve Estado auditd Socket AF_ALG/AF_RXRPC + llamadas al sistema splice + unshare ✅ Desplegado Sigma Patrones de syscalls vía SIEM ✅ Regla lista YARA Código PoC en disco / en memoria ✅ Regla lista FIM (AIDE/Tripwire) Cambios en archivos ❌ Ciego – no se produce ninguna escritura en disco

Playbook de Respuesta a Incidentes

Un informe completo de respuesta a incidentes está disponible en reports/incident-dirtyfrag.md. Incluye:

Resumen ejecutivo — se observó explotación de Dirty Frag

Indicadores de compromiso (IoCs) — alertas de auditd por creación de sockets AF_ALG/AF_RXRPC, llamadas a splice(), eventos de namespace con unshare y ejecución de binarios SUID por procesos no root

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

Pasos de contención y erradicación — bloqueo de módulos, vaciado de la caché de páginas, actualización del kernel

Lecciones aprendidas sobre los ataques fileless y la importancia de la auditoría a nivel de llamadas al sistema

Mitigación

Mitigación inmediata (sin necesidad de reiniciar):

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

⚠️ Impacto: deshabilitar estos módulos rompe las VPN IPsec y la funcionalidad del sistema de archivos AFS.

Se incluye un script de mitigación listo para usar en mitigation/dirtyfrag_mitigation.sh.

Solución permanente: actualiza tu kernel a una versión parcheada.