Escalada de privilegios en Linux

Tienes una shell en un Linux, pero como un usuario cualquiera. El objetivo de este módulo es llegar a root, y la buena noticia es que en Linux casi nunca hace falta un exploit del kernel: la inmensa mayoría de las escaladas se deben a configuraciones descuidadas que el sistema te deja usar en tu contra. Enumerar bien es el 90% del trabajo.

1. El modelo de permisos de Linux

Cada usuario tiene un UID; el UID 0 es root, que se salta todas las comprobaciones. Cada fichero tiene permisos de lectura/escritura/ejecución para dueño, grupo y otros. La pieza que hace posible casi toda la escalada es el bit SUID:

• Un ejecutable con el bit SUID activado corre con los privilegios de su dueño, no de quien lo lanza. Si el dueño es root y tú lo ejecutas, ese programa corre como root durante su ejecución.
• Es un mecanismo legítimo (lo usa passwd para modificar /etc/shadow, por ejemplo). El problema aparece cuando un binario SUID root permite, de forma directa o indirecta, ejecutar comandos o leer ficheros arbitrarios.
• Se reconoce por la s en los permisos (-rwsr-xr-x) y se busca con find / -perm -4000.

La escalada consiste, casi siempre, en encontrar algo que corre como root (un SUID, una regla sudo, un cron, un servicio) y que tú puedas influir.

2. Metodología: enumerar primero

Antes de nada, se recoge el estado del sistema. Los comandos base, por orden:

$ id ; sudo -l                            # quién eres y qué puedes hacer con sudo
find / -perm -4000 -type f 2>/dev/null  # binarios SUID
getcap -r / 2>/dev/null                 # capabilities
ls -l /etc/passwd /etc/shadow           # ¿permisos anómalos?
cat /etc/crontab /etc/cron.d/*          # tareas programadas
uname -a ; cat /etc/os-release          # versión, por si hay exploit de kernel

Automatizado, el estándar es LinPEAS (de la suite PEASS-ng): enumera todo esto y resalta en color lo explotable. pspy observa procesos y cron sin ser root. No sustituyen al criterio, pero no se te escapa nada.

3. Binarios SUID y GTFOBins

No todo binario SUID es explotable; lo es si permite salirse de su función para ejecutar comandos o leer ficheros como root. La referencia imprescindible es GTFOBins: un catálogo de binarios de Unix y de cómo abusar de cada uno según el contexto (SUID, sudo, capabilities). Por ejemplo, si find es SUID root:

$ find . -exec /bin/sh -p \; -quit    # -p conserva los privilegios; shell como root

La lógica es siempre la misma: buscar en GTFOBins el binario que tienes y copiar la invocación correspondiente. Un binario SUID que solo lee ficheros (como el readlog del laboratorio) no da shell, pero sí te deja leer /etc/shadow o cualquier flag de root.

4. Abuso de sudo

sudo -l lista qué puedes ejecutar como otro usuario (normalmente root) y con qué condiciones. Cada binario permitido es un candidato de GTFOBins. Si puedes ejecutar awk como root:

$ sudo awk 'BEGIN{system("/bin/sh")}'    # shell root desde awk

Casos especiales que hay que reconocer: reglas NOPASSWD (no piden tu contraseña, ideales), el uso de comodines peligrosos, la variable LD_PRELOAD permitida en env_keep, y versiones de sudo con CVE propio. La lección de fondo: dar sudo sobre un binario que puede ejecutar código (editores, intérpretes, find, awk...) es dar root.

5. Capabilities

Las capabilities parten los superpoderes de root en piezas, para poder dar solo una a un binario sin hacerlo SUID completo. Suena más seguro, pero algunas piezas equivalen a root. La más peligrosa es cap_setuid: permite a un proceso cambiar su propio UID a 0. Si un intérprete la tiene:

$ getcap -r / 2>/dev/null                 # ...  /usr/bin/python3 cap_setuid+ep
/usr/bin/python3 -c 'import os; os.setuid(0); os.system("/bin/sh")'

Otras capabilities peligrosas: cap_dac_read_search (leer cualquier fichero), cap_dac_override (escribir cualquier fichero) y cap_sys_admin (casi todo). GTFOBins también documenta el abuso por capability.

6. Tareas programadas (cron)

Un cron que corre como root y ejecuta un script modificable por ti es root garantizado: editas el script, esperas al disparador y tu código corre con privilegios. Lo mismo si el cron llama a un binario por PATH relativo, o si usa comodines de forma insegura. Se enumeran en /etc/crontab, /etc/cron.d/ y con pspy (que además ve crons no listados). La comprobación clave es quién puede escribir el script que ejecuta el cron.

7. Ficheros críticos con permisos erróneos

• /etc/passwd escribible: si puedes escribir en él, añades una línea con un usuario de UID 0 y una contraseña que tú generas (openssl passwd), y haces su a él. Root instantáneo. Es un fallo grosero pero aparece.
• /etc/shadow legible: te llevas los hashes y los crackeas offline (módulo 12).
• Ficheros de configuración y backups legibles: /var/backups, .bash_history, ficheros .conf con contraseñas, claves SSH privadas dejadas donde no debían.

$ echo 'hacker:$(openssl passwd -1 clave):0:0::/root:/bin/bash' >> /etc/passwd
su hacker    # -> root

8. Secuestro de PATH

Si un programa privilegiado (un SUID, un script de root) invoca otro binario sin su ruta absoluta —por ejemplo system("id") en vez de system("/usr/bin/id")—, el sistema lo busca recorriendo el PATH. Si tú controlas una entrada del PATH que se consulta antes, colocas ahí un binario malicioso con ese nombre y el programa privilegiado ejecutará el tuyo:

$ cd /tmp && echo '/bin/sh' > id && chmod +x id
export PATH=/tmp:$PATH
/usr/local/bin/netcheck    # llama a 'id' -> ejecuta /tmp/id como root

La defensa: los programas privilegiados deben llamar a todo con ruta absoluta y sanear el PATH.

9. Credenciales y reutilización

A menudo la escalada no es un exploit sino una contraseña encontrada: en un fichero de configuración, en el historial de shell, en un backup. Y como la gente reutiliza contraseñas, la clave de un servicio suele ser también la de una cuenta del sistema. Un su otro_usuario con la contraseña hallada te mueve lateralmente, y desde esa nueva cuenta quizá haya una escalada que no tenías antes. Es el mismo hilo del módulo 3: los hallazgos se encadenan.

10. Kernel, como último recurso

Si la configuración está impecable, queda el kernel: un Linux antiguo puede ser vulnerable a un exploit local (Dirty COW, Dirty Pipe, PwnKit...). uname -a da la versión. Es el último recurso porque un exploit de kernel puede colgar la máquina; se prueba con cuidado y a ser posible en una réplica (módulo 10).

Autoevaluación

1. ¿Qué hace exactamente el bit SUID y por qué lo convierte en el centro de la escalada en Linux?
2. Tienes sudo sobre awk. ¿Cómo consigues una shell root y por qué funciona?
3. ¿Por qué una capability cap_setuid en un intérprete equivale a root?
4. ¿Qué hace explotable a un cron que corre como root?
5. Explica cómo se escala con un /etc/passwd escribible.
6. ¿Qué condición debe cumplir un binario privilegiado para ser vulnerable a secuestro de PATH?
7. ¿Por qué encontrar una contraseña en un fichero puede valer más que un exploit?