Ces dernières semaines, les médias ont beaucoup parlé de Log4Shell, la vulnérabilité de Log4j.
Même si vous ne travaillez pas dans le domaine de la sécurité ou de l’informatique, vous avez peut-être regardé des reportages sur cette vulnérabilité, ou informé via les médias sociaux des informations désignant Log4Shell comme une entité qui s’attaque aux équipes de sécurité informatique vulnérables.
Mais quelle est exactement cette vulnérabilité et qui est-elle susceptible d’affecter ?
Log4Shell, explication !
Log4j est un “loggin framework” basé sur Java qui est intégré dans Apache Web Servers partout dans le monde.
Log4j, comme tous les logiciels distribués par l’Apache Software Foundation, est un logiciel libre (Open-source).
La “Foundation” indique qu’il a été distribué via un “mirror system” pendant de nombreuses années, puis plus récemment, la livraison est passée à un réseau de diffusion de contenu (CDN), qui l’envoie directement aux utilisateurs et aux développeurs.
Il est également livré directement aux organisations, qui le transmettent ensuite aux clients et aux entreprises dans le cadre de leurs projets, produits ou services.
En d’autres termes, Log4j est un logiciel utilisé dans le monde entier et son utilisation est également omniprésente.
Le produit qui en résulte peut être vendu et se retrouver n’importe où ex: une salle de réunion, une maison, …etc..
C’est là que réside le problème!
Qui a découvert la vulnérabilité de Log4j ?
Dans l’après-midi du 24 novembre, pendant les vacances de Thanksgiving aux États-Unis, Chen Zhaojun, ingénieur en sécurité chez Alibaba, a découvert et divulgué en privé à l’Apache Software Foundation les détails d’une faille d’exécution de code à distance facile à exploiter dans l’utilitaire Log4j 2.x, en particulier les versions 2.14.1 et antérieures.
“Je veux signaler un bogue de sécurité”, a écrit Zhaojun, membre de l’équipe chargée de la sécurité du cloud d’Alibaba Group Holding Ltd. en Chine, ajoutant que “la vulnérabilité a un impact majeur.” Comme il s’est avéré,…, ce n’était pas exagéré!
La base de données nationale des vulnérabilités maintenue par le NIST (National Institute of Standards and Technology) a signalé la vulnérabilité (CVE-2021-44228) le 10 décembre, indiquant dans son avis :
“Les fonctionnalités JNDI d’Apache Log4j2 2.0-beta9 à 2.12.1 et 2.13.0 à 2.15.0 utilisées dans la configuration, messages log et paramètres ne protègent pas contre les attackers-controlled LDAP et autres endpoints liés à JNDI.
Un attaquant qui peut contrôler les messages de log ou les paramètres des messages log peut exécuter du code arbitraire chargé à partir de serveurs LDAP lorsque la substitution de recherche de message est activée.”
Combien de personnes sont touchées par la vulnérabilité de Log4j ?
L’Apache Software Foundation a déclaré dans un blog publié le 14 décembre qu’elle ne se risquerait même pas à deviner l’ampleur de l’impact de cette vulnérabilité :
“Nous savons que Log4j est inclus dans un certain nombre de projets ASF, d’autres projets open source, et un certain nombre de produits et services. Mais au-delà, tout chiffre avancé, ne serait que spéculation et très probablement faux à plus grande échelle.”
Le problème auquel le monde de l’informatique est confronté aujourd’hui, alors que de nombreuses équipes et personnel de centres d’opérations de sécurité (SOC) sans doute déjà en congé pour cette période de l’année, est que la bibliothèque Log4j est utilisée par de très nombreux services Apache framework.
Le corriger à l’échelle mondiale reviendrait à demander à tous les propriétaires d’une certaine marque de voiture de vérifier personnellement si une pièce du moteur potentiellement défectueuse ne se cache pas quelque part sous le capot, puis à leur demander de la remplacer eux-mêmes.
Les utilisateurs d’Apache n’ont pas la possibilité d’amener leurs serveurs chez le concessionnaire pour un rappel de pièces, si l’on poursuit cette analogie.
Pour faire court, un composant d’application vulnérable, comme Log4j, crée un risque de sécurité complexe qui ne peut être résolu par une simple mise à jour.
De nombreuses entreprises se démènent encore pour publier leurs propres correctifs internes afin d’empêcher l’exploitation de la vulnérabilité Log4j.
Comment CVE-2021-44228 est-il exploité ?
Pour ceux qui ne le savent pas, l’exploitation de la faille Log4j consiste simplement pour l’attaquant à envoyer un texte spécialement conçu à une application vulnérable.
L’envoi d’une séquence particulière de caractères demande à la bibliothèque Log4j d’extraire du code JAVA d’un serveur distant, ce qui ouvre la porte en grand aux cybercriminels pour accéder aux systèmes ciblés.
C’est ce qui rend cette vulnérabilité si critique.
La facilité relative de l’exploitation signifie que même un attaquant novice pourrait prendre le contrôle à distance de systèmes, allant des appareils de l’Internet des objets (IoT) aux systèmes critiques connectés à l’entreprise et effectuer des actions aussi simples (et désastreuses) tel que d’espionner son voisin à travers les caméras de sécurité de sa maison, ou de causer des ravages dans un pays ou même à l’international par le biais d’un sabotage massif des infrastructures.
Un tel attaquant n’a pas besoin d’une formation en génie logiciel, il lui suffit d’écrire (ou de copier) une ligne de code pour accéder à l’appareil de son choix.
Un autre problème majeur auquel sont confrontées la plupart des organisations est de savoir quelles applications utilisent Log4j et à quel point la bibliothèque est intégrée dans leurs produits.
Une simple application autonome utilisant la bibliothèque Log4j peut être facile à corriger.
Cependant, il faut tenir compte de la complexité de la correction d’une application construite sur d’autres, comme un château de cartes, où la bibliothèque vulnérable se trouve à six niveaux de la chaîne de dépendances.
Corriger une faille de sécurité profondément ancrée peut être une tâche monumentale, même pour les organisations qui sont bien équipées et conscientes du problème.
Malheureusement, Log4j est une bibliothèque si populaire que de nombreuses entreprises utilisent peut-être les produits concernés sans se rendre compte qu’ils sont susceptibles d’être attaqués.
À quoi ressemble une attaque de Log4Shell ?
Les cybercriminels travaillent maintenant jour et nuit pour profiter de la vulnérabilité aussi vite que possible, avant que les organisations ne se rendent compte qu’elles sont touchées.
Le niveau d’activité suggère une mentalité de “Gold Rush”, saisissant l’occasion de détourner les applications pour exécuter des codes à distance (RCE).
Bien souvent, l’objectif est de prendre pied dans l’entreprise et de se livrer à d’autres activités telles que le vol de propriété intellectuelle, le cryptomining, le déploiement de ransomwares, les attaques DDoS, ou toutes autres activités semblables.
Pour réussir, du point de vue du cybercriminel, il faut charger puis exécuter un logiciel malveillant dans l’environnement cible.
Même un logiciel malveillant de base peut exercer un large éventail d’activités malveillantes sur l’appareil de la victime, qu’il s’agisse de voler des informations bancaires, de verrouiller des systèmes et d’exiger une rançon pour les décrypter, ou d’exfiltrer des informations hautement confidentielles, telles que celles détenues par des systèmes médicaux, financiers ou gouvernementaux.
Les chercheurs en sécurité ont constaté que les acteurs de la menace ont lancé une activité d’analyse massive quelques heures après que la vulnérabilité a été signalée publiquement pour la première fois.
Au départ, les premières attaques étaient de nature exploratoire et étaient principalement axées sur le cryptomining.
Au 9 décembre, l’exploitation active et généralisée de la vulnérabilité Log4j avait été identifiée dans la nature par de nombreuses sources externes.
Microsoft a depuis confirmé l’activité d’un nation-state par des acteurs de la menace en Chine, en Iran, en Corée du Nord et en Turquie.
En outre, les chercheurs de SecurityScorecard affirment avoir constaté l’activité d’un nation-state en Russie, ainsi que des preuves de la présence du malware Dovorub, une boîte à outils liée à APT28.
Chaque jour, de nouveaux rapports révèlent la distribution de familles de logiciels malveillants via la vulnérabilité Log4j, alors que les acteurs de la menace tentent continuellement d’exploiter cette vulnérabilité.
Par exemple, le 12 décembre, Check Point, un fournisseur de solutions de cybersécurité pour les gouvernements et les entreprises, a déclaré qu’il voyait environ 100 tentatives d’exploitation par minute, en donnant plus de détails dans un blog.
La société a également identifié plus de 2,8 millions de tentatives d’exploitation de Log4j, précisant que 46 % des cyberattaques provenaient de groupes de hackers connus.
Jim Simpson, directeur des renseignements sur les menaces chez BlackBerry, a déclaré :
“Comme nous l’avons vu à maintes reprises, les hackers d’État prospèrent dans le bruit, là où l’efficacité des attaques est élevée et où l’attribution est entravée par des eaux troubles. Il s’agit d’un terrain de choix pour eux, où ils peuvent s’installer et faire leur travail.”
Les acteurs de la cybermenace deviennent de plus en plus audacieux à mesure que les jours défilent, dans l’espoir d’atteindre les entreprises et d’autres cibles avant qu’elles ne puissent mettre en place des correctifs pour leurs systèmes.
Par exemple, le 13 décembre, BitDifender a observé des attaquants déployant le nouveau ransomware Khonsari, le cheval de Troie d’accès à distance (RAT) Orcus et XMRig (Monero CPU miner), parmis bien d’autres logiciels malveillants.
XMRig est particulièrement dangereux pour les entreprises, quelque soit sa taille, car il transforme essentiellement les appareils infectés en drones de botnet de minage de crypto-monnaies.
Le 17 décembre, AdvIntel a signalé que le groupe ransomware Conti exploitait activement la vulnérabilité Log4j pour cibler les réseaux VMware vCenter.
Plus récemment, le 20 décembre, un article de Bleeping Computer a évoqué la découverte du cheval de Troie bancaire Dridex s’exécutant après l’exploitation.
Réponse fédérale américaine
La Cybersecurity and Infrastructure Security Agency (CISA) a depuis créé un groupe de leadership au sein de la Joint Cyber Defense Collaborative pour traiter la vulnérabilité Log4j.
CVE-2021-44228 a également été ajoutée au catalogue des vulnérabilités exploitées connues de la CISA.
La directrice du CISA, Jen Easterly, a publié sa première directive opérationnelle contraignante (DOC), demandant aux agences civiles fédérales de “remédier de manière urgente et prioritaire” aux vulnérabilités activement exploitables.
“Chaque jour, nos adversaires utilisent des vulnérabilités connues pour cibler les agences fédérales”, a déclaré Mme Easterly dans un communiqué de presse de la CISA publié le 3 novembre.
“En tant que responsable opérationnel de la cybersécurité fédérale, nous utilisons notre autorité en matière de directives pour orienter les efforts de cybersécurité vers la réduction des vulnérabilités spécifiques que nous savons être activement utilisées par des cybercriminels.
La directive énonce des exigences claires pour que les agences civiles fédérales prennent des mesures immédiates afin d’améliorer leurs pratiques de gestion des vulnérabilités.”
M. Easterly poursuit : “Bien que cette directive s’applique aux agences civiles fédérales, nous savons que des organisations de tout le pays, y compris des entités d’infrastructures critiques, sont ciblées par ces mêmes vulnérabilités.
Il est donc essentiel que chaque organisation adopte cette directive et donne la priorité à l’atténuation des vulnérabilités répertoriées dans le catalogue public de la CISA.”
Atténuation
De nombreuses grandes entreprises industrielles et grand public ont lancé des enquêtes internes pour déterminer si leurs produits grand public incluent Log4j.
Si celui-ci est découvert, cela ouvre un scénario potentiellement désastreux où le monde industriel, y compris ceux désignés comme infrastructures critiques pourrait être soumis à des cyberattaques, des vols de données, ransomwares, extorsions voir même des doubles extorsions, etc.
Il y a tout de même encore de l’espoir.
L’Apache Software Foundation, auteur de la bibliothèque Log4j vulnérable, a publié des correctifs de sécurité les 14 et 18 décembre.
Le site Web Logging.apache fournit les informations suivantes sur les mesures d’atténuation simples :
“Mettez à niveau vers Log4j 2.3.1 (pour Java 6), 2.12.3 (pour Java 7) ou 2.17.0 (pour Java 8 et versions ultérieures).”
Des dizaines de fournisseurs ont également publié des mises à jour et des correctifs de sécurité.
Le fournisseur d’outils de gestion informatique N-able a déployé des correctifs dans ses produits RMM et de renseignement sur les risques.
Le fournisseur de logiciels de gestion automatisée des correctifs ConnectWise a également publié des mises à jour de son service Perch Cloud en raison de composants tiers potentiellement vulnérables.
La National Vulnerability Database fournit ce message rassurant sur son entrée pour CVE-2021-44228 :
“Depuis la version 2.15.0 de log4j, ce comportement a été désactivé par défaut. Depuis la version 2.16.0, cette fonctionnalité a été complètement supprimée. Notez que cette vulnérabilité est spécifique à log4j-core et n’affecte pas log4net, log4cxx, ou d’autres projets Apache Logging Services.”
Comment BlackBerry peut aider à stopper les tentatives de post-exploitation de Log4j
Un composant logiciel vulnérable n’est pas un logiciel malveillant, ce qui rend l’existence de la vulnérabilité Log4j “invisible” (pour les anciens produits de sécurité axés sur la détection de fichiers malveillants connus), en utilisant des signatures de virus pour détecter les logiciels malveillants ou les ransomwares intrusifs.
Cependant, des solutions de sécurité plus avancées comme BlackBerry® Protect et BlackBerry® Optics détectent les charges utiles et les techniques d’attaque tentées par l’exploitation d’une vulnérabilité, et les empêchent de s’exécuter.
Au fil des années, BlackBerry a testé une grande quantité de ransomwares et de “coins miners” contre ses produits, que la plateforme a détectés avec succès et dont elle a empêché l’exécution.
Les produits BlackBerry font appel à des modèles d’intelligence artificielle (IA) hautement qualifiés qui utilisent l’apprentissage automatique pour détecter les activités et les comportements suspects dans l’environnement de la victime ciblée, même en l’absence de logiciel malveillant.
La mise en œuvre d’un cadre de zéro trust est un autre moyen très efficace de repousser les cyberattaques qui ne reposent pas sur des logiciels malveillants.
Comme l’ont noté de nombreux chercheurs, de nombreuses applications qui s’appuient sur la bibliothèque Log4j n’ont probablement pas les autorisations du système de fichiers.
Ce simple refus des autorisations peut suffire à empêcher l’exploitation de Log4j pour des attaques par ransomware.
Les environnements de confiance zéro étendent ces protections à toutes les applications, à tous les appareils et à tous les utilisateurs, en appliquant des politiques d’accès de moindre privilège à tous les niveaux.
Bien que la vulnérabilité de Log4j soit toujours active et non corrigée, de nombreux attaquants tenteront finalement d’exploiter la faille afin de charger des fichiers malveillants sur des systèmes compromis.
Ces charges utiles malveillantes, qui sont des fichiers, peuvent être détectées et arrêtées par BlackBerry Protect, un système de protection des points d’extrémité optimisé par Cylance® AI.
BlackBerry Protect est formé pour identifier les logiciels malveillants connus et de type “zero-day” et les arrêter avant qu’ils ne soient exécutés.
Alors que les cyber criminels réfléchissent aux opportunités, en particulier pendant les vacances, lorsque les processus organisationnels ralentissent et que le personnel est réduit au minimum, Log4Shell pourrait bien être le cadeau que les attaquants attendaient.
Dans l’intervalle, BlackBerry restera toujours vigilant et partagera de nouvelles informations sur cette menace dès qu’elles seront disponibles.
Assistance BlackBerry
Indépendamment de votre relation existante avec BlackBerry, l’équipe BlackBerry Incident Response peut travailler avec des organisations de toute taille et de tout secteur vertical, afin d’évaluer et d’améliorer la posture de sécurité de leurs terminaux et de maintenir de manière proactive la sécurité, l’intégrité et la résilience de leur infrastructure réseau.
Pour une assistance d’urgence, veuillez nous envoyer un courriel à DLIR@blackberry.com, ou utiliser notre formulaire de contact.
Assistance fédérale
Le FBI souhaite que les organisations les contactent si elles pensent avoir été compromises par Log4j.
La déclaration du FBI sur la vulnérabilité de Log4j indique : “Si vous pensez que vos systèmes ont été compromis par la vulnérabilité Log4j ou si vous cherchez à y remédier, nous vous encourageons à employer toutes les mesures d’atténuation recommandées et à suivre les conseils de la CISA.
Si vous pensez que votre organisation a été compromise à cause de la vulnérabilité Log4j, rendez-vous sur fbi.gov/log4j pour le signaler au FBI.
Veuillez inclure autant d’informations que possible afin d’aider le FBI et le CISA à déterminer les priorités en matière de sensibilisation des victimes.”
Les organisations peuvent également déposer des plaintes par l’intermédiaire du Centre de plaintes pour les crimes sur Internet (IC3).
Le FBI ou le CISA peuvent demander des informations supplémentaires.
Resources:
https://logging.apache.org/log4j/2.x/security.html
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://blogs.apache.org/foundation/entry/apache-log4j-cves
https://logging.apache.org/log4j/2.x/download.html
https://github.com/cisagov/log4j-affected-db
https://www.n-able.com/security-and-privacy/apache-log4j-vulnerability
https://www.connectwise.com/company/trust/advisories
https://securityscorecard.com/blog/log4j-active-exploitation-from-nation-state-actors-findings
https://www.cybersecuritydive.com/news/CISA-vulnerability-patch-directive-CVE-catalog/609393/
https://blogs.blackberry.com/en/2019/08/inside-the-apt28-dll-backdoor-blitz
https://cyber.dhs.gov/bod/22-01/
https://www.theregister.com/2021/12/13/log4j_rce_latest/
https://blogs.blackberry.com/en/2019/10/malicious-payloads-hiding-beneath-the-wav
https://www.fbi.gov/news/pressrel/press-releases/fbi-statement-on-log4j-vulnerability
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
Source : BlackBerry
Plus d’informations concernant les solutions :
