Linux kernel exploit

Un exploit de kernel aprovecha un fallo en el núcleo de Linux (o en uno de sus drivers / subsistemas) para ejecutar código con privilegios de anillo 0. En la práctica, eso se traduce en pasar de un usuario normal a root de un solo salto, sin depender de configuraciones erróneas ni de credenciales.

Cuándo es el vector. Es la escalada típica de sistemas viejos y sin parchear. Si la enumeración local (sudo -l, SUID, cron, capabilities, ficheros escribibles) no da nada, el siguiente paso es mirar la versión exacta del kernel y de la distribución. En ZenPhoto, la caja era un Ubuntu 10.04 con kernel 2.6.37: una release antigua, terreno perfecto para Full-Nelson (15704.c), que encadena los fallos CVE-2010-4258, CVE-2010-3850 y CVE-2010-3849 en el subsistema Econet para conseguir root.

El flujo de trabajo:

1. Identificar versión. uname -a da el kernel; cat /etc/issue o lsb_release -a, la distribución y su release.
2. Mapear a exploits. searchsploit 'Ubuntu 10.04' (o el kernel concreto) cruza la versión con la base de exploit-db; herramientas como linux-exploit-suggester automatizan la sugerencia.
3. Compilar en el objetivo (o para él). Muchos PoC son en C. Si la máquina tiene gcc, se compila allí mismo (gcc 15704.c -o exploit); si no, hay que compilar en una máquina con la toolchain y arquitectura compatibles y subir el binario.
4. Ejecutar. Si funciona, el proceso queda como root (id → uid=0).

Comandos del flujo

Identificar kernel, distribución y arquitectura:

uname -a; uname -r; arch
cat /etc/issue; cat /etc/os-release; lsb_release -a

Sugerir exploits (desde el atacante o subiendo el script al objetivo):

searchsploit "Linux Kernel 2.6.37"
searchsploit -m 15704                     # copiar el PoC al directorio actual
./linux-exploit-suggester.sh              # LES: subir y ejecutar en el objetivo
./les.sh -k 2.6.37
perl linux-exploit-suggester-2.pl -k 2.6.37

Compilar y ejecutar:

gcc 15704.c -o exploit && ./exploit       # compilar en el objetivo si hay gcc
gcc -m32 exp.c -o exp -pthread            # forzar 32 bits si la arquitectura lo pide
gcc -static exp.c -o exp                  # estatico para esquivar problemas de libc
id                                        # uid=0 confirma root

Exploits recurrentes:

gcc -pthread dirty.c -o dirty -lcrypt && ./dirty <pass>   # Dirty COW (CVE-2016-5195)
./PwnKit                                                  # PwnKit (CVE-2021-4034, polkit)
./dirtypipe                                               # DirtyPipe (CVE-2022-0847)

Matiz importante: el exploit depende de la versión exacta. No hay bala de plata. Full-Nelson sirve para kernels 2.6.x concretos; un Dirty COW (CVE-2016-5195) cubre un rango distinto; PwnKit (CVE-2021-4034) no es del kernel sino de polkit. Confirmar uname -r y la arquitectura antes de elegir ahorra intentos fallidos.

Riesgo operacional. Los exploits de kernel son los más propensos a provocar inestabilidad o un kernel panic que tumbe la máquina. En un laboratorio es asumible; en producción es ruidoso y peligroso, así que se reservan para cuando las demás vías están agotadas y, a ser posible, con un PoC probado y fiable.

Cómo detectarlo. El indicio más ruidoso es la inestabilidad: un kernel oops/panic o mensajes del subsistema explotado en dmesg//var/log/kern.log justo tras ejecutar un binario desconocido. Un exploit con éxito deja un proceso con transición a uid=0 cuyo padre es una shell de usuario sin privilegios (auditd sobre setuid/execve), y a menudo una compilación reciente (gcc <exp>.c en el historial y un binario nuevo en /tmp//dev/shm, FIM). Los PoC precompilados conocidos los marca el EDR por firma. En reposo, un uname -r antiguo sin parches es la exposición.

Defensa. Parchear y mantener el kernel al día es la única mitigación real. Los sistemas heredados que no se pueden actualizar deben aislarse de la red o jubilarse; mantener un Linux antiguo expuesto es indefendible.