Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,103 +6,99 @@
 
 ## VCS
 
-VCS stands for **Version Control System**, this systems allows developers to **manage their source code**. The most common one is **git** and you will usually find companies using it in one of the following **platforms**:
+VCS sta per **Version Control System**, questi sistemi consentono agli sviluppatori di **gestire il loro codice sorgente**. Il più comune è **git** e di solito troverai aziende che lo utilizzano in una delle seguenti **piattaforme**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Cloud providers (they offer their own VCS platforms)
+- Fornitori di cloud (offrono le proprie piattaforme VCS)
 
 ## CI/CD Pipelines
 
-CI/CD pipelines enable developers to **automate the execution of code** for various purposes, including building, testing, and deploying applications. These automated workflows are **triggered by specific actions**, such as code pushes, pull requests, or scheduled tasks. They are useful for streamlining the process from development to production.
+Le pipeline CI/CD consentono agli sviluppatori di **automatizzare l'esecuzione del codice** per vari scopi, inclusi la costruzione, il test e il deployment delle applicazioni. Questi flussi di lavoro automatizzati sono **attivati da azioni specifiche**, come push di codice, pull request o attività programmate. Sono utili per semplificare il processo dallo sviluppo alla produzione.
 
-However, these systems need to be **executed somewhere** and usually with **privileged credentials to deploy code or access sensitive information**.
+Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito con **credenziali privilegiate per distribuire codice o accedere a informazioni sensibili**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
+> Anche se alcune piattaforme VCS consentono di creare pipeline, in questa sezione analizzeremo solo i potenziali attacchi al controllo del codice sorgente.
 
-Platforms that contains the source code of your project contains sensitive information and people need to be very careful with the permissions granted inside this platform. These are some common problems across VCS platforms that attacker could abuse:
+Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e le persone devono essere molto attente ai permessi concessi all'interno di questa piattaforma. Questi sono alcuni problemi comuni tra le piattaforme VCS che un attaccante potrebbe sfruttare:
 
-- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
-- **Access**: If an attacker can **access to an account inside the VCS platform** he could gain **more visibility and permissions**.
-  - **Register**: Some platforms will just allow external users to create an account.
-  - **SSO**: Some platforms won't allow users to register, but will allow anyone to access with a valid SSO (so an attacker could use his github account to enter for example).
-  - **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... there are several kind of tokens a user could steal to access in some way a repo.
-- **Webhooks**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**.
-  - If no secret is in place, the attacker could abuse the webhook of the third party platform
-  - If the secret is in the URL, the same happens and the attacker also have the secret
-- **Code compromise:** If a malicious actor has some kind of **write** access over the repos, he could try to **inject malicious code**. In order to be successful he might need to **bypass branch protections**. These actions can be performed with different goals in mid:
-  - Compromise the main branch to **compromise production**.
-  - Compromise the main (or other branches) to **compromise developers machines** (as they usually execute test, terraform or other things inside the repo in their machines).
-  - **Compromise the pipeline** (check next section)
+- **Leaks**: Se il tuo codice contiene leak nei commit e l'attaccante può accedere al repo (perché è pubblico o perché ha accesso), potrebbe scoprire i leak.
+- **Access**: Se un attaccante può **accedere a un account all'interno della piattaforma VCS**, potrebbe guadagnare **maggiore visibilità e permessi**.
+- **Register**: Alcune piattaforme consentiranno solo agli utenti esterni di creare un account.
+- **SSO**: Alcune piattaforme non consentiranno agli utenti di registrarsi, ma permetteranno a chiunque di accedere con un SSO valido (quindi un attaccante potrebbe usare il suo account github per entrare, ad esempio).
+- **Credentials**: Nome utente+Pwd, token personali, chiavi ssh, token Oauth, cookie... ci sono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repo.
+- **Webhooks**: Le piattaforme VCS consentono di generare webhooks. Se non sono **protetti** con segreti non visibili, un **attaccante potrebbe abusarne**.
+- Se non c'è alcun segreto in atto, l'attaccante potrebbe abusare del webhook della piattaforma di terze parti.
+- Se il segreto è nell'URL, succede la stessa cosa e l'attaccante ha anche il segreto.
+- **Code compromise:** Se un attore malintenzionato ha qualche tipo di accesso **in scrittura** sui repo, potrebbe cercare di **iniettare codice malevolo**. Per avere successo, potrebbe dover **bypassare le protezioni dei branch**. Queste azioni possono essere eseguite con diversi obiettivi in mente:
+- Compromettere il branch principale per **compromettere la produzione**.
+- Compromettere il principale (o altri branch) per **compromettere le macchine degli sviluppatori** (poiché di solito eseguono test, terraform o altre cose all'interno del repo sulle loro macchine).
+- **Compromettere la pipeline** (controlla la sezione successiva).
 
 ## Pipelines Pentesting Methodology
 
-The most common way to define a pipeline, is by using a **CI configuration file hosted in the repository** the pipeline builds. This file describes the order of executed jobs, conditions that affect the flow, and build environment settings.\
-These files typically have a consistent name and format, for example — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), and the GitHub Actions YAML files located under .github/workflows. When triggered, the pipeline job **pulls the code** from the selected source (e.g. commit / branch), and **runs the commands specified in the CI configuration file** against that code.
+Il modo più comune per definire una pipeline è utilizzare un **file di configurazione CI ospitato nel repository** che la pipeline costruisce. Questo file descrive l'ordine dei lavori eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.\
+Questi file di solito hanno un nome e un formato coerenti, ad esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e i file YAML di GitHub Actions situati sotto .github/workflows. Quando attivata, la job della pipeline **estrae il codice** dalla sorgente selezionata (ad es. commit / branch) e **esegue i comandi specificati nel file di configurazione CI** contro quel codice.
 
-Therefore the ultimate goal of the attacker is to somehow **compromise those configuration files** or the **commands they execute**.
+Pertanto, l'obiettivo finale dell'attaccante è in qualche modo **compromettere quei file di configurazione** o i **comandi che eseguono**.
 
 ### PPE - Poisoned Pipeline Execution
 
-The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.
+Il percorso Poisoned Pipeline Execution (PPE) sfrutta i permessi in un repository SCM per manipolare una pipeline CI e eseguire comandi dannosi. Gli utenti con i permessi necessari possono modificare i file di configurazione CI o altri file utilizzati dal job della pipeline per includere comandi malevoli. Questo "avvelena" la pipeline CI, portando all'esecuzione di questi comandi malevoli.
 
-For a malicious actor to be successful performing a PPE attack he needs to be able to:
+Affinché un attore malintenzionato abbia successo nell'eseguire un attacco PPE, deve essere in grado di:
 
-- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access).
-  - Note that sometimes an **external PR count as "write access"**.
-- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**.
-  - For this, he might need to be able to **bypass branch protections**.
+- Avere **accesso in scrittura alla piattaforma VCS**, poiché di solito le pipeline vengono attivate quando viene eseguito un push o una pull request. (Controlla la metodologia di pentesting VCS per un riepilogo dei modi per ottenere accesso).
+- Nota che a volte un **PR esterno conta come "accesso in scrittura"**.
+- Anche se ha permessi di scrittura, deve essere sicuro di poter **modificare il file di configurazione CI o altri file su cui si basa la configurazione**.
+- Per questo, potrebbe dover essere in grado di **bypassare le protezioni dei branch**.
 
-There are 3 PPE flavours:
+Ci sono 3 varianti di PPE:
 
-- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed.
-- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config).
-- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR.
-  - **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**.
+- **D-PPE**: Un attacco **Direct PPE** si verifica quando l'attore **modifica il file di configurazione CI** che verrà eseguito.
+- **I-DDE**: Un attacco **Indirect PPE** si verifica quando l'attore **modifica** un **file** su cui il file di configurazione CI che verrà eseguito **si basa** (come un file make o una configurazione terraform).
+- **Public PPE o 3PE**: In alcuni casi, le pipeline possono essere **attivate da utenti che non hanno accesso in scrittura nel repo** (e che potrebbero non essere nemmeno parte dell'organizzazione) perché possono inviare un PR.
+- **3PE Command Injection**: Di solito, le pipeline CI/CD **imposteranno variabili di ambiente** con **informazioni sul PR**. Se quel valore può essere controllato da un attaccante (come il titolo del PR) ed è **utilizzato** in un **luogo pericoloso** (come l'esecuzione di **comandi sh**), un attaccante potrebbe **iniettare comandi lì**.
 
 ### Exploitation Benefits
 
-Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:
+Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attaccante potrebbe ottenere dopo un'esploitazione riuscita:
 
-- **Secrets**: As it was mentioned previously, pipelines require **privileges** for their jobs (retrieve the code, build it, deploy it...) and this privileges are usually **granted in secrets**. These secrets are usually accessible via **env variables or files inside the system**. Therefore an attacker will always try to exfiltrate as much secrets as possible.
-  - Depending on the pipeline platform the attacker **might need to specify the secrets in the config**. This means that is the attacker cannot modify the CI configuration pipeline (**I-PPE** for example), he could **only exfiltrate the secrets that pipeline has**.
-- **Computation**: The code is executed somewhere, depending on where is executed an attacker might be able to pivot further.
-  - **On-Premises**: If the pipelines are executed on premises, an attacker might end in an **internal network with access to more resources**.
-  - **Cloud**: The attacker could access **other machines in the cloud** but also could **exfiltrate** IAM roles/service accounts **tokens** from it to obtain **further access inside the cloud**.
-  - **Platforms machine**: Sometimes the jobs will be execute inside the **pipelines platform machines**, which usually are inside a cloud with **no more access**.
-  - **Select it:** Sometimes the **pipelines platform will have configured several machines** and if you can **modify the CI configuration file** you can **indicate where you want to run the malicious code**. In this situation, an attacker will probably run a reverse shell on each possible machine to try to exploit it further.
-- **Compromise production**: If you ware inside the pipeline and the final version is built and deployed from it, you could **compromise the code that is going to end running in production**.
+- **Secrets**: Come menzionato in precedenza, le pipeline richiedono **privilegi** per i loro lavori (recuperare il codice, costruirlo, distribuirlo...) e questi privilegi sono solitamente **concessi in segreti**. Questi segreti sono di solito accessibili tramite **variabili di ambiente o file all'interno del sistema**. Pertanto, un attaccante cercherà sempre di esfiltrare quanti più segreti possibile.
+- A seconda della piattaforma della pipeline, l'attaccante **potrebbe dover specificare i segreti nella configurazione**. Questo significa che se l'attaccante non può modificare la pipeline di configurazione CI (**I-PPE** ad esempio), potrebbe **solo esfiltrare i segreti che quella pipeline ha**.
+- **Computation**: Il codice viene eseguito da qualche parte, a seconda di dove viene eseguito, un attaccante potrebbe essere in grado di pivotare ulteriormente.
+- **On-Premises**: Se le pipeline vengono eseguite in sede, un attaccante potrebbe finire in una **rete interna con accesso a più risorse**.
+- **Cloud**: L'attaccante potrebbe accedere a **altre macchine nel cloud** ma potrebbe anche **esfiltrare** i token **IAM roles/service accounts** da esso per ottenere **ulteriore accesso all'interno del cloud**.
+- **Platforms machine**: A volte i lavori verranno eseguiti all'interno delle **macchine della piattaforma delle pipeline**, che di solito si trovano all'interno di un cloud con **nessun altro accesso**.
+- **Select it:** A volte la **piattaforma delle pipeline avrà configurato diverse macchine** e se puoi **modificare il file di configurazione CI** puoi **indicare dove vuoi eseguire il codice malevolo**. In questa situazione, un attaccante probabilmente eseguirà una reverse shell su ciascuna possibile macchina per cercare di sfruttarla ulteriormente.
+- **Compromise production**: Se sei all'interno della pipeline e la versione finale viene costruita e distribuita da essa, potresti **compromettere il codice che andrà a finire in produzione**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per l'audit della tua catena di fornitura software per la conformità alla sicurezza basato su un nuovo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal tempo di codice al tempo di distribuzione.
 
 ### Top 10 CI/CD Security Risk
 
-Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Controlla questo interessante articolo sui 10 principali rischi CI/CD secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
-- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- Su ciascuna piattaforma che puoi eseguire localmente troverai come lanciarla localmente in modo da poterla configurare come desideri per testarla.
+- Laboratorio Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** è uno strumento di analisi statica del codice per l'infrastruttura come codice.
 
 ## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
 {{#include ../banners/hacktricks-training.md}}
-
-
-
-