Exploits de kernel en Linux

Cuando la escalada por malas configuraciones (sudo, SUID, cron, capabilities) no da fruto, queda explotar una vulnerabilidad en el propio kernel de Linux. Un exploit de kernel exitoso da root de forma directa, independientemente de permisos y configuraciones. Pero es el último recurso: muchos exploits son inestables, pueden tumbar (kernel panic) el host, y son muy ruidosos. Primero agota las vías de configuración (ver Escalada de privilegios en Linux).

Por qué es el último recurso

Riesgo de caída: un exploit mal portado puede causar un kernel panic y tirar el servidor (en un pentest real, esto es grave).
Ruido: los exploits de kernel suelen ser detectables por EDR y dejan rastros.
Fiabilidad variable: dependen de la versión exacta, arquitectura y mitigaciones (KASLR, SMEP/SMAP).

Por eso: enumera y prueba todo lo demás primero; el kernel solo cuando no haya otra.

Identificar la versión y mapear exploits

uname -a                       # versión exacta del kernel y arquitectura
cat /etc/os-release            # distro (afecta a qué parches tiene backporteados)
cat /proc/version
# herramientas que sugieren exploits según la versión
linux-exploit-suggester.sh     # (LES) mapea CVEs/exploits al kernel
linux-exploit-suggester-2.pl
# cruzar manualmente: searchsploit linux kernel <version>

Cuidado: la distro puede haber backporteado el parche sin cambiar el número de versión mayor. LES ayuda, pero verifica.

CVEs de kernel famosos (referencia)

Dirty COW (CVE-2016-5195)      race condition en COW -> escritura en ficheros de solo lectura
Dirty Pipe (CVE-2022-0847)     sobrescribir ficheros de solo lectura vía pipes -> root
PwnKit (CVE-2021-4034)         en realidad pkexec (SUID), no kernel, pero "root universal"
nf_tables (CVE-2024-1086)      use-after-free -> LPE
OverlayFS (varios)             CVE-2021-3493, CVE-2023-0386
Sequoia (CVE-2021-33909)       overflow en seq_file -> root

Dirty COW y Dirty Pipe son los más conocidos por su amplísimo alcance y fiabilidad relativa.

Flujo de explotación (con cuidado)

1. uname -a -> versión exacta
2. LES / searchsploit -> candidatos
3. Verificar que el exploit aplica (versión, arch, mitigaciones)
4. PREFERIR exploits conocidos y bien probados (Dirty Pipe suele ser estable)
5. Compilar en el objetivo o portar el binario (ojo con glibc/arch)
6. Ejecutar -> idealmente en lab/snapshot primero
7. Confirmar root (id) y estabilizar

Compilar en el objetivo requiere gcc; si no está, compila en una máquina con el mismo entorno o usa binarios precompilados compatibles.

Para la defensa

Parcheo del kernel al día (unattended-upgrades, livepatch/kpatch para no reiniciar): la defensa nº1.
Mitigaciones activas: KASLR, SMEP/SMAP, kernel.unprivileged_userns_clone=0, kernel.kptr_restrict, lockdown.
Reducir superficie: deshabilitar módulos/funcionalidad innecesaria, seccomp, AppArmor/SELinux.
EDR que detecte patrones de exploit de kernel; monitorizar compilaciones/ejecuciones sospechosas.
Grsecurity/hardened kernels en entornos críticos.

Checklist de prueba

uname -a + distro → versión y arquitectura exactas
LES / searchsploit para mapear exploits
Verificar aplicabilidad (versión, arch, mitigaciones)
Haber agotado antes las vías de configuración (Escalada de privilegios en Linux)
Preferir exploits estables (Dirty Pipe, etc.)
Probar en lab/snapshot antes del objetivo real
Confirmar root y estabilizar la shell
Blue: ¿kernel parcheado, mitigaciones, EDR?