mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-27 21:23:07 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains
This commit is contained in:
Translator
@@ -6,7 +6,7 @@
|
||||
|
||||
In questa pagina troverai:
|
||||
|
||||
- Un **riassunto di tutti gli impatti** di un attaccante che riesce ad accedere a un'azione di Github
|
||||
- Un **riassunto di tutti gli impatti** di un attaccante che riesce ad accedere a una Github Action
|
||||
- Diversi modi per **ottenere accesso a un'azione**:
|
||||
- Avere **permessi** per creare l'azione
|
||||
- Abusare dei trigger relativi alle **pull request**
|
||||
@@ -21,9 +21,9 @@ Per un'introduzione su [**Github Actions controlla le informazioni di base**](..
|
||||
Se puoi **eseguire codice arbitrario in GitHub Actions** all'interno di un **repository**, potresti essere in grado di:
|
||||
|
||||
- **Rubare segreti** montati nella pipeline e **abusare dei privilegi della pipeline** per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP.
|
||||
- **Compromettere distribuzioni** e altri **artifacts**.
|
||||
- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla catena di approvvigionamento.
|
||||
- **Eseguire codice in worker personalizzati** per abusare della potenza di calcolo e pivotare su altri sistemi.
|
||||
- **Compromettere i deployment** e altri **artifacts**.
|
||||
- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla supply chain.
|
||||
- **Eseguire codice in worker personalizzati** per abusare della potenza di calcolo e pivotare verso altri sistemi.
|
||||
- **Sovrascrivere il codice del repository**, a seconda dei permessi associati al `GITHUB_TOKEN`.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
@@ -141,9 +141,9 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
## Esecuzione Consentita
|
||||
|
||||
> [!NOTE]
|
||||
> Questo sarebbe il modo più semplice per compromettere le azioni di Github, poiché questo caso suppone che tu abbia accesso a **creare un nuovo repo nell'organizzazione**, o abbia **privilegi di scrittura su un repository**.
|
||||
> Questo sarebbe il modo più semplice per compromettere le azioni di Github, poiché questo caso presuppone che tu abbia accesso per **creare un nuovo repo nell'organizzazione**, o abbia **privilegi di scrittura su un repository**.
|
||||
>
|
||||
> Se ti trovi in questo scenario, puoi semplicemente controllare le [tecniche di Post Exploitation](./#post-exploitation-techniques-from-inside-an-action).
|
||||
> Se ti trovi in questo scenario, puoi semplicemente controllare le [tecniche di Post Exploitation](#post-exploitation-techniques-from-inside-an-action).
|
||||
|
||||
### Esecuzione dalla Creazione del Repo
|
||||
|
||||
@@ -151,7 +151,7 @@ Nel caso in cui i membri di un'organizzazione possano **creare nuovi repo** e tu
|
||||
|
||||
### Esecuzione da un Nuovo Branch
|
||||
|
||||
Se puoi **creare un nuovo branch in un repository che già contiene un'azione Github** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'azione dal nuovo branch**. In questo modo puoi **esfiltrare i segreti a livello di repository e organizzazione** (ma devi sapere come si chiamano).
|
||||
Se puoi **creare un nuovo branch in un repository che contiene già un'azione Github** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'azione dal nuovo branch**. In questo modo puoi **esfiltrare i segreti a livello di repository e organizzazione** (ma devi sapere come si chiamano).
|
||||
|
||||
Puoi rendere l'azione modificata eseguibile **manualmente,** quando viene **creato un PR** o quando **alcuni codici vengono caricati** (a seconda di quanto vuoi essere evidente):
|
||||
```yaml
|
||||
@@ -183,20 +183,20 @@ Il trigger del workflow **`pull_request`** eseguirà il workflow ogni volta che
|
||||
>
|
||||
> **Ho testato questo e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e ha cancellato il suo account.~~
|
||||
|
||||
Inoltre, per impostazione predefinita **previene i permessi di scrittura** e **l'accesso ai segreti** al repository di destinazione come menzionato nella [**documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
Inoltre, per impostazione predefinita **previene i permessi di scrittura** e **l'accesso ai segreti** al repository target come menzionato nella [**documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> Con l'eccezione di `GITHUB_TOKEN`, **i segreti non vengono passati al runner** quando un workflow è attivato da un **repository forked**. Il **`GITHUB_TOKEN` ha permessi di sola lettura** nelle pull request **da repository forked**.
|
||||
> Con l'eccezione di `GITHUB_TOKEN`, **i segreti non vengono passati al runner** quando un workflow è attivato da un repository **forked**. Il **`GITHUB_TOKEN` ha permessi di sola lettura** nelle pull request **da repository forked**.
|
||||
|
||||
Un attaccante potrebbe modificare la definizione del Github Action per eseguire cose arbitrarie e aggiungere azioni arbitrarie. Tuttavia, non sarà in grado di rubare segreti o sovrascrivere il repo a causa delle limitazioni menzionate.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Sì, se l'attaccante cambia nella PR l'azione github che verrà attivata, la sua Github Action sarà quella utilizzata e non quella del repo di origine!**
|
||||
|
||||
Poiché l'attaccante controlla anche il codice eseguito, anche se non ci sono segreti o permessi di scrittura sul `GITHUB_TOKEN`, un attaccante potrebbe ad esempio **caricare artefatti dannosi**.
|
||||
Poiché l'attaccante controlla anche il codice in esecuzione, anche se non ci sono segreti o permessi di scrittura sul `GITHUB_TOKEN`, un attaccante potrebbe ad esempio **caricare artefatti dannosi**.
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** al repository di destinazione e **accesso ai segreti** (e non richiede permesso).
|
||||
Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** sul repository target e **accesso ai segreti** (e non richiede permesso).
|
||||
|
||||
Nota che il trigger del workflow **`pull_request_target`** **viene eseguito nel contesto di base** e non in quello fornito dalla PR (per **non eseguire codice non attendibile**). Per ulteriori informazioni su `pull_request_target` [**controlla la documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Inoltre, per ulteriori informazioni su questo specifico uso pericoloso, controlla questo [**post del blog di github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
@@ -207,7 +207,7 @@ E questo avrà **accesso ai segreti**.
|
||||
|
||||
### `workflow_run`
|
||||
|
||||
Il trigger [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) consente di eseguire un workflow da un altro quando è `completato`, `richiesto` o `in_corso`.
|
||||
Il trigger [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) consente di eseguire un workflow da un altro quando è `completato`, `richiesto` o `in_progress`.
|
||||
|
||||
In questo esempio, un workflow è configurato per essere eseguito dopo che il separato workflow "Esegui Test" è completato:
|
||||
```yaml
|
||||
@@ -217,7 +217,7 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
Inoltre, secondo la documentazione: Il workflow avviato dall'evento `workflow_run` è in grado di **accedere a segreti e scrivere token, anche se il workflow precedente non lo era**.
|
||||
Inoltre, secondo la documentazione: Il workflow avviato dall'evento `workflow_run` è in grado di **accedere ai segreti e scrivere token, anche se il workflow precedente non lo era**.
|
||||
|
||||
Questo tipo di workflow potrebbe essere attaccato se **dipende** da un **workflow** che può essere **attivato** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Il primo consiste nel workflow attivato da **`workflow_run`** che scarica il codice degli attaccanti: `${{ github.event.pull_request.head.sha }}`\
|
||||
Il secondo consiste nel **passare** un **artifact** dal codice **non attendibile** al workflow **`workflow_run`** e utilizzare il contenuto di questo artifact in un modo che lo rende **vulnerabile a RCE**.
|
||||
@@ -234,7 +234,7 @@ Abbiamo menzionato tutti i modi in cui un attaccante esterno potrebbe riuscire a
|
||||
|
||||
### Esecuzione di checkout non attendibile
|
||||
|
||||
Nel caso di **`pull_request`,** il workflow verrà eseguito nel **contesto del PR** (quindi eseguirà il **codice malevolo del PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](./#pull_request).
|
||||
Nel caso di **`pull_request`,** il workflow verrà eseguito nel **contesto del PR** (quindi eseguirà il **codice malevolo del PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](#pull_request).
|
||||
|
||||
Nel caso di un workflow che utilizza **`pull_request_target` o `workflow_run`** che dipende da un workflow che può essere attivato da **`pull_request_target` o `pull_request`**, il codice del repository originale verrà eseguito, quindi l'**attaccante non può controllare il codice eseguito**.
|
||||
|
||||
@@ -269,14 +269,14 @@ message: |
|
||||
Thank you!
|
||||
</code></pre>
|
||||
|
||||
Il potenziale **codice non attendibile viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i **pacchetti** referenziati sono controllati dall'autore del PR.
|
||||
Il codice **potenzialmente non attendibile viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i **pacchetti referenziati sono controllati dall'autore del PR**.
|
||||
|
||||
> [!WARNING]
|
||||
> Un dork di github per cercare azioni vulnerabili è: `event.pull_request pull_request_target extension:yml` tuttavia, ci sono diversi modi per configurare i lavori da eseguire in modo sicuro anche se l'azione è configurata in modo insicuro (come utilizzare condizioni su chi è l'attore che genera il PR).
|
||||
> Un github dork per cercare azioni vulnerabili è: `event.pull_request pull_request_target extension:yml`, tuttavia, ci sono diversi modi per configurare i lavori da eseguire in modo sicuro anche se l'azione è configurata in modo insicuro (come utilizzare condizioni su chi è l'attore che genera il PR).
|
||||
|
||||
### Iniezioni di Script nel Contesto <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
Nota che ci sono certi [**contesti di github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea il PR. Se l'azione di github utilizza quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **esecuzione di codice arbitrario:**
|
||||
Nota che ci sono certi [**contesti github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea il PR. Se l'azione github utilizza quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **esecuzione di codice arbitrario:**
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
@@ -292,11 +292,11 @@ Ad esempio ([**questo**](https://www.legitsecurity.com/blog/github-privilege-esc
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Azioni di Terze Parti Vulnerabili di Github
|
||||
### Azioni Github di Terze Parti Vulnerabili
|
||||
|
||||
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
|
||||
|
||||
Come menzionato in [**questo post del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Azione Github consente di accedere ad artifact provenienti da diversi workflow e persino repository.
|
||||
Come menzionato in [**questo post del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Azione Github consente di accedere agli artifact da diversi workflow e persino repository.
|
||||
|
||||
Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere utilizzati o persino eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusare di questo per compromettere altri workflow che si fidano dell'Artifact.
|
||||
|
||||
@@ -340,14 +340,14 @@ path: ./script.py
|
||||
```
|
||||
---
|
||||
|
||||
## Altro Accesso Esterno
|
||||
## Altri Accessi Esterni
|
||||
|
||||
### Hijacking di Namespace Repo Cancellati
|
||||
|
||||
Se un account cambia nome, un altro utente potrebbe registrare un account con quel nome dopo un po' di tempo. Se un repository aveva **meno di 100 stelle prima del cambio di nome**, Github permetterà al nuovo utente registrato con lo stesso nome di creare un **repository con lo stesso nome** di quello cancellato.
|
||||
|
||||
> [!CAUTION]
|
||||
> Quindi, se un'azione sta utilizzando un repo da un account non esistente, è ancora possibile che un attaccante possa creare quell'account e compromettere l'azione.
|
||||
> Quindi, se un'azione sta utilizzando un repo di un account non esistente, è ancora possibile che un attaccante possa creare quell'account e compromettere l'azione.
|
||||
|
||||
Se altri repository stavano utilizzando **dipendenze da questi repo utente**, un attaccante sarà in grado di hijackarli. Qui hai una spiegazione più completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
@@ -448,7 +448,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
- Se il segreto è usato **direttamente in un'espressione**, lo script shell generato è memorizzato **su disco** ed è accessibile.
|
||||
- Se il segreto è utilizzato **direttamente in un'espressione**, lo script shell generato è memorizzato **su disco** ed è accessibile.
|
||||
- ```bash
|
||||
cat /home/runner/work/_temp/*
|
||||
```
|
||||
@@ -456,7 +456,7 @@ cat /home/runner/work/_temp/*
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- Per un **azione personalizzata**, il rischio può variare a seconda di come un programma utilizza il segreto ottenuto dall'**argomento**:
|
||||
- Per un **'azione personalizzata'**, il rischio può variare a seconda di come un programma utilizza il segreto ottenuto dall'**argomento**:
|
||||
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
@@ -468,7 +468,7 @@ key: ${{ secrets.PUBLISH_KEY }}
|
||||
|
||||
Il modo per trovare quali **Github Actions vengono eseguite in infrastrutture non-Github** è cercare **`runs-on: self-hosted`** nella configurazione yaml dell'azione Github.
|
||||
|
||||
I runner **self-hosted** potrebbero avere accesso a **informazioni extra sensibili**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? servizio di metadata?) o, anche se è isolato e distrutto, **più di un'azione potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe **rubare i segreti** dell'altra.
|
||||
I runner **self-hosted** potrebbero avere accesso a **informazioni extra sensibili**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? servizio di metadata?) o, anche se isolati e distrutti, **più di un'azione potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe **rubare i segreti** dell'altra.
|
||||
|
||||
Nei runner self-hosted è anche possibile ottenere i **segreti dal processo \_Runner.Listener**\_\*\* che conterrà tutti i segreti dei flussi di lavoro in qualsiasi fase dumpando la sua memoria:
|
||||
```bash
|
||||
@@ -477,14 +477,14 @@ sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ prin
|
||||
```
|
||||
Controlla [**questo post per ulteriori informazioni**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
|
||||
|
||||
### Registro delle Immagini Docker di Github
|
||||
### Github Docker Images Registry
|
||||
|
||||
È possibile creare azioni di Github che **costruiranno e memorizzeranno un'immagine Docker all'interno di Github**.\
|
||||
È possibile creare azioni Github che **costruiranno e memorizzeranno un'immagine Docker all'interno di Github**.\
|
||||
Un esempio può essere trovato nel seguente espandibile:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
```yaml
|
||||
[...]
|
||||
|
||||
@@ -525,7 +525,7 @@ docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
Poi, l'utente potrebbe cercare **segreti trapelati nei livelli dell'immagine Docker:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### Informazioni sensibili nei log di Github Actions
|
||||
@@ -534,9 +534,9 @@ Anche se **Github** cerca di **rilevare valori segreti** nei log delle azioni e
|
||||
|
||||
## Coprire le tue tracce
|
||||
|
||||
(Tecnica da [**qui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR sollevata è chiaramente visibile al pubblico su Github e all'account GitHub target. In GitHub per impostazione predefinita, non **possiamo eliminare un PR da internet**, ma c'è un colpo di scena. Per gli account Github che sono **sospesi** da Github, tutti i loro **PR vengono automaticamente eliminati** e rimossi da internet. Quindi, per nascondere la tua attività, devi o far **sospendere il tuo account GitHub o far segnare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (fondamentalmente rimuovere tutti i tuoi exploit PR)
|
||||
(Tecnica da [**qui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR sollevata è chiaramente visibile al pubblico su Github e all'account GitHub target. In GitHub per impostazione predefinita, **non possiamo eliminare un PR da internet**, ma c'è un colpo di scena. Per gli account GitHub che sono **sospesi** da Github, tutti i loro **PR vengono automaticamente eliminati** e rimossi da internet. Quindi, per nascondere la tua attività, devi o far **sospendere il tuo account GitHub o far segnare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (fondamentalmente rimuovere tutti i tuoi PR di exploit)
|
||||
|
||||
Un'organizzazione in GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualcosa" nell'Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e lì hai, reso il tuo exploit invisibile su github.
|
||||
Un'organizzazione in GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualcosa" in un Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e così hai reso il tuo exploit invisibile su github.
|
||||
|
||||
> [!WARNING]
|
||||
> L'unico modo per un'organizzazione di capire di essere stata presa di mira è controllare i log di GitHub da SIEM poiché dall'interfaccia di GitHub il PR verrebbe rimosso.
|
||||
|
||||
Reference in New Issue
Block a user