fail2ban privesc (actionban)

fail2ban es un servicio que vigila los logs (por ejemplo de SSH) y banea automáticamente las IP con demasiados intentos fallidos. Para banear ejecuta una acción definida en /etc/fail2ban/action.d/ (típicamente iptables-multiport.conf), cuyo campo actionban es, literalmente, un comando que se ejecuta como root cuando se produce un baneo.

Ahí está el abuso: si un usuario puede modificar el actionban y además reiniciar el servicio para aplicar la nueva configuración, controla un comando que correrá con privilegios de root. El caso habitual es un sudo -l que permite reiniciar fail2ban:

(root) NOPASSWD: /etc/init.d/fail2ban restart

El plan: cambiar actionban por algo que conceda privilegios persistentes (poner SUID a /bin/bash es lo más limpio), aplicar la configuración y forzar un baneo para disparar la acción.

# 1) Editar actionban (si el fichero no es escribible, copiar-editar-reemplazar)
#    actionban = chmod u+s /bin/bash
# 2) Aplicar la nueva config
sudo /etc/init.d/fail2ban restart
# 3) Provocar un baneo (muchos intentos SSH fallidos)
hydra -l <user> -P rockyou.txt ssh://<ip> -t 64
# 4) Cuando salte el ban, /bin/bash queda SUID
bash -p        # euid=0 -> root

Matices. A veces el fichero de acción no es escribible directamente por el usuario, pero sí el directorio o se puede sustituir (copiar a /tmp, editar, renombrar el original y mover el modificado). El baneo hay que dispararlo activamente (un brute force basta) y conviene devolver luego la configuración original para no romper el servicio.

Cómo detectarlo. Deben coincidir dos señales: un sudo -l que permita reiniciar fail2ban (o un grupo/permiso que deje tocar /etc/fail2ban/action.d/) y escritura efectiva sobre el actionban (directa o vía el directorio, ls -la /etc/fail2ban/action.d/). Sin las dos, editar la acción y aplicarla, no hay vector.

Defensa. No conceder por sudo el control de fail2ban (ni restart) a usuarios no administradores, proteger action.d/ (propiedad y permisos de root, directorio no escribible), y evitar que cuentas de servicio puedan alterar las acciones. Es un caso particular del principio general: dar control sobre un servicio que ejecuta comandos arbitrarios como root equivale a dar root, igual que el abuso de binarios por sudo.