Le temps presse pour corriger une faille découverte dans Jenkins, la solution de déploiement continu à l’intention des développeurs. En effet, à peine trouvée, la vulnérabilité fait l’objet de plusieurs exploits disponibles sur GitHub ouvrant ainsi la voie à une multiplication d’attaques. D'après les analyses effectuées par le service Shodan, plus de 75 000 serveurs Jenkins sont exposés à Internet. Ce service est couramment utilisé pour l'intégration continue et de la livraison continue (CI/CD), car il permet d'automatiser la construction, le test et le déploiement du code.

Compte tenu de ses nombreuses intégrations avec d'autres services et outils, Jenkins est très populaire dans toutes les entreprises de développement. Sa part de marché est estimée à environ 44%. Qualifiée de critique, la vulnérabilité, référencée CVE-2024-23897, résulte d’un problème de lecture arbitraire de fichier que les attaquants peuvent exploiter pour lire des fichiers binaires entiers ou partiels à partir du système de fichiers. Ils peuvent ainsi extraire des clés secrètes et les utiliser pour élever leurs privilèges au niveau administrateur et exécuter du code malveillant. Ce problème a été corrigé dans les versions 2.442 et LTS 2.426.3 de Jenkins, en même temps que plusieurs autres failles de gravité élevée et moyenne.

Des lignes de commandes exposent des secrets

La faille provient de l'utilisation par Jenkins de la bibliothèque args4j pour analyser les arguments de commande (command line argument parsing), et les options lors du traitement des commandes envoyées via l'interface de ligne de commande (CLI) de Jenkins. L'analyseur remplace le caractère @ suivi d'un chemin d'accès à un fichier dans un argument de commande par le contenu du fichier, exposant ainsi potentiellement des secrets. Selon les chercheurs de SonarSource, qui ont découvert et signalé la vulnérabilité, les attaquants non authentifiés peuvent l'exploiter s'ils obtiennent l'autorisation de lecture sur le serveur. Ce qui est possible dans plusieurs configurations : si le serveur a une autorisation en mode legacy activée, si il est configuré avec « Allow anonymous read access » coché dans le mode d'autorisation « logged-in users can do anything », ou si la fonction signup est activée et permet à n'importe qui de créer un compte sur le serveur.

Même si aucune de ces conditions n'est remplie, les utilisateurs non authentifiés peuvent toujours lire les premières lignes des fichiers au lieu de leur contenu intégral. « Un attaquant pourrait tirer parti de cette situation en trouvant une commande qui prend un nombre arbitraire d'arguments et les affiche à l'utilisateur », expliquent les chercheurs dans un billet de blog. « Étant donné que les arguments sont tirés du contenu du fichier, un pirate pourrait faire fuiter le contenu du fichier de cette manière. Selon nos recherches, la commande connect-to-node est un bon candidat : elle reçoit une liste de chaînes comme argument et tente de se connecter à chacune d'entre elles. En cas d'échec, un message d'erreur est généré avec le nom du nœud connecté qui a échoué ». Parmi les fichiers du serveur susceptibles d'intéresser un pirate, on peut citer les clés SSH, le fichier /etc/passwd, le fichier /etc/shadow, les secrets et les informations d'identification du projet, le code source et les artefacts de construction, etc. L'équipe de sécurité de Jenkins documente plusieurs chemins d'attaque pour obtenir l'exécution de code à distance et d'autres vols de secrets avec cette vulnérabilité. Il s'agit notamment de l'utilisation abusive de la fonctionnalité « Resource Root URL », de la falsification des cookies « Remember me », de l'insertion d'attaques XSS (Cross-Site Scripting) dans les journaux de build, de la falsification des jetons de protection contre la falsification des requêtes intersites, du décryptage des secrets binaires et du téléchargement d'un dump mémoire Java.

Atténuer la vulnérabilité du serveur CI/CD Jenkins

Le correctif consiste à désactiver l'analyseur de commandes qui expose le contenu des fichiers. Cela peut poser des problèmes pour certains déploiements, auquel cas un mécanisme est disponible pour l'annuler. Cependant, son utilisation est fortement déconseillée sur les instances Jenkins accessibles sur le réseau par des non-administrateurs.

Un autre moyen d'atténuer la menace consiste à désactiver complètement l'accès à l'interface CLI de Jenkins jusqu'à ce que les correctifs puissent être appliqués. Des chercheurs en sécurité ont averti vendredi dernier que plusieurs exploits de preuve de concept pour cette vulnérabilité avaient déjà été publiés sur GitHub et d'autres ont déjà signalé des exploitations de la faille dans la nature.