Escalada de privilegios con binarios SUID en Linux: qué es, cómo se explota y cómo se corrige

Conseguir acceso a un servidor como un usuario sin privilegios es solo la mitad del camino. La otra mitad es la escalada de privilegios: pasar de ese usuario limitado a root, el administrador con control total. En Linux, una de las vías más clásicas y más frecuentes en los laboratorios son los binarios SUID.

El bit SUID es una función legítima del sistema: permite que ciertos programas hagan tareas que requieren privilegios, como cambiar tu contraseña. El problema aparece cuando ese permiso está en un programa que no debería tenerlo o en uno que puede ejecutar otras cosas. Entonces, cualquier usuario puede usarlo como escalera hasta root.

En esta lección vas a entender qué es el bit SUID, por qué es peligroso, cómo se encuentran los binarios SUID, cómo se explotan en un laboratorio autorizado y cómo se audita y endurece un sistema.

Practica estas técnicas solo en sistemas propios o en entornos autorizados, como los laboratorios de whoami-labs. Escalar privilegios en un sistema ajeno sin permiso es un delito.

Qué es el bit SUID#

En Linux, cada proceso se ejecuta con la identidad de un usuario. Normalmente, cuando ejecutas un programa, este corre con tus permisos. El bit SUID (Set User ID) cambia esa regla: un programa con SUID se ejecuta con los permisos de su propietario, no con los de quien lo lanza.

El ejemplo clásico es passwd. Para cambiar tu contraseña, el programa necesita escribir en /etc/shadow, un archivo que solo root puede modificar. Por eso passwd es propiedad de root y tiene el bit SUID: cualquier usuario lo ejecuta, pero el programa trabaja como root el tiempo justo para hacer su tarea, y está diseñado para no hacer nada más.

En la lista de permisos, el bit SUID aparece como una s en lugar de la x del propietario:

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 /usr/bin/passwd

Existe también el bit SGID (Set Group ID), que hace lo mismo con el grupo del archivo y aparece como una s en la posición del grupo.

Por qué es peligroso#

Un binario SUID de root es seguro solo si hace una única cosa controlada. El peligro aparece en tres situaciones:

1. Programas de uso general con SUID. Si find, vim, python, bash o cp tienen el bit SUID, cualquier usuario puede usarlos para ejecutar comandos, leer o escribir archivos como root, porque esos programas permiten hacer casi cualquier cosa.
2. Binarios propios mal programados. Un programa hecho en casa que llama a otros comandos sin ruta absoluta, que acepta argumentos sin validar o que tiene un desbordamiento de memoria.
3. Versiones vulnerables de binarios SUID legítimos con fallos conocidos.

La mala práctica de fondo casi siempre es la misma: alguien añadió el bit SUID «para que funcionara» algo, sin entender que estaba dando poderes de root a todo el sistema.

Cómo se enumeran los binarios SUID#

En un laboratorio, una vez dentro de la máquina, uno de los primeros comandos es buscar todos los archivos con el bit SUID:

find / -perm -4000 -type f 2>/dev/null

• -perm -4000 busca archivos con el bit SUID activado.
• 2>/dev/null oculta los errores de permisos en directorios que no puedes leer.

Para SGID, el valor es -2000, y puedes buscar ambos a la vez:

find / -perm /6000 -type f -exec ls -l {} \; 2>/dev/null

El resultado será una lista larga. La clave está en saber distinguir lo normal de lo sospechoso:

Herramientas como LinPEAS automatizan esta enumeración y resaltan los binarios peligrosos, pero conviene saber hacerlo a mano.

Usuario real y usuario efectivo#

Para entender por qué funciona la escalada hay que distinguir dos identidades que tiene cada proceso:

• El usuario real (UID): quién lanzó el programa. Sigue siendo tú.
• El usuario efectivo (EUID): con qué permisos actúa el programa. Es el que el sistema consulta al abrir archivos o ejecutar acciones.

En un proceso normal, los dos coinciden. Con un binario SUID de root, el usuario real es el tuyo, pero el efectivo es root, y eso es lo único que importa para acceder a archivos protegidos. Por eso, tras explotar un SUID, el comando id muestra algo como uid=1001(estudiante) euid=0(root): sigues siendo tú, pero actúas como root.

Dónde encaja en la enumeración#

Revisar los binarios SUID es solo una de las comprobaciones que se hacen al entrar a una máquina. Un recorrido ordenado evita pasar algo por alto:

Herramientas como LinPEAS recorren todo esto automáticamente, pero conocer cada comprobación te permite entender lo que encuentran y no depender de ellas.

Explotación paso a paso en un laboratorio#

Paso 1: encontrar el binario sospechoso#

En un laboratorio, tras entrar como el usuario estudiante, ejecutas la búsqueda y entre los binarios normales aparece uno que no debería estar ahí:

/usr/bin/passwd
/usr/bin/su
/usr/bin/mount
/usr/bin/find        <- sospechoso

Paso 2: consultar GTFOBins#

GTFOBins es un catálogo público que documenta cómo cada binario de Unix puede usarse para salir de restricciones o escalar privilegios cuando tiene SUID, sudo o capabilities. Buscando find en la sección SUID, verás que puede ejecutar comandos con la opción -exec.

Paso 3: escalar con el binario#

Como find corre como root por el SUID, lo que ejecute heredará esos privilegios. La opción -p de bash le indica que conserve el usuario efectivo en lugar de descartarlo:

find . -exec /bin/sh -p \; -quit

# Comprobar la identidad obtenida
id
uid=1001(estudiante) gid=1001(estudiante) euid=0(root)

El campo euid=0(root) indica que el usuario efectivo es root: ya puedes leer /root y hacer cualquier cosa en el sistema.

Otros ejemplos habituales en laboratorios#

Paso 4: el caso de los binarios propios#

Muchos laboratorios incluyen un binario hecho a medida, por ejemplo /usr/local/bin/backup, con SUID de root. Para entender qué hace sin código fuente:

strings /usr/local/bin/backup | less
ltrace /usr/local/bin/backup 2>&1 | head

Si ves que llama a un comando sin ruta absoluta, como system("tar -czf ..."), puedes crear tu propio tar en un directorio que controles y ponerlo al principio de PATH: el binario ejecutará tu versión como root. Esta técnica, el secuestro de PATH, la tienes explicada a fondo en su propia lección de /aprende.

Qué puede lograr un atacante#

Cómo se corrige#

Auditar e inventariar#

Haz periódicamente la misma búsqueda que haría un atacante y compárala con una lista de binarios esperados. Cualquier binario nuevo con SUID debe tener una justificación.

find / -xdev -perm /6000 -type f 2>/dev/null | sort > suid_actual.txt
diff suid_esperado.txt suid_actual.txt

Quitar el bit a lo que no lo necesita#

sudo chmod u-s /usr/bin/find

Ningún editor, intérprete ni utilidad de uso general debería tener SUID. Si un usuario necesita hacer una tarea privilegiada concreta, es mejor una regla de sudo limitada a ese comando exacto.

Montar con nosuid donde no haga falta#

Las particiones donde los usuarios pueden escribir (/home, /tmp, /var/tmp, discos externos) deberían montarse con la opción nosuid, que hace que el sistema ignore el bit SUID en ellas:

# /etc/fstab
/dev/sdb1  /home  ext4  defaults,nosuid,nodev  0  2

Programar binarios propios con cuidado#

Si de verdad necesitas un binario privilegiado propio: rutas absolutas para todo, entorno limpio, validación estricta de argumentos y, si es posible, soltar los privilegios en cuanto ya no hagan falta. En la mayoría de casos, una regla de sudo bien escrita es más segura.

Vigilar los cambios#

Herramientas de integridad como AIDE o reglas de auditd pueden alertar cuando aparece un nuevo archivo con SUID, algo que no debería pasar sin que nadie lo sepa.

Errores comunes al defenderse#

• Poner SUID para «arreglar» un error de permisos. Resuelve el síntoma dando root a todo el mundo.
• Pensar que un binario propio es seguro porque es pequeño. Una sola llamada a system() sin ruta absoluta basta.
• Revisar solo /usr/bin. Los binarios sospechosos suelen estar en /opt, /usr/local o carpetas de aplicaciones.
• Olvidar SGID. Un binario con SGID de un grupo privilegiado (como shadow o disk) también puede ser una vía de escalada.

Preguntas frecuentes#

¿Qué diferencia hay entre SUID y sudo?#

SUID hace que un programa concreto siempre se ejecute como su propietario, para cualquier usuario. Sudo permite que usuarios concretos ejecuten comandos concretos como otro usuario, con reglas y registro. Sudo es mucho más controlable.

¿Por qué hay que usar -p con bash?#

Por seguridad, bash descarta el usuario efectivo privilegiado al arrancar si no coincide con el real. La opción -p le indica que lo conserve, y por eso aparece en muchas técnicas de GTFOBins.

¿Todos los binarios SUID son vulnerables?#

No. La mayoría de los que trae el sistema son necesarios y están diseñados para ello. El riesgo está en los programas de uso general con SUID, en binarios propios inseguros y en versiones con fallos conocidos.

¿Qué es GTFOBins?#

Un catálogo público de binarios de Unix que documenta cómo pueden abusarse cuando tienen SUID, permisos de sudo o capabilities. Es una referencia tanto para auditores como para administradores que quieren saber qué no deben permitir.

¿Dónde practico esto?#

En los laboratorios de whoami-labs enlazados al final de esta lección, que empiezan por los fundamentos del bit SUID y llegan hasta binarios propios para analizar.

Resumen#

• El bit SUID hace que un programa se ejecute con los permisos de su propietario; si es root, con poder de root.
• Es peligroso en programas de uso general (find, vim, python, bash, cp), en binarios propios mal hechos y en versiones vulnerables.
• Se enumera con find / -perm -4000 y se explota en laboratorios con la ayuda de GTFOBins.
• Se corrige auditando el inventario, quitando el bit, montando con nosuid, prefiriendo reglas de sudo concretas y vigilando los cambios.

Fuentes y lecturas recomendadas#

• GTFOBins
• MITRE ATT&CK T1548.001: Setuid and Setgid
• Página de manual de chmod (bits especiales)
• Página de manual de credentials: usuarios reales y efectivos