From d2ebda0cbd2069fd94fa871832d0a2993cc576c5 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 6 Jul 2026 15:54:46 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c --- src/pentesting-ci-cd/argocd-security.md | 219 ++++++++++++++++++ .../pentesting-ci-cd-methodology.md | 115 ++++----- 2 files changed, 277 insertions(+), 57 deletions(-) create mode 100644 src/pentesting-ci-cd/argocd-security.md diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md new file mode 100644 index 000000000..ddd9c9113 --- /dev/null +++ b/src/pentesting-ci-cd/argocd-security.md @@ -0,0 +1,219 @@ +# Argo CD Security + +{{#include ../banners/hacktricks-training.md}} + +## 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. + +Z perspektywy atakującego traktuj Argo CD jako **silnik wdrożeniowy z poświadczeniami Kubernetes**. Udana kompromitacja 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. + +## Architektura i interesujące komponenty + +Typowe obiekty i usługi Kubernetes: +```bash +kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd' +kubectl get applications,appprojects,applicationsets -A 2>/dev/null +kubectl get secrets,configmaps -n argocd 2>/dev/null +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. + +Z kompromitowanego pod lub wewnętrznego segmentu sieci sprawdź wewnętrzną dostępność: +```bash +nc -vz 443 +nc -vz 8081 +nc -vz 6379 +``` +## Public API / UI Attacks + +Jeśli masz poświadczenia Argo CD albo wystawioną instancję, zacznij od normalnej powierzchni API: +```bash +argocd login +argocd account get-user-info +argocd account list +argocd proj list +argocd app list +argocd repo list +argocd cluster list +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ą. + +Wylicz konfigurację z Kubernetes, gdy masz cluster read access: +```bash +kubectl get applications.argoproj.io -A -o yaml +kubectl get appprojects.argoproj.io -A -o yaml +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 + +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. + +Common payload locations: + +- 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`. + +Sprawdź, czy app używa automated sync, pruning, self-heal, sync windows albo manual approvals: +```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`. + +Praktyczne sprawdzenia: +```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: + +- 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. + +## 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`. + +Niebezpieczny primitive polega na wymuszeniu, aby repo-server sklonował zawartość repository kontrolowaną przez atakującego 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: +```yaml +helmCharts: +- name: pwn +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. + +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. + +## Redis Cache Poisoning to Deploy Manifests + +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. + +Interesujące prefixy key: +```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: + +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. + +Wpływ: + +- Przy włączonym Auto Sync Argo CD może automatycznie zastosować zatruty zbuforowany manifest. +- 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. + +## ApplicationSet Attacks + +ApplicationSet jest szczególnie wrażliwy, ponieważ tworzy lub aktualizuje obiekty `Application` na podstawie wyjścia generatora. + +Review: +```bash +kubectl get applicationsets.argoproj.io -A -o yaml +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. + +## Post-Exploitation + +Z poziomu shell w podzie Argo CD, priorytetyzuj: +```bash +env +cat /proc/1/environ 2>/dev/null | tr '\0' '\n' +find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null +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. + +## Detection & 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. + +Przydatne komendy: +```bash +kubectl get networkpolicy -n argocd +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 + +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: + +- Typ odbiorcy, taki jak `Server` lub `Service`. +- Pierwszy parametr to `context.Context`. +- Drugi parametr to typed request object. + +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. + +## 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) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 921b56172..6968dcba8 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Metodologia Pentesting CI/CD +# Pentesting CI/CD Methodology {{#include ../banners/hacktricks-training.md}} @@ -6,7 +6,7 @@ ## VCS -VCS oznacza **Version Control System**, ten system pozwala developerom **zarządzać kodem źródłowym**. Najczęściej spotykany to **git** i zwykle można go znaleźć w firmach używających jednej z poniższych **platform**: +VCS to skrót od **Version Control System**, ten system pozwala developerom **zarządzać swoim source code**. Najpopularniejszy z nich to **git** i zwykle można go znaleźć w firmach używających jednej z poniższych **platform**: - Github - Gitlab @@ -18,39 +18,39 @@ VCS oznacza **Version Control System**, ten system pozwala developerom **zarząd ## CI/CD Pipelines -CI/CD pipelines umożliwiają developerom **automatyzację wykonywania code** do różnych celów, w tym budowania, testowania i wdrażania aplikacji. Te zautomatyzowane workflow są **wyzwalane przez konkretne akcje**, takie jak push code, pull requesty lub zadania zaplanowane. Są użyteczne do usprawnienia procesu od development do production. +CI/CD pipelines umożliwiają developerom **automatyzację wykonywania code** do różnych celów, w tym buildowania, testowania i deployowania aplikacji. Te zautomatyzowane workflow są **wyzwalane przez określone akcje**, takie jak push code, pull requests lub zaplanowane zadania. Są przydatne do usprawnienia procesu od developmentu do production. -Jednak te systemy muszą być **uruchamiane gdzieś** i zwykle z **uprzywilejowanymi credentials do wdrażania code lub dostępu do poufnych informacji**. +Jednak te systemy muszą być **wykonywane gdzieś** i zwykle z **privileged credentials do deploy code lub access do wrażliwych informacji**. ## VCS Pentesting Methodology > [!NOTE] -> Nawet jeśli niektóre platformy VCS pozwalają tworzyć pipelines, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę nad kodem źródłowym. +> Nawet jeśli niektóre platformy VCS pozwalają tworzyć pipelines, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę source code. -Platformy zawierające kod źródłowy Twojego projektu zawierają poufne informacje i ludzie muszą bardzo uważać na uprawnienia nadawane w obrębie tej platformy. Oto kilka typowych problemów występujących na platformach VCS, które atakujący mógłby wykorzystać: +Platformy, które zawierają source code twojego projektu, zawierają wrażliwe informacje i ludzie muszą bardzo uważać na uprawnienia przyznawane w tej platformie. Oto kilka typowych problemów występujących na platformach VCS, które attacker mógłby wykorzystać: -- **Leaks**: Jeśli Twój code zawiera leaks w commitach, a atakujący może uzyskać dostęp do repo (bo jest publiczne albo ma dostęp), może odkryć te leaks. -- **Access**: Jeśli atakujący może **uzyskać dostęp do konta w platformie VCS**, może zdobyć **większą widoczność i więcej uprawnień**. -- **Register**: Niektóre platformy po prostu pozwalają zewnętrznym użytkownikom utworzyć konto. -- **SSO**: Niektóre platformy nie pozwalają użytkownikom się rejestrować, ale pozwalają każdemu uzyskać dostęp przy użyciu poprawnego SSO (więc atakujący mógłby na przykład użyć swojego konta github, aby wejść). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... istnieje kilka rodzajów tokenów, które użytkownik mógłby ukraść, aby w jakiś sposób uzyskać dostęp do repo. -- **Webhooks**: Platformy VCS pozwalają generować webhooks. Jeśli nie są **zabezpieczone** niewidocznymi secrets, **atakujący mógłby je nadużyć**. -- Jeśli nie ma ustawionego secret, atakujący może nadużyć webhooka platformy third party -- Jeśli secret jest w URL, dzieje się to samo, a atakujący również ma secret -- **Code compromise:** Jeśli złośliwy aktor ma jakiś rodzaj dostępu **write** do repo, może spróbować **wstrzyknąć złośliwy code**. Aby to się udało, może potrzebować **obejść branch protections**. Działania te mogą być wykonywane z różnymi celami: -- Skompromitować główną gałąź, aby **skomproitować production**. -- Skompromitować główną (lub inne gałęzie), aby **skomproitować maszyny developerów** (ponieważ zwykle uruchamiają oni test, terraform lub inne rzeczy w repo na swoich maszynach). -- **Skompromitować pipeline** (sprawdź następną sekcję) +- **Leaks**: Jeśli twój code zawiera leaks w commitach i attacker może access repo (bo jest publiczne albo bo ma access), może odkryć te leaks. +- **Access**: Jeśli attacker może **access do account w platformie VCS**, może zyskać **większą widoczność i uprawnienia**. +- **Register**: Niektóre platformy po prostu pozwalają zewnętrznym użytkownikom tworzyć account. +- **SSO**: Niektóre platformy nie pozwalają użytkownikom się rejestrować, ale pozwalają każdemu access z ważnym SSO (więc attacker mógłby na przykład użyć swojego github account, aby wejść). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... istnieje kilka rodzajów tokens, które user może ukraść, aby w jakiś sposób access repo. +- **Webhooks**: Platformy VCS pozwalają generować webhooks. Jeśli nie są **chronione** niewidocznymi secrets, **attacker could abuse them**. +- Jeśli nie ma żadnego secret, attacker może wykorzystać webhook platformy zewnętrznej +- Jeśli secret jest w URL, dzieje się to samo, a attacker także ma secret +- **Code compromise:** Jeśli złośliwy actor ma jakiegoś rodzaju access **write** do repo, może spróbować **wstrzyknąć malicious code**. Aby odnieść sukces, może potrzebować **bypass branch protections**. Te działania mogą być wykonane z różnymi celami: +- Compromise główną branch, aby **compromise production**. +- Compromise główną (lub inne branches), aby **compromise developers machines** (ponieważ zwykle uruchamiają testy, terraform lub inne rzeczy w repo na swoich maszynach). +- **Compromise the pipeline** (check next section) ## Pipelines Pentesting Methodology -Najczęstszym sposobem definiowania pipeline jest użycie **pliku CI configuration hostowanego w repository**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na przepływ oraz ustawienia środowiska builda.\ -Te pliki zwykle mają spójną nazwę i format, na przykład — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions znajdujące się w .github/workflows. Po uruchomieniu job pipeline **pobiera code** z wybranego źródła (np. commit / branch) i **uruchamia commands określone w pliku CI configuration** na tym code. +Najczęstszym sposobem definiowania pipeline jest użycie **CI configuration file hostowanego w repository** budowanego przez pipeline. Ten plik opisuje kolejność wykonywanych jobs, warunki wpływające na flow oraz ustawienia środowiska build.\ +Te pliki zwykle mają spójną nazwę i format, na przykład — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions znajdujące się w .github/workflows. Gdy pipeline zostanie wyzwolony, job pipeline **pobiera code** z wybranego source (np. commit / branch) i **uruchamia commands określone w CI configuration file** przeciwko temu code. -Dlatego ostatecznym celem atakującego jest w jakiś sposób **skomproitować te pliki konfiguracyjne** albo **commands, które wykonują**. +Dlatego ostatecznym celem attacker jest w jakiś sposób **compromise tych configuration files** albo **commands, które wykonują**. > [!TIP] -> Niektóre hosted builders pozwalają contributorom wybrać Docker build context i ścieżkę do Dockerfile. Jeśli context jest kontrolowany przez atakującego, możesz ustawić go poza repo (np. ".."), aby w trakcie builda wczytać pliki hosta i wyekstrahować secrets. Zobacz: +> Niektóre hosted builders pozwalają contributorom wybierać Docker build context i ścieżkę Dockerfile. Jeśli context jest kontrolowany przez attacker, możesz ustawić go poza repo (np. ".."), aby podczas build odczytać host files i exfiltrate secrets. Zobacz: > >{{#ref}} >docker-build-context-abuse.md @@ -58,72 +58,73 @@ Dlatego ostatecznym celem atakującego jest w jakiś sposób **skomproitować te ### PPE - Poisoned Pipeline Execution -Ścieżka Poisoned Pipeline Execution (PPE) wykorzystuje uprawnienia w repo SCM do manipulowania CI pipeline i wykonywania szkodliwych commands. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować pliki CI configuration lub inne pliki używane przez job pipeline, aby wstawić złośliwe commands. To „zatruwa” CI pipeline, prowadząc do wykonania tych złośliwych commands. +Ścieżka Poisoned Pipeline Execution (PPE) wykorzystuje uprawnienia w repository SCM do manipulowania pipeline CI i uruchamiania harmful commands. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować CI configuration files lub inne pliki używane przez job pipeline, aby dodać malicious commands. To „zatruwa” pipeline CI, prowadząc do wykonania tych malicious commands. -Aby złośliwy aktor odniósł sukces w ataku PPE, musi być w stanie: +Aby malicious actor mógł skutecznie przeprowadzić attack PPE, musi być w stanie: -- Mieć **write access do platformy VCS**, ponieważ zwykle pipelines są wyzwalane, gdy wykonywany jest push lub pull request. (Sprawdź VCS pentesting methodology, aby zobaczyć podsumowanie sposobów uzyskania dostępu). -- Zwróć uwagę, że czasem **external PR liczy się jako "write access"**. -- Nawet mając write permissions, musi mieć pewność, że może **modyfikować plik CI config lub inne pliki, na których opiera się config**. -- W tym celu może potrzebować możliwości **obejścia branch protections**. +- Mieć **write access do platformy VCS**, ponieważ zwykle pipelines są wyzwalane przy push lub pull request. (Sprawdź VCS pentesting methodology po podsumowanie sposobów uzyskania access). +- Zwróć uwagę, że czasami **external PR count as "write access"**. +- Nawet jeśli ma write permissions, musi mieć pewność, że może **modify CI config file lub other files, na których config polega**. +- W tym celu może potrzebować możliwości **bypass branch protections**. Istnieją 3 odmiany PPE: -- **D-PPE**: Atak **Direct PPE** występuje, gdy aktor **modyfikuje plik CI config**, który ma zostać wykonany. -- **I-DDE**: Atak **Indirect PPE** występuje, gdy aktor **modyfikuje** **plik**, na którym opiera się plik CI config, który ma zostać wykonany (na przykład make file lub terraform config). -- **Public PPE or 3PE**: W niektórych przypadkach pipeline mogą być **wyzwalane przez użytkowników, którzy nie mają write access do repo** (i którzy mogą nawet nie należeć do org), ponieważ mogą wysłać PR. -- **3PE Command Injection**: Zwykle CI/CD pipelines **ustawiają environment variables** z **informacjami o PR**. Jeśli ta wartość może być kontrolowana przez atakującego (na przykład tytuł PR) i jest **używana** w **niebezpiecznym miejscu** (na przykład do wykonywania **sh commands**), atakujący może **wstrzyknąć tam commands**. +- **D-PPE**: Atak **Direct PPE** występuje, gdy actor **modyfikuje CI config** file, który ma zostać wykonany. +- **I-DDE**: Atak **Indirect PPE** występuje, gdy actor **modyfikuje** **file**, na którym CI config file, który ma zostać wykonany, **polega** (np. make file lub terraform config). +- **Public PPE or 3PE**: W niektórych przypadkach pipelines mogą być **wyzwalane przez users, którzy nie mają write access w repo** (a nawet mogą nie być częścią org), ponieważ mogą wysłać PR. +- **3PE Command Injection**: Zwykle CI/CD pipelines **ustawiają environment variables** z **informacjami o PR**. Jeśli taką wartością może sterować attacker (np. tytułem PR) i jest ona **używana** w **niebezpiecznym miejscu** (np. do wykonywania **sh commands**), attacker może **inject commands** tam. ### Exploitation Benefits -Znając 3 odmiany zatruwania pipeline, sprawdźmy, co atakujący może uzyskać po skutecznej eksploatacji: +Znając 3 odmiany zatruwania pipeline, sprawdźmy, co attacker mógłby uzyskać po udanym exploitation: -- **Secrets**: Jak wspomniano wcześniej, pipelines wymagają **uprawnień** do swoich jobów (pobranie code, build, deploy itp.), a te uprawnienia są zwykle **zawarte w secrets**. Te secrets są zwykle dostępne przez **env variables lub pliki w systemie**. Dlatego atakujący zawsze będzie próbował wyekstrahować jak najwięcej secrets. -- Zależnie od platformy pipeline atakujący **może potrzebować wskazać secrets w config**. Oznacza to, że jeśli atakujący nie może modyfikować CI configuration pipeline (**I-PPE** na przykład), może **ekstrahować tylko te secrets, które ma dany pipeline**. -- **Computation**: Code jest wykonywany gdzieś; w zależności od tego gdzie, atakujący może być w stanie dalej pivotować. -- **On-Premises**: Jeśli pipelines są uruchamiane on premises, atakujący może trafić do **internal network z dostępem do większej liczby zasobów**. -- **Cloud**: Atakujący mógłby uzyskać dostęp do **innych maszyn w cloud**, ale także **ekstrahować** IAM roles/service accounts **tokens** z nich, aby uzyskać **dalszy dostęp wewnątrz cloud**. -- **Platforms machine**: Czasem joby będą wykonywane na **maszynach platformy pipelines**, które zwykle są w cloud z **brakiem dalszego dostępu**. -- **Select it:** Czasem **platforma pipelines będzie miała skonfigurowanych kilka maszyn** i jeśli możesz **modyfikować plik CI configuration**, możesz **określić, gdzie chcesz uruchomić złośliwy code**. W takiej sytuacji atakujący prawdopodobnie uruchomi reverse shell na każdej możliwej maszynie, aby spróbować wykorzystać ją dalej. -- **Compromise production**: Jeśli jesteś inside pipeline, a finalna wersja jest z niego budowana i wdrażana, możesz **skomproitować code, który finalnie będzie uruchomiony w production**. +- **Secrets**: Jak wspomniano wcześniej, pipelines wymagają **privileges** do swoich jobs (pobranie code, build, deploy it...) i te privileges są zwykle **przyznawane w secrets**. Te secrets są zwykle dostępne przez **env variables lub files wewnątrz systemu**. Dlatego attacker zawsze będzie próbował exfiltrate jak najwięcej secrets. +- W zależności od platformy pipeline attacker **może potrzebować określić secrets w config**. Oznacza to, że jeśli attacker nie może modify CI configuration pipeline (**I-PPE** na przykład), może **tylko exfiltrate secrets, które ten pipeline ma**. +- **Computation**: code jest wykonywany gdzieś, a w zależności od miejsca wykonania attacker może mieć możliwość dalszego pivot. +- **On-Premises**: Jeśli pipelines są wykonywane on premises, attacker może skończyć w **internal network z access do większej liczby resources**. +- **Cloud**: Attacker może access **other machines in the cloud**, ale także może **exfiltrate** IAM roles/service accounts **tokens** stamtąd, aby uzyskać **dalszy access inside the cloud**. +- **Platforms machine**: Czasami jobs będą execute wewnątrz **maszyn platformy pipelines**, które zwykle znajdują się w cloud z **brakiem dalszego access**. +- **Select it:** Czasami **platforma pipelines będzie miała skonfigurowane kilka maszyn** i jeśli możesz **modify CI configuration file**, możesz **wskazać, gdzie chcesz uruchomić malicious code**. W takiej sytuacji attacker prawdopodobnie uruchomi reverse shell na każdej możliwej maszynie, aby spróbować wykorzystać ją dalej. +- **Compromise production**: Jeśli jesteś inside pipeline i finalna wersja jest z niego buildowana i deployowana, możesz **compromise code, który będzie ostatecznie działał w production**. ### Dependency & Registry Supply-Chain Abuse -Skompromitowanie CI/CD pipeline lub kradzież credentials z niego może pozwolić atakującemu przejść od **pipeline execution** do **ecosystem-wide code execution** poprzez backdooring dependencies lub release tooling: +Compromising CI/CD pipeline albo stealing credentials z niego może pozwolić attackerowi przejść od **pipeline execution** do **ecosystem-wide code execution** przez backdooring dependencies lub release tooling: -- **Install-time code execution via package hooks**: opublikuj wersję package, która dodaje `preinstall`, `postinstall`, `prepare` lub podobne hooks, aby payload uruchamiał się automatycznie na stacjach developerów i runnerach CI podczas instalacji dependency. -- **Secondary execution paths**: nawet jeśli cele instalują z `--ignore-scripts`, złośliwy package może nadal zarejestrować **common CLI name** w polu `bin`, dzięki czemu wrapper kontrolowany przez atakującego zostanie zlinkowany do `PATH` i uruchomi się później, gdy polecenie zostanie użyte. -- **Runtime bootstrapping**: mały installer może pobrać drugi runtime lub toolchain podczas instalacji (na przykład Bun lub spakowany interpreter), a następnie uruchomić z nim główny payload, omijając lokalne wymagania dependency. -- **Credential harvesting from build environments**: gdy code działa wewnątrz CI, sprawdź environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs oraz lokalne narzędzia, takie jak `gh auth token`. W GitHub Actions sprawdź także secrets i artifacts specyficzne dla runnera. -- **Workflow injection with stolen GitHub tokens**: token z uprawnieniami **`repo` + `workflow`** wystarcza, aby utworzyć branch, commit złośliwego pliku w `.github/workflows/`, uruchomić go, zebrać wygenerowane artifacts/logs, a następnie usunąć tymczasowy branch/uruchomienie workflow, aby ograniczyć ślady. -- **Wormable registry propagation**: skradzione npm tokens należy zweryfikować pod kątem uprawnień **publish** i tego, czy omijają 2FA. Jeśli tak, wylicz zapisywalne packages, pobierz ich tarballe, wstrzyknij loader taki jak `setup.mjs`, ustaw `preinstall`, aby go wykonał, zwiększ wersję patch i opublikuj ponownie. To zamienia jedno skompromitowanie CI w auto-execution downstream w innych środowiskach. +- **Install-time code execution via package hooks**: opublikuj wersję package, która dodaje `preinstall`, `postinstall`, `prepare` lub podobne hooks, aby payload uruchamiał się automatycznie na developer workstations i CI runners podczas dependency installation. +- **Secondary execution paths**: nawet jeśli targets instalują z `--ignore-scripts`, malicious package nadal może zarejestrować **common CLI name** w polu `bin`, dzięki czemu wrapper kontrolowany przez attacker zostanie zlinkowany do `PATH` i uruchomi się później, gdy command zostanie użyty. +- **Runtime bootstrapping**: mały installer może pobrać drugi runtime lub toolchain podczas installation (na przykład Bun lub spakowany interpreter), a następnie uruchomić z nim główny payload, omijając lokalne dependency requirements. +- **Credential harvesting from build environments**: gdy code uruchamia się w CI, sprawdź environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs i lokalne tooling, takie jak `gh auth token`. W GitHub Actions sprawdź też secrets i artifacts specyficzne dla runnera. +- **Workflow injection with stolen GitHub tokens**: token z uprawnieniami **`repo` + `workflow`** wystarczy, aby utworzyć branch, commit z malicious file wewnątrz `.github/workflows/`, wyzwolić go, zebrać wygenerowane artifacts/logs, a następnie usunąć tymczasowy branch/workflow run, aby zmniejszyć ślady. +- **Wormable registry propagation**: skradzione npm tokens należy zweryfikować pod kątem uprawnień **publish** i tego, czy omijają 2FA. Jeśli tak, zidentyfikuj writable packages, pobierz ich tarballs, wstrzyknij loader taki jak `setup.mjs`, ustaw `preinstall`, aby go uruchamiał, zwiększ patch version i opublikuj ponownie. To zamienia jedno kompromitowane CI w downstream auto-execution w innych środowiskach. #### Practical checks during an assessment -- Przejrzyj release automation pod kątem hooks package-manager dodanych do `package.json`, nieoczekiwanych wpisów `bin` lub bumpów wersji, które zmieniają tylko release artifact. -- Sprawdź, czy CI przechowuje długowieczne credentials registry w plikach tekstowych, takich jak `~/.npmrc`, zamiast używać krótkotrwałych OIDC lub trusted publishing. -- Zweryfikuj, czy GitHub tokens dostępne w CI mogą zapisywać pliki workflow lub tworzyć branche/tagi. -- Jeśli podejrzewany jest skompromitowany package, sprawdź opublikowany tarball, a nie tylko Git repository, ponieważ złośliwy loader/runtime może istnieć tylko w opublikowanym artefakcie. -- Szukaj nieoczekiwanego wykonywania package-manager w CI, takiego jak `npm install` zamiast `npm ci`, nieoczekiwanych pobrań/uruchomień Bun lub nowych artifacts workflow generowanych z przejściowych branchy. +- Przejrzyj release automation pod kątem package-manager hooks dodanych do `package.json`, nieoczekiwanych wpisów `bin` lub bumpów wersji, które zmieniają tylko release artifact. +- Sprawdź, czy CI przechowuje długowieczne registry credentials w plikach tekstowych, takich jak `~/.npmrc`, zamiast używać krótkotrwałego OIDC lub trusted publishing. +- Zweryfikuj, czy GitHub tokens dostępne w CI mogą zapisywać workflow files lub tworzyć branches/tags. +- Jeśli podejrzewasz compromise package, sprawdź opublikowany tarball, a nie tylko Git repository, ponieważ malicious loader/runtime może istnieć tylko w opublikowanym artifact. +- Szukaj nieoczekiwanego package-manager execution w CI, takiego jak `npm install` zamiast `npm ci`, nieoczekiwane pobrania/uruchomienia Bun lub nowe workflow artifacts generowane z transient branches. +- Przejrzyj GitOps deployment engines także jako targets CI/CD. Specyficzna dla Argo CD enumeracja, abuse repo-server oraz ataki Redis cache poisoning są omówione w [Argo CD Security](argocd-security.md). ## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to open-source tool do audytu software supply chain stack pod kątem zgodności bezpieczeństwa na podstawie nowego [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audyt koncentruje się na całym procesie SDLC, gdzie może ujawnić ryzyka od code time do deploy time. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to open-source tool do audytu software supply chain stack pod kątem security compliance na podstawie nowego [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audyt skupia się na całym procesie SDLC, gdzie może ujawnić risks od code time do deploy time. ### Top 10 CI/CD Security Risk -Sprawdź ten interesujący artykuł o top 10 ryzykach CI/CD według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Sprawdź ten interesujący artykuł o top 10 CI/CD risks według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcję, jak uruchomić ją lokalnie, aby móc skonfigurować ją tak, jak chcesz do testów +- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcje, jak uruchomić ją lokalnie, aby móc skonfigurować ją tak, jak chcesz do testów - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** to narzędzie static code analysis dla infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** to narzędzie do static code analysis dla infrastructure-as-code. ## References