Sommaire
[Étant donné que cet article concerne une vulnérabilité récemment publiée, les informations concernant les dernières recherches seront mises à jour périodiquement]
Le jeudi 9 décembre 2021, une vulnérabilité d’exécution de code (appelée Log4Shell et référencée CVE-2021-44228) affectant la bibliothèque de journalisation Java Log4j a été publié sur Internet par une société nommée Lunasec. Log4j est une bibliothèque de journalisation largement utilisée dans les applications de bureau et de serveur Java.
Des tonnes de services cloud, d’applications Web et d’applications de bureau ont été testées et exploitées avec succès. L’exploitation de sa simplicité d’utilisation – par l’injection d’une simple chaîne de caractères – a provoqué une vague de scans automatiques à la recherche d’actifs vulnérables. Dans le FLINT, nous présentons les sujets suivants :
- Analyse technique
- Tentatives d’exploitation d’ITW
- Actifs touchés par
- Log4Shell Stratégie de détection de Log4Shell
- Au-delà de ce RCE, quelle est la suite ?
- Alors que faire?
Analyse technique
La librairie Log4j dispose d’un mécanisme appelé substitution de recherche de message permettant de enrichir les logs produits par la bibliothèque avec plusieurs valeurs dynamiques contextuelles appelées « Lookups ». Ces recherches permettent par exemple d’écrire dans les logs les variables d’environnement du système sur lequel il s’exécute (Version Java, système d’exploitation). Jusqu’à la version 2.15.0 de Log4j, Log4j autorisait les recherches JNDI.
JNDI (Java Naming and Directory Interface) est une interface Java utilisée pour interroger plusieurs services de nommage et d’annuaire. Comme décrit par une recherche précédente, les interfaces LDAP et RMI JNDI ont des faiblesses qui leur permettent d’exécuter du code arbitraire en passant à l’URI d’un objet qui fait référence à un fichier de classe Java qui sera exécuté par l’instance Java. Désormais, Log4j peut être sujet à une vulnérabilité car la version antérieure à la 2.16.0 autorisait JNDI par défaut et recherchait les injections à partir d’une valeur contrôlée par l’attaquant.
Pour déclencher cette vulnérabilité, un attaquant n’a qu’à injecter une recherche JNDI interrogeant un (faux) serveur LDAP contrôlé par lui sur n’importe quel champ qui sera potentiellement journalisé par l’application, par exemple, un nom d’utilisateur ou un champ HTTP comme un User-Agent . Voici un exemple de requête HTTP GET essayant de déclencher la vulnérabilité en injectant le champ d’en-tête User-Agent.
Exemple de tentative d’exploitation
Si l’application vulnérable utilise Log4j et traite dans les logs le User-Agent, une recherche LDAP JNDI sera effectuée par Java. Java émettra la requête LDAP pour examiner l’objet « foo » qui fait référence à une classe Java externe. Ensuite, en suivant cette référence, Java émettra une requête HTTP pour télécharger et exécuter la classe Java, comme le montre la capture réseau ci-dessous :
La méthode d’exploitation présentée ci-dessus n’est pas la seule qui peut être utilisée contre une application vulnérable. Plusieurs autres moyens peuvent être utilisés, tels que l’intégration directe de l’objet Java sérialisé malveillant dans la réponse LDAP ou l’utilisation de LDAPS pour empêcher les signatures réseau sur les réponses LDAP.
Tentatives d’exploitation d’ITW
Au cours du week-end, plusieurs exploits publics ont été diffusés sur Internet. Depuis lors, la plupart des analyses massives d’Internet cherchant à exploiter Log4Shell ne sont plus liées à des chercheurs mais associées à des activités malveillantes de minage de crypto et à des botnets historiques comme Mirai, Muhstik ou Kinsing. Cependant, le succès de ces « scans aveugles » à la recherche de serveurs vulnérables par le simple envoi de requêtes HTTP semble être surestimé par la communauté de la sécurité.
Le taux de réussite de ces scans peut être évalué en regardant la campagne « bingsearchlib ». Cette campagne de numérisation massive semble avoir été lancée le 9 décembre, le jour où le domaine « bingsearchlib[.]com » a été enregistré et le billet du blog Lunasec a été publié.
Au début de la crise, un bot utilisant des adresses IP TOR semble avoir scanné tout Internet à la recherche de serveurs vulnérables en envoyant cette chaîne spécifique en tant qu’agent utilisateur HTTP :
la chaîne hexadécimale dans le sous-domaine semble être unique par hôte scanné et semble représenter l’adresse IP du serveur ciblé. Dès lors, si l’exploitation réussit, une requête DNS sera faite au nom de domaine. Cette requête se retrouvera avec une chance dans le cache DNS passif tel que PassiveTotal.
En regardant ces caches, il n’y a que quelques dizaines de sous-domaines qui ont été vus, 140 sur PassiveTotal. Kryptos Logic a indiqué dans un tweet 10k serveurs web vulnérables après un scan effectué durant le week-end sur divers champs HTTP – moins que pour le CVE-2021-41773. Parmi ces 10 000 serveurs vulnérables, un certain nombre pourraient être liés à des Honeypots exposés par des chercheurs en sécurité. En effet, plusieurs projets ont été partagés sur GitHub permettant de déployer des services vulnérables à la vulnérabilité Log4Shell. Soit dit en passant, peu de chercheurs se sont plaints du bruit créé par les scanners. Depuis, le taux de réussite réel de ces véritables campagnes d’exploitation à l’aveugle faites par les botnets semble très limité à l’échelle d’Internet.
Cependant, de nombreuses attaques ciblées utilisant Log4Shell semblent avoir commencé. Microsoft a déclaré dans un article de blog qu’ils avaient déjà observé les activités de post-exploitation de Log4j, y compris Cobalt Strike.
Actifs affectés par Log4Shell
Au-delà de ces scans aveugles, l’étendue de cette vulnérabilité est difficile à estimer car elle peut cibler littéralement n’importe quelle application intégrant une implémentation vulnérable de la bibliothèque Log4j. Par conséquent, la vulnérabilité n’impacte pas seulement les serveurs web, contrairement à ce que l’on pourrait attendre, mais également les applications bureautiques ou les systèmes embarqués, souvent plus complexes voire impossibles à mettre à jour.
Avec cela, les vecteurs d’exploitation sont multiples. Voici quelques exemples, où un attaquant peut utiliser des injections JNDI malveillantes déclenchées par Log4j :
- applications Web et terminaux d’API utilisant Log4j en envoyant des requêtes intégrant une injection JNDI malveillante ;
- Serveur, middleware et appliance utilisant Log4j en envoyant une requête spécifique intégrant une injection JNDI malveillante (ex. serveur SMTP JAMES) ;
- Applications de bureau utilisant Log4j en forgeant – par exemple – un fichier malveillant embarquant une injection JNDI malveillante à ouvrir par l’application (par exemple la vulnérabilité Ghidra) ;
- Application cliente 2-tiers / 3-tiers écrite en Java et utilisant Log4j en empoisonnant une base de données avec une injection JNDI malveillante afin d’infecter les systèmes clients récupérant les données de la base de données ;
- Toute application de traitement (ex. OCR) utilisant Log4j en forgeant une entrée à traiter contenant une injection JNDI illicite.
Cependant, le risque peut être réduit si l’entrée journalisée a été vérifiée par rapport à un modèle valide avant le traitement par l’application et Log4j.
À ce jour, de nombreux éditeurs étudient la surface d’attaque potentielle et la vulnérabilité de leurs produits. Dès lors, il est fort probable que de nombreuses applications open source et propriétaires recevront des mises à jour de sécurité majeures dans les prochains jours.
Stratégie de détection Log4Shell
En raison du nombre de vecteurs par lesquels la vulnérabilité peut être déclenchée et du nombre de moyens d’obscurcissement des injections JNDI malveillantes, la détection d’une tentative d’exploitation par les signatures réseau et système standard est principalement limitée aux injections JNDI non obscurcies. . Voici une liste non exhaustive des obfuscations possibles pour la recherche JNDI :
La détection peut être basée sur :
- L’arborescence des processus de Java exécutant des utilitaires spécifiques via des signatures heuristiques basées sur les journaux système comme Sigma ;
- La détection d’exploitation réussie via les signatures réseau sur les réponses LDAP, RMI et HTTP contenant la classe Java lorsqu’une exploitation est réussie. Les signatures Suricata sont partagées par SEKOIA.IO à la fin de cet article de blog ;
- IOC connus des domaines de rappel qui seront déclenchés si une exploitation réussit.
En bref, les tentatives d’exploitation de la vulnérabilité Log4j sont difficiles à détecter ; il est important de patcher les systèmes vulnérables et de concentrer la détection sur les phases de Kill Chain suivant la compromission initiale.
Au-delà de ce RCE, quelle est la suite ?
Cette vulnérabilité Log4Shell, nous pourrions nous attendre dans les jours et semaines à venir, à de multiples nouvelles vulnérabilités spécifiques au sein des produits concernés et à d’éventuels vers exploitant cette vulnérabilité. Les acteurs de la menace (APT, groupes de rançongiciels et autres groupes de cybercriminels) les rechercheront, ce qui conduira à une exploitation potentielle dans la nature. Sekoia.io a identifié au moins un groupe de rançongiciels (LockBit) travaillant sur la vulnérabilité Log4j, selon nos informations sur le Darkweb :
Legasov (à propos du représentant de LockBit étant hors ligne pendant un certain temps) : « il s’est déconnecté et ne s’est plus jamais présenté »
chinarules : « ils m’ont dit qu’ils travaillaient sur log4j »
Alors, que faire ?
Tout d’abord, restez calme. Malgré le bruit sur cette vulnérabilité, les analyses massives en ce moment ne sont que des analyses aveugles, qui ne ciblent aucune application spécifique, de sorte que leur taux de réussite est assez limité. Cependant, cette vulnérabilité est grave et générera de nouvelles vulnérabilités dans plusieurs logiciels bien connus utilisés dans les secteurs public et privé. Depuis :
- Gardez un œil sur les avis et mises à jour publiés par les éditeurs de logiciels. Nous pouvons nous attendre – avec une confiance moyenne – à ce qu’une pluie de vulnérabilités critiques liées à des produits spécifiques vienne dans les jours suivants ;
- En priorité, concentrez-vous sur votre surface d’attaque externe pour les correctifs (logiciels métier, serveurs de messagerie et Web, tout serveur et application connectés à votre réseau et accessibles depuis Internet) ;
- Déployez des signatures de détection basées sur le système et le réseau. Pas sur des tentatives d’exploitation car cela brûlera vos analystes SOC, mais sur une exploitation réussie (ex : réponses HTTP contenant une JavaClass malveillante, réponse LDAP faisant référence à des objets Java etc.) ;
- Si vous avez développé des applications Java métier à l’aide de log4j, demandez à vos équipes de développement de les corriger.
Course of actions
Mettre à jour le logiciel
De nombreux éditeurs de logiciels utilisant la librairie Log4j ont des mises à jour disponibles.
Atténuation alternative
Lorsque vous ne pouvez pas mettre à niveau vers la dernière version de Log4j : soit en modifiant l’utilisation existante de Log4j, soit la configuration de la machine virtuelle Java
Règles de pare-feu
Vérifiez les connexions serveur sortantes autorisées à Internet. Empêchez votre serveur d’initier une connexion à des ressources non approuvées sur Internet en utilisant un pare-feu.
IOCs & Détails techniques
IOCs associés à l’exploitation de Log4j
- Sur SEKOIA.IO : Les IOCs
- sont associés à la campagne « Campagne d’exploitation massive ciblant la CVE-2021-44228 ». Ils ont été obtenus à partir de différentes sources telles que GreyNoise, Twitter, URLhaus ou ThreatFox. Ils seront mis à jour régulièrement.
- Des centaines d’observables liés à la numérisation ont également été ajoutés à la base de données d’observables SEKOIA.IO avec la balise « CVE-2021-44228 ». Ils seront mis à jour régulièrement.
- Partagé sur URLhaus : https://urlhaus.abuse.ch/browse/tag/log4j/
- Partagé sur ThreatFox : https://threatfox.abuse.ch/browse/tag/log4j/
Yara Rules
Règles YARA de SEKOIA.IO permettant de détecter la chaîne utilisée pour l’injection de recherche JNDI utilisée pour l’exploitation Log4Shell :
rule Log4Shell_JNDI_Lookup_LDAP_Injection {
meta:
id = "cf8d4455-189d-4350-b448-99fdba158053"
description = "Detects JNDI lookup LDAP injection attempt"
version = "1.0"
creation_date = "2021-12-13"
modification_date = "2021-12-13"
classification = "TLP:WHITE"
source="SEKOIA"
version="1.0"
strings:
$ = { 24 7b [0-15] (6a|4a)
[0-15] (6e|4e) [0-15]
(64|44) [0-15] (69|49)
[0-15] 3a [0-15] (6c|4c)
[0-15] (64|44) [0-15]
(61|41) [0-15] (70|50)
[10-120] 7d }
condition:
$
}
rule Log4Shell_JNDI_Lookup_RMI_Injection {
meta:
id = "cf8d4455-189d-4350-b448-99fdba158053"
description = "Detects JNDI lookup RMI injection attempt"
version = "1.0"
creation_date = "2021-12-13"
modification_date = "2021-12-13"
classification = "TLP:WHITE"
source="SEKOIA"
version="1.0"
strings:
$ = { 24 7b [0-15] (6a|4a)
[0-15] (6e|4e) [0-15]
(64|44) [0-15] (69|49)
[0-15] 3a [0-15] [0-15]
(72|52) [0-15] (6d|4d)
[0-15] (69|49) [10-120] 7d }
condition:
$
}Snort Rules
Emerging Threats a partagé des règles open-source Suricata pour détecter et traquer les tentatives d’exploitation Log4j RCE :
https://rules.emergingthreatspro.com/open/
Réponse LDAP avec javaNamingReference à une URL HTTP
alert tcp $EXTERNAL_NET any -> $HOME_NET any (flow: from_server, established;content:”0″;startswith;content:”objectClass”;content:”javaNamingReference”;
content:”javaClassName”;content:”javaCodeBase”;pcre:/http(s)?:\/\//;depth:300;
msg:”Detect LDAP answer with javaNamingReference to an HTTP URL #log4shell”;sid:XXXXXXXXX; rev:001;
reference:url,www.sekoia.io/en/log4shell-the-defenders-worst-nightmare;)Paquet TCP avec JavaClass Magic et contenant getRuntime-exec compilé.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (flow: from_server, established;content:”|ca fe ba be 00 00 00|”;content:”java/lang/Runtime”;content:”|04 65 78 65 63 01|”;depth:2000; msg:”Detect JAVA class using getRuntime().exec over unencrypted protocol #log4shell”; sid:XXXXXXXXX; rev:001;reference:url,www.sekoia.io/en/log4shell-the-defenders-worst-nightmare;)Paquet TCP avec JavaClass Magic et contenant la commande ProcessBuilder compilée.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (flow: from_server, established;content:”|ca fe ba be 00 00 00|”;content:”java/lang/ProcessBuilder”;content:”|07 63 6f 6d 6d 61 6e 64 01|”;depth:2000;msg:”Detect JAVA class using builder.command over unencrypted protocol #log4shell”;sid:XXXXXXXXX; rev:001;reference:url,www.sekoia.io/en/log4shell-the-defenders-worst-nightmare;)Références externes
³[GovCERT.ch] Zero- Day Exploit Targeting Popular Java Library Log4j
⁴[CERT-FR] Bulletin d’alerte du CERT-FR
⁵[MOGWAI LABS] Vulnerability notes: Log4Shell
⁶[Blackhat] A journey from JNDI/LDAP manipulation to remote code execution dream land
⁷[Microsoft ] Conseils pour prévenir, détecter et chasser l’exploitation de CVE-2021-44228 Log4j 2
⁸[GitHub de SwitHak] BlueTeam CheatSheet : Bulletins liés à Log4Shell
⁹[GitHub de nice0e3] log4j_POC
Vous pouvez également lire notre article sur : MSDT abusé pour atteindre RCE sur Microsoft Office.
Échangez avec l’équipe
Vous souhaitez en savoir plus sur nos solutions de protection ? Vous voulez découvrir nos produits de XDR et de CTI ? Vous avez un projet de cybersécurité dans votre organisation ? Prenez rendez-vous et rencontrons-nous !