La vulnérabilité Log4shell expliquée

 

La vulnérabilité Log4J est apparue en décembre 2021, exposant des centaines de milliers de systèmes à des attaques. Plus d'un an plus tard, voici où nous en sommes.En décembre 2021, l’une des vulnérabilités zero-day les plus graves de l’industrie technologique a été découverte : Log4j. 

Qu’est-ce qu’une vulnérabilité zero-day exactement ? Un zéro-day est défini comme une vulnérabilité qui a été divulguée mais qui n’a pas de correctif ou de correctif de sécurité correspondant. Cela met en danger tous les systèmes et applications où la vulnérabilité est présente en raison du manque de correction de la faiblesse. Nous pouvons comparer cela à un scénario dans lequel le mécanisme de verrouillage des portes de votre voiture cesse de fonctionner, mais le concessionnaire automobile n’a aucun moyen de résoudre le problème. Cela expose votre voiture à un risque de vol puisque vous n’avez pas la possibilité de verrouiller les portes.

Log4j a été découvert le 9 décembre 2021, obligeant de nombreux professionnels de la cybersécurité à travailler plus de 40 heures par semaine jusqu'à la fin de l'année pour évaluer leurs environnements et coordonner les efforts de remédiation au sein de leurs organisations. C’est aussi une question qui a amené de nombreuses autres personnes à se demander : « Quel est le problème ? De nouveaux zéro-day sont publiés chaque semaine, alors pourquoi celui-ci est-il si mauvais ? »

Même si cette vulnérabilité semblait similaire à de nombreux Zero Days en raison de sa facilité d’exploitation et de l’absence d’authentification requise pour réaliser l’exploit, elle était très préoccupante en raison du nombre de systèmes et de logiciels concernés. 

Qu’est-ce que Log4j ?

Log4j est un framework de journalisation open source maintenu par Apache. Il est utilisé pour enregistrer les messages dans le logiciel et a la capacité de communiquer avec d’autres services sur un système. C'est dans cette fonctionnalité de communication que la vulnérabilité existe, offrant à un attaquant la possibilité d'injecter du code malveillant dans les journaux afin qu'il puisse être exécuté sur le système. Après sa découverte, les chercheurs en sécurité ont constaté des millions de tentatives d’exploitation, dont beaucoup se sont transformées en attaques par déni de service (DoS).

Apache est une fondation logicielle. log4j s'agit d'un utilitaire basé sur Java, ce qui en fait un service populaire utilisé sur les systèmes et applications basés sur Java. Lorsque le Zero Day de Log4j a été révélé, les organisations se sont efforcées de comprendre quel impact cela pourrait avoir sur elles.

En quelques jours, des experts en cybersécurité ont collaboré pour commencer à dresser une liste des logiciels affectés par la vulnérabilité Log4j ainsi que de ceux qui ne l’étaient pas. Bien que cette liste ait aidé les entreprises à mieux évaluer leurs environnements pour détecter les systèmes et applications concernés, les équipes de sécurité sont restées des cibles faciles pendant quelques jours, à la merci des fournisseurs de technologie, attendant qu'ils produisent des correctifs de sécurité qui remédieraient à la faille. En conséquence, les organisations ont été invitées à supprimer tous les systèmes connectés à Internet et non critiques pour empêcher leur exploitation, pendant que les équipes de sécurité attendaient la publication de ces mises à jour du système.

Il n’est pas surprenant qu’après sa découverte, les chercheurs en sécurité aient constaté des millions de tentatives d’exploitation, dont beaucoup se sont transformées en attaques par déni de service (DoS). Il n’a pas fallu longtemps non plus pour qu’une nouvelle variante de ransomware exploitant cet exploit soit développée. C’est la principale raison pour laquelle les équipes de sécurité se sont empressées de mettre hors ligne bon nombre de leurs systèmes touchés par ce Zero Day. Laisser exposé un système ou une application jugée vulnérable revenait à jouer à la roulette.

En raison de la gravité évidente et de la publicité autour de ce jour zéro particulier, les fournisseurs n'ont pas tardé à publier des correctifs de sécurité et les correctifs ont commencé. Malheureusement pour de nombreuses équipes informatiques et de sécurité, ce projet massif s'est produit juste pendant les vacances, dans les dernières semaines de décembre.

Comment fonctionne l'exploit Log4j ?

Comme mentionné précédemment, les experts en cybersécurité ont considéré l'exploit Log4j comme critique en raison de sa facilité d'exploitation et du fait qu'aucune authentification n'était requise pour l'exécuter. Ajoutez à cela la prévalence de la vulnérabilité des systèmes destinés au public et vous obtenez une source de préoccupation majeure.

Log4j est utilisé pour enregistrer les messages dans un logiciel et a la capacité de communiquer avec d'autres services sur un système. C'est dans cette fonctionnalité de communication que la vulnérabilité existe, offrant à un attaquant la possibilité d'injecter du code malveillant dans les journaux afin qu'il puisse être exécuté sur le système.

La vulnérabilité a été découverte pour la première fois dans une version du jeu Minecraft. Des individus malveillants ont appris que le chat du jeu était enregistré à l'aide de Log4j et, s'ils saisissaient du code malveillant dans le chat, cela entraînait une exécution de code à distance (RCE). L'exécution de code à distance est un type de cyberattaque qui permet à un individu d'exécuter du code sur un système backend, à distance.

Suite à cette découverte, un monde d’opportunités s’est ouvert alors que les pirates informatiques et les chercheurs en sécurité ont commencé à tester jusqu’où ils pouvaient pousser cette faille potentielle. C’est ainsi qu’a commencé l’activité d’analyse massive du réseau nécessaire pour trouver les systèmes potentiellement vulnérables, puis effectuer des POC (preuve de concept) de l’exploit.

Il n’a pas fallu longtemps pour que le code POC officiel fasse surface sur GitHub, une communauté de codage open source où les membres peuvent partager et collaborer sur des projets de codage. La communauté du logiciel l'utilise pour développer des programmes. Pour les experts en cybersécurité, cependant, il est utilisé pour partager des scripts et des programmes liés à la sécurisation ou à l’exploitation de divers systèmes ou vulnérabilités. Cela inclut le code POC, ou code d'exploitation, généralement accompagné d'instructions, qui explique comment exploiter une vulnérabilité spécifique.
Dans le cas de Log4j, un utilisateur de GitHub a publié un POC Log4j pour l'exécution de code à distance LDAP (Lightweight Directory Access Protocol). Si vous vous en souvenez, les attaques RCE entraînent l'exécution de code malveillant sur un système distant et l'exploit exploite le service LDAP, qui est un protocole utilisé pour l'authentification des services d'annuaire multiplateformes. En termes plus simples, c'est ce qui permet de rechercher et d'utiliser un répertoire distant (généralement Microsoft Active Directory) à des fins d'authentification auprès d'un service interne.

Pour réaliser l'exploit à l'aide du code POC populaire sur GitHub, tout ce qu'un attaquant a à faire est d'exécuter le script fourni sur son système pour déployer un serveur HTTP et un faux serveur LDAP, puis d'injecter la charge utile malveillante spécialement conçue dans un champ de texte sur une plateforme vulnérable. . Cela peut se faire dans le cadre d'une discussion, comme dans l'exploit Minecraft, ou simplement en collant la commande dans le champ du nom d'utilisateur d'un formulaire de connexion avec un mot de passe aléatoire.

Vous vous demandez peut-être : « Quelle est la particularité de la charge utile conçue ? » La charge utile est en fin de compte ce qui exploite la vulnérabilité Log4j. Pour ce faire, il utilise JNDI, Java Naming and Directory Interface, une fonctionnalité qui permet à un utilisateur de récupérer et de charger des objets Java à partir d'un serveur. Bien qu'il s'agisse d'une fonctionnalité sécurisée, la faille Log4j permet à un attaquant d'entrer ses propres recherches JNDI, où il dirige ensuite le serveur vers son faux serveur LDAP. À partir de là, l’attaquant contrôle désormais le système distant et peut exécuter des logiciels malveillants, exfiltrer des informations sensibles telles que des mots de passe, etc.

L’exploit Log4j peut-il être corrigé ?

La vulnérabilité Zero Day de Log4j a pris d’assaut le monde de la cybersécurité. De nombreux experts du secteur, outre la directrice du CISA, Jen Easterly, ont affirmé qu’ils n’avaient jamais rien vu de pareil au cours de leur carrière. Si vous demandez à n’importe quel professionnel de la sécurité ayant travaillé pour une grande entreprise lorsque la vulnérabilité Log4j a été révélée pour la première fois, il vous racontera probablement les heures passées à travailler avec diverses équipes informatiques pour évaluer et répondre à l’actualité afin de protéger le réseau de leur organisation.

De nombreuses équipes de sécurité ont passé des journées entières à évaluer les vulnérabilités, puis à identifier les systèmes qui devraient être coupés du World Wide Web. Ce type d’activité ayant un impact direct sur les opérations de l’entreprise, les décisions ont nécessité l’implication de divers hauts responsables du département informatique et ont impacté les fonctions de l’entreprise, tandis que les responsables de la sécurité ont fait de leur mieux pour relayer la gravité de la situation afin d’éviter une cyberattaque.

Depuis décembre, la plupart des fournisseurs ont publié des mises à jour de sécurité qui corrigent la faille Log4j dans leurs applications, et Apache lui-même a publié des correctifs et des versions mises à jour qui corrigent la vulnérabilité. Cela étant dit, des milliers de systèmes sont encore vulnérables En avril 2022, la société de cybersécurité Rezilion affirmait que plus de 68 000 systèmes accessibles au public étaient encore menacés. À ce stade, beaucoup d’entre nous se demandent si les organisations qui possèdent ces systèmes savent même qu’ils existent. Une chose est sûre cependant : ils le sauront une fois que l’un d’entre eux sera exploité.