Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Il modo più comune per accedere a Jenkins è con un nome utente o una password.
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).
Jenkins può essere configurato utilizzando plugin per essere accessibile tramite SSO di terze parti.
Gli utenti possono generare token per dare accesso alle applicazioni per impersonarli tramite CLI o REST API.
Questo componente fornisce un server SSH integrato per Jenkins. È un'interfaccia alternativa per il Jenkins CLI, e i comandi possono essere invocati in questo modo utilizzando qualsiasi client SSH. (Dalla documentazione)
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 registrati possono fare qualsiasi cosa: In questa modalità, ogni utente registrato 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.
Strategia di autorizzazione basata su progetto: Questa modalità è un'estensione della "sicurezza basata su matrice" che consente di definire matrici ACL aggiuntive per ciascun progetto separatamente.
Strategia basata su ruoli: Consente di definire autorizzazioni utilizzando una strategia basata su ruoli. Gestisci i ruoli in /role-strategy.
In /configureSecurity è possibile configurare il reame di sicurezza. Per impostazione predefinita, Jenkins include supporto per alcuni diversi Reami di Sicurezza:
Delegare al contenitore servlet: Per delegare l'autenticazione a un contenitore servlet che esegue il controller Jenkins, come 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: Delegare 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.
I plugin possono fornire ulteriori reami di sicurezza che possono essere utili per incorporare Jenkins in sistemi di identità esistenti, come:
Definizioni dalla documentazione:
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 messo offline se uno di questi valori supera la soglia configurata.
Agenti gestiscono l'esecuzione dei compiti per conto del controller Jenkins utilizzando esecutori. Un agente può utilizzare qualsiasi sistema operativo che supporti Java. Gli strumenti necessari per le build e i 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.
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 in un dato momento. In altre parole, questo determina il numero di stages Pipeline concorrenti che possono essere eseguiti su quel nodo in un dato momento.
Definizione dalla documentazione: 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 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 che sono memorizzate in $JENKINS_HOME/secrets/ con un nome file corrispondente al loro id CryptoConfidentialKey. 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; e
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.
Secondo la documentazione: 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.
Ecco perché, per esfiltrare le credenziali, un attaccante deve, ad esempio, codificarle in base64.
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
