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 zasadniczo pomaga uruchamiać terraform z Pull Requests z twojego serwera git.
Przejdź do strony wydań atlantis w https://github.com/runatlantis/atlantis/releases i pobierz tę, która ci odpowiada.
Utwórz osobisty token (z dostępem do repozytoriów) swojego użytkownika github.
Wykonaj ./atlantis testdrive, a utworzy to demo repo, którego możesz użyć do rozmowy z atlantis.
Możesz uzyskać dostęp do strony internetowej pod adresem 127.0.0.1:4141.
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.
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ów do Internetu.
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.
Atlantis uruchamia Terraform, po prostu wykonując polecenia terraform plan i apply na serwerze, na którym Atlantis jest hostowany. Tak jak podczas uruchamiania Terraform lokalnie, Atlantis potrzebuje poświadczeń dla twojego konkretnego dostawcy.
To od ciebie zależy, jak przekazujesz poświadczenia dla twojego 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")
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.
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 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.
Wartości są wybierane w tej kolejności:
Flagi
Zmienne środowiskowe
Plik konfiguracyjny
Zauważ, że w konfiguracji możesz znaleźć interesujące wartości, takie jak tokeny i hasła.
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:
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ą.
Prawdopodobnie wymagane, aby były dozwolone przez flagi, takie jak allowed_overrides lub allow_custom_workflows.
Konfiguracja po stronie serwera: Możesz ją przekazać za pomocą flagi --repo-config, a jest to yaml konfiguracyjny nowych ustawień dla każdego repozytorium (obsługiwane regexy).
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 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.
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 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.
Sprawdzanie polityki Conftest
Atlantis wspiera uruchamianie po stronie serwera conftest polityk w odniesieniu do 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. udostępnianie bezpiecznych portów publicznie)
Możesz sprawdzić, jak to skonfigurować w dokumentacji.
W dokumentacji znajdziesz opcje, które możesz wykorzystać do uruchomienia Atlantis:
Jeśli podczas eksploatacji napotkasz ten błąd: Error: Error acquiring the state lock
Możesz to naprawić, uruchamiając:
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ł 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:
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:
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ś 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.
Możesz zrzucić sekrety używane przez terraform, uruchamiając atlantis plan (terraform plan), umieszczając coś takiego w pliku terraform:
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:
Postępuj zgodnie z zaleceniami z poprzedniej techniki, aby przeprowadzić ten atak w bardziej dyskretny sposób.
Podczas uruchamiania atlantis plan lub atlantis apply, terraform jest uruchamiany w tle, możesz przekazać polecenia do terraform z atlantis, komentując coś takiego:
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
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 dla każdego użytkownika, który ma dostęp do tego repo.
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ść.
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ź wcześniejsze scenariusze) w konfiguracji terraform, uruchomić atlantis plan/apply i uzyskać RCE.
To jest ustawienie w ochronach gałęzi Github:
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 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).
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)
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ń.
--allow-fork-prsJeś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-allowlistAtlantis 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.
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:
Wbudować dostawców w obraz Atlantis lub hostować i odmówić wychodzenia w produkcji.
Wdrożyć wewnętrznie protokół rejestru dostawców i odmówić publicznego wychodzenia, w ten sposób kontrolujesz, kto ma dostęp do zapisu w rejestrze.
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.
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 mogliby 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 obsługuje wysyłanie nagłówka podstawowej autoryzacji we wszystkich zdarzeniach webhooka. Wymaga to użycia adresu URL HTTPS dla lokalizacji webhooka.
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.
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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
