Exploits de kernel en Linux: PwnKit, Dirty Pipe y OverlayFS

Un exploit de kernel es la última bala, no la primera: puede colgar la máquina y casi nunca es el camino que pensó el creador. Pero hay un puñado de vulnerabilidades tan fiables y tan extendidas que conviene comprobarlas siempre, sobre todo en máquinas antiguas. Esta guía va de cuándo probarlos y cuáles.

Antes de nada: ¿es el camino?

Si la máquina es de 2020 o posterior y no has revisado sudo -l, SUID, capabilities, cron y credenciales, no es el momento (ver sudo, SUID y capabilities y cron, PATH y grupos). Las pistas de que sí lo es:

• El kernel o el sistema son muy viejos para la fecha de la máquina.
• No hay nada más después de una enumeración completa.
• La máquina lo insinúa (un correo sobre "parchear el kernel" en TwoMillion).

Sacar las versiones exactas

uname -a                       # versión del kernel
cat /etc/os-release            # distribución y versión
sudo --version | head -1       # versión de sudo
pkexec --version               # polkit (PwnKit)
dpkg -l | grep -E 'linux-image|polkit|sudo'   # paquetes y su parche concreto

Ojo: una Ubuntu con kernel 5.15.0-56 puede estar parcheada aunque el número "suene" vulnerable. Las distribuciones aplican parches sin cambiar la versión base; compara con el aviso de seguridad de la distro (USN en Ubuntu, DSA en Debian).

Las herramientas que lo cruzan por ti:

./linux-exploit-suggester.sh            # lista CVE candidatos con su probabilidad
./linpeas.sh -s                         # la sección "Linux Exploit Suggester"

Los que más funcionan

PwnKit y Baron Samedit no son del kernel en sentido estricto, pero se buscan a la vez y son los primeros que hay que probar: funcionan sin compilar nada raro y casi nunca rompen la máquina. Baron Samedit es la escalada de RouterSpace; Dirty COW, una vía alternativa en Valentine.

Compilar sin romperte la cabeza

El exploit tiene que compilarse para la misma arquitectura y una glibc compatible. Por orden de preferencia:

1. Si la víctima tiene gcc, compila allí: gcc exploit.c -o exp && ./exp.
2. Si no, compila en tu máquina estático: gcc -static exploit.c -o exp -lpthread. Funciona aunque la glibc de la víctima sea más antigua.
3. Para 32 bits: gcc -m32 -static ... (necesitas gcc-multilib).
4. Algunos exploits (PwnKit, varias de OverlayFS) tienen versiones en Python o en shell que no necesitan compilar.

Si el binario se queja de GLIBC_2.34 not found, es que no lo compilaste estático o tu glibc es más nueva: usa la opción 2 o compílalo dentro de un contenedor de la misma versión de la distro (docker run -it ubuntu:18.04).

Usarlos con cuidado

• Lee el código antes. Muchos exploits viejos de Exploit-DB modifican /etc/passwd o dejan el sistema inestable; haz copia (cp /etc/passwd /tmp/passwd.bak) para devolverlo a su estado.
• Los exploits de condición de carrera (Dirty COW) pueden tardar o colgar la máquina: prueba primero las variantes que escriben un fichero en vez de las que alteran la memoria.
• Si el exploit lo pide, ejecuta desde /tmp o /dev/shm y comprueba que no están montados con noexec (mount | grep shm).

Si nada de esto sale, vuelve a la chuleta de escalada en Linux: casi siempre se ha quedado algo sin mirar.