Cette semaine, Microsoft a mis en garde les organisations contre le potentiel élevé des acteurs de la menace d'étendre l'utilisation des vulnérabilités d'exécution de code à distance (RCE) récemment découvertes dans le cadre de journalisation Apache Log4j pour mener une variété d'attaques.
La société a déclaré que ses chercheurs en sécurité avaient observé une grande quantité d'activités d'analyse et de tentatives d'exploitation ciblant les failles au cours des dernières semaines de décembre.
De nombreux groupes d'attaque, y compris des acteurs d'États-nations et des groupes de rançongiciels, ont ajouté des exploits pour les vulnérabilités à leurs kits d'attaque et les utilisent pour établir des shells inversés, supprimer des kits d'outils d'accès à distance et mener des attaques au clavier sur des systèmes vulnérables. Les portes dérobées et les coques inversées que Microsoft a observées en cours de déploiement via les failles Log4j incluent Bladabindi, HabitsRAT, Meterpreter, Cobalt Strike et PowerShell.
"À ce stade, les clients doivent supposer que la large disponibilité du code d'exploitation et des capacités d'analyse constitue un danger réel et actuel pour leur environnement", a déclaré lundi le groupe de sécurité de Microsoft dans un communiqué. mettre à jour une entrée de blog la société a publié pour la première fois le 11 décembre. "Les organisations peuvent ne pas se rendre compte que leurs environnements peuvent déjà être compromis."
Apache Log4j est un composant de journalisation open source largement utilisé qui est présent dans presque tous les environnements où une application Java est utilisée. Cela inclut les serveurs connectés à Internet, les systèmes dorsaux et les composants réseau, les applications tierces, les services qui utilisent ces applications, dans les environnements cloud et dans les systèmes de contrôle industriels et les systèmes SCADA.
Le 9 décembre, l'Apache Software Foundation a divulgué un RCE critique (CVE-2021-44228) vulnérabilité dans le composant qui a donné aux attaquants un moyen relativement simple d'obtenir le contrôle complet des systèmes vulnérables. La divulgation a suscité une inquiétude généralisée et des avertissements urgents de la part des experts en sécurité sur la nécessité pour les organisations de mettre à jour rapidement leur version de Log4j en raison de l'activité d'analyse généralisée et des tentatives d'exploitation. Moins d'une semaine après la révélation de la première faille, la Fondation Apache a révélé une deuxième faille dans Log4j (CVE-2021-45046) puis quelques jours plus tard, une troisième (CVE-2021-45105).
La prévalence généralisée de la faille - et la facilité avec laquelle elle peut être exploitée - a suscité l'intérêt d'un large éventail d'acteurs de la menace. Dans les semaines qui ont suivi la révélation de la première faille, de nombreux fournisseurs ont signalé avoir observé des opérateurs de rançongiciels ; les mineurs de crypto-monnaie ; des acteurs de l'État-nation de pays tels que l'Iran, la Turquie et la Chine ; et d'autres tentant d'exploiter les failles.
Les acteurs de la menace persistante avancée (APT) qui ont été observés en train d'exploiter les failles incluent le groupe Hafnium basé en Chine qui était responsable de la réalisation d'attaques zero-day contre le soi-disant ensemble de failles ProxyLogon d'Exchange Server l'année dernière. Parmi les autres acteurs APT exploitant les failles de Log4j, citons Phosphorous, un opérateur de ransomware iranien, et Aquatic Panda, un acteur basé en Chine qui CrowdStrike déjoué au milieu d'une attaque ciblée contre une grande organisation universitaire quelques jours après la révélation de la première faille.
Dans cette attaque, ont observé les chercheurs de CrowdStrike, l'auteur de la menace a tenté d'exécuter des commandes Linux sur l'hôte Windows de l'organisation victime, a déclaré Param Singh, vice-président du service de chasse aux menaces Falcon OverWatch de CrowdStrike. Lorsque les tentatives d'exécution des commandes Linux ont échoué, l'auteur de la menace s'est rapidement tourné vers l'utilisation des services natifs de Windows ou des binaires dits vivants hors de la terre (LOLBins).
Ce comportement s'est démarqué des chasseurs de menaces OverWatch, dit Singh. "La manœuvre rapide et le changement de tactique que l'acteur de la menace a utilisé des commandes Linux pour tirer parti des LOLBins Windows est révélateur d'une activité interactive sur le clavier plutôt que d'une attaque scriptée opportuniste."
L'activité d'analyse généralisée se poursuit
Selon Microsoft, l'activité d'analyse représente la majeure partie du trafic d'attaque observé jusqu'à présent. Une grande partie de l'activité semble provenir de chercheurs en sécurité et d'équipes rouges à la recherche de failles sur leurs réseaux. Mais parmi ceux qui recherchent les failles, il y a des acteurs de la menace, y compris les opérateurs de botnets comme Mirai, ceux ciblant les systèmes Elasticsearch vulnérables pour déployer des mineurs de crypto-monnaie et des attaquants cherchant à déployer la porte dérobée Tsunami sur les systèmes Linux.
Dans bon nombre de ces campagnes, les attaquants exécutent des analyses simultanées pour les systèmes Windows vulnérables et les systèmes Linux. Les attaquants utilisent les commandes Base 64 incluses dans JDNI:ldap:// pour lancer des commandes bash sur les systèmes Linux et PowerShell sur Windows, a déclaré Microsoft.
Microsoft et de nombreux autres experts en sécurité ont exhorté les organisations à déployer des outils et des scripts d'analyse pour identifier les vulnérabilités Log4j dans leur environnement. Mais en raison du fonctionnement de Java-packing, la vulnérabilité peut être enfouie dans plusieurs couches profondes des applications et difficilement visible pour les scanners, ont déclaré des experts en sécurité.
Rézilion, par exemple, a récemment testé plusieurs outils d'analyse open source et commerciaux pour voir dans quelle mesure ils seraient efficaces pour détecter les fichiers Java où Log4j était imbriqué et emballé dans divers formats. Les outils d'analyse qu'il a testés comprenaient ceux de Google, Palantir, Aqua Security, Mergebase et JFrog. L'exercice a montré que si certains scanners étaient meilleurs que d'autres, aucun d'entre eux n'était capable de détecter Log4j dans tous les formats.
Depuis les tests de Rezilion, JFrog et Mergebase ont mis à jour leurs outils, explique Yotam Perkal, responsable de la recherche sur les vulnérabilités chez Rezilion.
"Mergebase a ajouté la prise en charge du format PAR, et JFrog a ajouté la prise en charge de PAR et ZIP, ainsi que amélioré leur prise en charge des fichiers JAR ombrés", note-t-il. "Bien qu'il soit difficile de donner une estimation précise, l'imbrication/intégration est une pratique courante chez les développeurs et nous voyons des jars imbriqués dans la plupart des environnements de production, de sorte que la probabilité d'instances non détectées est élevée."
