CVE-2024-23897 : Jenkins

Résumé

• CVE-2024-23897, annoncée le 24 janvier 2024, est une vulnérabilité dans Jenkins CI/CD, qui peut entraîner la lecture de fichiers arbitraires.
• Au 30 janvier 2024, Censys a observé 83 509 serveurs Jenkins sur Internet, dont 79 952 (~96 %) sont potentiellement vulnérables.
• Les utilisateurs sont invités à mettre à jour Jenkins 2.442 pour la version standard de Jenkins et 2.426.3 pour les éditions Long-Term Support (LTS).
• Dans la mesure du possible, les serveurs Jenkins ne doivent pas être directement connectés à l'internet.

Introduction

Serveurs Jenkins sur l'internet.

Le 24 janvier 2024, une vulnérabilité de niveau critique a été annoncée pour le système d'intégration et de déploiement continus (CI/CD) Jenkins, qui est actuellement suivie comme CVE-2024-23897(avis du fournisseur 3314). En cas de succès, un attaquant non authentifié peut utiliser une exécution de code à distance (RCE) pour faciliter la lecture de fichiers arbitraires (avec quelques mises en garde).

Avec la configuration par défaut, un attaquant non authentifié ne dispose d'aucune autorisation par défaut et ne peut lire que les deux ou trois premières lignes d'un fichier en clair arbitraire. Lorsqu'il est authentifié, un attaquant peut visualiser l'intégralité de n'importe quel fichier en clair .

En revanche, si le serveur Jenkins a été configuré avec l'une des deux options "dangereuses" listées ci-dessous :

• "Autoriser les utilisateurs à s'inscrire"
• "Autoriser l'accès anonyme en lecture"

Les utilisateurs disposant des autorisations ci-dessus peuvent lire l'intégralité des fichiers en texte clair et des fichiers binaires (bien que les fichiers binaires soient convertis en texte clair).

Le problème provient de l'une des bibliothèques de programmation que Jenkins utilise pour analyser les arguments envoyés à un utilitaire de ligne de commande. L'API en question, args4j, possède une fonctionnalité qui remplace les caractères "@", suivis d'un chemin de fichier, par le contenu réel du fichier. Les versions de Jenkins LTS antérieures à la 2.426.2 incluse et les versions de Jenkins 2.441 et antérieures ne désactivent pas cette fonctionnalité spécifique, ce qui permet à un attaquant de lire des fichiers arbitraires sur le système de fichiers de Jenkins.

Les quelques exploits de démonstration de faisabilité qui ont été publiés jusqu'à présent n'ont permis que de lire des fichiers arbitraires ; ils n'ont pas exécuté de commandes arbitraires. Cela signifie qu'un attaquant peut potentiellement lire des fichiers sensibles tels que /etc/passwd (qui, en réalité, n'est pas si sensible que cela étant donné que les vrais mots de passe hachés se trouvent dans /etc/shadow). L'utilisation de cet exploit seul ne permettra pas à l'attaquant d'obtenir un shell à distance. Cependant, un attaquant pourrait avoir de la chance et trouver un mot de passe stocké dans un fichier spécifique, qui pourrait, à son tour, être utilisé pour obtenir un accès supplémentaire.

En bref, bien que cet exploit exécute une commande, il est limité aux utilitaires auxquels le serveur Jenkins a accès (comme la Jenkins-CLI via une WebSocket), dont les résultats peuvent être potentiellement utilisés pour obtenir un accès élevé.

Cela ne veut pas dire que ce n'est pas un problème ; il s'agit techniquement d'un "RCE" en ce sens qu'une commande (spécifique) est exécutée, et nous ne minimisons en aucun cas cet aspect. Nous ne disons pas non plus qu'un attaquant ne pourrait pas trouver un fichier qui pourrait être utilisé pour obtenir un accès supplémentaire (comme une clé SSH privée) ; c'est juste que jusqu'à présent, la gravité est fortement limitée en fonction de la configuration du serveur Jenkins.

Pour plus de détails sur les différentes sévérités de configuration et un excellent résumé des types de données qui peuvent être exfiltrées, nous recommandons vivement le résumé de Horizon3.ai sur la CVE-2024-23897 et l'article de Sonar sur le même sujet.

Pour comprendre pourquoi cela pourrait être un problème dans de bonnes conditions, nous devons d'abord comprendre ce qu'est Jenkins, ce qu'il fait, pourquoi les gens l'utilisent, et les ramifications potentielles en termes de sécurité de l'appropriation de l'un de ces services.

Qu'est-ce que la est Jenkins ?

Jenkins est, à la base, un système de construction et de livraison de logiciels. Toute personne ayant travaillé dans une organisation ou dans un domaine nécessitant des programmeurs et des développeurs a probablement dû, à un moment ou à un autre, utiliser un système de construction de logiciels. Jenkins est l'une des plateformes d'intégration continue les plus connues (parfois tristement célèbres). Il s'agit d'un logiciel libre et facilement accessible à toute personne souhaitant l'utiliser. Outre les tâches "simples" telles que la compilation d'un ou plusieurs projets et la création de paquets, Jenkins peut également déployer automatiquement ces applications dans les réseaux des clients.

Ce service est souvent le catalyseur du cycle de déploiement du code de toute une organisation, et c'est pour cette raison que nous pouvons mieux comprendre pourquoi il est considéré comme une cible très précieuse pour les attaquants.

Jenkins est la chaîne d'approvisionnement...

...ou, du moins, une partie très importante de celui-ci.

D'une manière générale, si un seul produit devait être considéré comme le véritable ventre mou de la chaîne d'approvisionnement d'un éditeur de logiciels (ou d'une équipe de développement), il s'agirait de ses serveurs de compilation. Non seulement ce serveur contient des copies (multiples) du code source d'une organisation, mais il contient aussi souvent tous les éléments qui composent une compilation unique, ce qui peut inclure les clés, les configurations et les mots de passe nécessaires à l'assemblage et au déploiement d'une application (bien que ces éléments soient spécifiques à chaque projet de compilation). Souvent, Jenkins est utilisé pour déterminer si un logiciel est prêt pour la production.

Dans le pire des cas, un attaquant capable de modifier un build sur un serveur Jenkins pourrait théoriquement empoisonner le pipeline de build et de déploiement en injectant du code ou des commandes malveillantes dans le cadre du travail. Cela s'est déjà produit en 2020 avec l'incident SolarWinds, où des acteurs malveillants ont pu installer des portes dérobées dans le logiciel de surveillance de réseau Orion de l'entreprise en utilisant leur pipeline CI/CD. Le logiciel a ensuite été déployé automatiquement auprès de milliers de clients, sous la forme d'une mise à jour normale.

"Pour s'implanter dans l'organisation, l'acteur de la menace a compromis le "cœur" du pipeline CI/CD, où le code est testé, enveloppé, conteneurisé et signé, puis a modifié avec succès le code source de SolarWinds." - CyberArk

Des incidents comme celui de SolarWinds2k font de l'accès à un système d'intégration continue (CI) ou de déploiement continu (CD) une véritable mine d'or pour un attaquant potentiel. Ou du moins, un point d'entrée très recherché.

Il ne s'agit pas de dire que la vulnérabilité de Jenkins est la même que celle utilisée dans l'attaque de SolarWinds, mais simplement de donner un exemple de ce qu'il est possible de faire avec un accès administratif aux systèmes de construction et de déploiement d'une entreprise.

Le point de vue de Censys

Note aux lecteurs.

Dans les sections suivantes, nous considérons toute version de Jenkins LTS inférieure ou égale à la version 2.426.2 et les versions de Jenkins inférieures ou égales à la version 2.441 comme vulnérables à cette CVE, conformément à l'avis de l'éditeur. Cela ne tient pas compte du fait que les conditions appropriées sont en place pour lire l'intégralité des fichiers texte et binaires (accès anonyme en lecture ou utilisateurs authentifiés), car notre scanner ne rapporte pas directement ce niveau de détail, et il ne s'agit pas de dire que le monde est en feu ; nous rapportons simplement le nombre brut de serveurs Jenkins sur l'internet pour donner une idée de l'étendue potentielle de ce problème.

Jenkins sur Internet

Au total, Censys observe 83 509 serveurs Jenkins sur l'internet. Parmi ceux-ci, 79 952 hôtes utilisent une version vulnérable, alors que seulement 3 557 hôtes ont été corrigés avec l'une des versions corrigées. Cela signifie que seuls 4,2 % des hôtes exécutant Jenkins sur l'internet sont à l'abri de cette CVE, et que 95,7 % sont potentiellement vulnérables.

La capture d'écran ci-dessus montre les huit derniers jours de serveurs Jenkins vulnérables et non vulnérables que nous avons pu trouver sur l'internet public. Nous constatons que le 25 janvier 2024, un jour après l'annonce de la vulnérabilité, un peu plus de 300 serveurs utilisaient les dernières versions non vulnérables. Au cours des prochains jours, nous verrons un nombre constant de serveurs Jenkins mis hors ligne et/ou mis à niveau vers la dernière version.

* 2024-01-24 est la date de diffusion de l'avis. Notez que nos statistiques ont été établies à 11 heures (heure de l'Est).

Nous avons déjà observé ce même schéma avec des produits comme Confluence, où une vulnérabilité est annoncée, et au lieu de voir un nombre constant de serveurs en ligne au total, nous constatons une diminution du nombre de serveurs en ligne dans l'ensemble. Cela indique que lorsqu'une vulnérabilité est annoncée, les administrateurs les retirent de l'internet au lieu de mettre à niveau leurs serveurs, soit en les plaçant derrière un pare-feu, soit en les mettant complètement hors ligne. Cela pourrait également indiquer que bon nombre de ces serveurs n'étaient pas utilisés au départ (il s'agissait d'instances de test, par exemple).

Les graphiques et les tableaux ci-dessous représentent le nombre de versions vulnérables et non vulnérables de Jenkins dans tous les systèmes autonomes et les pays où ils se trouvent au 30 janvier 2024.

Systèmes autonomes (30 janvier 2024)

Pays (30 janvier 2024)

Serveurs Jenkins vulnérables dans l'espace quantique

Censys suggère aux administrateurs de noter soigneusement tous les services Jenkins fonctionnant sur leurs hôtes, car nous avons trouvé un peu moins de 600 hôtes sur l'internet qui exécutent plusieurs versions du logiciel Jenkins sur plusieurs ports et un peu plus de 60 hôtes qui ont à la fois une version vulnérable et une version non vulnérable de Jenkins.

Par exemple, dans la capture d'écran ci-dessous, nous voyons un seul hôte exécutant une version corrigée de Jenkins LTS sur le port TCP 80 et une version vulnérable sur le port TCP 9001.

Identification des services Jenkins

Avec Censys, il vous suffit d'une seule requête pour découvrir tous les serveurs Jenkins en cours d'exécution sur Internet :

• services : (software.vendor : jenkins et software.product : jenkins)

L'un des moyens les plus simples d'identifier non seulement si un hôte exécute un serveur Jenkins, mais aussi d'obtenir la version exacte du service en cours d'exécution, consiste à analyser les en-têtes de la réponse HTTP et à rechercher l'existence de la clé X-Jenkins, dont la valeur correspondra souvent à la version réelle du serveur.

Un hôte exécutant Jenkins.

Le plus souvent, une requête HTTP adressée au serveur Jenkins aboutit à un code d'état 403, qui nous informe, en tant que client, que le serveur requiert une authentification ; en d'autres termes, si vous vous rendez à cette URL dans votre navigateur, vous verrez apparaître un formulaire de connexion.

Le même hôte mais dans un navigateur.

Mais la capture d'écran ci-dessus n'est pas la seule vue que vous pouvez voir avec Censys et Jenkins ; un serveur Jenkins peut être configuré de manière à ce qu'un accès anonyme/invité soit donné à l'internet en général, ce qui donne à n'importe quel utilisateur la possibilité (au minimum) de voir les différents travaux et constructions qui sont actuellement configurés.

Si vous modifiez la requête de recherche Censys pour y inclure une recherche de titre HTML, vous trouverez de nombreux exemples de serveurs Jenkins ayant un accès en lecture globale au système :

• services : (software.vendor : jenkins et software.product : jenkins et http.response.html_title : "Tableau de bord [Jenkins]")

Il convient de noter que de nombreux serveurs Jenkins ayant un accès en lecture au tableau de bord ne sont pas nécessairement mal configurés, car de nombreux projets open-source utilisent Jenkins comme moyen de construire et de tester leurs logiciels. Mais c'est quelque chose à noter.

Différencier Jenkins LTS de Jenkins Release

Dans l'avis, nous voyons que les versions de Jenkins inférieures ou égales à la version 2.441 sont vulnérables à cette CVE. D'autre part, les versions de Jenkins LTS inférieures ou égales à 2.426.2 sont également vulnérables. Comme il y a un peu de chevauchement entre ces deux arbres de code, nous avons besoin d'un moyen de différencier un serveur Jenkins LTS (Long Term Support) d'un serveur Jenkins normal.

Heureusement, la valeur de la version dans l'en-tête de la réponse HTTP X-Jenkins comprendra trois chiffres (major, minor, patch, séparés par un point) pour les versions LTS et seulement deux chiffres (major, minor, séparés par un point) pour les versions standard. Pour une fois, nous avons un fournisseur qui fait du versionnage sémantique correctement.

Que peut-on faire ?

• Se référer à l'avis du avis du fournisseurqui indique que les utilisateurs doivent mettre à jour vers Jenkins 2.442 ou la version LTS 2.426.3.
• Utilisez cette Censys requête de recherche pour trouver les serveurs Jenkins exposés à l'internet.
• Censys Les clients d'ASM auront accès à un nouveau risque qui identifiera les serveurs Jenkins potentiellement vulnérables (rechercher "CVE-2024-23897").