Incertidumbre: los errores de configuración que se repiten en producción
Errores de configuración que se repiten en producción, de un Grafana sin parchear con LFI a una capability en Python que entrega root.
Avanzado · Linux
URL del reto: labs.thehackerslabs.com/machines/48
Por qué la diseñé
Incertidumbre representa errores de configuración y fallos de seguridad que he visto repetirse durante años gestionando infraestructura en producción. No la monté porque sí, cada vector refleja un problema técnico que, en un sistema mal mantenido, termina en compromiso. La pensé para que quien la resuelve entienda la cadena de malas decisiones que la hace posible, y no se quede en la explotación.
Cada fallo de la cadena es de los que aparecen cuando un servicio se deja sin parchear por miedo a tocar producción, cuando los secretos viven en un fichero de configuración o cuando se le dan a un binario común más privilegios de los que necesita.
La máquina de un vistazo
Expone SSH, un Apache que solo devuelve 403 y un Grafana en el puerto 3000, que es la entrada. La cadena arranca en una lectura de ficheros arbitrarios sobre ese Grafana, saca las credenciales de la base de datos de su fichero de configuración, reutiliza una contraseña hasta un acceso SSH y remata con una capability mal puesta en Python que entrega root.
Cómo la monté, paso a paso
Un Grafana sin parchear
La entrada es un Grafana en la versión 8.2.0, vulnerable a lectura de ficheros arbitrarios sin autenticación por la CVE-2021-43798. Elegí un fallo con CVE conocida a propósito, porque representa lo más común de todo, un servicio expuesto que no se actualiza por miedo a tocar producción. No da ejecución, pero sí lectura del sistema, y con eso arranca la cadena.
Los secretos en el fichero de configuración
Con esa lectura saqué dos cosas, el /etc/passwd para ver qué usuarios hay y el grafana.ini, el fichero de configuración de Grafana, que guarda en claro las credenciales con las que el servicio se conecta a su base de datos. Ese es uno de los errores que más veo, secretos metidos en ficheros de configuración accesibles para quien consigue una lectura indebida. Muchas intrusiones empiezan así, con una mala exposición de datos y no con una shell.
La credencial reutilizada hasta SSH
La base de datos de Grafana lleva a un usuario, cloud, que en el /etc/passwd ya aparecía con shell válida. Juntando las dos fuentes sale una credencial que sirve para entrar por SSH. Ese encadenamiento es de lo más común, un fallo en una aplicación expuesta deja leer su configuración, la configuración lleva a una base de datos y la base de datos termina dando acceso al sistema. El problema de fondo es la falta de separación entre la aplicación, la base de datos y el propio sistema.
El remate, una capability mal puesta en Python
Ya dentro como cloud, dejé dos pistas de escalada. Una es un sudo NOPASSWD sobre un script que el usuario puede ejecutar como root pero no leer, una automatización privilegiada concedida por comodidad. La que remata la máquina es otra, el binario de Python tiene la capability cap_setuid, y con eso un usuario sin privilegios cambia su UID a 0 y ejecuta como root (os.setuid(0); os.system("/bin/bash")). Aparece cuando se le dan privilegios de más a un binario común para resolver una necesidad operativa rápida, sin medir el impacto.
Qué quería enseñar
Incertidumbre va de entender qué representa cada fallo y por qué sigue ocurriendo en sistemas que están en uso, más que de encadenar pasos hasta root.
| Vector | Qué enseña | Error que representa |
|---|---|---|
| LFI en Grafana | Explotar software expuesto y sin parchear | Servicios desactualizados por miedo a tocar producción |
| Credenciales en grafana.ini | Los secretos en config se leen | Passwords en claro en ficheros de servicio |
| SSH reutilizando la credencial | Reutilización insegura entre capas | Poca separación entre app, base de datos y sistema |
| cap_setuid en Python | Privilegios de más en un binario común | Permisos peligrosos concedidos por comodidad |
| sudo NOPASSWD | Automatización privilegiada mal delegada | Scripts críticos sin revisión de riesgo |
El objetivo era que quien la resuelve entienda la cadena de malas decisiones técnicas que hace posible el compromiso completo, no solo la explotación.