diff --git a/scripts/__pycache__/translator.cpython-312.pyc b/scripts/__pycache__/translator.cpython-312.pyc deleted file mode 100644 index 1b472af5e..000000000 Binary files a/scripts/__pycache__/translator.cpython-312.pyc and /dev/null differ diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md index ddd9c9113..7586e34a5 100644 --- a/src/pentesting-ci-cd/argocd-security.md +++ b/src/pentesting-ci-cd/argocd-security.md @@ -4,14 +4,14 @@ ## Podstawowe informacje -[Argo CD](https://argo-cd.readthedocs.io/) to platforma ciągłego dostarczania GitOps dla Kubernetes. Monitoruje repozytoria Git, renderuje manifesty Kubernetes za pomocą narzędzi takich jak Helm, Kustomize, Jsonnet lub wtyczki do zarządzania konfiguracją, a następnie uzgadnia rzeczywisty stan klastra z pożądanym stanem zapisanym w Git. +[Argo CD](https://argo-cd.readthedocs.io/) to platforma continuous delivery GitOps dla Kubernetes. Monitoruje repozytoria Git, renderuje manifesty Kubernetes za pomocą narzędzi takich jak Helm, Kustomize, Jsonnet lub config management plugins, a następnie uzgadnia stan działającego klastra z żądanym stanem przechowywanym w Git. -Z perspektywy atakującego traktuj Argo CD jako **silnik wdrożeniowy z poświadczeniami Kubernetes**. Udana kompromitacja Argo CD może prowadzić do: +Z perspektywy atakującego Argo CD należy traktować jako **deployment engine posiadający credentials Kubernetes**. Skuteczne przejęcie Argo CD może prowadzić do: -- Dostępu do prywatnych repozytoriów Git i poświadczeń repozytoriów. -- Dostępu do secretów klastra Kubernetes używanych przez Argo CD. -- Wykonania code execution przy generowaniu manifestów w `argocd-repo-server`. -- Nieautoryzowanego wdrażania obiektów Kubernetes przez zaufane repozytoria Git, aplikacje Argo CD lub manipulację cache. +- Dostępu do prywatnych repozytoriów Git i credentials repozytoriów. +- Dostępu do secrets klastra Kubernetes używanych przez Argo CD. +- Wykonywania kodu podczas generowania manifestów w `argocd-repo-server`. +- Nieautoryzowanego wdrażania obiektów Kubernetes za pośrednictwem zaufanych repozytoriów Git, aplikacji Argo CD lub manipulacji cache. ## Architektura i interesujące komponenty @@ -24,21 +24,21 @@ kubectl get networkpolicy -n argocd 2>/dev/null ``` Interesujące usługi: -- **`argocd-server`**: publiczne API, web UI, CLI API, uwierzytelnianie i autoryzacja. -- **`argocd-application-controller`**: porównuje desired i live state, a następnie stosuje resources do Kubernetes. -- **`argocd-repo-server`**: klonuje repositories, buforuje dane Git i uruchamia Helm/Kustomize/Jsonnet/plugins, aby generować manifests. Domyślny port gRPC to **8081**. -- **`argocd-redis`**: cache dla application, manifest i Git reference data. Domyślny port Redis to **6379**. -- **`argocd-applicationset-controller`**: generuje obiekty Argo CD `Application` z generatorów takich jak Git, SCM, clusters i pull requests. +- **`argocd-server`**: publiczne API, web UI, API CLI, uwierzytelnianie i autoryzacja. +- **`argocd-application-controller`**: porównuje stan docelowy ze stanem bieżącym, a następnie stosuje zasoby w Kubernetes. +- **`argocd-repo-server`**: klonuje repozytoria, buforuje dane Git i uruchamia Helm/Kustomize/Jsonnet/plugins w celu generowania manifestów. Domyślny port gRPC to **8081**. +- **`argocd-redis`**: cache dla danych aplikacji, manifestów i referencji Git. Domyślny port Redis to **6379**. +- **`argocd-applicationset-controller`**: generuje obiekty Argo CD `Application` na podstawie generatorów takich jak Git, SCM, klastry i pull requesty. -Z kompromitowanego pod lub wewnętrznego segmentu sieci sprawdź wewnętrzną dostępność: +Z przejętego poda lub wewnętrznego segmentu sieci sprawdź dostępność wewnętrzną: ```bash nc -vz 443 nc -vz 8081 nc -vz 6379 ``` -## Public API / UI Attacks +## Ataki na publiczne API / UI -Jeśli masz poświadczenia Argo CD albo wystawioną instancję, zacznij od normalnej powierzchni API: +Jeśli masz dane uwierzytelniające Argo CD lub dostęp do ujawnionej instancji, zacznij od standardowej powierzchni API: ```bash argocd login argocd account get-user-info @@ -51,13 +51,13 @@ argocd admin settings rbac can ``` Przydatne ścieżki ataku: -- **Application write access**: zmodyfikuj `source.repoURL`, `source.path`, wartości Helm, opcje Kustomize, ustawienia pluginów lub opcje sync, aby Argo CD wdrożyło manifesty kontrolowane przez atakującego. -- **Project misconfiguration**: obiekty `AppProject` mogą zezwalać na szerokie `sourceRepos`, szerokie `destinations`, niebezpieczne `clusterResourceWhitelist` lub słabe ograniczenia namespace. -- **Repository credential abuse**: sekrety repository, poświadczenia GitHub App, klucze SSH i tokeny mogą umożliwiać push do zaufanych repo lub dodawanie złośliwych dependencies. -- **Cluster credential abuse**: sekrety cluster mogą zawierać bearer tokens lub konfigurację exec-provider używaną przez Argo CD do wdrażania do docelowych cluster. -- **Local admin / project tokens**: długowieczne tokeny Argo CD mogą być ponownie używane przez API, dopóki nie zostaną revoked albo nie wygasną. +- **Dostęp do zapisu aplikacji**: modyfikuj `source.repoURL`, `source.path`, wartości Helm, opcje Kustomize, ustawienia pluginów lub opcje synchronizacji, aby Argo CD wdrażało kontrolowane przez atakującego manifesty. +- **Błędna konfiguracja projektu**: obiekty `AppProject` mogą zezwalać na szerokie `sourceRepos`, szerokie `destinations`, niebezpieczne `clusterResourceWhitelist` lub słabe ograniczenia przestrzeni nazw. +- **Nadużycie poświadczeń repozytorium**: sekrety repozytorium, poświadczenia GitHub App, klucze SSH i tokeny mogą umożliwić wysyłanie zmian do zaufanych repozytoriów lub dodawanie złośliwych zależności. +- **Nadużycie poświadczeń klastra**: sekrety klastra mogą zawierać tokeny bearer lub konfigurację exec-provider używaną przez Argo CD do wdrażania w klastrach docelowych. +- **Tokeny lokalnego administratora / projektu**: długotrwałe tokeny Argo CD mogą być ponownie używane za pośrednictwem API, dopóki nie zostaną unieważnione lub wygasną. -Wylicz konfigurację z Kubernetes, gdy masz cluster read access: +Wyliczaj konfigurację z Kubernetes, gdy masz dostęp do odczytu klastra: ```bash kubectl get applications.argoproj.io -A -o yaml kubectl get appprojects.argoproj.io -A -o yaml @@ -65,49 +65,49 @@ kubectl get applicationsets.argoproj.io -A -o yaml kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey' kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml ``` -## Trusted Git Repository Abuse +## Nadużycie zaufanego repozytorium Git -Jeśli możesz pushować do repozytorium zaufanego przez Argo CD, zwykle możesz wpływać na to, co zostanie wdrożone. Impact zależy od granic `AppProject` i uprawnień service account używanych przez application controller. +Jeśli możesz wykonywać push do repozytorium zaufanego przez Argo CD, zwykle możesz wpływać na to, co zostanie wdrożone. Skutki zależą od granic `AppProject` oraz uprawnień service account używanych przez application controller. -Common payload locations: +Typowe miejsca umieszczania payloadów: -- Raw Kubernetes YAML pod ścieżką aplikacji. -- Helm chart templates i `values.yaml`. -- Kustomize overlays, remote bases i generatory. -- Jsonnet albo wejście pluginu config management. -- Pliki generatora ApplicationSet, które tworzą albo aktualizują obiekty `Application`. +- Surowy Kubernetes YAML w ścieżce aplikacji. +- Szablony Helm chartów i `values.yaml`. +- Overlaye Kustomize, remote bases i generatory. +- Dane wejściowe Jsonnet lub config management plugin. +- Pliki generatorów ApplicationSet, które tworzą lub aktualizują obiekty `Application`. -Sprawdź, czy app używa automated sync, pruning, self-heal, sync windows albo manual approvals: +Sprawdź, czy aplikacja używa automatycznej synchronizacji, pruning, self-heal, sync windows lub ręcznych zatwierdzeń: ```bash kubectl get applications.argoproj.io -A \ -o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server' ``` ## Bezpośrednie nadużycie `argocd-repo-server` -Nie zakładaj, że publiczne API Argo CD to jedyna powierzchnia ataku. Wewnętrzne komponenty Argo CD komunikują się z `argocd-repo-server` przez gRPC. Jeśli dowolne pods mogą osiągnąć repo-server, kontrolowane przez atakującego wewnętrzne żądania mogą ominąć kontrole normalnie egzekwowane przez `argocd-server`. +Nie zakładaj, że publiczne API Argo CD jest jedyną powierzchnią ataku. Wewnętrzne komponenty Argo CD komunikują się z `argocd-repo-server` za pośrednictwem gRPC. Jeśli dowolne pody mogą łączyć się z repo-server, żądania wewnętrzne kontrolowane przez atakującego mogą omijać kontrole normalnie wymuszane przez `argocd-server`. -Praktyczne sprawdzenia: +Praktyczne kontrole: ```bash kubectl get svc -n argocd argocd-repo-server -o yaml kubectl get endpoints -n argocd argocd-repo-server -o wide nc -vz 8081 ``` -Interesujące sygnały: +Ciekawe oznaki: -- Endpoint gRPC repo-server jest osiągalny z podów spoza Argo CD. -- Brakuje NetworkPolicies albo zezwalają tylko na allow-list egress bez blokowania ingress. -- repo-server ma dostęp do niestandardowych pluginów config management, narzędzi do decryptowania albo zawartości repository z wielu tenantów. -- Redis jest osiągalny z podów spoza Argo CD, co pozwala na inspekcję cache albo jego modyfikację, jeśli credentials są dostępne albo nie są wymagane. +- Endpoint gRPC repo-server jest dostępny z podów spoza Argo CD. +- Brakuje NetworkPolicies albo zezwalają one wyłącznie na egress bez blokowania ingress. +- repo-server ma dostęp do niestandardowych pluginów zarządzania konfiguracją, narzędzi deszyfrujących lub zawartości repozytoriów należących do wielu tenantów. +- Redis jest dostępny z podów spoza Argo CD, co umożliwia inspekcję lub modyfikowanie cache, jeśli dane uwierzytelniające są dostępne albo nie są wymagane. ## Unauthenticated Repo-Server RCE via Kustomize Options -W lipcu 2026 Synacktiv ujawnił chain wykonania code bez uwierzytelnienia w `repo-server` Argo CD, gdy atakujący może dosięgnąć wewnętrznej usługi gRPC. Atak wykorzystuje bezpośredni dostęp do `/repository.RepoServerService/GenerateManifest` oraz kontrolowane przez atakującego `KustomizeOptions`. +W lipcu 2026 roku Synacktiv ujawnił nieuwierzytelniony łańcuch code execution w Argo CD, gdy attacker może uzyskać dostęp do wewnętrznej usługi gRPC `repo-server`. Atak wykorzystuje bezpośredni dostęp do `/repository.RepoServerService/GenerateManifest` oraz kontrolowane przez attackera `KustomizeOptions`. -Niebezpieczny primitive polega na wymuszeniu, aby repo-server sklonował zawartość repository kontrolowaną przez atakującego i uruchomił Kustomize z obsługą Helm: +Niebezpieczny primitive polega na wymuszeniu, aby repo-server sklonował zawartość repozytorium kontrolowaną przez attackera i uruchomił Kustomize z obsługą Helm: ```bash kustomize build --enable-helm --helm-command ./payload.sh ``` -Minimalny złośliwy input Kustomize potrzebny do uruchomienia przetwarzania Helm: +Minimalny złośliwy input Kustomize musi uruchomić przetwarzanie Helm: ```yaml helmCharts: - name: pwn @@ -115,37 +115,37 @@ version: 0.0.1 ``` Dlaczego to działa: -- `argocd-repo-server` klonuje repository przed renderowaniem. -- `--helm-command ./payload.sh` rozwiązuje się względnie do sklonowanego repository. -- code execution nie wymaga wstrzyknięcia shell metacharacterów, jeśli attacker może kontrolować renderowane repository i opcje build Kustomize. +- `argocd-repo-server` klonuje repozytorium przed renderowaniem. +- `--helm-command ./payload.sh` jest rozwiązywane względem sklonowanego repozytorium. +- Wykonanie kodu nie wymaga wstrzykiwania metaznaków powłoki, jeśli atakujący może kontrolować renderowane repozytorium i opcje kompilacji Kustomize. -W momencie ujawnienia przez Synacktiv 1 lipca 2026, zgłosili oni, że issue nie miała oficjalnego fix ani CVE. Traktuj to najpierw jako problem network-exposure: exploitation wymaga osiągalności wewnętrznego portu gRPC repo-server. +W chwili ujawnienia przez Synacktiv 1 lipca 2026 r. poinformowali oni, że problem nie miał oficjalnej poprawki ani CVE. W pierwszej kolejności traktuj to jako problem z ekspozycją sieciową: exploitation wymaga osiągalności wewnętrznego portu gRPC repo-server. -## Redis Cache Poisoning to Deploy Manifests +## Redis Cache Poisoning do wdrażania manifestów -Po code execution w `argocd-repo-server`, albo po bezpośrednim dostępie do Redis z poprawnymi credentials, sprawdź cache entries oparte na Redis. Argo CD często przechowuje gzip-compressed wartości JSON. +Po wykonaniu kodu w `argocd-repo-server` lub po uzyskaniu bezpośredniego dostępu do Redis przy użyciu prawidłowych danych uwierzytelniających sprawdź wpisy cache opartego na Redis. Argo CD często przechowuje wartości JSON skompresowane gzipem. -Interesujące prefixy key: +Interesujące prefiksy kluczy: ```text mfst|... # cached rendered manifests git-refs|... # Git branch/ref to commit mappings app|... # application resource/cache data cluster|... # cluster cache information ``` -Atak cache poisoning opisany przez Synacktiv nadużywa dwóch elementów stanu: +Atak cache poisoning opisany przez Synacktiv wykorzystuje dwa elementy stanu: -1. Zmodyfikuj odpowiedni wpis cache manifestu `mfst|...`, aby zawierał manifest Kubernetes kontrolowany przez atakującego. -2. Zmodyfikuj powiązane mapowanie `git-refs|...`, aby Argo CD uwierzyło, że gałąź została przesunięta, a następnie ponownie zsynchronizowało się do zbuforowanej wersji. +1. Modyfikację odpowiedniego wpisu cache manifestu `mfst|...` w celu dodania manifestu Kubernetes kontrolowanego przez atakującego. +2. Modyfikację powiązanego mapowania `git-refs|...`, aby Argo CD uznało, że branch został zmieniony, a następnie wykonało reconcile z powrotem do revision znajdującego się w cache. Wpływ: -- Przy włączonym Auto Sync Argo CD może automatycznie zastosować zatruty zbuforowany manifest. +- Przy włączonym Auto Sync Argo CD może automatycznie zastosować zatruty manifest znajdujący się w cache. - Bez Auto Sync payload może nadal zostać zastosowany, gdy użytkownik ręcznie zsynchronizuje aplikację. -- Końcowy wpływ jest ograniczony przez destination aplikacji docelowej oraz uprawnienia Kubernetes dostępne dla Argo CD. +- Ostateczny wpływ jest ograniczony przez destination docelowej aplikacji oraz uprawnienia Kubernetes dostępne dla Argo CD. ## ApplicationSet Attacks -ApplicationSet jest szczególnie wrażliwy, ponieważ tworzy lub aktualizuje obiekty `Application` na podstawie wyjścia generatora. +ApplicationSet jest szczególnie wrażliwy, ponieważ tworzy lub aktualizuje obiekty `Application` na podstawie danych wyjściowych generatora. Review: ```bash @@ -154,15 +154,15 @@ kubectl get appprojects.argoproj.io -A -o yaml ``` Interesujące wzorce: -- Generatory git odczytujące pliki zapisywalne przez atakującego, które kontrolują nazwy app, ścieżki, projekty lub destinations. -- Generatory pull request dla publicznych repozytoriów, gdzie nieufni contributorzy mogą wpływać na generowane applications. -- Pola template, które pozwalają na szerokie destination clusters/namespaces. -- AppProjects, które zezwalają na `sourceRepos: ["*"]` lub szerokie `destinations`. -- Generowane applications, które dziedziczą automated sync i pruning. +- Git generators odczytujące pliki zapisywalne przez attackera, które kontrolują nazwy aplikacji, ścieżki, projekty lub destinations. +- Pull request generators dla publicznych repozytoriów, w których niezaufani kontrybutorzy mogą wpływać na generowane aplikacje. +- Pola szablonów umożliwiające szeroki zakres docelowych klastrów lub namespace’ów. +- AppProjects zezwalające na `sourceRepos: ["*"]` lub szerokie `destinations`. +- Generowane aplikacje dziedziczące automated sync i pruning. ## Post-Exploitation -Z poziomu shell w podzie Argo CD, priorytetyzuj: +Z poziomu powłoki poda Argo CD priorytetowo: ```bash env cat /proc/1/environ 2>/dev/null | tr '\0' '\n' @@ -171,24 +171,24 @@ mount | grep -E 'secret|token|config' ``` Przydatne cele: -- Ukradnij `REDIS_PASSWORD` lub material TLS/client Redis. -- Wyciągnij credentials repozytorium z zamontowanych secrets lub Argo CD Kubernetes secrets. -- Zidentyfikuj cluster credentials używane przez Argo CD. -- Odczytaj wygenerowane manifests i output pluginów, które mogą zawierać wstrzyknięte sekrety. -- Sprawdź, czy custom plugins, SOPS, Helm secrets, Vault plugins lub cloud CLIs ujawniają decryption keys i cloud credentials. +- Steal `REDIS_PASSWORD` lub materiały klienta/TLS Redis. +- Extract credentials repozytoriów z zamontowanych secrets lub secrets Kubernetes Argo CD. +- Identify credentials klastra używane przez Argo CD. +- Read generated manifests i output pluginów, które mogą zawierać wstrzyknięte secrets. +- Check whether custom plugins, SOPS, Helm secrets, Vault plugins lub cloud CLIs expose decryption keys i credentials chmurowe. -## Detection & Hardening +## Wykrywanie i hardening Ważne kontrole: -- Ogranicz port **8081** `argocd-repo-server` i port Redis **6379** za pomocą NetworkPolicies, aby tylko oczekiwane komponenty Argo CD mogły się z nimi łączyć. -- W wdrożeniach Helm sprawdź, czy network policies są faktycznie tworzone. Wartości Argo CD Helm chart historycznie miały domyślnie wyłączone tworzenie network policy dla komponentów. -- Traktuj `argocd-server` jako uwierzytelniony punkt wejścia. Usługi wewnętrzne nie powinny być osiągalne z dowolnych workloadów. -- Wyłącz nieużywane narzędzia i pluginy do config management. -- Ogranicz `AppProject` `sourceRepos`, `destinations`, uprawnienia namespace oraz cluster-scoped resources. -- Unikaj przechowywania szerokich repository credentials, które może zostać ponownie użyte przez użytkownika Argo CD o niskich uprawnieniach. -- Monitoruj requests do repo-server, Kustomize build options, wykonania pluginów, zapisy do Redis oraz nieoczekiwany dostęp do kluczy `mfst|` / `git-refs|`. -- Rotuj lokalnych użytkowników Argo CD, project tokens, repository credentials i cluster credentials po kompromitacji. +- Ogranicz port `argocd-repo-server` **8081** i port Redis **6379** za pomocą NetworkPolicies, tak aby tylko oczekiwane komponenty Argo CD mogły się z nimi łączyć. +- W Helm deployments sprawdź, czy network policies są faktycznie tworzone. Wartości Helm chartu Argo CD historycznie domyślnie wyłączały tworzenie network policy dla komponentów. +- Utrzymuj `argocd-server` jako uwierzytelniony punkt wejścia. Usługi wewnętrzne nie powinny być dostępne z dowolnych workloadów. +- Wyłącz nieużywane narzędzia i pluginy do zarządzania konfiguracją. +- Ogranicz `AppProject` `sourceRepos`, `destinations`, uprawnienia do namespace’ów oraz zasoby o zasięgu klastra. +- Unikaj przechowywania szerokich credentials repozytoriów w miejscu, w którym użytkownik Argo CD o niskich uprawnieniach może doprowadzić do ich ponownego użycia. +- Monitoruj requests repo-server, opcje buildowania Kustomize, uruchomienia pluginów, zapisy Redis oraz nieoczekiwany dostęp do kluczy `mfst|` / `git-refs|`. +- Po kompromitacji wykonaj rotację lokalnych użytkowników Argo CD, tokenów projektów, credentials repozytoriów i credentials klastra. Przydatne komendy: ```bash @@ -197,23 +197,24 @@ kubectl get networkpolicy -A | grep -i argocd kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null ``` -## Uwaga dotycząca statycznej analizy: Typed API Requests w CodeQL +## Uwaga dotycząca analizy statycznej: typowane żądania API w CodeQL -Dla usług Go używających handlerów gRPC/REST, domyślne remote sources w CodeQL mogą nie wychwycić przepływów po tym, jak raw input został zdeserializowany do typed request objects. Przydatny model dla usług w stylu Argo CD to: +W przypadku usług Go korzystających z handlerów gRPC/REST domyślne zdalne źródła CodeQL mogą nie wykrywać przepływów po zdeserializowaniu surowych danych wejściowych do typowanych obiektów żądań. Przydatny model dla usług w stylu Argo CD obejmuje: - Typ odbiorcy, taki jak `Server` lub `Service`. - Pierwszy parametr to `context.Context`. -- Drugi parametr to typed request object. +- Drugi parametr to typowany obiekt żądania. -Zamodeluj ten drugi parametr jako remote source i dodaj niestandardowe sinks dla argumentów `exec.Command` / `exec.CommandContext`. To pomaga znaleźć przepływy z pól wewnętrznych API request do helperów wykonujących komendy. +Potraktuj drugi parametr jako zdalne źródło i dodaj własne sinki dla argumentów `exec.Command` / `exec.CommandContext`. Pomaga to wykrywać przepływy z wewnętrznych pól żądań API do helperów wykonujących polecenia. ## Referencje -- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql) -- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) -- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/) -- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/) -- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml) -- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) -- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md) -- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md) +- [Synacktiv - Caught in the Octopus Trap: nieuwierzytelnione RCE w Argo CD z CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql) +- [Dokumentacja Argo CD - uwagi dotyczące bezpieczeństwa](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) +- [Dokumentacja Argo CD - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/) +- [Dokumentacja Argo CD - referencja poleceń repo-server](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/) +- [Argo CD - manifest NetworkPolicy dla repo-server](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml) +- [Dokumentacja Argo CD - metryki](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) +- [Argo Helm - referencja wartości chartu](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md) +- [Kustomize - przykład generatora chartu Helm](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md) +{{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md index 52b7c1b91..ed71bf4d6 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md @@ -6,4 +6,8 @@ az-azure-ai-foundry-post-exploitation.md {{#endref}} +{{#ref}} +az-container-registry-post-exploitation.md +{{#endref}} + {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md new file mode 100644 index 000000000..1a242ebce --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md @@ -0,0 +1,87 @@ +# Az - Container Registry Post Exploitation + +{{#include ../../../banners/hacktricks-training.md}} + +## Azure Container Registry + +Więcej informacji o tej usłudze znajdziesz tutaj: + +{{#ref}} +../az-services/az-container-registry.md +{{#endref}} + +### `Microsoft.ContainerRegistry/registries/listCredentials/action`, `Microsoft.ContainerRegistry/registries/write` + +Tożsamość z dostępem do płaszczyzny zarządzania ACR może przekształcić ten dostęp w **wielokrotnego użytku poświadczenia Docker**. Jeśli **użytkownik administratora** jest wyłączony, ale podmiot ma również uprawnienie `registries/write`, włącz go, odzyskaj hasła i uwierzytelnij się bezpośrednio wobec `.azurecr.io`. +```bash +az acr show --resource-group --name --query adminUserEnabled +az acr update --resource-group --name --admin-enabled true +az acr credential show -n +docker login .azurecr.io -u -p +``` +Jest to przydatne, ponieważ odzyskane dane uwierzytelniające można ponownie wykorzystać poza Azure CLI do **wyświetlania, pobierania, przesyłania, nadpisywania, a czasami także usuwania** zawartości registry, dopóki konto administratora nie zostanie wyłączone lub hasła nie zostaną zmienione. + +### `Microsoft.ContainerRegistry/registries/pull/read` + +Użyj dostępu pull do **repository reconnaissance** i **secret hunting** wewnątrz obrazów. Przeanalizuj zarówno końcową konfigurację kontenera, jak i historyczne warstwy filesystem, ponieważ pliki skopiowane w jednej warstwie mogą pozostać możliwe do odzyskania, nawet jeśli później zostaną usunięte. +```bash +az acr repository list -n +az acr repository show-tags -n --repository --detail +docker pull .azurecr.io/: + +container_id=$(docker create .azurecr.io/:) +docker cp "$container_id":/ ./extracted_container +docker rm "$container_id" +docker inspect .azurecr.io/: | jq -r '.[0].Config.Env[]?' +dive .azurecr.io/: +``` +Cele o wysokiej wartości obejmują **zmienne środowiskowe**, **konfiguracje aplikacji**, **skrypty deploymentu**, **certyfikaty**, **tokeny dostępu** oraz **connection strings**. Aby znaleźć więcej pomysłów podczas przeglądania warstw, sprawdź stronę Docker forensics: + +{{#ref}} +https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html +{{#endref}} + +### `Microsoft.ContainerRegistry/registries/push/write` + +Uprawnienia push pozwalają atakującemu **zatruwać zaufane repozytoria** lub **nadpisywać modyfikowalne tagi**, takie jak `latest`, `prod` lub `stable`. Każdy workload, który nadal wykonuje deployment na podstawie tagu zamiast digestu, może pobrać obraz atakującego podczas następnego deploymentu, zdarzenia scale-out lub restartu. +```bash +# Retag an existing local image for the target ACR + +docker tag : .azurecr.io/: +docker push .azurecr.io/: + +# If your workstation architecture differs from the target runtime, build for the consumer platform first + +docker buildx build --platform linux/amd64 -t .azurecr.io/: --load . +docker push .azurecr.io/: +``` +Przed zastąpieniem tagu sprawdź, które repozytoria i tagi są faktycznie używane przez downstream workloads. Konsumenci **digest-pinned** (`@sha256:...`) są znacznie trudniejsi do przekierowania niż konsumenci korzystający z tagów. + +### `Microsoft.ContainerRegistry/registries/push/write`, `Microsoft.ContainerInstance/containerGroups/restart/action` + +Jeśli możesz zarówno **zastąpić obraz** używany przez downstream container workload, jak i **zrestartować** ten workload, złośliwy entrypoint zostanie wykonany w **kontekście sieciowym i kontekście managed identity** docelowego kontenera. Następnie obraz może żądać tokenów z IMDS i uzyskiwać dostęp do zasobów Azure osiągalnych dla tej workload identity. +```bash +TOKEN=$(curl -s -H Metadata:true 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' | jq -r .access_token) +curl -H "Authorization: Bearer $TOKEN" \ +'https://.vault.azure.net/secrets/?api-version=7.4' +az container restart --resource-group --name +``` +Ta zmiana tagu ACR w **code execution**, **secret theft** lub **lateral movement** wewnątrz dowolnego konsumenta kontenera, który ufa zmodyfikowanemu tagowi i udostępnia użyteczną tożsamość. + +### Powiązana ścieżka privesc: ACR Tasks managed identities + +Jeśli masz również `Microsoft.ContainerRegistry/registries/tasks/write` i `Microsoft.ContainerRegistry/registries/runs/write`, przejdź do ścieżki ACR privesc i bezpośrednio wykorzystaj managed identity zadania: + +{{#ref}} +../az-privilege-escalation/az-container-registry-privesc.md +{{#endref}} + +## Referencje + +- [TrustedSec - Pandora's Container Part 1: Unpacking Azure Container Security](https://trustedsec.com/blog/pandoras-container-part-1-unpacking-azure-container-security) +- [Microsoft Learn - Azure Container Registry authentication](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication) +- [Microsoft Learn - az acr credential](https://learn.microsoft.com/en-us/cli/azure/acr/credential?view=azure-cli-latest) +- [Microsoft Learn - az acr repository](https://learn.microsoft.com/en-us/cli/azure/acr/repository?view=azure-cli-latest) +- [Microsoft Learn - ACR Tasks YAML reference](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-reference-yaml) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md index 1a5de07c1..9810dc5aa 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md +++ b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md @@ -4,37 +4,37 @@ ## Podstawowe informacje -Azure Container Registry (ACR) to bezpieczny, prywatny registry, który pozwala **przechowywać, zarządzać i uzyskiwać dostęp do container images w Azure cloud**. Integruje się bezproblemowo z kilkoma usługami Azure, zapewniając automatyczne workflows build i deployment na dużą skalę. Dzięki funkcjom takim jak geo-replication i vulnerability scanning, ACR pomaga zapewnić bezpieczeństwo klasy enterprise oraz compliance dla aplikacji kontenerowych. +Azure Container Registry (ACR) to bezpieczny, prywatny registry, który umożliwia **przechowywanie, zarządzanie obrazami kontenerów oraz uzyskiwanie do nich dostępu w Azure cloud**. Integruje się bezproblemowo z kilkoma usługami Azure, zapewniając zautomatyzowane workflow budowania i wdrażania na dużą skalę. Dzięki funkcjom takim jak geo-replikacja i skanowanie podatności ACR pomaga zapewnić bezpieczeństwo klasy enterprise oraz zgodność dla aplikacji konteneryzowanych. -### Permissions +### Uprawnienia -Oto **różne permissions** [zgodnie z docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager), które można nadać dla Container Registry: +Są to **różne uprawnienia** [zgodnie z dokumentacją](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager), które można nadać w ramach Container Registry: -- Access Resource Manager -- Create/delete registry -- Push image -- Pull image -- Delete image data -- Change policies -- Sign images +- Dostęp do Resource Manager +- Tworzenie/usuwanie registry +- Push obrazu +- Pull obrazu +- Usuwanie danych obrazu +- Zmiana policies +- Podpisywanie obrazów -Istnieją też pewne **built-in roles**, które można przypisać, a także możliwe jest tworzenie **custom roles**. +Dostępne są również pewne **wbudowane role**, które można przypisać, a także możliwe jest tworzenie **custom roles**. -![Azure Container Registry built-in roles permissions matrix for managing registry, image, data, policies, and signing actions](/images/registry_roles.png) +![Macierz uprawnień wbudowanych ról Azure Container Registry do zarządzania registry, obrazami, danymi, policies i operacjami podpisywania](/images/registry_roles.png) -### Authentication +### Uwierzytelnianie > [!WARNING] -> Bardzo ważne jest, że nawet jeśli nazwa registry zawiera wielkie litery, zawsze powinieneś używać **małych liter** do login, push i pull images. +> Bardzo ważne jest, aby nawet jeśli nazwa registry zawiera wielkie litery, zawsze używać **małych liter** podczas logowania oraz wykonywania push i pull obrazów. -Istnieją 4 sposoby authentication do ACR: +Istnieją 4 sposoby uwierzytelniania w ACR: -- **With Entra ID**: To jest **default** sposób authentication do ACR. Używa komendy **`az acr login`**, aby authenticate do ACR. Ta komenda **zapisze credentials** w pliku **`~/.docker/config.json`**. Co więcej, jeśli uruchamiasz tę komendę w środowisku bez dostępu do docker socket, jak w **cloud shell**, można użyć flagi **`--expose-token`**, aby uzyskać **token** do authenticate do ACR. Następnie, aby authenticate, musisz użyć jako nazwy użytkownika `00000000-0000-0000-0000-000000000000`, np.: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` -- **With an admin account**: Admin user jest domyślnie wyłączony, ale można go włączyć, a wtedy będzie możliwy access do registry przy użyciu **username** i **password** konta admin z pełnymi permissions do registry. Nadal jest to wspierane, ponieważ używają tego niektóre usługi Azure. Zwróć uwagę, że dla tego użytkownika tworzone są **2 passwords** i oba są poprawne. Możesz to włączyć poleceniem `az acr update -n --admin-enabled true`. Zwróć uwagę, że username to zwykle nazwa registry (a nie `admin`). -- **With a token**: Możliwe jest utworzenie **token** z określonym **scope map** (permissions) do access registry. Następnie można użyć nazwy token jako username i dowolnego z wygenerowanych passwords do authenticate do registry przy użyciu `docker login -u -p ` -- **With a Service Principal**: Możliwe jest utworzenie **service principal** i przypisanie roli takiej jak **`AcrPull`**, aby pull images. Wtedy będzie możliwy **login to the registry** przy użyciu appId SP jako username oraz wygenerowanego secret jako password. +- **Za pomocą Entra ID**: Jest to **domyślny** sposób uwierzytelniania w ACR. Wykorzystuje polecenie **`az acr login`** do uwierzytelnienia w ACR. To polecenie **zapisze dane uwierzytelniające** w pliku **`~/.docker/config.json`**. Ponadto, jeśli uruchamiasz to polecenie ze środowiska bez dostępu do socketu Docker, na przykład w **cloud shell**, można użyć flagi **`--expose-token`**, aby uzyskać **token** do uwierzytelnienia w ACR. Następnie, aby się uwierzytelnić, należy użyć jako nazwy użytkownika `00000000-0000-0000-0000-000000000000`, na przykład: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` +- **Za pomocą konta administratora**: Użytkownik administratora jest domyślnie wyłączony, ale można go włączyć. Następnie możliwy będzie dostęp do registry przy użyciu **nazwy użytkownika** i **hasła** konta administratora, które ma pełne uprawnienia do registry. Jest to nadal obsługiwane, ponieważ niektóre usługi Azure z niego korzystają. Należy pamiętać, że dla tego użytkownika tworzone są **2 hasła** i oba są prawidłowe. Można je włączyć za pomocą `az acr update -n --admin-enabled true`. Należy pamiętać, że nazwa użytkownika to zwykle nazwa registry (a nie `admin`). +- **Za pomocą tokena**: Możliwe jest utworzenie **tokena** z określonym **`scope map`** (uprawnieniami) w celu uzyskania dostępu do registry. Następnie można użyć nazwy tokena jako nazwy użytkownika oraz dowolnego wygenerowanego hasła do uwierzytelnienia w registry za pomocą `docker login -u -p ` +- **Za pomocą Service Principal**: Możliwe jest utworzenie **service principal** i przypisanie mu roli takiej jak **`AcrPull`** w celu pobierania obrazów. Następnie możliwe będzie **logowanie do registry** przy użyciu appId SP jako nazwy użytkownika oraz wygenerowanego sekretu jako hasła. -Przykładowy skrypt z [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal), aby wygenerować SP z access do registry: +Przykładowy skrypt z [dokumentacji](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) do wygenerowania SP z dostępem do registry: ```bash #!/bin/bash ACR_NAME=$containerRegistry @@ -51,39 +51,39 @@ echo "Service principal password: $PASSWORD" ``` ### Szyfrowanie -Tylko **Premium SKU** obsługuje **encryption at rest** dla obrazów i innych artefaktów. +Tylko **Premium SKU** obsługuje **szyfrowanie danych w spoczynku** dla obrazów i innych artefaktów. -### Networking +### Sieci -Tylko **Premium SKU** obsługuje **private endpoints**. Pozostałe obsługują tylko **public access**. Public endpoint ma format `.azurecr.io`, a private endpoint ma format `.privatelink.azurecr.io`. Z tego powodu nazwa registry musi być unikalna w całym Azure. +Tylko **Premium SKU** obsługuje **prywatne punkty końcowe**. Pozostałe obsługują wyłącznie **publiczny dostęp**. Publiczny punkt końcowy ma format `.azurecr.io`, a prywatny punkt końcowy ma format `.privatelink.azurecr.io`. Z tego powodu nazwa rejestru musi być unikalna w całym Azure. ### Microsoft Defender for Cloud -To pozwala **scan the images** w registry pod kątem **vulnerabilities**. +Umożliwia **skanowanie obrazów** w rejestrze pod kątem **podatności**. ### Soft-delete -Funkcja **soft-delete** pozwala **odzyskać usunięty registry** w określonej liczbie dni. Ta funkcja jest **disabled by default**. +Funkcja **soft-delete** umożliwia **odzyskanie usuniętego rejestru** w ciągu wskazanej liczby dni. Ta funkcja jest **domyślnie wyłączona**. ### Webhooks -Możliwe jest **create webhooks** wewnątrz registry. W tym webhooku trzeba podać URL, na który **request będzie wysyłany za każdym razem, gdy zostanie wykonana akcja push lub delete**. Dodatkowo Webhooks mogą wskazywać scope, aby określić repositories (images), których to dotyczy. Na przykład, 'foo:\*' oznacza zdarzenia w obrębie repository 'foo'. +Możliwe jest **tworzenie Webhooks** wewnątrz rejestrów. W tym Webhooku należy określić adres URL, do którego **zostanie wysłane żądanie za każdym razem, gdy zostanie wykonana akcja push lub delete**. Ponadto Webhooks mogą określać zakres wskazujący repozytoria (obrazy), których będą dotyczyć. Na przykład `foo:\*` oznacza zdarzenia w repozytorium `foo`. -Z perspektywy attackers interesujące jest sprawdzenie tego **przed wykonaniem jakiejkolwiek akcji** w registry, a w razie potrzeby tymczasowe usunięcie tego, aby uniknąć wykrycia. +Z perspektywy atakującego interesujące jest sprawdzenie tego **przed wykonaniem jakiejkolwiek akcji** w rejestrze i tymczasowe usunięcie Webhooka, jeśli jest to konieczne, aby uniknąć wykrycia. -### Connected registries +### Połączone rejestry -To zasadniczo pozwala **mirror the images** z jednego registry do innego, zwykle znajdującego się on-premises. +Zasadniczo umożliwia to **mirrorowanie obrazów** z jednego rejestru do drugiego, zwykle znajdującego się lokalnie (on-premises). -Ma 2 tryby: **ReadOnly** i **ReadWrite**. W pierwszym obrazy są tylko **pulled** ze źródłowego registry, a w drugim obrazy mogą być także **pushed** do źródłowego registry. +Dostępne są 2 tryby: **ReadOnly** i **ReadWrite**. W pierwszym obrazy są tylko **pobierane** z rejestru źródłowego, a w drugim obrazy mogą być również **wysyłane** do rejestru źródłowego. -Aby clients mogli uzyskać dostęp do registry z Azure, generowany jest **token** przy użyciu connected registry. +Aby klienci mogli uzyskać dostęp do rejestru z Azure, podczas korzystania z połączonego rejestru generowany jest **token**. ### Runs & Tasks -Runs & Tasks pozwala wykonywać w Azure działania związane z container, które zazwyczaj trzeba było robić lokalnie albo w pipeline CI/CD. Na przykład możesz **build, push, and run images in the registry**. +Runs & Tasks umożliwia wykonywanie w Azure działań związanych z kontenerami, które zazwyczaj trzeba było wykonywać lokalnie lub w potoku CI/CD. Możesz na przykład **budować, wysyłać i uruchamiać obrazy w rejestrze**. -Najprostszy sposób na zbudowanie i uruchomienie container to użycie zwykłego Run: +Najłatwiejszym sposobem na zbudowanie i uruchomienie kontenera jest użycie zwykłego Run: ```bash # Build echo "FROM mcr.microsoft.com/hello-world" > Dockerfile @@ -92,20 +92,20 @@ az acr build --image sample/hello-world:v1 --registry mycontainerregistry008 --f # Run az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world:v1' /dev/null ``` -However, to uruchomi runs, które nie są super interesujące z perspektywy attacker, ponieważ nie mają do nich attached żadnej managed identity. +Jednak spowoduje to uruchomienie zadań, które z perspektywy atakującego nie są szczególnie interesujące, ponieważ nie jest do nich przypisana żadna managed identity. -However, **tasks** mogą mieć attached **system and user managed identity**. Te tasks są tymi, które są użyteczne do **escalate privileges** w kontenerze. W sekcji privileges escalation można zobaczyć, jak używać tasks do escalate privileges. +Jednak **tasks** mogą mieć przypisaną **system and user managed identity**. To właśnie te tasks są przydatne do **escalate privileges** w kontenerze. W sekcji dotyczącej privilege escalation można zobaczyć, jak używać tasks do eskalowania uprawnień. ### Cache -Funkcja cache pozwala **download images from an external repository** i store the new versions w registry. Wymaga to skonfigurowania pewnych **credentials** przez wybranie credentials z Azure Vault. +Funkcja cache umożliwia **download images from an external repository** i przechowywanie nowych wersji w registry. Wymaga to posiadania **credentials configured** poprzez wybranie poświadczeń z Azure Vault. -Jest to bardzo interesujące z perspektywy attacker, ponieważ pozwala na **pivot to an external platform** jeśli attacker ma wystarczające permissions, aby access credentials, **download images from an external repository** i configuring a cache could also be used as **persistence mechanism**. +Jest to bardzo interesujące z perspektywy atakującego, ponieważ umożliwia **pivot to an external platform**, jeśli atakujący ma wystarczające uprawnienia do uzyskania dostępu do poświadczeń. **Download images from an external repository** i skonfigurowanie cache może również służyć jako **persistence mechanism**. ## Enumeration > [!WARNING] -> Bardzo ważne jest, aby nawet jeśli nazwa registry zawiera jakieś uppercase letters, do access it w url należy używać wyłącznie lowercase letters. +> Bardzo ważne jest, aby nawet jeśli nazwa registry zawiera wielkie litery, w adresie URL używanym do uzyskania dostępu stosować wyłącznie małe litery. ```bash # List of all the registries # Check the network, managed identities, adminUserEnabled, softDeletePolicy, url... @@ -143,19 +143,23 @@ az acr cache list --registry # Get cache details az acr cache show --name --registry ``` -## Nieautoryzowany dostęp +## Niezautoryzowany dostęp {{#ref}} ../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md {{#endref}} -## Privilege Escalation & Post Exploitation +## Eskalacja uprawnień i Post Exploitation {{#ref}} ../az-privilege-escalation/az-container-registry-privesc.md {{#endref}} -## References +{{#ref}} +../az-post-exploitation/az-container-registry-post-exploitation.md +{{#endref}} + +## Referencje - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli) - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)