Log4j : Chronologie de l’exploit zero-day d’apache

La vulnérabilité Apache Log4j a eu un impact sur les organisations du monde entier. Voici une chronologie des événements clés entourant l’exploit Log4j tels qu’ils se sont déroulés.

La vulnérabilité Apache Log4j a fait la une des journaux mondiaux depuis sa découverte début décembre. La faille a touché un grand nombre d’organisations à travers le monde alors que les équipes de sécurité se sont efforcées d’atténuer les risques associés. Voici une chronologie des événements clés entourant la vulnérabilité Log4j tels qu’ils se sont déroulés.

Jeudi 9 décembre : Découverte de l’exploit zero-day Apache Log4j

Apache a publié des détails sur une vulnérabilité critique dans Log4j, une bibliothèque de journalisation utilisée dans des millions d’applications basées sur Java. 

Les attaquants ont commencé à exploiter la faille (CVE-2021-44228) – surnommée “Log4Shell“, qui a été notée 10 sur 10 sur l’échelle d’évaluation des vulnérabilités CVSS. 

Cela pourrait conduire à l’exécution de code à distance (RCE) sur les serveurs sous-jacents qui exécutent des applications vulnérables. 

“Un attaquant qui peut contrôler les messages de journal ou les paramètres de message de journal peut exécuter du code arbitraire chargé à partir de serveurs LDAP lorsque la substitution de recherche de message est activée”, ont écrit les développeurs d’Apache dans un avis. 

Un correctif pour le problème a été mis à disposition avec la sortie de Log4j 2.15.0 alors que les équipes de sécurité du monde entier travaillaient pour protéger leurs organisations. Les entreprises ont été invitées à installer la dernière version.

Vendredi 10 décembre : le NCSC britannique émet un avertissement Log4j aux organisations britanniques

Alors que les retombées de la vulnérabilité se poursuivaient, le National Cyber ​​​​Security Center (NCSC) du Royaume-Uni a lancé un avertissement public aux entreprises britanniques concernant la faille et a décrit des stratégies d’atténuation. 

Le NCSC a conseillé à toutes les organisations d’installer la dernière mise à jour immédiatement partout où Log4j était connu pour être utilisé. 

Cela devrait être la première priorité pour toutes les organisations britanniques utilisant un logiciel connu pour inclure Log4j. Les organisations doivent mettre à jour à la fois les logiciels accessibles sur Internet et non accessibles sur Internet », indique le communiqué. 

Les entreprises ont également été invitées à rechercher des instances inconnues de Log4j et à déployer une surveillance/un blocage de réseau de protection.

Samedi 11 décembre : le directeur de CISA commente le « défi urgent lancé aux défenseurs des réseaux »

Tout comme le NCSC du Royaume-Uni, la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis a répondu publiquement à la vulnérabilité Log4j avec la réalisatrice Jen Easterly réfléchissant au défi urgent qu’elle présentait aux défenseurs du réseau. 

“CISA travaille en étroite collaboration avec nos partenaires des secteurs public et privé pour résoudre de manière proactive une vulnérabilité critique affectant les produits contenant la bibliothèque logicielle Log4j“, a-t-elle déclaré dans un communiqué .. « Nous prenons des mesures urgentes pour atténuer cette vulnérabilité et détecter toute activité de menace associée. 

Nous avons ajouté cette vulnérabilité à notre catalogue de vulnérabilités exploitées connues, ce qui oblige les agences civiles fédérales – et signale aux partenaires non fédéraux – à corriger ou à corriger de toute urgence cette vulnérabilité. 

Nous contactons de manière proactive les entités dont les réseaux peuvent être vulnérables et tirons parti de nos outils d’analyse et de détection d’intrusion pour aider les partenaires gouvernementaux et industriels à identifier l’exposition ou l’exploitation de la vulnérabilité.

La CISA a recommandé aux propriétaires d’actifs de prendre trois mesures immédiates supplémentaires pour aider à atténuer la vulnérabilité :

• Énumérez tous les périphériques externes sur lesquels Log4j est installé
• Assurez-vous que les centres d’opérations de sécurité agissent sur chaque alerte sur les appareils qui entrent dans la catégorie ci-dessus
• Installez un pare-feu d’application Web avec des règles qui se mettent à jour automatiquement afin que les centres d’opérations de sécurité (SOC) puissent se concentrer sur moins d’alertes

Mardi 14 décembre : deuxième vulnérabilité Log4j porteuse d’une menace de déni de service détectée, nouveau correctif publié

Une deuxième vulnérabilité impactant Apache Log4j a été découverte. Le nouvel exploit, CVE 2021-45046, a permis à des acteurs malveillants de créer des données d’entrée malveillantes à l’aide d’un modèle de recherche JNDI pour créer des attaques par déni de service (DoS), selon la description de CVE . 

Un nouveau correctif pour l’exploit a été mis à disposition, supprimant la prise en charge des modèles de recherche de message et désactivant la fonctionnalité JNDI par défaut, le correctif Log4j 2.15.0 pour le défaut d’origine étant incomplet dans certaines configurations non par défaut.

Bien que CVE-2021-45046 soit moins grave que la vulnérabilité d’origine, il devient un autre vecteur permettant aux acteurs de la menace de mener des attaques malveillantes contre des systèmes non corrigés ou mal corrigés, a déclaré Amy Chang, responsable des risques et de la réponse chez Resilience, au CSO peu après la faille a été découverte.

Le correctif incomplet de CVE-2021-44228 pourrait être utilisé de manière abusive pour créer des données d’entrée malveillantes, ce qui pourrait entraîner une attaque DoS. 

Une attaque DoS peut arrêter une machine ou un réseau et le rendre inaccessible aux utilisateurs auxquels il est destiné », a-t-elle ajouté. Les organisations ont été invitées à mettre à jour Log4j : 2.16.0 dès que possible.

Vendredi 17 décembre : troisième vulnérabilité Log4j révélée, nouveau correctif mis à disposition

Apache a publié les détails d’une troisième vulnérabilité majeure de Log4j et a mis à disposition un autre correctif. Il s’agissait d’une faille de récursivité infinie notée 7,5 sur 10 .pour Java 8 et plus, écrit-il.

Les versions 2.0-alpha1 à 2.16.0 d’Apache Log4j2 ne protégeaient pas de la récursivité incontrôlée des recherches auto-référentielles. Lorsque la configuration de journalisation utilise une disposition de modèle autre que celle par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants contrôlant les données d’entrée de Thread Context Map (MDC) peuvent créer des données d’entrée malveillantes contenant une recherche récursive. , entraînant une StackOverflowError qui mettra fin au processus.

Ceci est également connu sous le nom d’attaque DoS (déni de service).

Apache a également décrit les mesures d’atténuation suivantes :

• Dans PatternLayout dans la configuration de journalisation, remplacez les recherches de contexte telles que ${ctx:loginId} ou $${ctx:loginId} par des modèles de carte de contexte de thread (%X, %mdc ou %MDC)
• Sinon, dans la configuration, supprimez les références aux recherches de contexte telles que ${ctx:loginId} ou $${ctx:loginId} lorsqu’elles proviennent de sources externes à l’application, telles que les en-têtes HTTP ou les entrées utilisateur.

Lundi 20 décembre : Log4j exploité pour installer Dridex et Meterpreter

Le groupe de recherche sur la cybersécurité Cryptolaemus a averti que la  vulnérabilité Log4j était exploitée  pour infecter les appareils Windows avec le cheval de Troie bancaire Dridex et les appareils Linux avec Meterpreter. Dridex est une forme de malware qui vole les informations d’identification bancaires via un système qui utilise des macros de Microsoft Word, tandis que Meterpreter est une charge utile d’attaque Metasploit qui fournit un shell interactif à partir duquel un attaquant peut explorer une machine cible et exécuter du code. 

Joseph Roosen, membre de Cryptolaemus, a déclaré à  BleepingComputer  que les pirates utilisent la variante d’exploitation Log4j RMI (Remote Method Invocation) pour forcer les appareils vulnérables à charger et exécuter une classe Java à partir d’un serveur distant contrôlé par l’attaquant.

Mercredi 22 décembre : les données montrent que 10 % de tous les actifs sont vulnérables à Log4Shell

Les données publiées par le fournisseur de cybersécurité Tenable ont révélé qu’un actif sur 10 était vulnérable à Log4Shell, tandis que 30 % des organisations n’avaient pas commencé à rechercher le bogue.

 Parmi les actifs qui ont été évalués, Log4Shell a été trouvé dans environ 10 % d’entre eux, y compris une large gamme de serveurs, d’applications Web, de conteneurs et d’appareils IoT, lit-on dans un blog de  Tenable .

Log4Shell est omniprésent dans tous les secteurs et toutes les zones géographiques. Un serveur d’entreprise sur 10 est exposé. Une application Web sur 10, etc. Un sur 10 de presque tous les aspects de notre infrastructure numérique présente un potentiel d’exploitation malveillante via Log4Shell.

Le fournisseur a averti que Log4Shell comporte une menace potentielle plus importante qu’EternalBlue (exploité dans les attaques WannaCry) en raison de l’omniprésence de Log4j dans l’infrastructure et les applications. «Aucune vulnérabilité unique dans l’histoire n’a appelé de manière aussi flagrante à être corrigée. 

Log4Shell définira l’informatique telle que nous la connaissons, en séparant ceux qui font l’effort de se protéger et ceux qui sont à l’aise d’être négligents », a-t-il ajouté.

Mardi 4 janvier: la FTC demande aux entreprises de corriger la vulnérabilité Log4j et menace de poursuites judiciaires

La Federal Trade Commission (FTC) a exhorté les organisations américaines à corriger immédiatement la vulnérabilité Log4Shell ou à risquer des mesures punitives de la part de l’agence.

Lorsque des vulnérabilités sont découvertes et exploitées, cela risque une perte ou une violation d’informations personnelles, une perte financière et d’autres dommages irréversibles.

Le devoir de prendre des mesures raisonnables pour atténuer les vulnérabilités logicielles connues implique des lois, notamment la Federal Trade Commission Act et la Gramm Leach Bliley Act », a  déclaré la FTC .. Il a ajouté qu’il est essentiel que les entreprises et leurs fournisseurs qui s’appuient sur Log4j agissent maintenant pour réduire le risque de préjudice pour les consommateurs et pour éviter une action en justice de la FTC.

La FTC a l’intention d’utiliser sa pleine autorité légale pour poursuivre les entreprises qui ne prennent pas de mesures raisonnables pour protéger les données des consommateurs contre l’exposition à la suite de Log4j, ou de vulnérabilités connues similaires à l’avenir.”

Lundi 10 janvier : Microsoft met en garde contre un opérateur de ransomware basé en Chine qui exploite Log4Shell

Microsoft a mis à jour sa  page de conseils sur la vulnérabilité Log4j avec les détails d’un opérateur de ransomware basé en Chine (DEV-0401) ciblant les systèmes connectés à Internet et déployant le ransomware NightSky.

Dès le 4 janvier, les attaquants ont commencé à exploiter la vulnérabilité CVE-2021-44228 dans les systèmes connectés à Internet exécutant VMware Horizon”, écrit-il. “DEV-0401 a déjà déployé plusieurs familles de rançongiciels, notamment LockFile, AtomSilo et Rook, et a exploité de la même manière des systèmes connectés à Internet exécutant Confluence (CVE-2021-26084) et des serveurs Exchange sur site (CVE-2021-34473).

Sur la base de l’analyse de Microsoft, il a été découvert que les attaquants utilisaient des serveurs de commande et de contrôle (CnC) qui usurpaient des domaines légitimes. Ceux-ci incluent service.trendmrcio.com, api.rogerscorp.org, api.sophosantivirus.ga, apicon.nvidialab.us, w2zmii7kjb81pfj0ped16kg8szyvmk.burpcollaborator.net, et 139.180.217.203.

source : securitynewspaper

Votez : (8 votes, average: 4,75 out of 5)

Loading...