Difficile de passer à côté de l’évènement de cette fin d’année ! On oublierait presque que la Covid19 est encore en progression… Il s’agit bien sûr de la faille dans Log4j. Ce terme, sûrement inconnu de beaucoup de non-développeurs il y a encore une semaine, est maintenant dans toutes les conversations, et c’est bien normal.
Je vous invite à faire le test suivant : chercher le mot « log4j » à la racine de votre disque dur d’ordinateur, vous serez surpris !
Rappel des faits de la faille Log4j
Une alerte a été publiée vendredi 10 décembre concernant la bibliothèque Log4j, utilitaire de journalisation très répandu sur tous les systèmes Java. C’est-à-dire une grande majorité des applications sur Internet. La vulnérabilité CVE-2021-44228 baptisée Log4Shell avait été repérée dès fin novembre. En effet, un chercheur du groupe chinois Alibaba a alerté la fondation Apache, distributeur de l’utilitaire Log4j, de problèmes de sécurité.
L’information a circulé jusqu’au 10 décembre où un chercheur en sécurité informatique a publié sur son site Github la manière d’exploiter cette vulnérabilité. La page a depuis été supprimée, mais le mal est fait. L’utilisation de la faille se répand de manière fulgurante et des alertes sont lancées en série par les différents organismes de sécurité informatique sur le danger encouru.
En pratique, la faille permet d’exécuter du code arbitraire à distance, sans besoin d’être authentifié. Il suffit pour cela d’un simple formulaire sur le site Web que vous remplissez avec des chaînes de caractères bien spécifiques. Ces éléments de formulaire sont alors logués et exécutés sur les serveurs par la librairie log4j. Ceci ouvrant la porte à l’intrusion de code malveillant sur le système visé.
Les correctifs identifiés
L’alerte est mondiale et prise très au sérieux. La note maximale de 10/10 lui est d’ailleurs attribuée en termes de dangerosité. Les tentatives de mise en œuvre enregistrées grimpent en flèche. La réaction des principaux acteurs d’Internet est rapide et les patchs correctifs sont communiqués.
Selon les versions de la librairie, la démarche suivre peut-être différente sans avoir besoin de mettre à jour la version :
- Versions 2.7.0 et supérieures : une possibilité est de modifier dans le code de l’application le format des évènements journalisés par la librairie avec la syntaxe %m{nolookups} pour tout texte saisi par un utilisateur dans un formulaire. Ceci nécessite donc de modifier du code existant, le tester, le redéployer.
- Versions 2.10.0 et supérieures : plusieurs solutions existent. La première consiste à modifier un paramètre dans un fichier de configuration. Positionner log4j2.formatMsgNoLookups à la valeur true et redémarrer l’environnement Java est efficace. Il est aussi possible de supprimer la classe JndiLookup du classpath. Cette dernière méthode est également efficace pour les versions de Log4j plus anciennes.
- Versions 1.X : ces versions sont moins exposées et la faille n’est possible que dans une configuration très particulière de la librairie.
Bien sûr, la meilleure méthode est toujours d’être le plus à jour possible dans les versions des librairies. La toute dernière de Log4j incluant maintenant les corrections nécessaires pour pallier cette faille. C’est d’ailleurs le message qui est en train d’être diffusé au moment de la rédaction de ces lignes. En effet, les analyses de la librairie continuent et il reste encore des incertitudes sur de potentielles exploitations de la faille mal identifiées dans les anciennes versions (jusqu’à la version 2.15).
La difficulté pour les petites et moyennes entreprises
Il est intéressant de voir avec cette crise de fin d’année comment la réponse à une menace a été traitée en un temps tout de même assez court. C’est derrière nous diront certains et nous passerons de bonnes fêtes de fin d’année. Apple, Microsoft, Amazon etc. ont déjà patché, migré, remplacé tous les bouts de code ou librairies en cause. Et cela en quelques heures ou jours. Mais quid des plus petits, qui constituent finalement la grande majorité ? Ce ne sera peut-être pas aussi simple.
Depuis le début de la crise, nous avons mis en œuvre chez Mind7 Consulting les mesures nécessaires pour assurer à nos clients et aussi à nos consultants que tout se passera bien. En effet, nous avons notamment mis en place l’inventaire en interne et en externe des ressources, en prenant en compte les logiciels sur étagère, le code spécifique, les équipements ou encore l’application des mesures de barrage. Selon les cas, il peut y avoir également des modifications de configuration ou une mise à jour de librairies.
Cet exercice nous a rassuré sur notre compétence à réagir vite et en conséquence à ce type d’évènement. Cela n’est pas sans effort préalable sur notre stratégie de développement.
Et pour aller plus loin, je peux en discuter avec vous !
Depuis plus de 15 ans maintenant, je travaille sur des sujets liés à la BI et à l’amélioration des processus. J’ai participé à un grand nombre de projets en tant que leader technique sur de nombreuses technologies.
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour échanger !
