Sudo group abuse

En Linux, la pertenencia a un grupo no siempre es decorativa: el grupo sudo (en Debian/Ubuntu; wheel en RHEL/CentOS) es el que la configuración por defecto de /etc/sudoers autoriza a ejecutar cualquier comando como root. Por eso, cuando comprometemos un usuario, lo primero es mirar a qué grupos pertenece:

id

Si en la salida aparece algo como groups=...,27(sudo) (el GID 27 es el del grupo sudo en Debian), ese usuario puede convertirse en root sin más fricción que conocer su propia contraseña, porque la regla %sudo ALL=(ALL:ALL) ALL del sudoers concede el privilegio a todo el grupo.

El abuso es directo: pedir una shell de root.

sudo su
sudo -i
sudo bash

Cualquiera de las tres formas funciona; sudo su lanza su (cambio de usuario a root) a través de sudo. El sistema pide la contraseña del usuario actual, no la de root, y a continuación devuelve un prompt #. Un id posterior confirma uid=0(root).

Por qué pasa. No es un fallo de software sino una concesión administrativa: alguien metió a la cuenta en sudo. En auditoría conviene comprobar siempre id y sudo -l (este último lista qué se permite ejecutar y con qué restricciones, incluso sin contraseña vía NOPASSWD). La diferencia es que sudo -l puede revelar permisos acotados a binarios concretos (que abren la vía de GTFOBins), mientras que pertenecer al grupo sudo sin restricciones es la llave maestra.

Cómo detectarlo. Cada sudo deja un registro en /var/log/auth.log (o journalctl _COMM=sudo) con el usuario, el TTY, el directorio y el COMMAND: un sudo su/sudo -i/sudo bash que abra una sesión de root es visible al instante, y en Linux moderno genera además un evento USER_CMD/CRED_ACQ de auditd. La señal de abuso no es un sudo puntual (es normal en un admin) sino el patrón: un usuario de servicio o una cuenta que no debería administrar el sistema escalando a root, o accesos fuera de horario. Una regla de auditd que vigile /etc/group y /etc/sudoers (-w /etc/group -p wa) delata el momento exacto en que se concede la pertenencia a sudo/wheel.

Defensa. Limitar quién está en sudo/wheel, exigir contraseña (no abusar de NOPASSWD), y acotar las reglas de sudoers a los comandos imprescindibles en lugar de conceder ALL.