Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle

src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md

@@ -6,7 +6,7 @@
 
 **Ansible Tower** o la sua versione open source [**AWX**](https://github.com/ansible/awx) è conosciuta anche come **interfaccia utente di Ansible, dashboard e REST API**. Con **controllo degli accessi basato sui ruoli**, pianificazione dei lavori e gestione grafica dell'inventario, puoi gestire la tua infrastruttura Ansible da un'interfaccia moderna. L'API REST di Tower e l'interfaccia a riga di comando rendono semplice integrarla negli strumenti e nei flussi di lavoro attuali.
 
-**Automation Controller è una versione più recente** di Ansible Tower con maggiori capacità.
+**Automation Controller è una versione** più recente di Ansible Tower con maggiori capacità.
 
 ### Differenze
 
@@ -15,7 +15,7 @@ Secondo [**questo**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood
 ### Stack Tecnologico
 
 - **Interfaccia Web**: Questa è l'interfaccia grafica in cui gli utenti possono gestire inventari, credenziali, modelli e lavori. È progettata per essere intuitiva e fornisce visualizzazioni per aiutare a comprendere lo stato e i risultati dei tuoi lavori di automazione.
-- **REST API**: Tutto ciò che puoi fare nell'interfaccia web, puoi farlo anche tramite l'API REST. Ciò significa che puoi integrare AWX/Tower con altri sistemi o scriptare azioni che normalmente esegui nell'interfaccia.
+- **REST API**: Tutto ciò che puoi fare nell'interfaccia web, puoi farlo anche tramite l'API REST. Questo significa che puoi integrare AWX/Tower con altri sistemi o scriptare azioni che normalmente esegui nell'interfaccia.
 - **Database**: AWX/Tower utilizza un database (tipicamente PostgreSQL) per memorizzare la sua configurazione, i risultati dei lavori e altri dati operativi necessari.
 - **RabbitMQ**: Questo è il sistema di messaggistica utilizzato da AWX/Tower per comunicare tra i diversi componenti, specialmente tra il servizio web e i task runner.
 - **Redis**: Redis funge da cache e backend per la coda dei task.
@@ -26,14 +26,14 @@ Secondo [**questo**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood
 - **Progetti**: Un progetto è essenzialmente una **collezione di playbook Ansible** provenienti da un **sistema di controllo versione** (come Git) per estrarre i playbook più recenti quando necessario.
 - **Modelli**: I modelli di lavoro definiscono **come verrà eseguito un particolare playbook**, specificando l'**inventario**, le **credenziali** e altri **parametri** per il lavoro.
 - **Credenziali**: AWX/Tower fornisce un modo sicuro per **gestire e memorizzare segreti, come chiavi SSH, password e token API**. Queste credenziali possono essere associate ai modelli di lavoro in modo che i playbook abbiano l'accesso necessario quando vengono eseguiti.
-- **Motore di Task**: Qui avviene la magia. Il motore di task è costruito su Ansible ed è responsabile per **eseguire i playbook**. I lavori vengono inviati al motore di task, che poi esegue i playbook Ansible contro l'inventario designato utilizzando le credenziali specificate.
-- **Pianificatori e Callback**: Queste sono funzionalità avanzate in AWX/Tower che consentono ai **lavori di essere pianificati** per essere eseguiti in momenti specifici o attivati da eventi esterni.
+- **Motore di Task**: Qui avviene la magia. Il motore di task è costruito su Ansible ed è responsabile per **l'esecuzione dei playbook**. I lavori vengono inviati al motore di task, che poi esegue i playbook Ansible contro l'inventario designato utilizzando le credenziali specificate.
+- **Pianificatori e Callback**: Queste sono funzionalità avanzate in AWX/Tower che consentono di **pianificare i lavori** per essere eseguiti in orari specifici o attivati da eventi esterni.
 - **Notifiche**: AWX/Tower può inviare notifiche in base al successo o al fallimento dei lavori. Supporta vari mezzi di notifiche come email, messaggi Slack, webhook, ecc.
 - **Playbook Ansible**: I playbook Ansible sono strumenti di configurazione, distribuzione e orchestrazione. Descrivono lo stato desiderato dei sistemi in modo automatizzato e ripetibile. Scritti in YAML, i playbook utilizzano il linguaggio di automazione dichiarativa di Ansible per descrivere configurazioni, attività e passaggi che devono essere eseguiti.
 
-### Flusso di Esecuzione del Lavoro
+### Flusso di Esecuzione dei Lavori
 
-1. **Interazione dell'Utente**: Un utente può interagire con AWX/Tower sia tramite l'**Interfaccia Web** che tramite l'**API REST**. Queste forniscono accesso front-end a tutte le funzionalità offerte da AWX/Tower.
+1. **Interazione dell'Utente**: Un utente può interagire con AWX/Tower sia tramite l'**Interfaccia Web** che l'**API REST**. Queste forniscono accesso front-end a tutte le funzionalità offerte da AWX/Tower.
 2. **Inizio del Lavoro**:
 - L'utente, tramite l'Interfaccia Web o l'API, avvia un lavoro basato su un **Modello di Lavoro**.
 - Il Modello di Lavoro include riferimenti all'**Inventario**, al **Progetto** (contenente il playbook) e alle **Credenziali**.
@@ -48,11 +48,11 @@ Secondo [**questo**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood
 5. **Risultati del Lavoro**:
 - Una volta che il playbook ha terminato l'esecuzione, i risultati (successo, fallimento, log) vengono salvati nel **Database**.
 - Gli utenti possono quindi visualizzare i risultati tramite l'Interfaccia Web o interrogarli tramite l'API REST.
-- In base ai risultati del lavoro, le **Notifiche** possono essere inviate per informare gli utenti o i sistemi esterni sullo stato del lavoro. Le notifiche possono essere email, messaggi Slack, webhook, ecc.
+- In base agli esiti dei lavori, le **Notifiche** possono essere inviate per informare gli utenti o i sistemi esterni sullo stato del lavoro. Le notifiche possono essere email, messaggi Slack, webhook, ecc.
 6. **Integrazione con Sistemi Esterni**:
-- **Inventari** possono essere recuperati dinamicamente da sistemi esterni, consentendo ad AWX/Tower di estrarre host da fonti come AWS, Azure, VMware e altro.
-- **Progetti** (playbook) possono essere recuperati da sistemi di controllo versione, garantendo l'uso di playbook aggiornati durante l'esecuzione del lavoro.
-- **Pianificatori e Callback** possono essere utilizzati per integrarsi con altri sistemi o strumenti, facendo sì che AWX/Tower reagisca a trigger esterni o esegua lavori a orari prestabiliti.
+- Gli **Inventari** possono essere recuperati dinamicamente da sistemi esterni, consentendo ad AWX/Tower di estrarre host da fonti come AWS, Azure, VMware e altro.
+- I **Progetti** (playbook) possono essere recuperati da sistemi di controllo versione, garantendo l'uso di playbook aggiornati durante l'esecuzione del lavoro.
+- I **Pianificatori e Callback** possono essere utilizzati per integrarsi con altri sistemi o strumenti, facendo sì che AWX/Tower reagisca a trigger esterni o esegua lavori a orari prestabiliti.
 
 ### Creazione di un laboratorio AWX per test
 
@@ -86,9 +86,9 @@ docker exec tools_awx_1 awx-manage create_preload_data
 
 ### Ruoli supportati
 
-Il ruolo più privilegiato è chiamato **System Administrator**. Chiunque abbia questo ruolo può **modificare qualsiasi cosa**.
+Il ruolo con il maggior privilegio è chiamato **System Administrator**. Chiunque abbia questo ruolo può **modificare qualsiasi cosa**.
 
-Da una revisione di **white box security**, avresti bisogno del **System Auditor role**, che consente di **visualizzare tutti i dati di sistema** ma non può apportare modifiche. Un'altra opzione sarebbe ottenere il **Organization Auditor role**, ma sarebbe meglio ottenere l'altro.
+Da una revisione della **sicurezza white box**, avresti bisogno del **System Auditor role**, che consente di **visualizzare tutti i dati di sistema** ma non può apportare modifiche. Un'altra opzione sarebbe ottenere il **Organization Auditor role**, ma sarebbe meglio ottenere l'altro.
 
 <details>
 
@@ -96,42 +96,109 @@ Da una revisione di **white box security**, avresti bisogno del **System Auditor
 
 1. **System Administrator**:
 - Questo è il ruolo superutente con permessi per accedere e modificare qualsiasi risorsa nel sistema.
-- Possono gestire tutte le organizzazioni, i team, i progetti, gli inventari, i modelli di lavoro, ecc.
+- Può gestire tutte le organizzazioni, i team, i progetti, gli inventari, i modelli di lavoro, ecc.
 2. **System Auditor**:
 - Gli utenti con questo ruolo possono visualizzare tutti i dati di sistema ma non possono apportare modifiche.
 - Questo ruolo è progettato per la conformità e la supervisione.
 3. **Ruoli dell'organizzazione**:
 - **Admin**: Controllo completo sulle risorse dell'organizzazione.
-- **Auditor**: Accesso in sola visualizzazione alle risorse dell'organizzazione.
-- **Member**: Membri di base in un'organizzazione senza permessi specifici.
+- **Auditor**: Accesso in sola lettura alle risorse dell'organizzazione.
+- **Member**: Membro base in un'organizzazione senza permessi specifici.
 - **Execute**: Può eseguire modelli di lavoro all'interno dell'organizzazione.
 - **Read**: Può visualizzare le risorse dell'organizzazione.
 4. **Ruoli del progetto**:
 - **Admin**: Può gestire e modificare il progetto.
 - **Use**: Può utilizzare il progetto in un modello di lavoro.
-- **Update**: Può aggiornare il progetto utilizzando SCM (source control).
+- **Update**: Può aggiornare il progetto utilizzando SCM (controllo sorgente).
 5. **Ruoli dell'inventario**:
 - **Admin**: Può gestire e modificare l'inventario.
 - **Ad Hoc**: Può eseguire comandi ad hoc sull'inventario.
 - **Update**: Può aggiornare la fonte dell'inventario.
 - **Use**: Può utilizzare l'inventario in un modello di lavoro.
-- **Read**: Accesso in sola visualizzazione.
+- **Read**: Accesso in sola lettura.
 6. **Ruoli del modello di lavoro**:
 - **Admin**: Può gestire e modificare il modello di lavoro.
 - **Execute**: Può eseguire il lavoro.
-- **Read**: Accesso in sola visualizzazione.
+- **Read**: Accesso in sola lettura.
 7. **Ruoli delle credenziali**:
 - **Admin**: Può gestire e modificare le credenziali.
-- **Use**: Può utilizzare le credenziali nei modelli di lavoro o in altre risorse pertinenti.
-- **Read**: Accesso in sola visualizzazione.
+- **Use**: Può utilizzare le credenziali in modelli di lavoro o altre risorse pertinenti.
+- **Read**: Accesso in sola lettura.
 8. **Ruoli del team**:
 - **Member**: Parte del team ma senza permessi specifici.
 - **Admin**: Può gestire i membri del team e le risorse associate.
 9. **Ruoli del workflow**:
 - **Admin**: Può gestire e modificare il workflow.
 - **Execute**: Può eseguire il workflow.
-- **Read**: Accesso in sola visualizzazione.
+- **Read**: Accesso in sola lettura.
 
 </details>
 
+## Enumerazione e Mappatura del Percorso di Attacco con AnsibleHound
+
+`AnsibleHound` è un collezionista BloodHound *OpenGraph* open-source scritto in Go che trasforma un token API di Ansible Tower/AWX/Automation Controller **in sola lettura** in un grafico di permessi completo pronto per essere analizzato all'interno di BloodHound (o BloodHound Enterprise).
+
+### Perché è utile?
+1. L'API REST di Tower/AWX è estremamente ricca ed espone **ogni oggetto e relazione RBAC** di cui la tua istanza è a conoscenza.
+2. Anche con il token di privilegio più basso (**Read**) è possibile enumerare ricorsivamente tutte le risorse accessibili (organizzazioni, inventari, host, credenziali, progetti, modelli di lavoro, utenti, team…).
+3. Quando i dati grezzi vengono convertiti nello schema di BloodHound, ottieni le stesse capacità di visualizzazione del *percorso di attacco* che sono così popolari nelle valutazioni di Active Directory – ma ora dirette verso il tuo patrimonio CI/CD.
+
+I team di sicurezza (e gli attaccanti!) possono quindi:
+* Comprendere rapidamente **chi può diventare admin di cosa**.
+* Identificare **credenziali o host che sono raggiungibili** da un account non privilegiato.
+* Collegare più bordi “Read ➜ Use ➜ Execute ➜ Admin” per ottenere il pieno controllo sull'istanza di Tower o sull'infrastruttura sottostante.
+
+### Requisiti
+* Ansible Tower / AWX / Automation Controller raggiungibile tramite HTTPS.
+* Un token API utente limitato a **Read** solo (creato da *User Details → Tokens → Create Token → scope = Read*).
+* Go ≥ 1.20 per compilare il collezionista (o utilizzare i binari precompilati).
+
+### Costruzione e Esecuzione
+```bash
+# Compile the collector
+cd collector
+go build . -o build/ansiblehound
+
+# Execute against the target instance
+./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"
+```
+Internamente, AnsibleHound esegue richieste `GET` *paginati* contro (almeno) i seguenti endpoint e segue automaticamente i link `related` restituiti in ogni oggetto JSON:
+```
+/api/v2/organizations/
+/api/v2/inventories/
+/api/v2/hosts/
+/api/v2/job_templates/
+/api/v2/projects/
+/api/v2/credentials/
+/api/v2/users/
+/api/v2/teams/
+```
+Tutte le pagine raccolte vengono unite in un unico file JSON su disco (predefinito: `ansiblehound-output.json`).
+
+### Trasformazione BloodHound
+I dati grezzi di Tower vengono quindi **trasformati in BloodHound OpenGraph** utilizzando nodi personalizzati con il prefisso `AT` (Ansible Tower):
+* `ATOrganization`, `ATInventory`, `ATHost`, `ATJobTemplate`, `ATProject`, `ATCredential`, `ATUser`, `ATTeam`
+
+E edge che modellano relazioni / privilegi:
+* `ATContains`, `ATUses`, `ATExecute`, `ATRead`, `ATAdmin`
+
+Il risultato può essere importato direttamente in BloodHound:
+```bash
+neo4j stop   # if BloodHound CE is running locally
+bloodhound-import ansiblehound-output.json
+```
+Facoltativamente, puoi caricare **icone personalizzate** in modo che i nuovi tipi di nodi siano visivamente distinti:
+```bash
+python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"
+```
+### Considerazioni Difensive e Offensive
+* Un token *Read* è normalmente considerato innocuo ma rivela comunque la **topologia completa e ogni metadato delle credenziali**. Trattalo come sensibile!
+* Applica il **principio del minimo privilegio** e ruota / revoca i token non utilizzati.
+* Monitora l'API per eccessiva enumerazione (richieste `GET` sequenziali multiple, alta attività di paginazione).
+* Dal punto di vista di un attaccante, questa è una tecnica perfetta di *punto d'appoggio iniziale → escalation dei privilegi* all'interno della pipeline CI/CD.
+
+## Riferimenti
+* [AnsibleHound – BloodHound Collector per Ansible Tower/AWX](https://github.com/TheSleekBoyCompany/AnsibleHound)
+* [BloodHound OSS](https://github.com/BloodHoundAD/BloodHound)
+
 {{#include ../banners/hacktricks-training.md}}

src/pentesting-ci-cd/concourse-security/concourse-architecture.md

@@ -1,9 +1,9 @@
 # Architettura di Concourse
 
-## Architettura di Concourse
-
 {{#include ../../banners/hacktricks-training.md}}
 
+## Architettura di Concourse
+
 [**Dati rilevanti dalla documentazione di Concourse:**](https://concourse-ci.org/internals.html)
 
 ### Architettura
@@ -18,11 +18,11 @@ La responsabilità del [checker](https://concourse-ci.org/checker.html) è quell
 
 #### TSA: registrazione dei worker e inoltro
 
-La TSA è un **server SSH personalizzato** utilizzato esclusivamente per **registrare** in modo sicuro i [**worker**](https://concourse-ci.org/internals.html#architecture-worker) con l'[ATC](https://concourse-ci.org/internals.html#component-atc).
+La TSA è un **server SSH personalizzato** utilizzato esclusivamente per registrare in modo sicuro [**i worker**](https://concourse-ci.org/internals.html#architecture-worker) con l'[ATC](https://concourse-ci.org/internals.html#component-atc).
 
 La TSA per **default ascolta sulla porta `2222`**, ed è solitamente collocata insieme all'[ATC](https://concourse-ci.org/internals.html#component-atc) e si trova dietro un bilanciatore di carico.
 
-La **TSA implementa CLI attraverso la connessione SSH,** supportando [**questi comandi**](https://concourse-ci.org/internals.html#component-tsa).
+La **TSA implementa CLI tramite la connessione SSH,** supportando [**questi comandi**](https://concourse-ci.org/internals.html#component-tsa).
 
 #### Worker
 

src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md

@@ -1,14 +1,14 @@
 # Concourse Enumeration & Attacks
 
-## Concourse Enumeration & Attacks
-
 {{#include ../../banners/hacktricks-training.md}}
 
+## Concourse Enumeration & Attacks
+
 ### User Roles & Permissions
 
 Concourse viene fornito con cinque ruoli:
 
-- _Concourse_ **Admin**: Questo ruolo è assegnato solo ai proprietari del **team principale** (team concourse iniziale predefinito). Gli Admin possono **configurare altri team** (ad es.: `fly set-team`, `fly destroy-team`...). I permessi di questo ruolo non possono essere influenzati da RBAC.
+- _Concourse_ **Admin**: Questo ruolo è assegnato solo ai proprietari del **team principale** (team concourse iniziale predefinito). Gli admin possono **configurare altri team** (ad es.: `fly set-team`, `fly destroy-team`...). I permessi di questo ruolo non possono essere influenzati da RBAC.
 - **owner**: I proprietari del team possono **modificare tutto all'interno del team**.
 - **member**: I membri del team possono **leggere e scrivere** all'interno delle **risorse del team** ma non possono modificare le impostazioni del team.
 - **pipeline-operator**: Gli operatori di pipeline possono eseguire **operazioni di pipeline** come attivare build e fissare risorse, tuttavia non possono aggiornare le configurazioni delle pipeline.
@@ -23,8 +23,8 @@ Nota che Concourse **raggruppa le pipeline all'interno dei Team**. Pertanto, gli
 
 Nei file di configurazione YAML puoi configurare valori utilizzando la sintassi `((_source-name_:_secret-path_._secret-field_))`.\
 [Dal documento:](https://concourse-ci.org/vars.html#var-syntax) Il **source-name è facoltativo**, e se omesso, verrà utilizzato il [credential manager a livello di cluster](https://concourse-ci.org/vars.html#cluster-wide-credential-manager), oppure il valore può essere fornito [staticamente](https://concourse-ci.org/vars.html#static-vars).\
-Il **\_secret-field**\_ facoltativo specifica un campo sul segreto recuperato da leggere. Se omesso, il credential manager può scegliere di leggere un 'campo predefinito' dal credential recuperato se il campo esiste.\
-Inoltre, il _**secret-path**_ e _**secret-field**_ possono essere racchiusi tra virgolette doppie `"..."` se **contengono caratteri speciali** come `.` e `:`. Ad esempio, `((source:"my.secret"."field:1"))` imposterà il _secret-path_ su `my.secret` e il _secret-field_ su `field:1`.
+Il **_secret-field facoltativo**_ specifica un campo sul segreto recuperato da leggere. Se omesso, il credential manager può scegliere di leggere un 'campo predefinito' dal credential recuperato se il campo esiste.\
+Inoltre, il _**secret-path**_ e il _**secret-field**_ possono essere racchiusi tra virgolette doppie `"..."` se contengono **caratteri speciali** come `.` e `:`. Ad esempio, `((source:"my.secret"."field:1"))` imposterà il _secret-path_ su `my.secret` e il _secret-field_ su `field:1`.
 
 #### Static Vars
 
@@ -34,7 +34,7 @@ Le variabili statiche possono essere specificate nei **passaggi delle attività*
 file: booklit/ci/unit.yml
 vars: { tag: 1.13 }
 ```
-Oppure utilizzando i seguenti `fly` **argomenti**:
+Or usando i seguenti `fly` **argomenti**:
 
 - `-v` o `--var` `NAME=VALUE` imposta la stringa `VALUE` come valore per la var `NAME`.
 - `-y` o `--yaml-var` `NAME=VALUE` analizza `VALUE` come YAML e lo imposta come valore per la var `NAME`.
@@ -46,12 +46,12 @@ Oppure utilizzando i seguenti `fly` **argomenti**:
 Ci sono diversi modi in cui un **Credential Manager può essere specificato** in una pipeline, leggi come in [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
 Inoltre, Concourse supporta diversi gestori di credenziali:
 
-- [Il gestore di credenziali Vault](https://concourse-ci.org/vault-credential-manager.html)
-- [Il gestore di credenziali CredHub](https://concourse-ci.org/credhub-credential-manager.html)
-- [Il gestore di credenziali AWS SSM](https://concourse-ci.org/aws-ssm-credential-manager.html)
-- [Il gestore di credenziali AWS Secrets Manager](https://concourse-ci.org/aws-asm-credential-manager.html)
-- [Gestore di Credenziali Kubernetes](https://concourse-ci.org/kubernetes-credential-manager.html)
-- [Il gestore di credenziali Conjur](https://concourse-ci.org/conjur-credential-manager.html)
+- [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html)
+- [The CredHub credential manager](https://concourse-ci.org/credhub-credential-manager.html)
+- [The AWS SSM credential manager](https://concourse-ci.org/aws-ssm-credential-manager.html)
+- [The AWS Secrets Manager credential manager](https://concourse-ci.org/aws-asm-credential-manager.html)
+- [Kubernetes Credential Manager](https://concourse-ci.org/kubernetes-credential-manager.html)
+- [The Conjur credential manager](https://concourse-ci.org/conjur-credential-manager.html)
 - [Caching credentials](https://concourse-ci.org/creds-caching.html)
 - [Redacting credentials](https://concourse-ci.org/creds-redacting.html)
 - [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)
@@ -123,7 +123,7 @@ rm /tmp/secrets.txt
 - admin:admin
 - test:test
 
-#### Enumerazione di segreti e parametri
+#### Enumerazione di Segreti e Parametri
 
 Nella sezione precedente abbiamo visto come puoi **ottenere tutti i nomi e le variabili dei segreti** utilizzati dalla pipeline. Le **variabili potrebbero contenere informazioni sensibili** e il nome dei **segreti sarà utile in seguito per cercare di rubarli**.
 
@@ -142,7 +142,7 @@ Con questi permessi potresti essere in grado di:
 
 #### Creazione/Modifica della Pipeline
 
-Se hai privilegi sufficienti (**ruolo membro o superiore**) sarai in grado di **creare/modificare nuove pipeline.** Controlla questo esempio:
+Se hai privilegi sufficienti (**ruolo di membro o superiore**) sarai in grado di **creare/modificare nuove pipeline.** Controlla questo esempio:
 ```yaml
 jobs:
 - name: simple
@@ -166,16 +166,16 @@ sleep 1000
 params:
 SUPER_SECRET: ((super.secret))
 ```
-Con la **modifica/creazione** di un nuovo pipeline sarai in grado di:
+Con la **modifica/creazione** di una nuova pipeline sarai in grado di:
 
 - **Rubare** i **segreti** (facendo l'echo o entrando nel container e eseguendo `env`)
 - **Evasione** verso il **nodo** (dandoti abbastanza privilegi - `privileged: true`)
 - Enumerare/Abusare dell'endpoint **cloud metadata** (dal pod e dal nodo)
-- **Eliminare** il pipeline creato
+- **Eliminare** la pipeline creata
 
-#### Esegui Compito Personalizzato
+#### Esegui un Compito Personalizzato
 
-Questo è simile al metodo precedente, ma invece di modificare/creare un intero nuovo pipeline puoi **semplicemente eseguire un compito personalizzato** (che sarà probabilmente molto più **furtivo**):
+Questo è simile al metodo precedente, ma invece di modificare/creare un'intera nuova pipeline puoi **semplicemente eseguire un compito personalizzato** (che sarà probabilmente molto più **furtivo**):
 ```yaml
 # For more task_config options check https://concourse-ci.org/tasks.html
 platform: linux
@@ -199,7 +199,7 @@ fly -t tutorial execute --privileged --config task_config.yml
 ```
 #### Uscire verso il nodo da un'attività privilegiata
 
-Nelle sezioni precedenti abbiamo visto come **eseguire un'attività privilegiata con concourse**. Questo non darà al contenitore esattamente lo stesso accesso del flag privilegiato in un contenitore docker. Ad esempio, non vedrai il dispositivo del filesystem del nodo in /dev, quindi l'uscita potrebbe essere più "complessa".
+Nelle sezioni precedenti abbiamo visto come **eseguire un'attività privilegiata con concourse**. Questo non darà al container esattamente lo stesso accesso del flag privilegiato in un container docker. Ad esempio, non vedrai il dispositivo del filesystem del nodo in /dev, quindi l'uscita potrebbe essere più "complessa".
 
 Nel seguente PoC useremo il release_agent per uscire con alcune piccole modifiche:
 ```bash
@@ -260,11 +260,11 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
 cat /output
 ```
 > [!WARNING]
-> Come avrai notato, questo è solo un [**escape regolare di release_agent**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) modificando semplicemente il percorso del cmd nel nodo
+> Come avrai notato, questo è solo un [**escape regolare del release_agent**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) modificando semplicemente il percorso del cmd nel nodo
 
-#### Escape al nodo da un contenitore Worker
+#### Uscire dal nodo da un contenitore Worker
 
-Un escape regolare di release_agent con una modifica minore è sufficiente per questo:
+Un escape regolare del release_agent con una modifica minore è sufficiente per questo:
 ```bash
 mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
 
@@ -330,14 +330,14 @@ select * from users;
 #### Abusare del Servizio Garden - Non un vero attacco
 
 > [!WARNING]
-> Queste sono solo alcune note interessanti sul servizio, ma poiché ascolta solo su localhost, queste note non presenteranno alcun impatto che non abbiamo già sfruttato prima.
+> Queste sono solo alcune note interessanti sul servizio, ma poiché ascolta solo su localhost, queste note non presenteranno alcun impatto che non abbiamo già sfruttato in precedenza.
 
 Per impostazione predefinita, ogni worker di concourse eseguirà un [**Garden**](https://github.com/cloudfoundry/garden) servizio sulla porta 7777. Questo servizio è utilizzato dal Web master per indicare al worker **cosa deve eseguire** (scaricare l'immagine ed eseguire ogni attività). Questo sembra piuttosto interessante per un attaccante, ma ci sono alcune buone protezioni:
 
-- È **esposto solo localmente** (127..0.0.1) e penso che quando il worker si autentica contro il Web con il servizio SSH speciale, viene creato un tunnel in modo che il server web possa **comunicare con ogni servizio Garden** all'interno di ogni worker.
-- Il server web **monitora i container in esecuzione ogni pochi secondi**, e i container **inaspettati** vengono **eliminati**. Quindi, se vuoi **eseguire un container personalizzato**, devi **manipolare** la **comunicazione** tra il server web e il servizio garden.
+- È **esposto solo localmente** (127..0.0.1) e penso che quando il worker si autentica contro il Web con il servizio SSH speciale, viene creato un tunnel affinché il server web possa **comunicare con ogni servizio Garden** all'interno di ogni worker.
+- Il server web **monitora i contenitori in esecuzione ogni pochi secondi**, e i contenitori **inaspettati** vengono **eliminati**. Quindi, se vuoi **eseguire un contenitore personalizzato**, devi **manipolare** la **comunicazione** tra il server web e il servizio garden.
 
-I worker di Concourse vengono eseguiti con privilegi elevati sui container:
+I worker di Concourse vengono eseguiti con elevati privilegi del contenitore:
 ```
 Container Runtime: docker
 Has Namespaces:
@@ -411,6 +411,6 @@ Accept-Encoding: gzip.
 ```
 ## Riferimenti
 
-- https://concourse-ci.org/vars.html
+- [https://concourse-ci.org/vars.html](https://concourse-ci.org/vars.html)
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md

@@ -1 +1,3 @@
 # Gh Actions - Avvelenamento degli Artifact
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md

@@ -1 +1,3 @@
 # GH Actions - Cache Poisoning
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -1 +1,3 @@
 # Gh Actions - Iniezioni di Script nel Contesto
+
+{{#include ../../../banners/hacktricks-training.md}}