Exploits de kernel en Linux: qué son, cuándo se usan y cómo mantener un servidor al día

El kernel es el programa más privilegiado de un sistema Linux: gestiona la memoria, los procesos, los dispositivos y los permisos. Todo lo demás (shells, navegadores, servidores) funciona por encima y le pide permiso para hacer cualquier cosa importante. Si el kernel tiene un fallo de seguridad explotable, no hay prácticamente defensa a nivel de aplicación: un atacante con acceso a una cuenta normal puede convertirse en root en un solo paso.

Los exploits de kernel son programas que aprovechan esos fallos. En los laboratorios de whoami-labs aparecen de vez en cuando como la vía prevista para resolver el reto, pero en una auditoría real suelen ser el último recurso: son ruidosos, pueden tumbar el servidor y requieren que el entorno coincida exactamente con el del exploit. Casi siempre es mejor buscar una escalada por SUID, sudo, cron o capabilities antes de pensar en el kernel.

En esta lección vas a ver qué es un exploit de kernel, cómo identificar la versión y qué exploits podrían aplicar, por qué deben usarse con precaución, los exploits famosos que conviene conocer y cómo mantener un sistema al día para no ser vulnerable.

Practica solo en sistemas propios o en entornos autorizados, como los laboratorios de whoami-labs. Ejecutar exploits en sistemas ajenos sin permiso es un delito.

Qué es un exploit de kernel#

El kernel vive en un modo privilegiado llamado anillo 0 (ring 0), donde puede acceder a cualquier parte del sistema. Las aplicaciones corren en el anillo 3 (ring 3), con permisos limitados, y deben pedirle al kernel cualquier operación sensible usando una llamada al sistema (syscall).

Si una de esas syscalls tiene un fallo (un desbordamiento de memoria, una condición de carrera, un uso de memoria después de liberarla), un atacante puede enviarle argumentos cuidadosamente preparados desde el anillo 3 para que el kernel ejecute lo que no debería. El resultado típico: el proceso atacante pasa a ejecutarse con UID 0 (root).

Por qué son tan graves#

• Saltan toda defensa de aplicación. Un firewall, un WAF o SELinux pueden dificultarlos, pero no están pensados para fallos del propio kernel.
• Afectan a cualquiera con cuenta local. No necesitan configuraciones especiales en el sistema.
• Convierten un acceso de usuario en root. Es la escalada más directa posible.

Cuándo se usan y cuándo no#

El equipo de respuesta a incidentes del cliente va a notar ejecuciones del kernel que no cuadran, cierres inesperados del servidor y entradas raras en los registros. En una auditoría ética, usar un exploit de kernel sin avisar al cliente es un error profesional grave.

Identificar versión y exploits aplicables#

Datos del sistema#

Tras conseguir una shell en un laboratorio autorizado, obtén tres datos clave:

uname -a               # kernel y arquitectura
cat /etc/os-release    # distribución y versión
lsb_release -a         # alternativa en algunas distribuciones

El resultado de uname -a incluye algo como Linux lab 5.4.0-91-generic #102-Ubuntu. Eso te da el número de versión, la arquitectura (x86_64, aarch64) y la distribución, que son lo que necesitas para buscar exploits.

Qué exploits aplican#

# Buscar exploits que mencionen la versión
searchsploit "Linux Kernel 5.4"

# Linux Exploit Suggester
./linux-exploit-suggester.sh

El suggester marca cada CVE con una «probabilidad» y un enlace al PoC. Léelos con cuidado: muchos requieren configuraciones concretas (cierta opción de compilación del kernel, cierto módulo cargado) y no funcionan en todos los sistemas aunque la versión coincida.

Comprobar antes de ejecutar#

Antes de ejecutar nada en un laboratorio, revisa:

• El código fuente del exploit: evita binarios de autor desconocido.
• Las precondiciones: qué módulos del kernel deben estar activos, qué privilegios iniciales se asumen.
• Los riesgos: ¿puede provocar un pánico del kernel y tumbar la máquina?

En auditorías con un cliente real, lo habitual es probar primero en una máquina clonada y, si se va a ejecutar en producción, hacerlo fuera de hora pico y con el equipo del cliente al tanto.

Las familias de fallos que ves una y otra vez#

No todos los exploits de kernel son iguales. Conocer las familias habituales ayuda a leer un aviso de seguridad y entender de qué va:

Dirty COW fue una condición de carrera; DirtyPipe un fallo en el estado de las tuberías. Casi todos los exploits famosos encajan en una de estas cajas. Al leer un CVE, identificar la familia da mucha información sobre lo que puede o no hacerse con él.

Exploits de kernel famosos#

Conocer algunos casos reales ayuda a entender el panorama. Son todos públicos y bien documentados.

Dirty COW (CVE-2016-5195)#

Condición de carrera en el subsistema de memoria COW (copy-on-write). Afectó a prácticamente todas las versiones de Linux desde 2007 hasta octubre de 2016. Permitía a un usuario normal escribir en archivos de solo lectura, incluidos binarios de root. Durante años fue el ejemplo de exploit de kernel sencillo y fiable.

DirtyPipe (CVE-2022-0847)#

Error en las tuberías anónimas (pipes) introducido en Linux 5.8. Permitía a un usuario normal sobrescribir archivos de solo lectura, incluidos binarios SUID del sistema. La prueba de concepto más famosa sobreescribía /etc/passwd para añadir un usuario con UID 0. Se corrigió en 5.16.11, 5.15.25 y 5.10.102.

PwnKit (CVE-2021-4034)#

No es técnicamente un exploit de kernel, sino de polkit (una herramienta de sistema, con SUID de root), pero aparece siempre en las listas por ser muy fiable, no requerir configuraciones especiales y afectar a casi todas las distribuciones mayoritarias con una versión de polkit antigua. Es útil como recordatorio de que las escaladas no tienen que ser del kernel.

Baron Samedit (CVE-2021-3156)#

Otro «no es kernel pero suena igual»: un desbordamiento en sudo que, bien aprovechado, da root. También está en casi todas las guías porque funcionó en muchísimos sistemas durante años.

Estos ejemplos ilustran algo importante: el objetivo de un auditor es conseguir root, no necesariamente «ejecutar un exploit de kernel». Si una vulnerabilidad en sudo o polkit lo logra con menos riesgo, es la elección correcta.

Cómo defenderse#

Mantener el kernel actualizado#

Es la defensa principal. Las distribuciones publican parches regularmente; aplicarlos pronto cierra la ventana en la que un exploit funciona:

# Debian / Ubuntu
sudo apt update && sudo apt upgrade
sudo reboot

# RHEL / CentOS / Rocky
sudo dnf upgrade
sudo reboot

Para evitar el reinicio, soluciones como kpatch, Ksplice o livepatch aplican parches en caliente. Son muy útiles en servidores críticos.

Reducir la superficie de ataque#

• Mínimo privilegio: menos cuentas con acceso local significa menos candidatos a usar un exploit.
• Módulos de kernel mínimos: desactiva los que no se usen, con rmmod y /etc/modprobe.d/*.conf.
• Aislamiento: contenedores con user namespaces y syscalls restringidas (seccomp), SELinux o AppArmor con políticas estrictas.
• No ejecutar como root lo que no debe serlo: aunque un exploit llegue, si la aplicación corre en un entorno aislado, el daño queda limitado.

Detección#

• auditd puede registrar llamadas al sistema sospechosas.
• Falco y Tetragon detectan patrones de abuso de syscalls en tiempo real.
• Alertar ante UID efectivos cambiados de forma inesperada, procesos que acceden a /dev/mem o /dev/kmem, o módulos de kernel cargados a destiempo.

Suscripciones de seguridad#

Para servidores críticos, suscripciones como Ubuntu Pro, Red Hat Insights u Oracle Ksplice incluyen parches en caliente y avisos tempranos. En entornos regulados compensan el coste.

Errores comunes#

• Saltar directamente al exploit de kernel sin revisar SUID, sudo y capabilities. La mayoría de las escaladas se pueden hacer sin kernel.
• Ejecutar binarios compilados de autores desconocidos. Pueden contener puertas traseras.
• No comprobar precondiciones. Un exploit para Ubuntu 20.04 puede fallar en Debian aunque el kernel sea similar.
• Olvidar los contenedores. Un exploit funcionando dentro de un contenedor puede comprometer también al anfitrión si no hay aislamiento.
• Posponer actualizaciones «porque reiniciar molesta». Los exploits de kernel públicos se usan contra servidores sin parchear durante años.

Preguntas frecuentes#

¿Qué diferencia hay entre un exploit de kernel y uno de aplicación?#

Un exploit de aplicación abusa de un fallo en un programa normal (por ejemplo, un servidor web). Un exploit de kernel abusa de un fallo en el núcleo del sistema, con lo que consigue directamente privilegios de root.

¿Son más peligrosos los exploits de kernel?#

Potencialmente sí, porque saltan la mayoría de defensas de aplicación. Pero son menos frecuentes de ver en acción porque dependen de que el sistema no esté actualizado y requieren precisión.

¿Un parche en caliente es seguro?#

Sí, cuando lo proporciona el proveedor oficial (Ubuntu, Red Hat, Oracle). Evita el reinicio aplicando el parche en memoria. Tiene algunas limitaciones (no todos los cambios se pueden parchear en caliente), por lo que el reinicio ocasional sigue siendo necesario.

¿Un contenedor me protege del kernel?#

Solo en parte: el contenedor y el anfitrión comparten el mismo kernel. Si el kernel es vulnerable, un proceso en el contenedor puede intentar un exploit igualmente. Las capabilities y seccomp limitan mucho ese riesgo.

¿Dónde practico?#

En los laboratorios con la etiqueta de kernel enlazados al final de esta lección, donde un exploit de kernel es parte del recorrido para resolver el reto.

Resumen#

• Un exploit de kernel aprovecha un fallo en el núcleo del sistema para dar root desde una cuenta sin privilegios.
• Son la escalada más poderosa, pero también la más ruidosa y arriesgada: suelen ser el último recurso en una auditoría.
• Para usarlos, identifica versión con uname -a, busca con searchsploit y linux-exploit-suggester, y revisa precondiciones.
• Dirty COW, DirtyPipe, PwnKit y Baron Samedit son los ejemplos clásicos que todo auditor debe conocer.
• La defensa es actualizar el kernel, aislar, reducir privilegios y detectar comportamientos anómalos.

Fuentes y lecturas recomendadas#

• Exploit-DB: buscador de exploits
• Linux Exploit Suggester
• Ubuntu Livepatch
• MITRE ATT&CK T1068: Exploitation for Privilege Escalation
• Kernel.org: política de seguridad