Log4Shell, un an plus tard

Il y a un an, en décembre 2021, la vulnérabilité Log4Shell (CVE-2021-44228) de la bibliothèque Apache Log4j a fait beaucoup de bruit. Même si l’incident ne faisait plus la une des médias informatiques au printemps, en novembre 2022 elle a fait son grand retour lorsqu’il a été dit que des cybercriminels avaient exploité cette vulnérabilité pour attaquer une agence fédérale américaine et pour installer un mineur de cryptomonnaie dans ses systèmes. C’est l’occasion d’expliquer ce qu’est vraiment Log4Shell, pourquoi il est trop tôt pour considérer que c’est terminé et comment protéger votre infrastructure.

Qu’est-ce que la bibliothèque Apache Log4j ?

Comme Java SDK n’était initialement pas compatible avec la journalisation, les développeurs ont dû créer leurs propres solutions, et lorsque l’API officielle Java Logging est apparue, il y en avait déjà plusieurs sur le marché. Apache Log4j est l’une d’elles : une célèbre bibliothèque Java open-source en développement depuis 2001. Ce n’est pas la seule solution de journalisation Java, mais c’est sans aucun doute une des plus utilisées. Diverses solutions alternatives sont principalement des rejetons de Log4j qui sont apparus aux différentes étapes de développement de la bibliothèque.

Qu’est-ce que la vulnérabilité Log4Shell ?

La bibliothèque Log4j permet de connecter automatiquement tous les événements système. Elle utilise un ensemble standard d’interfaces pour accéder aux données de l’API Java Naming and Directory Interface (JNDI). En novembre 2021, il s’est avéré que pendant la journalisation, la bibliothèque pouvait exécuter les ordres de JNDI passés par un événement, par exemple, dans l’en-tête d’une requête, dans le message d’un chat ou dans la description du message d’erreur 404 d’un site Internet.

La vulnérabilité permet aux cybercriminels, du moins en théorie, de faire tout ce qu’ils veulent sur le système de la victime (si aucune mesure de sécurité supplémentaire n’intervient). En pratique, les escrocs utilisent surtout Log4Shell pour installer illégalement des mineurs et pour lancer des attaques de rançongiciels. Cette vulnérabilité a aussi été utilisée de façon plus originale, avec des attaques ciblées, la distribution du botnet Mirai ou pour du RickRolling, avec la reproduction de l’addictive chanson du chanteur des années 80 Rick Astley, « Never Gonna Give You Up ».

Pourquoi cette vulnérabilité est-elle si dangereuse et encore menaçante ?

Java est un des principaux langages de programmation et est utilisé par de nombreux systèmes back end, qu’il s’agisse des petits serveurs d’une entreprise, de systèmes d’automation industrielle ou de dispositifs de l’Internet des Objets (IoT). La plupart de ces systèmes utilisent la journalisation d’une façon ou d’une autre. Depuis des années, la solution la plus simple consiste à utiliser la bibliothèque Log4j. Lorsqu’il a été communiqué en décembre 2021 qu’il y avait une vulnérabilité, les experts ont déclaré que ce serait un problème de taille pour les années à venir. Voici pourquoi :

• Des applications Java en tout genre utilisent la bibliothèque Log4j. Lorsqu’elle a été découverte, la vulnérabilité se trouvait dans plus de 35 000 paquets du dépôt Maven Central (le plus grand répertoire de paquets Java), soit 8 % de tous les fichiers infectés. Selon nos experts, près de 40 % des réseaux dans le monde entier étaient en danger à cause de Log4Shell.
• En plus des ordinateurs et serveurs conventionnels, Java est aussi utilisé par le matériel industriel, médical et spécialisé. Tous ces équipements sont aussi connus pour leur utilisation de la bibliothèque Log4j.
• Les utilisateurs finaux des solutions qui utilisent la bibliothèque Log4j, et parfaitement inconscients de la présence de cette vulnérabilité, pourraient remettre à plus tard les mises à jour.
• Les développeurs de solutions qui se servent de la bibliothèque Log4j auraient pu faire faillite depuis longtemps, abandonner le marché ou chercher de l’aide pour leurs programmes. Même si les utilisateurs finaux voulaient installer une mise à jour, cette option n’était peut-être plus disponible, alors que changer de programme pourrait s’avérer plus difficile que prévu.
• Log4j est une bibliothèque open-source, ce qui signifie que les programmeurs peuvent la copier, la modifier et l’utiliser dans leurs projets. Malheureusement, certains développeurs ne respectent pas les règles d’accréditation et n’indiquent pas toujours le code de la paternité. En théorie, la même vulnérabilité pourrait être détectée dans un projet tiers même si, officiellement, il n’utilise pas Log4j.
• Log4Shell était une vulnérabilité de type zero-day, ce qui signifie que les cybercriminels pouvaient l’exploiter avant que des informations ne soient publiées à son sujet. Certaines preuves laissent entendre que les escrocs ont testé la faille pendant neuf jours avant de la rendre publique.
• Les produits VMware figurent parmi les victimes, notamment la solution de virtualisation des postes de travail VMware Horizon. Parmi les attaques enregistrées, beaucoup ont pu accéder au système via ce programme.
• Les mises à jour du logiciel auront peu d’effet si les intrus sont déjà dans le système. En aucun cas les attaques commencent immédiatement après la pénétration, et il est fort possible que de nombreux systèmes contiennent actuellement une porte dérobée.

Les dommages réels

En toute justice, il convient de souligner que, pour le moment, aucune conséquence catastrophique causée par l’exploitation de Log4Shell n’a été signalée. Du moins en ce qui concerne les cas publics. Cette vulnérabilité a tout de même été un véritable casse-tête pour les développeurs et les experts en sécurité, et a sûrement gâché les vacances de Noël de milliers d’informaticiens partout dans le monde. Les entreprises qui prennent la sécurité au sérieux, la leur et celle de leurs clients, ont dû débourser des sommes considérables afin de localiser la vulnérabilité dans leurs systèmes et dans leurs logiciels, et pour l’éliminer.

Vous trouverez ci-dessous certains des incidents Log4Shell les plus importants :

• Le 20 décembre 2021, le ministère de la Défense belge a confirmé une attaque qui exploitait cette vulnérabilité au sein de son infrastructure. Naturellement, les détails n’ont pas été partagés.
• Le 29 décembre 2021 des rapports médiatiques indiquaient qu’une certaine institution scientifique des États-Unis avait été attaquée via Log4Shell. Selon CrowdStrike, le groupe APT Aquatic Panda a exploité la version non corrigée du programme VMware Horizon. L’activité suspecte a été arrêtée à temps, mais cet incident montre que de grands groupes de cybercriminels exploitent la vulnérabilité.
• Toujours en décembre 2021, les médias parlaient d’une exploitation de Log4Shell dans les serveurs de Minecraft : Java Edition, un serveur qui n’est pas hébergé par l’éditeur du jeu (Microsoft). L’entreprise a confirmé l’information et a attiré l’attention sur la simplicité de l’attaque. Les cybercriminels ont partagé un code malveillant dans un chat habituel du jeu, ce qui a permis son exécution sur le serveur et sur le dispositif du client vulnérable. Ce cas est moins intéressant pour la victime mais l’est particulièrement en termes de mise en œuvre technique. Dans certaines conditions, une attaque peut être réalisée simplement via un chat interne. C’est inquiétant puisque les chats s’utilisent désormais au-delà du monde des jeux vidéo. Ils restent la méthode de communication de prédilection de nombreuses entreprises. C’est ce que les entreprises de technologie financière ou d’autres applications utilisent pour l’assistance client.
• En juin 2022, l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) et l’organisation américaine US Coast Guard Cyber Command (CGCYBER) ont émis une alerte indiquant que la vulnérabilité était encore activement exploitée. Le communiqué indiquait que les cybercriminels avaient utilisé une faille de VMware Horizon pour accéder aux réseaux internes de deux organismes gouvernementaux. De plus, les cybercriminels auraient eu accès à 130 GB de données sensibles relatives aux forces de l’ordre.
• En novembre 2022, la CISA et le FBI ont émis une autre alerte à propos d’une attaque Log4Shell qui visait un autre organisme gouvernemental. Les cybercriminels avaient eu accès au système en février, avaient été détectés en avril et avaient été actifs jusqu’en juin-juillet. Pendant ce temps, ils avaient créé un compte avec des privilèges administrateur, avaient modifié le mot de passe d’un administrateur légitime et avaient téléchargé un logiciel de minage sur le serveur. Il semblerait que l’attaque soit l’œuvre de cybercriminels parrainés par le gouvernement iranien. C’est pourquoi certains experts pensent que le minage n’est qu’une couverture utilisée pour dissimuler leurs intentions.

Comment protéger votre infrastructure

N’importe quelle entreprise peut être victime de Log4Shell, et c’est souvent simplement parce qu’elle ne sait pas que ses systèmes ou ses programmes sont vulnérables. Si vous ne savez pas si vos systèmes, vos outils, vos produits ou vos services se servent de la bibliothèque Log4j, il convient de réaliser un [security assessment services placeholder]audit de sécurité approfondi[/security assessment services placeholder]. En plus de ça, nous vous invitons à suivre les conseils de nos experts pour vous protéger.

• Si le programme que vous développez utilise Log4j, utilisez la dernière version de la bibliothèque disponible sur la page du projet.
• Lisez le guide officiel Apache Logging Services et suivez les indications, le cas échéant.
• Si des produits tiers utilisent Log4j, mettez à jour tous les logiciels vulnérables.
• Installez des solutions de sécurité robustes et capables de détecter les tentatives d’exploitation des vulnérabilités sur les serveurs et sur les postes de travail.
• Surveillez l’activité suspecte au sein du périmètre de votre entreprise un utilisant des solutions de type EDR ou des services externes comme ceux de détection et de réponse gérés. Cela vous permet de détecter et d’éliminer les attaques à un stade précoce.