Ansible Tower / AWX / Seguridad del controlador de automatización

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Consulta los subscription plans!
• Únete al 💬 Discord group o al telegram group o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud github repos.

Información Básica

Ansible Tower o su versión de código abierto AWX también se conoce como la interfaz de usuario, el panel de control y la API REST de Ansible. Con control de acceso basado en roles, programación de trabajos y gestión gráfica de inventarios, puedes gestionar tu infraestructura de Ansible desde una interfaz moderna. La API REST de Tower y la interfaz de línea de comandos facilitan su integración en herramientas y flujos de trabajo actuales.

El Controlador de Automatización es una versión más nueva de Ansible Tower con más capacidades.

Diferencias

Según esto, las principales diferencias entre Ansible Tower y AWX son el soporte recibido y que Ansible Tower tiene características adicionales como control de acceso basado en roles, soporte para APIs personalizadas y flujos de trabajo definidos por el usuario.

Stack Tecnológico

• Interfaz Web: Esta es la interfaz gráfica donde los usuarios pueden gestionar inventarios, credenciales, plantillas y trabajos. Está diseñada para ser intuitiva y proporciona visualizaciones para ayudar a entender el estado y los resultados de tus trabajos de automatización.
• API REST: Todo lo que puedes hacer en la interfaz web, también puedes hacerlo a través de la API REST. Esto significa que puedes integrar AWX/Tower con otros sistemas o script acciones que normalmente realizarías en la interfaz.
• Base de Datos: AWX/Tower utiliza una base de datos (típicamente PostgreSQL) para almacenar su configuración, resultados de trabajos y otros datos operativos necesarios.
• RabbitMQ: Este es el sistema de mensajería utilizado por AWX/Tower para comunicarse entre los diferentes componentes, especialmente entre el servicio web y los ejecutores de tareas.
• Redis: Redis sirve como caché y backend para la cola de tareas.

Componentes Lógicos

• Inventarios: Un inventario es una colección de hosts (o nodos) contra los cuales se pueden ejecutar trabajos (playbooks de Ansible). AWX/Tower te permite definir y agrupar tus inventarios y también admite inventarios dinámicos que pueden obtener listas de hosts de otros sistemas como AWS, Azure, etc.
• Proyectos: Un proyecto es esencialmente una colección de playbooks de Ansible obtenidos de un sistema de control de versiones (como Git) para extraer los últimos playbooks cuando sea necesario.
• Plantillas: Las plantillas de trabajo definen cómo se ejecutará un playbook en particular, especificando el inventario, credenciales y otros parámetros para el trabajo.
• Credenciales: AWX/Tower proporciona una forma segura de gestionar y almacenar secretos, como claves SSH, contraseñas y tokens de API. Estas credenciales pueden asociarse con plantillas de trabajo para que los playbooks tengan el acceso necesario cuando se ejecuten.
• Motor de Tareas: Aquí es donde ocurre la magia. El motor de tareas está construido sobre Ansible y es responsable de ejecutar los playbooks. Los trabajos se envían al motor de tareas, que luego ejecuta los playbooks de Ansible contra el inventario designado utilizando las credenciales especificadas.
• Programadores y Retornos de Llamada: Estas son características avanzadas en AWX/Tower que permiten programar trabajos para que se ejecuten en momentos específicos o se activen por eventos externos.
• Notificaciones: AWX/Tower puede enviar notificaciones basadas en el éxito o fracaso de los trabajos. Soporta varios medios de notificación como correos electrónicos, mensajes de Slack, webhooks, etc.
• Playbooks de Ansible: Los playbooks de Ansible son herramientas de configuración, implementación y orquestación. Describen el estado deseado de los sistemas de manera automatizada y repetible. Escritos en YAML, los playbooks utilizan el lenguaje de automatización declarativa de Ansible para describir configuraciones, tareas y pasos que deben ejecutarse.

Flujo de Ejecución de Trabajos

1. Interacción del Usuario: Un usuario puede interactuar con AWX/Tower a través de la Interfaz Web o la API REST. Estas proporcionan acceso frontal a todas las funcionalidades ofrecidas por AWX/Tower.
2. Inicio del Trabajo:

• El usuario, a través de la Interfaz Web o API, inicia un trabajo basado en una Plantilla de Trabajo.
• La Plantilla de Trabajo incluye referencias al Inventario, Proyecto (que contiene el playbook) y Credenciales.
• Al iniciar el trabajo, se envía una solicitud al backend de AWX/Tower para poner en cola el trabajo para su ejecución.

3. Colocación en Cola del Trabajo:

• RabbitMQ maneja la mensajería entre el componente web y los ejecutores de tareas. Una vez que se inicia un trabajo, se envía un mensaje al motor de tareas utilizando RabbitMQ.
• Redis actúa como el backend para la cola de tareas, gestionando los trabajos en cola que esperan ejecución.

4. Ejecución del Trabajo:

• El Motor de Tareas recoge el trabajo en cola. Recupera la información necesaria de la Base de Datos sobre el playbook asociado al trabajo, inventario y credenciales.
• Usando el playbook de Ansible recuperado del Proyecto asociado, el Motor de Tareas ejecuta el playbook contra los nodos de Inventario especificados utilizando las Credenciales proporcionadas.
• A medida que se ejecuta el playbook, su salida de ejecución (registros, hechos, etc.) se captura y almacena en la Base de Datos.

5. Resultados del Trabajo:

• Una vez que el playbook termina de ejecutarse, los resultados (éxito, fracaso, registros) se guardan en la Base de Datos.
• Los usuarios pueden ver los resultados a través de la Interfaz Web o consultarlos a través de la API REST.
• Según los resultados del trabajo, se pueden enviar Notificaciones para informar a los usuarios o sistemas externos sobre el estado del trabajo. Las notificaciones pueden ser correos electrónicos, mensajes de Slack, webhooks, etc.

6. Integración con Sistemas Externos:

• Inventarios pueden ser obtenidos dinámicamente de sistemas externos, permitiendo que AWX/Tower extraiga hosts de fuentes como AWS, Azure, VMware y más.
• Proyectos (playbooks) pueden ser extraídos de sistemas de control de versiones, asegurando el uso de playbooks actualizados durante la ejecución del trabajo.
• Programadores y Retornos de Llamada pueden ser utilizados para integrarse con otros sistemas o herramientas, haciendo que AWX/Tower reaccione a disparadores externos o ejecute trabajos en momentos predeterminados.

Creación de laboratorio AWX para pruebas

Siguiendo la documentación es posible usar docker-compose para ejecutar AWX:

git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version

cd awx

# Build
make docker-compose-build

# Run
make docker-compose

# Or to create a more complex env
MAIN_NODE_TYPE=control EXECUTION_NODE_COUNT=2 COMPOSE_TAG=devel make docker-compose

# Clean and build the UI
docker exec tools_awx_1 make clean-ui ui-devel

# Once migrations are completed and the UI is built, you can begin using AWX. The UI can be reached in your browser at https://localhost:8043/#/home, and the API can be found at https://localhost:8043/api/v2.

# Create an admin user
docker exec -ti tools_awx_1 awx-manage createsuperuser

# Load demo data
docker exec tools_awx_1 awx-manage create_preload_data

RBAC

Roles soportados

El rol más privilegiado se llama Administrador del Sistema. Cualquiera con este rol puede modificar cualquier cosa.

Desde una revisión de seguridad de caja blanca, necesitarías el rol de Auditor del Sistema, que permite ver todos los datos del sistema pero no puede hacer ningún cambio. Otra opción sería obtener el rol de Auditor de la Organización, pero sería mejor obtener el otro.

Enumeración y Mapeo de Ruta de Ataque con AnsibleHound

AnsibleHound es un colector de OpenGraph de BloodHound de código abierto escrito en Go que convierte un token de API de Ansible Tower/AWX/Automation Controller solo de lectura en un gráfico de permisos completo listo para ser analizado dentro de BloodHound (o BloodHound Enterprise).

¿Por qué es útil esto?

1. La API REST de Tower/AWX es extremadamente rica y expone cada objeto y relación RBAC que tu instancia conoce.
2. Incluso con el token de menor privilegio (Read) es posible enumerar recursivamente todos los recursos accesibles (organizaciones, inventarios, hosts, credenciales, proyectos, plantillas de trabajo, usuarios, equipos…).
3. Cuando los datos en bruto se convierten al esquema de BloodHound, obtienes las mismas capacidades de visualización de ruta de ataque que son tan populares en las evaluaciones de Active Directory, pero ahora dirigidas a tu infraestructura de CI/CD.

Los equipos de seguridad (¡y los atacantes!) pueden, por lo tanto:

• Comprender rápidamente quién puede convertirse en admin de qué.
• Identificar credenciales u hosts que son alcanzables desde una cuenta sin privilegios.
• Encadenar múltiples bordes “Read ➜ Use ➜ Execute ➜ Admin” para obtener control total sobre la instancia de Tower o la infraestructura subyacente.

Requisitos previos

• Ansible Tower / AWX / Automation Controller accesible a través de HTTPS.
• Un token de API de usuario limitado a Read solamente (creado desde Detalles del Usuario → Tokens → Crear Token → alcance = Read).
• Go ≥ 1.20 para compilar el colector (o usar los binarios preconstruidos).

Construcción y Ejecución

# Compile the collector
cd collector
go build . -o build/ansiblehound

# Execute against the target instance
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"

Internamente, AnsibleHound realiza solicitudes GET paginadas contra (al menos) los siguientes endpoints y sigue automáticamente los enlaces related devueltos en cada objeto JSON:

/api/v2/organizations/
/api/v2/inventories/
/api/v2/hosts/
/api/v2/job_templates/
/api/v2/projects/
/api/v2/credentials/
/api/v2/users/
/api/v2/teams/

Todos los archivos recopilados se fusionan en un solo archivo JSON en el disco (predeterminado: ansiblehound-output.json).

Transformación de BloodHound

Los datos en bruto de Tower se transforman a BloodHound OpenGraph utilizando nodos personalizados con el prefijo AT (Ansible Tower):

• ATOrganization, ATInventory, ATHost, ATJobTemplate, ATProject, ATCredential, ATUser, ATTeam

Y bordes que modelan relaciones / privilegios:

• ATContains, ATUses, ATExecute, ATRead, ATAdmin

El resultado se puede importar directamente en BloodHound:

neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json

Opcionalmente, puedes subir iconos personalizados para que los nuevos tipos de nodos sean visualmente distintos:

python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"

Consideraciones Defensivas y Ofensivas

• Un token de Lectura normalmente se considera inofensivo pero aún filtra la topología completa y todos los metadatos de credenciales. ¡Trátalo como sensible!
• Aplica el mínimo privilegio y rota / revoca tokens no utilizados.
• Monitorea la API por enumeración excesiva (múltiples solicitudes GET secuenciales, alta actividad de paginación).
• Desde la perspectiva de un atacante, esta es una técnica perfecta de punto de apoyo inicial → escalada de privilegios dentro del pipeline de CI/CD.

Referencias

• AnsibleHound – Recolector BloodHound para Ansible Tower/AWX
• BloodHound OSS

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Consulta los subscription plans!
• Únete al 💬 Discord group o al telegram group o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud github repos.