Informations de base sur Jenkins

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir 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 et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks