Informazioni di base su Jenkins

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Accesso

Nome utente + Password

Il modo piÚ comune per effettuare il login in Jenkins è usare un nome utente e una password

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/Plugins

Jenkins può essere configurato tramite plugin per essere accessibile tramite SSO di terze parti.

Tokens

Gli utenti possono generare token per consentire ad applicazioni di impersonarli via CLI o REST API.

SSH Keys

Questo componente fornisce un server SSH integrato per Jenkins. È un’interfaccia alternativa per la Jenkins CLI, e i comandi possono essere invocati in questo modo usando qualsiasi client SSH. (From the docs)

Autorizzazione

In /configureSecurity è possibile configurare il metodo di autorizzazione di Jenkins. Ci sono diverse opzioni:

  • 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.

  • 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.

Security Realm

In /configureSecurity è possibile configurare il security realm. Per impostazione predefinita Jenkins include il supporto per alcuni Security Realm differenti:

  • Delegate to servlet container: Per delegare l’autenticazione a un servlet container che esegue il controller Jenkins, come 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 Security Realm aggiuntivi che possono essere utili per integrare Jenkins in sistemi di identity esistenti, come:

Jenkins Nodes, Agents & Executors

Definizioni dalle docs:

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.

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 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

Encryption of Secrets and Credentials

Definizione dalle docs: 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 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 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: 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; e

Accesso alle Credentials

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 the docs: 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 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.

# 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

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks