Atlantis Security
Основна інформація
Атлантіс допомагає вам запускати terraform з Pull Requests з вашого git сервера.
Локальна лабораторія
Перейдіть на сторінку релізів атлантісу за посиланням https://github.com/runatlantis/atlantis/releases та завантажте той, який вам підходить.
Створіть особистий токен (з доступом до репозиторіїв) вашого github користувача.
Виконайте
./atlantis testdrive
і він створить демо-репозиторій, який ви можете використовувати для спілкування з атлантісом.Ви можете отримати доступ до веб-сторінки за адресою 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
можна вказати за допомогою прапорців командного рядка, змінних середовища, файлу конфігурації або комбінації трьох.
Ви можете знайти тут список прапорців, які підтримує сервер Атлантіс
Ви можете знайти тут, як перетворити параметр конфігурації в змінну середовища
Значення вибираються в такому порядку:
Прапорці
Змінні середовища
Файл конфігурації
Зверніть увагу, що в налаштуваннях ви можете знайти цікаві значення, такі як токени та паролі.
Налаштування репозиторіїв
Деякі налаштування впливають на тим, як керуються репозиторії. Однак можливо, що кожен репозиторій вимагає різних налаштувань, тому є способи вказати кожен репозиторій. Це порядок пріоритету:
Файл
/atlantis.yml
репозиторію. Цей файл може бути використаний для вказання того, як атлантіс повинен обробляти репозиторій. Однак за замовчуванням деякі ключі не можуть бути вказані тут без деяких прапорців, що дозволяють це.Ймовірно, потрібно дозволити за допомогою прапорців, таких як
allowed_overrides
абоallow_custom_workflows
Конфігурація на стороні сервера: Ви можете передати її за допомогою прапорця
--repo-config
і це yaml, що налаштовує нові параметри для кожного репозиторію (підтримуються регулярні вирази)За замовчуванням значення
Захист PR
Atlantis дозволяє вказати, чи хочете ви, щоб PR був затверджений
кимось іншим (навіть якщо це не встановлено в захисті гілки) і/або був злитий
(пройшли захисти гілки) перед запуском apply. З точки зору безпеки рекомендується встановити обидві опції.
У випадку, якщо allowed_overrides
встановлено на True, ці налаштування можуть бути перезаписані на кожному проекті за допомогою файлу /atlantis.yml
.
Сценарії
Конфігурація репозиторію може вказувати сценарії, які виконуються перед (перед хуками робочого процесу) та після (після хуків робочого процесу) виконання робочого процесу.
Немає жодної опції, що дозволяє вказати ці сценарії в файлі конфігурації репозиторію /atlantis.yml
.
Робочий процес
У конфігурації репозиторію (конфігурація на стороні сервера) можна вказати новий типовий робочий процес, або створити нові користувацькі робочі процеси. Також можна вказати, які репозиторії можуть отримати доступ до створених нових.
Потім можна дозволити файлу atlantis.yaml кожного репозиторію вказати робочий процес, який слід використовувати.
Якщо прапорець конфігурації на стороні сервера allow_custom_workflows
встановлено на True, робочі процеси можуть бути вказані в файлі atlantis.yaml
кожного репозиторію. Також можливо, що allowed_overrides
також вказує також workflow
для перевизначення робочого процесу, який буде використовуватися.
Це фактично надасть RCE в сервері Atlantis будь-якому користувачеві, який може отримати доступ до цього репозиторію.
Перевірка політики Conftest
Атлантіс підтримує запуск серверної conftest політики проти вихідного плану. Загальні випадки використання цього кроку включають:
Відмова від використання списку модулів
Перевірка атрибутів ресурсу під час створення
Виявлення ненавмисного видалення ресурсів
Запобігання ризикам безпеки (тобто викладання захищених портів у публічний доступ)
Ви можете перевірити, як це налаштувати в документації.
Команди Атлантіс
У документації ви можете знайти параметри, які можна використовувати для запуску Атлантісу:
Атаки
Якщо під час експлуатації ви знаходите цю помилку: Error: Error acquiring the state lock
Ви можете виправити це, виконавши:
План RCE Atlantis - Зміна конфігурації в новому PR
Якщо у вас є права на запис у репозиторій, ви зможете створити нову гілку на ньому та згенерувати PR. Якщо ви можете виконати atlantis plan
(або це виконується автоматично), ви зможете виконати RCE всередині сервера Atlantis.
Ви можете це зробити, зробивши Atlantis завантажити зовнішнє джерело даних. Просто вставте пейлоад, подібний до наведеного нижче, у файл main.tf
:
Прихована атака
Ви можете виконати цю атаку ще більш приховано, дотримуючись цих рекомендацій:
Замість того, щоб додавати обернену оболонку безпосередньо до файлу terraform, ви можете завантажити зовнішній ресурс, який містить обернену оболонку:
Можна знайти код оболонки 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:
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
:
Виконайте рекомендації з попередньої техніки, щоб виконати цей атаку в більш прихований спосіб.
Впровадження параметрів Terraform
Під час виконання atlantis plan
або atlantis apply
terraform запускається під-потребу, ви можете передавати команди до terraform з atlantis, прокоментувавши щось на зразок:
Щось, що можна передати, це змінні середовища, які можуть бути корисні для обходу деяких захистів. Перевірте змінні середовища 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 будь-якому користувачеві, який може отримати доступ до цього репозиторію.
Обхід захисту плану/застосування
Якщо прапорець конфігурації зі сторони сервера allowed_overrides
має налаштований 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 lineatlantis server
(може містити чутливі дані)
Заходи запобігання
Не Використовуйте На Публічних Репозиторіях
Оскільки будь-хто може коментувати на публічні запити на злиття, навіть з усіма доступними засобами безпеки, все ще небезпечно запускати Atlantis на публічних репозиторіях без належної конфігурації параметрів безпеки.
Не Використовуйте --allow-fork-prs
--allow-fork-prs
Якщо ви працюєте з публічним репозиторієм (що не рекомендується, див. вище), ви не повинні встановлювати --allow-fork-prs
(за замовчуванням вимкнено), оскільки будь-хто може відкрити запит на злиття зі свого форку до вашого репозиторію.
--repo-allowlist
--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
.
Посилання
Last updated