Log4j était autrefois un simple cadre de journalisation Java populaire, l'un des nombreux composants qui fonctionnent en arrière-plan dans de nombreuses applications web modernes. Mais depuis la publication de la vulnérabilité zero-day (CVE-2021-44228), Log4j a eu un impact considérable sur la communauté de la sécurité, car les chercheurs ont découvert qu'il était vulnérable à l'exécution de code arbitraire.
Log4Shell est une vulnérabilité logicielle dans Apache Log4j 2, une bibliothèque Java populaire pour l'enregistrement des messages d'erreur dans les applications. La vulnérabilité, publiée sous le nom de CVE-2021-44228, permet à un attaquant distant de prendre le contrôle d'un appareil sur Internet si l'appareil utilise certaines versions de Log4j 2.
Cela signifie que Log4Shell affecte Log4j ou Log4j 2. Qu'est-ce que Log4j ? Il s'agit d'un cadre de journalisation open-source en Java que les développeurs utilisent pour suivre l'activité des logiciels dans les applications d'entreprise et en nuage. Cela signifie qu'il est utilisé dans un grand nombre de choses, Java étant présent sur des milliards de systèmes, y compris des appareils IoT, des kits médicaux, etc.
Le 9 décembre 2021, une vulnérabilité de type "zero-day" a été publiée pour la première fois dans le populaire cadre de journalisation Log4j pour Java. Le NIST a attribué à cette vulnérabilité (CVE-2021-44228) une note de 10 sur 10, ce qui est très critique et significatif car le NIST attribue rarement une note de 10 aux vulnérabilités. Comme cette vulnérabilité permet l'exécution de code à distance et peut être facilement exploitée, il existe déjà des dizaines de preuves de concept (PoC) pour des kits d'exploitation disponibles en ligne. En outre, de nombreux rapports indiquent qu'elle est massivement exploitée dans la nature.
Pour mieux comprendre les événements liés à cette vulnérabilité critique, voici une chronologie de base :
Un mois après le début de la bataille pour éliminer la vulnérabilité, de nombreux responsables de la sécurité informatique pensent que les tentatives d'exploitation de la vulnérabilité Log4Shell se poursuivront probablement pendant des années et deviendront une cible privilégiée pour les testeurs de pénétration et les acteurs de la menace soutenus par des États-nations. Sophos a ajouté dans son blog la semaine dernière : "L'urgence d'identifier où il est utilisé dans les applications et de mettre à jour le logiciel avec le correctif reste plus critique que jamais".
La véritable crainte de la plupart des organisations est que les attaquants aient déjà accédé à leurs réseaux et qu'ils se contentent d'attendre, de surveiller le réseau en attendant le moment idéal pour frapper.
Dans l'intervalle, de nombreux organismes de sécurité ont mis au point des outils permettant d'identifier la vulnérabilité. En voici un de Trend Micro qui est devenu assez fiable : https://log4j-tester.trendmicro.com/
Microsoft a immédiatement mis en garde les organisations contre le risque élevé que les acteurs de la menace étendent l'utilisation des vulnérabilités d'exécution de code à distance (RCE) récemment découvertes dans le cadre de journalisation Apache Log4j à de nombreux types d'attaques.
L'entreprise a déclaré que ses chercheurs en sécurité avaient observé un grand nombre d'activités de balayage et de tentatives d'exploitation ciblant les failles au cours des dernières semaines de décembre par ce qu'ils supposaient être des acteurs de la menace à la recherche de la vulnérabilité.
De nombreux groupes d'attaquants, y compris des acteurs étatiques et des groupes de ransomware, ont ajouté des exploits pour les vulnérabilités à leurs kits d'attaque et les utilisent pour établir des shells inversés, déposer des boîtes à outils d'accès à distance et mener des attaques clavier à la main sur des systèmes vulnérables. Parmi les portes dérobées et les shells inversés dont Microsoft a observé le déploiement via les failles de Log4j figurent Bladabindi, HabitsRAT, Meterpreter, Cobalt Strike et PowerShell.
Apache Log4j est un composant de journalisation open-source largement utilisé, présent dans presque tous les environnements où une application Java est utilisée. Ainsi, lorsque nous avons parlé de milliards d'appareils plus tôt dans le billet, cela inclut les serveurs orientés vers l'internet, les systèmes dorsaux, les composants réseau, les applications tierces, les services qui utilisent ces applications, dans les environnements en nuage et dans les systèmes de contrôle industriel et les systèmes SCADA.
Un script est également disponible sur Github pour détecter la présence de la vulnérabilité sur les systèmes Linux et Windows. Les versions vulnérables de Log4j 2 sont toutes les versions de Log4j-core, de 2.0-beta9 à 2.14.1. Le meilleur conseil est de mettre à jour vos dépendances pour utiliser la dernière version, 2.15.0. Les versions antérieures 1.x de Log4j ne sont pas concernées par cette vulnérabilité, mais elles présentent leurs propres problèmes.
Le 9 décembre, lorsque l'Apache Software Foundation a révélé la vulnérabilité critique RCE (CVE-2021-44228) (Log4Shell), la communauté de la sécurité a immédiatement compris que la vulnérabilité offrait aux attaquants un moyen relativement trivial de prendre le contrôle complet des systèmes vulnérables. La divulgation de cette faille a suscité une grande inquiétude et des avertissements urgents de la part des experts en sécurité sur la nécessité pour les organisations de mettre rapidement à jour leur version de Log4j en raison de l'activité de balayage et des tentatives d'exploitation qui se sont multipliées. Moins d'une semaine après la divulgation de la première faille, la Fondation Apache a divulgué une deuxième faille dans Log4j (CVE-2021-45046) et, quelques jours plus tard, une troisième (CVE-2021-45105).
La prévalence généralisée de la faille ainsi que la facilité avec laquelle elle peut être exploitée ont suscité l'intérêt d'un large éventail d'acteurs de la menace. Dans les semaines qui ont suivi la divulgation de la première faille, de nombreux fournisseurs ont signalé avoir observé des opérateurs de ransomware, des mineurs de crypto-monnaie, des acteurs étatiques de pays tels que l'Iran, la Turquie, la Chine et d'autres qui tentaient d'exploiter les failles.
Parmi les acteurs qui ont été observés en train d'exploiter les failles, on trouve le groupe Hafnium, basé en Chine, qui a été responsable de l'exécution d'attaques "zero-day" contre la série de failles Exchange Server dite "ProxyLogon" l'année dernière. Parmi les autres acteurs exploitant les failles de Log4j figurent Phosphorous, un opérateur iranien de ransomware, et Aquatic Panda, un acteur basé en Chine que CrowdStrike a déjoué au milieu d'une attaque ciblée contre une grande organisation universitaire quelques jours après la divulgation de la première faille.
Dans cette attaque, les chercheurs de CrowdStrike ont observé que l'auteur de la menace tentait d'exécuter des commandes Linux sur l'hôte Windows de l'organisation victime, explique Param Singh, vice-président du service de chasse aux menaces Falcon OverWatch de CrowdStrike. Lorsque les tentatives d'exécution de commandes Linux ont échoué, l'acteur de la menace est rapidement passé à l'utilisation de services natifs Windows ou de binaires "living-off-the-land" (LOLBins).
Si elles ne sont pas corrigées, de nombreuses applications d'entreprise et services en nuage écrits en Java sont également potentiellement vulnérables aux failles de Log4j. La bibliothèque de journalisation open-source est censée être utilisée sous une forme ou une autre, soit directement, soit indirectement, en s'appuyant sur un cadre Java. Ce cadre est utilisé par presque TOUTES les grandes organisations.
Cependant, à l'époque, "Sophos pense que la menace immédiate d'une exploitation massive de Log4Shell par des attaquants a été écartée parce que la gravité du bogue a uni les communautés du numérique et de la sécurité et a galvanisé les gens pour qu'ils passent à l'action".
Peu d'attaques majeures utilisant Log4j ont été divulguées à ce jour. Cependant, le 20 décembre, le ministère de la défense belge a révélé qu'une partie de son réseau avait été fermée à la suite d'une cyber-attaque. Selon le ministère de la défense, l'attaque résultait en effet de l'exploitation de la vulnérabilité de Log4j. En outre, des pirates informatiques, y compris des groupes soutenus par l'État chinois, ont lancé plus de 840 000 attaques contre des entreprises du monde entier au cours de la semaine qui a suivi la découverte de la vulnérabilité. Le problème est qu'il existe d'innombrables vecteurs d'attaque Log4Shell qui doivent être traités. Des cybercriminels tels que le tristement célèbre gang Conti ransomware, connu pour avoir gagné des millions en utilisant un modèle de ransomware-as-a-service, ont déjà été démasqués en train d'utiliser Log4Shell pour des mouvements latéraux au sein d'organisations.
Les organisations devraient profiter de la situation de Log4j pour prendre du recul et répondre aux questions fondamentales suivantes en matière de sécurité et de gestion des risques :
Quel est notre plan ?
À l'heure actuelle, la plupart des organisations réagissent aux logiciels jugés vulnérables ou aux cyberattaques. Il y aura probablement une migration vers une approche plus méthodique qui identifiera d'abord comment l'organisation est affectée et rectifiera ensuite les problèmes constatés. Les grandes organisations et entreprises auront besoin d'une approche progressive pour gérer cette question sur plusieurs semaines ou mois, avec des équipes capables de maintenir une réponse à moyen terme.
Comment saurons-nous si nous sommes attaqués et comment pourrons-nous réagir ?
Log4j permet aux attaquants d'accéder aux réseaux, et les attaquants eux-mêmes travaillent certainement à exploiter la vulnérabilité comme nous l'avons suggéré. Vos équipes sauraient-elles si votre organisation est ciblée et seraient-elles prêtes à réagir de manière appropriée ?
Quelle visibilité avons-nous sur nos logiciels, nos serveurs et nos données critiques ?
Les équipes essaient de trouver des instances de logiciels et de Log4j lui-même. Cette tâche sera plus facile sur les actifs gérés par l'entreprise, mais moins sur les actifs non gérés, y compris tout actif basé sur SaaS ou tout appareil personnel pouvant accéder au réseau de l'entreprise.
Comment s'attaquer à l'informatique parallèle et aux appareils ?
En plus de réparer les actifs gérés par l'entreprise, les équipes doivent réfléchir à la manière dont elles découvriront les éléments qui ont pu passer entre les mailles du filet et qui ne sont pas gérés de manière centralisée, ce que l'on appelle parfois l'"informatique fantôme", qui est devenue courante depuis l'épidémie de Covid.
Le risque lié aux tiers est-il important ?
Si votre organisation dépend de fournisseurs clés particuliers qui ont accès à votre réseau. Des tiers gèrent-ils des logiciels essentiels à votre activité ou des accès administratifs à distance ?