Atlantis Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Atlantis в основному допомагає вам запускати terraform з Pull Requests з вашого git сервера.
Перейдіть на сторінку релізів atlantis за https://github.com/runatlantis/atlantis/releases і завантажте той, що вам підходить.
Створіть персональний токен (з доступом до репозиторіїв) вашого github користувача.
Виконайте ./atlantis testdrive, і він створить демо репозиторій, який ви можете використовувати для взаємодії з atlantis.
Ви можете отримати доступ до веб-сторінки за адресою 127.0.0.1:4141.
Atlantis підтримує кілька git хостів, таких як Github, Gitlab, Bitbucket та Azure DevOps. Однак, щоб отримати доступ до репозиторіїв на цих платформах і виконувати дії, потрібно надати деякий привілейований доступ (принаймні права на запис). Документація рекомендує створити користувача на цих платформах спеціально для Atlantis, але деякі люди можуть використовувати особисті акаунти.
У будь-якому випадку, з точки зору атакуючого, акаунт Atlantis буде дуже цікавим для компрометації.
Atlantis за бажанням використовує Webhook secrets для перевірки, що webhooks, які він отримує від вашого Git хоста, є легітимними.
Один зі способів підтвердити це - дозволити запити лише з IP-адрес вашого Git хоста, але простіший спосіб - використовувати Webhook Secret.
Зверніть увагу, що якщо ви не використовуєте приватний сервер github або bitbucket, вам потрібно буде відкрити вебхуки для Інтернету.
Atlantis буде відкривати вебхуки, щоб git сервер міг надсилати йому інформацію. З точки зору атакуючого було б цікаво знати, чи можете ви надсилати йому повідомлення.
Atlantis запускає Terraform, просто виконуючи команди terraform plan та apply на сервері, на якому розміщено Atlantis. Так само, як і при запуску Terraform локально, Atlantis потребує облікових даних для вашого конкретного провайдера.
Вам вирішувати, як ви надаєте облікові дані для вашого конкретного провайдера в Atlantis:
Helm Chart для Atlantis та AWS Fargate Module мають свої механізми для облікових даних провайдера. Читайте їх документацію.
Якщо ви запускаєте Atlantis у хмарі, багато хмар мають способи надати доступ до API хмари для додатків, що на них працюють, наприклад:
AWS EC2 Roles (Шукайте "EC2 Role")
Багато користувачів встановлюють змінні середовища, наприклад, AWS_ACCESS_KEY, де працює Atlantis.
Інші створюють необхідні конфігураційні файли, наприклад, ~/.aws/credentials, де працює Atlantis.
Використовуйте HashiCorp Vault Provider для отримання облікових даних провайдера.
Контейнер, в якому працює Atlantis, ймовірно, міститиме привілейовані облікові дані для провайдерів (AWS, GCP, Github...), якими Atlantis керує через Terraform.
За замовчуванням Atlantis буде запускати веб-сторінку на порту 4141 на localhost. Ця сторінка просто дозволяє вам увімкнути/вимкнути atlantis apply і перевірити статус плану репозиторіїв та розблокувати їх (вона не дозволяє змінювати речі, тому не є дуже корисною).
Ви, напевно, не знайдете її відкритою для Інтернету, але, здається, за замовчуванням не потрібні облікові дані для доступу до неї (а якщо потрібні, то atlantis:atlantis є за замовчуванням).
Конфігурацію для atlantis server можна вказати через командні прапорці, змінні середовища, конфігураційний файл або комбінацію трьох.
Ви можете знайти тут список прапорців, підтримуваних сервером Atlantis.
Ви можете знайти тут, як перетворити параметр конфігурації на змінну середовища.
Значення вибираються в такому порядку:
Прапорці
Змінні середовища
Конфігураційний файл
Зверніть увагу, що в конфігурації ви можете знайти цікаві значення, такі як токени та паролі.
Деякі конфігурації впливають на те, як управляються репозиторії. Однак можливо, що кожен репозиторій вимагатиме різних налаштувань, тому є способи вказати кожен репозиторій. Це порядок пріоритету:
Репозиторій /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 будь-якому користувачу, який може отримати доступ до цього репозиторію.
Перевірка політики Conftest
Atlantis підтримує виконання серверних conftest політик проти виходу плану. Загальні випадки використання цього кроку включають:
Заборону використання списку модулів
Підтвердження атрибутів ресурсу під час створення
Виявлення ненавмисних видалень ресурсів
Запобігання ризикам безпеки (тобто, відкриття безпечних портів для публіки)
Ви можете перевірити, як це налаштувати в документації.
У документації ви можете знайти опції, які можна використовувати для запуску Atlantis:
Якщо під час експлуатації ви знайдете цю помилку: Error: Error acquiring the state lock
Ви можете виправити це, запустивши:
Якщо у вас є права на запис у репозиторії, ви зможете створити нову гілку та згенерувати PR. Якщо ви можете виконати atlantis plan (або, можливо, це виконується автоматично) ви зможете RCE всередині сервера Atlantis.
Ви можете зробити це, змусивши Atlantis завантажити зовнішнє джерело даних. Просто вставте корисне навантаження, подібне до наступного, у файл main.tf:
Стійкіший Атак
You can perform this attack even in a стійкіший спосіб, by following this suggestions:
Instead of adding the rev shell directly into the terraform file, you can завантажити зовнішній ресурс that contains the rev shell:
Ви можете знайти код 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 і гілки.
Ви можете вивантажити секрети, які використовуються terraform, запустивши atlantis plan (terraform plan), вставивши щось на зразок цього в файл terraform:
Якщо у вас є права на запис у репозиторій, ви зможете створити нову гілку та згенерувати 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:
Слідуйте рекомендаціям з попередньої техніки, щоб виконати цю атаку більш приховано.
Коли ви виконуєте 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 будь-якому користувачу, який може отримати доступ до цього репозиторію.
Якщо прапор server side config allowed_overrides має налаштоване apply_requirements, можливо, що репозиторій зможе змінити захист plan/apply, щоб обійти їх.
Якщо хтось надсилає atlantis plan/apply коментарі до ваших дійсних pull request-ів, це призведе до запуску terraform, коли ви цього не хочете.
Більше того, якщо у вас не налаштовано захист гілок для запиту на перегляд кожного PR, коли до нього додається новий коміт, хтось може написати шкідливі конфігурації (перевірте попередні сценарії) у конфігурації terraform, запустити atlantis plan/apply і отримати RCE.
Це налаштування у захисті гілок Github:
Якщо вам вдасться викрасти секрет вебхука або якщо не використовується жоден секрет вебхука, ви зможете викликати вебхук Atlantis і виконати команди atlatis безпосередньо.
Bitbucket Cloud не підтримує секрети вебхука. Це може дозволити зловмисникам підробляти запити з Bitbucket. Переконайтеся, що ви дозволяєте лише IP-адреси Bitbucket.
Це означає, що зловмисник може надсилати фальшиві запити до Atlantis, які виглядають так, ніби вони надходять з Bitbucket.
Якщо ви вказуєте --repo-allowlist, то вони можуть підробляти лише запити, що стосуються цих репозиторіїв, тому найбільша шкода, яку вони можуть завдати, буде полягати в плануванні/застосуванні на ваших власних репозиторіях.
Щоб запобігти цьому, додайте до білого списку IP-адреси Bitbucket (див. вихідні 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 Командний рядок atlantis server (може містити чутливі дані)
Оскільки будь-хто може коментувати публічні pull request-и, навіть з усіма доступними заходами безпеки, все ще небезпечно запускати Atlantis на публічних репозиторіях без належної конфігурації налаштувань безпеки.
--allow-fork-prsЯкщо ви працюєте на публічному репозиторії (що не рекомендується, див. вище), вам не слід встановлювати --allow-fork-prs (за замовчуванням false), оскільки будь-хто може відкрити pull request зі свого форка до вашого репозиторію.
--repo-allowlistAtlantis вимагає, щоб ви вказали список дозволених репозиторіїв, з яких він прийматиме вебхуки, за допомогою прапора --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 для отримання додаткової інформації.
Якщо у вашій моделі загроз є зловмисники, які надсилають pull request-и з шкідливим кодом Terraform, то ви повинні знати, що схвалення terraform apply недостатньо. Можливо, запустити шкідливий код у terraform plan, використовуючи external data source або вказавши шкідливий провайдер. Цей код може потім ексфільтрувати ваші облікові дані.
Щоб запобігти цьому, ви можете:
Включити провайдери в образ Atlantis або хостити їх і заборонити вихід у виробництві.
Реалізувати протокол реєстру провайдерів внутрішньо та заборонити публічний вихід, таким чином ви контролюєте, хто має доступ на запис до реєстру.
Змінити крок plan у вашій конфігурації репозиторіїв на стороні сервера для перевірки на використання заборонених провайдерів або джерел даних або PR-ів від не дозволених користувачів. Ви також можете додати додаткову перевірку на цьому етапі, наприклад, вимагати "палець вгору" на PR перед тим, як дозволити plan продовжити. Conftest може бути корисним тут.
Atlantis слід запускати з налаштованими секретами вебхука через змінні середовища $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET. Навіть з установленим прапором --repo-allowlist, без секрету вебхука, зловмисники можуть надсилати запити до Atlantis, видаючи себе за репозиторій, який є в білому списку. Секрети вебхука забезпечують, щоб запити вебхука дійсно надходили від вашого постачальника VCS (GitHub або GitLab).
Якщо ви використовуєте Azure DevOps, замість секретів вебхука додайте базове ім'я користувача та пароль.
Azure DevOps підтримує надсилання заголовка базової аутентифікації у всіх подіях вебхука. Це вимагає використання HTTPS URL для вашого місця вебхука.
Якщо ви використовуєте секрети вебхука, але ваш трафік йде через HTTP, то секрети вебхука можуть бути вкрадені. Увімкніть SSL/HTTPS, використовуючи прапори --ssl-cert-file і --ssl-key-file.
Дуже рекомендується увімкнути аутентифікацію у веб-сервісі. Увімкніть BasicAuth, використовуючи --web-basic-auth=true та налаштуйте ім'я користувача та пароль, використовуючи прапори --web-username=yourUsername та --web-password=yourPassword.
Ви також можете передати їх як змінні середовища ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername та ATLANTIS_WEB_PASSWORD=yourPassword.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
