Un premier blog a été publié sur l’exploit Log4j et un autre avec une deuxième méthode de détection pour détecter la première étape des exploits se produisant sur LDAP.
Dans ce blog, nous allons aborder une troisième méthode de détection, celle-ci se concentrant sur le téléchargement de la deuxième étape, lorsque la JVM télécharge des charges utiles de code Java supplémentaires via HTTP.
Notez que la technique que nous décrivons ici fonctionne même si un vecteur autre que LDAP est utilisé pour la première étape, comme cela a été récemment signalé.
Si vous téléchargez ce PCAP et l’ouvrez dans Wireshark, vous verrez les en-têtes suivants dans le GET HTTP de l’exploit :
L’agent utilisateur est “Java/1.8.0_51”, ce qui signifie que Java a lancé ce téléchargement.
Il télécharge un fichier appelé “Exploit.class”, qui est un fichier de classe Java.
Le serveur signale que ce fichier a un type MIME de “application/java-vm” :
Nous pouvons coder une détection pour ce scénario en utilisant Zeek.
CoreLight a ajouté cette détection à son CVE-2020-44228 Zeek Package dans un fichier nommé “CVE_2021_44228_java_GET.zeek”.
En haut du fichier, CoreLight configure ses nouvelles notices pour ce type de détection (lignes 3-5).
Aux lignes 7-9, est ajouté une variable à l’enregistrement de la connexion pour sauvegarder certains états associés.
Vous verrez aux lignes 12 et 14 des expressions régulières pour détecter Java dans les champs User-Agent et MIME.
Ensuite, nous gérons l’événement “http_header”.
Dans ce gestionnaire d’événement, CoreLight utilise ses modèles pour rechercher le type MIME Java dans les en-têtes HTTP.
Si une correspondance est trouvée, celle-ci est notée dans la variable d’enregistrement de connexion créée précédemment.
Ce process peut-être sauté, si (1) la méthode de requête est autre que “GET”, (2) les en-têtes proviennent du client plutôt que du serveur, ou (3) nous avons déjà vu ce que nous cherchons.
Enfin, nous traitons l’événement “http_end_entity”.
Les entités HTTP peuvent être imbriquées, donc l’entité la plus extérieure (non imbriquée) est vérifiée puis traîtée.
Ensuite une vérification est effectuée si nous avons déjà vu un en-tête HTTP indiquant que cette entité est Java, ou si Zeek a attribué un ou plusieurs types MIME à l’entité (ce qu’il fait en “sniffing” le “body” de l’élément) et si l’un d’eux correspond au modèle que nous recherchons.
Si l’une ou l’autre de ces conditions est remplie et si l’agent utilisateur indique que la requête provient de Java, alors la connexion est notifiée comme reflétant un log4j RCE réussi et un avis et de ce fait généré.
Lorsque cette détection se produit, un avis de type “LOG4J_JAVA_CLASS_DOWNLOAD” est écrit dans votre journal des avis.
Avec cette détection, nous avons maintenant couvert toutes les étapes des exploits les plus courants basés sur LDAP Log4j que l’on trouve actuellement sur Internet.
1) Nous avons identifié les tentatives d’attaques entrantes et collecté les sites qu’elles atteindront en cas de succès.
2) Nous avons identifié les connexions LDAP utilisées dans la première phase d’une attaque pour induire le téléchargement de code Java.
3) Nous avons trouvé des cas où une JVM désormais compromise passe à la deuxième étape et télécharge la charge utile finale.
Un avantage important de cette détection finale est qu’elle fonctionne même en présence d’un vecteur de première étape autre que LDAP.
Source : CoreLight
Pour plus d’informations concernant les solutions
