Last updated
Apprenez et pratiquez le hacking AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : Formation HackTricks GCP Red Team Expert (GRTE)
La façon la plus courante de se connecter à Jenkins est avec un nom d'utilisateur ou un mot de passe.
Si un cookie autorisé est volé, il peut être utilisé pour accéder à la session de l'utilisateur. Le cookie est généralement appelé JSESSIONID.*. (Un utilisateur peut terminer toutes ses sessions, mais il doit d'abord découvrir qu'un cookie a été volé).
Jenkins peut être configuré à l'aide de plugins pour être accessible via un SSO tiers.
Les utilisateurs peuvent générer des jetons pour donner accès aux applications pour les usurper via CLI ou REST API.
Ce composant fournit un serveur SSH intégré pour Jenkins. C'est une interface alternative pour le Jenkins CLI, et les commandes peuvent être invoquées de cette manière en utilisant n'importe quel client SSH. (D'après les docs)
Dans /configureSecurity, il est possible de configurer la méthode d'autorisation de Jenkins. Il existe plusieurs options :
Tout le monde peut tout faire : Même l'accès anonyme peut administrer le serveur.
Mode hérité : Identique à Jenkins <1.164. Si vous avez le rôle "admin", vous aurez un contrôle total sur le système, et sinon (y compris les utilisateurs anonymes), vous aurez un accès en lecture.
Les utilisateurs connectés peuvent tout faire : Dans ce mode, chaque utilisateur connecté obtient un contrôle total de Jenkins. Le seul utilisateur qui n'aura pas un contrôle total est l'utilisateur anonyme, qui n'a qu'un accès en lecture.
Sécurité basée sur une matrice : 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/rôle. Cela inclut un utilisateur spécial 'anonyme', qui représente les utilisateurs non authentifiés, ainsi que 'authentifié', qui représente tous les utilisateurs authentifiés.
Stratégie d'autorisation basée sur les projets : Ce mode est une extension à "la sécurité basée sur une matrice" qui permet de définir une matrice ACL supplémentaire pour chaque projet séparément.
Stratégie basée sur les rôles : Permet de définir des autorisations en utilisant une stratégie basée sur les rôles. Gérez les rôles dans /role-strategy.
Dans /configureSecurity, il est possible de configurer le royaume de sécurité. Par défaut, Jenkins inclut le support de quelques royaumes de sécurité différents :
Déléguer au conteneur de servlets : Pour déléguer l'authentification à un conteneur de servlets exécutant le contrôleur Jenkins, tel que Jetty.
Base de données utilisateur propre à Jenkins : Utilisez le magasin de données utilisateur intégré de Jenkins pour l'authentification au lieu de déléguer à un système externe. Cela est activé par défaut.
LDAP : Déléguer toute l'authentification à un serveur LDAP configuré, y compris les utilisateurs et les groupes.
Base de données utilisateur/groupe Unix : Délègue l'authentification à la base de données utilisateur au niveau du système d'exploitation Unix sous-jacent sur le contrôleur Jenkins. Ce mode permettra également la réutilisation des groupes Unix pour l'autorisation.
Les plugins peuvent fournir des royaumes de sécurité supplémentaires qui peuvent être utiles pour intégrer Jenkins dans des systèmes d'identité existants, tels que :
Définitions des docs :
Les nœuds sont les machines sur lesquelles les agents de construction s'exécutent. Jenkins surveille chaque nœud attaché pour l'espace disque, l'espace temporaire libre, l'échange libre, l'heure/synchronisation de l'horloge et le temps de réponse. Un nœud est mis hors ligne si l'une de ces valeurs dépasse le seuil configuré.
Les agents gèrent l'exécution des tâches au nom du contrôleur Jenkins en utilisant des exécuteurs. Un agent peut utiliser n'importe quel système d'exploitation qui prend en charge Java. Les outils nécessaires pour les constructions et les tests sont installés sur le nœud où l'agent s'exécute ; ils peuvent être installés directement ou dans un conteneur (Docker ou Kubernetes). Chaque agent est effectivement un processus avec son propre PID sur la machine hôte.
Un exécuteur est un emplacement pour l'exécution des tâches ; en effet, c'est un thread dans l'agent. Le nombre d'exécuteurs sur un nœud définit le nombre de tâches concurrentes qui peuvent être exécutées sur ce nœud à un moment donné. En d'autres termes, cela détermine le nombre de stages de pipeline concurrentes qui peuvent s'exécuter sur ce nœud à un moment donné.
Définition des docs : Jenkins utilise AES pour chiffrer et protéger les secrets, les identifiants et leurs clés de chiffrement respectives. Ces clés de chiffrement sont stockées dans $JENKINS_HOME/secrets/ avec la clé maître utilisée pour protéger ces clés. Ce répertoire doit être configuré de sorte que seul l'utilisateur du système d'exploitation sous lequel le contrôleur Jenkins s'exécute ait un accès en lecture et en écriture à ce répertoire (c'est-à-dire, une valeur chmod de 0700 ou en utilisant des attributs de fichier appropriés). La clé maître (parfois appelée "clé de chiffrement" dans le jargon cryptographique) est stockée _non chiffrée_ sur le système de fichiers du contrôleur Jenkins dans $JENKINS_HOME/secrets/master.key ce qui ne protège pas contre les attaquants ayant un accès direct à ce fichier. La plupart des utilisateurs et des développeurs utiliseront ces clés de chiffrement indirectement via soit l'API Secret pour chiffrer des données secrètes génériques ou via l'API des identifiants. Pour les curieux de cryptographie, Jenkins utilise AES en mode de chaîne de blocs de chiffrement (CBC) avec un remplissage PKCS#5 et des IV aléatoires pour chiffrer des instances de CryptoConfidentialKey qui sont stockées dans $JENKINS_HOME/secrets/ avec un nom de fichier correspondant à leur id CryptoConfidentialKey. Les ids de clé courants incluent :
hudson.util.Secret : utilisé pour des secrets génériques ;
com.cloudbees.plugins.credentials.SecretBytes.KEY : utilisé pour certains types d'identifiants ;
jenkins.model.Jenkins.crumbSalt : utilisé par le mécanisme de protection CSRF ; et
Les identifiants peuvent être scopés aux fournisseurs globaux (/credentials/) qui peuvent être accessibles par tout projet configuré, ou peuvent être scoper à des projets spécifiques (/job/<project-name>/configure) et donc uniquement accessibles depuis le projet spécifique.
Selon les docs : Les identifiants qui sont dans le champ d'application sont mis à disposition du pipeline sans limitation. Pour prévenir une exposition accidentelle dans le journal de construction, les identifiants sont masqués de la sortie régulière, donc une invocation de env (Linux) ou set (Windows), ou des programmes imprimant leur environnement ou leurs paramètres ne révèleraient pas ces identifiants dans le journal de construction aux utilisateurs qui n'auraient pas autrement accès aux identifiants.
C'est pourquoi, pour exfiltrer les identifiants, un attaquant doit, par exemple, les encoder en base64.
Apprenez et pratiquez le hacking AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : Formation HackTricks GCP Red Team Expert (GRTE)
