Informations de base sur Jenkins

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

AccĂšs

Nom d’utilisateur + mot de passe

La façon la plus courante de se connecter à Jenkins est avec un nom d’utilisateur et un mot de passe.

Si un cookie autorisĂ© est volĂ©, il peut ĂȘtre utilisĂ© pour accĂ©der Ă  la session de l’utilisateur. Le cookie s’appelle gĂ©nĂ©ralement JSESSIONID.*. (Un utilisateur peut terminer toutes ses sessions, mais il devra d’abord dĂ©couvrir qu’un cookie a Ă©tĂ© volĂ©).

SSO/Plugins

Jenkins peut ĂȘtre configurĂ© via des plugins pour ĂȘtre accessible via un SSO tiers.

Tokens

Les utilisateurs peuvent générer des tokens pour donner accÚs à des applications afin de les impersonner via le CLI ou le REST API.

Clés SSH

Ce composant fournit un serveur SSH intĂ©grĂ© pour Jenkins. C’est une interface alternative pour le Jenkins CLI, et des commandes peuvent ĂȘtre invoquĂ©es de cette façon avec n’importe quel client SSH. (Extrait des docs)

Autorisation

Dans /configureSecurity il est possible de configurer la mĂ©thode d’autorisation de Jenkins. Il existe plusieurs options :

  • Anyone can do anything : MĂȘme l’accĂšs anonyme peut administrer le serveur.
  • Legacy mode : Identique Ă  Jenkins <1.164. Si vous avez le rĂŽle “admin”, vous obtiendrez le contrĂŽle total du systĂšme, et sinon (y compris les utilisateurs anonymous) vous aurez un accĂšs en lecture.
  • Logged-in users can do anything : Dans ce mode, chaque utilisateur connectĂ© obtient le contrĂŽle total de Jenkins. Le seul utilisateur qui n’aura pas le contrĂŽle total est l’utilisateur anonymous, qui n’obtient que l’accĂšs en lecture.
  • Matrix-based security : Vous pouvez configurer qui peut faire quoi dans un tableau. Chaque colonne reprĂ©sente une permission. Chaque ligne reprĂ©sente un utilisateur ou un groupe/role. Cela inclut un utilisateur spĂ©cial ‘anonymous’, qui reprĂ©sente les utilisateurs non authentifiĂ©s, ainsi que ‘authenticated’, qui reprĂ©sente tous les utilisateurs authentifiĂ©s.

  • Project-based Matrix Authorization Strategy: Ce mode est une extension de la “Matrix-based security” qui permet de dĂ©finir une matrice ACL supplĂ©mentaire pour chaque projet sĂ©parĂ©ment.
  • Role-Based Strategy: Permet de dĂ©finir les autorisations via une stratĂ©gie basĂ©e sur les rĂŽles. GĂ©rez les rĂŽles dans /role-strategy.

Security Realm

Dans /configureSecurity il est possible de configurer le security realm. Par défaut, Jenkins inclut la prise en charge de quelques Security Realms différents :

  • Delegate to servlet container : Pour dĂ©lĂ©guer l’authentification Ă  un servlet container exĂ©cutant le controller Jenkins, comme Jetty.
  • Jenkins’ own user database: Utiliser le magasin d’utilisateurs intĂ©grĂ© de Jenkins pour l’authentification au lieu de dĂ©lĂ©guer Ă  un systĂšme externe. Ceci est activĂ© par dĂ©faut.
  • LDAP : DĂ©lĂ©guer toute l’authentification Ă  un serveur LDAP configurĂ©, incluant Ă  la fois les utilisateurs et les groupes.
  • Unix user/group database : DĂ©lĂšgue l’authentification Ă  la base d’utilisateurs du systĂšme Unix sous-jacent sur le controller Jenkins. Ce mode permettra Ă©galement la rĂ©utilisation des groupes Unix pour l’autorisation.

Les plugins peuvent fournir des security realms additionnels qui peuvent ĂȘtre utiles pour intĂ©grer Jenkins dans des systĂšmes d’identitĂ© existants, tels que :

Jenkins Nodes, Agents & Executors

DĂ©finitions d’aprĂšs les docs :

Nodes sont les machines sur lesquelles tournent les agents de build. Jenkins surveille chaque node attachĂ© pour l’espace disque, l’espace temporaire libre, le swap libre, la synchronisation/heure de l’horloge et le temps de rĂ©ponse. Un node est mis hors ligne si l’une de ces valeurs dĂ©passe le seuil configurĂ©.

Agents gĂšrent l’exĂ©cution des tĂąches au nom du controller Jenkins en utilisant des executors. Un agent peut utiliser n’importe quel systĂšme d’exploitation qui supporte Java. Les outils requis pour les builds et les tests sont installĂ©s sur le node oĂč l’agent tourne ; ils peuvent ĂȘtre installĂ©s directement ou dans un conteneur (Docker ou Kubernetes). Chaque agent est en pratique un processus avec son propre PID sur la machine hĂŽte.

Un executor est un slot d’exĂ©cution de tĂąches ; en pratique, c’est un thread dans l’agent. Le nombre d’executors sur un node dĂ©finit le nombre de tĂąches concurrentes qui peuvent ĂȘtre exĂ©cutĂ©es sur ce node en mĂȘme temps. En d’autres termes, cela dĂ©termine le nombre de stages Pipeline concurrents qui peuvent s’exĂ©cuter sur ce node en mĂȘme temps.

Jenkins Secrets

Chiffrement des secrets et des credentials

DĂ©finition d’aprĂšs les docs : Jenkins utilise AES pour chiffrer et protĂ©ger les secrets, les credentials, et leurs clĂ©s de chiffrement respectives. Ces clĂ©s de chiffrement sont stockĂ©es dans $JENKINS_HOME/secrets/ ainsi que la master key utilisĂ©e pour protĂ©ger ces clĂ©s. Ce rĂ©pertoire doit ĂȘtre configurĂ© de sorte que seul l’utilisateur systĂšme sous lequel tourne le controller Jenkins ait les droits de lecture et Ă©criture sur ce rĂ©pertoire (par exemple chmod 0700 ou en utilisant des attributs de fichier appropriĂ©s). La master key (parfois appelĂ©e “key encryption key” en jargon crypto) est stockĂ©e unencrypted sur le systĂšme de fichiers du controller Jenkins dans $JENKINS_HOME/secrets/master.key, ce qui ne protĂšge pas contre des attaquants ayant un accĂšs direct Ă  ce fichier. La plupart des utilisateurs et dĂ©veloppeurs utiliseront ces clĂ©s de chiffrement indirectement via soit l’API [Secret] pour chiffrer des donnĂ©es secrĂštes gĂ©nĂ©riques, soit via l’API des credentials. Pour les cryptocurieux, Jenkins utilise AES en mode cipher block chaining (CBC) avec padding PKCS#5 et IVs alĂ©atoires pour chiffrer des instances de [CryptoConfidentialKey] qui sont stockĂ©es dans $JENKINS_HOME/secrets/ avec un nom de fichier correspondant Ă  leur identifiant CryptoConfidentialKey. Les identifiants de clĂ© courants incluent :

  • hudson.util.Secret : utilisĂ© pour les secrets gĂ©nĂ©riques ;
  • com.cloudbees.plugins.credentials.SecretBytes.KEY : utilisĂ© pour certains types de credentials ;
  • jenkins.model.Jenkins.crumbSalt : utilisĂ© par le CSRF protection mechanism ; et

AccĂšs aux credentials

Les credentials peuvent ĂȘtre scopĂ©s Ă  des providers globaux (/credentials/) qui peuvent ĂȘtre accessibles par n’importe quel projet configurĂ©, ou peuvent ĂȘtre scĂ©Ă©s Ă  des projets spĂ©cifiques (/job/<project-name>/configure) et donc uniquement accessibles depuis le projet concernĂ©.

Selon les docs : Les credentials qui sont dans le scope sont disponibles pour le pipeline sans limitation. Pour Ă©viter une exposition accidentelle dans le log de build, les credentials sont masquĂ©s dans la sortie normale, donc une invocation de env (Linux) ou set (Windows), ou des programmes affichant leur environnement ou paramĂštres ne les rĂ©vĂ©leront pas dans le log de build Ă  des utilisateurs qui n’auraient pas autrement accĂšs aux credentials.

C’est pourquoi, pour exfiltrer les credentials, un attaquant doit par exemple les encoder en base64.

Secrets dans les configs de plugin/job sur le disque

Ne supposez pas que les secrets se trouvent uniquement dans credentials.xml. De nombreux plugins conservent des secrets dans leur propre XML global sous $JENKINS_HOME/*.xml ou dans le $JENKINS_HOME/jobs/<JOB>/config.xml par job, parfois mĂȘme en clair (le masquage UI ne garantit pas un stockage chiffrĂ©). Si vous obtenez un accĂšs en lecture au systĂšme de fichiers, Ă©numĂ©rez ces XML et recherchez des balises Ă©videntes contenant des 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" {} \\;

Références

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks