Log4Shell : la faille de sécurité qui secoue Internet
Une faille de sécurité critique a été découverte au sein de la bibliothèque de journalisation Apache Log4j. Baptisée "Log4Shell" est extrêmement dangereuse puisqu'elle permet d'exécuter du code à distance sans authentification et de façon très simple !
La vulnérabilité Log4Shell (appelée aussi Javageddon), identifiée avec la référence CVE-2021-44228, bénéficie d'une note maximale de 10/10, ce qui est une preuve de sa dangerosité. D'ailleurs, vendredi dernier le CERT-FR a publié une alerte à son sujet.
La bibliothèque de journalisation Apache Log4j est utilisée par Java donc on l'a retrouve sur de très nombreuses plateformes dont Tomcat, et au sein de beaucoup d'entreprises y compris des géants de l'Internet et de l'industrie. En effet, parmi les entreprises vulnérables, on peut trouver Apple, Steam, Twitter, Amazon, Tesla, Minecraft, VMware, Webex, etc... Preuve que cette bibliothèque est très populaire (voir ce lien). Clairement, c'est la panique !
Log4Shell : une énorme menace !
Imaginez un site Internet, avec un formulaire (par exemple) et derrière un serveur Web où la bibliothèque Log4j est utilisée. À partir de là, l'attaquant peut exécuter une simple requête sur le serveur Web en intégrant une chaîne de caractères spécifiques. Lorsque cette chaîne de caractères sera traitée par Log4j (au moment de journaliser la requête), il va exécuter la requête malveillante envoyée par l'attaquant. Résultat, un malware peut être installé sur le serveur ciblé.
Si l'on regarde les statistiques de CloudFlare, on peut voir qu'il y a énormément d'attaques en cours (et bloquées par leur système) :
Par mesure de sécurité, certains préfèrent mettre le site hors ligne, c'est notamment le cas au Québec où près de 4 000 sites et services gouvernementaux ont été mis hors ligne par sécurité.
À propos de cette faille, il faut savoir une chose : ce n'est pas parce que vous n'utilisez pas Java que vous n'êtes pas vulnérable. En effet, de nombreux frameworks s'appuient sur cette bibliothèque donc elle peut être utilisée par ce biais. C'est le cas de Flink, Druid ou encore Apache Struts2. Même la NSA utilise un framework qui intègre cette bibliothèque, au sein de son outil GHIDRA comme le rapport Rob Joyce, directeur de la cybersécurité au sein de la NSA.
Quant à la date de détection de cette faille de sécurité, c'est un peu flou. L'équipe de sécurité d'Alibaba Cloud aurait notifié cette faille de sécurité à Apache le 24 novembre 2021. Néanmoins, certaines personnes évoquent l'utilisation de cette faille de sécurité lors de l'événement BlackHat USA de 2016.
Comment se protéger de la vulnérabilité Log4Shell ?
Pour faire simple, toutes les versions de Log4J sont concernées par cette faille de sécurité ! Enfin, presque car la version 2.15.0 qui vient de sortir corrige cette faille justement !
Se mettre à jour, c'est facile à dire, mais pas toujours simple à appliquer : tout dépend aussi de la version dans laquelle on se situe actuellement. Même si la mise à jour est fortement recommandée (et dès que possible), il existe quelques solutions alternatives.
Voici ce que nous dit le CERT-FR à ce sujet :
- Log4j versions 2.7.0 et ultérieures : "il est possible de se prémunir contre toute attaque en modifiant le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur. Cette modification impose de modifier le fichier de configuration de log4j pour produire une nouvelle version de l'application. Cela requiert donc d'effectuer de nouveau les étapes de validation technique et fonctionnelle avant le déploiement de cette nouvelle version."
Mais aussi :
- Log4j version 2.10.0 et ultérieures : "il est également possible de se prémunir contre toute attaque en modifiant le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true, par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true. Une autre alternative consiste à supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque)."
Il existe une petite subtilité au sujet de la version 1.X de Log4j. En effet, elle est vulnérable seulement si le composant JMS Appender est configuré pour prendre en compte JNDI. Autrement dit, cette version est vulnérable seulement avec des configurations spécifiques.
Note : si vous utilisez CrowdSec, sachez qu'un scénario de détection pour Log4Shell existe et qu'il est présent au sein de la collection "http-cve" (que vous devez mettre à jour si vous l'utilisez déjà).
Pour tester votre application, vous pouvez utiliser ce site Web : CanaryTokens.org
