Au début du mois, des chercheurs en sécurité ont découvert une série de vulnérabilités majeures dans le logiciel Java Log4j, utilisé dans des dizaines de milliers d'applications Web. Ce code est très répandu, autant dans les systèmes grand public que ceux des entreprises : la palette va de Minecraft, Steam et iCloud aux systèmes Fortinet et Red Hat. Selon un analyste, des millions de points de terminaison pourraient être à risque. Après SolarWinds (dont le processus de build était compromis) et Kaseya (où les attaquants avaient substitué un code contenant des logiciels malveillants), Log4j est la dernière des attaques ciblant la chaîne d'approvisionnement des logiciels. Depuis que la première vulnérabilité de Log4j a été révélée, les fournisseurs et les analystes de sécurité ont publié de nombreuses informations sur la marche à suivre, assorties de scénarios aux conséquences plus ou moins chaotiques. Check Point Software Technologies a constaté que près de la moitié de sa clientèle faisait l’objet de tentatives d'exploitation. Et Contrast Security a découvert que 58 % des applications Java comportaient des versions vulnérables, mais que seulement 37 % d'entre elles utilisaient effectivement Log4j.

Les quatre vulnérabilités en question sont identifiées par les références CVE suivantes : CVE-2021-44228, CVE-2021-45046, CVE-2021-4104 et CVE-2021-45105. L'Agence américaine de cybersécurité et de sécurité des infrastructures (US Cybersecurity and Infrastructure Security Agency, CISA) a ouvert une page web spécifique avec des liens vers les blogs de divers fournisseurs, une liste des applications affectées qu’elle essaie de maintenir à jour avec les corrections éventuelles. Les problèmes concernent plusieurs fonctionnalités du logiciel de journalisation, notamment l'interface Java Naming and Directory Interface (JDNI) et les messages d'événement JMSAppender, qui permettent tous deux l'exécution de code à distance. Cette série de vulnérabilités est dangereuse parce que les attaquants n'ont pas besoin d’être très aguerris pour gagner cet accès à distance. La dernière vulnérabilité fait référence à un déni de service, ce qui maintient tout le monde sur le qui-vive. De plus, tout récemment, Blumira a trouvé un nouveau vecteur d'attaque qui élargit la surface globale en utilisant les WebSockets. Ce qui laisse à penser que Log4j devrait mobiliser les équipes de sécurité pendant un certain temps encore. Ce qui est clair, c'est que les développeurs d'applications vont devoir redoubler d’efforts pour trouver, corriger et prévenir les problèmes liés à Log4j à court terme, et qu’ils ont du souci à se faire à plus long terme.

Le risque est déjà là 

Avant de commencer à verrouiller les choses, Ariel Parnes, COO de Mitiga, conseille aux entreprises de vérifier si elles ont été piratées via Log4j dans le passé. « Les pirates sont peut-être déjà dans vos systèmes », prévient-il. Quant à John Cronin, responsable informatique de Matrix IT, il pose plusieurs questions importantes : « Savez-vous lesquels de vos serveurs utilisent Log4j ? Combien de temps vous faudra-t-il pour produire cette liste de serveurs ? Pouvez-vous les corriger instantanément ? Disposez-vous d'outils automatisés ou quelqu'un doit-il se connecter à chaque serveur et le faire manuellement ? Avez-vous mis en place un processus pour corriger les serveurs de production en live pendant les périodes d'utilisation intensive ? » Répondre à ces questions demande sûrement un certain effort. Un article précédent expliquait ce qu'il fallait faire pour détecter une infection. Les analystes de sécurité ont trouvé des exploits remontant au 1er décembre 2021. Ils ont aussi constaté qu’ils avaient utilisé des protocoles réseau très divers, notamment LDAP, RMI, DNS et HTTP. De plus, ces exploits ont installé plusieurs malwares, en particulier des mineurs de cryptomonnaies cachés, une nouvelle famille de ransomware baptisée Khonsari par Bitdefender, et du code pour rejoindre le botnet Mirai. Et pour couronner le tout, plusieurs chercheurs ont signalé des exploits provenant d'attaquants parrainés par des États : Chine, Corée du Nord, Turquie et Iran. 

Un plan de défense immédiat 

La première ligne de défense consiste à mettre à niveau vers les versions les plus récentes de Log4j. Dans un premier temps, Apache avait publié un correctif comportant encore des vulnérabilités. Les versions les plus récentes sont Log4j v.2.17.0, si l’on utilise Java 8 ou une version ultérieure, et Log4j v.2.12.2, si l’on utilise Java 7 dans son infrastructure d'applications Web. Ces versions désactivent l’interface Java Naming and Directory Interface (JNDI) par défaut et suppriment l'accès à la consultation des messages, deux éléments essentiels à l’exploitation des diverses vulnérabilités. La désactivation de JNDI peut déstabiliser une fonction dans les applications, il est donc fortement conseillé de la tester soigneusement avant de l'implémenter dans un système de production. On pourrait aussi être tenté de stopper toute journalisation basée sur Java si l’une de ses applications peut s’en passer. Mais encore une fois, mieux vaut faire un test avant de le déployer. Quant à ceux qui exploitent leur propre serveur Minecraft, ils doivent vérifier s'ils utilisent Minecraft v.1.8.8 ou une version ultérieure, car ces versions sont vulnérables. Microsoft a publié une mise à jour Minecraft v.1.18.1, qui corrige le problème. Il faut mettre à niveau immédiatement ou trouver un autre serveur plus fiable qui a été corrigé.

Des outils de détection disponibles 

Les fournisseurs de solutions de sécurité ont travaillé dur pour améliorer leurs outils, et c’est le moment de profiter de diverses offres gratuites. Voici une sélection de scanners pouvant servir à localiser le code vulnérable dans les applications en cours d'exécution ou dans les fichiers sources. Il faut aussi chercher si ce code a été déployé dans une instance de production. 

- Qualys propose une version d'essai gratuite de 30 jours de son scanner d'applications Web et explique comment l’utiliser sur son blog. 

- Check Point propose également son scanner CloudGuard AppSec avec un essai gratuit de 30 jours. 

- Le CERT a développé plusieurs scanners d’applications web pour Windows, Python et Bash. 

- Pour les utilisateurs de Burp Suite, X-Force d'IBM dispose d’un scanner gratuit et SilentSignal et propose un plug-in dédié. 

- WhiteSource pousse un scanner gratuit. 

- JFrog met à disposition un outil d'analyse gratuit basé sur Python appelé Xray pour examiner ses propres bibliothèques de code Java. 

- Voici la marche à suivre pour les utilisateurs de Semgrep. 

- Orca Security a lancé un outil en ligne gratuit pour analyser les environnements AWS, Azure et Google Cloud, et un essai de 30 jours de sa plateforme. 

Améliorer la sécurité du code à long terme  

Tout d’abord, il faut bien comprendre les dépendances du code. L'un des défis posés par Log4j, c’est qu’il est très répandu et qu’il est utilisé dans de nombreuses bibliothèques Java. Une fois les anciennes versions supprimées de son propre code, il faut chercher si un autre code en dépend. Si l’on utilise les frameworks Apache Struts2, Flume, Dubbo, Kafka, Solr, Druid ou Fink, il faudra mettre à jour les bibliothèques Log4j dans ces projets. Les utilisateurs de Struts doivent savoir qu'en 2017, un exploit a conduit à la compromission des bases de données d'Equifax et à la fuite des données privées de plus de 140 millions de clients. Tanya Janca, de WeHackPurple (une excellente source sur la sécurité des applications en général), suggère d'utiliser dependencyGraph, Snyk ou Dependency-Check de l'Open Web Application Security Project (OWASP), une communauté impliquée dans la sécurité des applications Web. Pour chaque dépendance identifiée, il est important de commenter le code appelant Log4j au cas où il n’est pas possible de le corriger immédiatement. 

Il faut aussi bien comprendre le fonctionnement des pares-feux d'applications Web (Web Application Firewall, WAF). Si vous n'avez pas de WAF, c'est le moment d'en acquérir un. Si une partie de votre code est déployée derrière un WAF, activez ses règles de détection et vérifiez si le fournisseur a mis à jour ses règles pour couvrir toutes les dernières vulnérabilités. Mais sachez que depuis l'annonce de la faille, les chercheurs ont montré qu’il était possible de construire des charges utiles imbriquées et obfusquées pouvant contourner les règles de filtrage WAF proposées. Le fournisseur Fastly explique en détail dans un document comment tester l'efficacité du WAF. 

Enfin, il existe des outils de correction et d'atténuation des vulnérabilités de Log4j. Plusieurs entreprises ont déjà fourni des outils d'atténuation pour Log4j : 

- Cybereason a créé ce code. LunaSec l'a encore amélioré et l'a hébergé sur un serveur live accessible au public. 

- L'équipe Corretto d'Amazon Web Services a développé un agent Java destiné à corriger Log4j. Cet agent est disponible sur GitHub.

- Contrast Security propose SafeLog4j, qui permet à la fois de détecter et de corriger les failles. Il est également censé fonctionner contre les attaques de contournement du WAF. 

- Cisco propose un essai gratuit de 30 jours de Secure Endpoint. D'autres fournisseurs de points de terminaison ont inclus des règles de détection, notamment Microsoft Defender (mais pour l'instant uniquement les versions Windows). 

- Si vous utilisez des conteneurs, vous aurez besoin de produits de protection spécialisés. Par exemple, Red Hat a mis à jour Advanced Cluster Security for Kubernetes et Palo Alto Networks a mis à jour Prisma Cloud.