UPDATE: On November 16, the Cybersecurity and Infrastructure Security Agency (CISA) announced that government-sponsored actors from Iran used the Log4j vulnerability to compromise a federal network, deploy Crypto Miner and Credential Harvester.
In this article Raxis, a top tier provider in cybersecurity penetration testing, demonstrates how a remote shell can be obtained on a target system using a Log4j open source exploit that is available to anyone.
Introduction
This critical vulnerability, labeled CVE-2021-44228, affects a large number of customers, as the Apache Log4j component is widely used in both commercial and open source software. In addition, ransomware attackers are weaponizing the Log4j exploit to increase their reach to more victims across the globe.
Our demonstration is provided for educational purposes to a more technical audience with the goal of providing more awareness around how this exploit works. Raxis believes that a better understanding of the composition of exploits it the best way for users to learn how to combat the growing threats on the internet.
Log4j Exploit Storyboard
The Apache Log4j vulnerability, CVE-2021-44228 (https://nvd.nist.gov/vuln/detail/CVE-2021-44228), affects a large number of systems, and attackers are currently exploiting this vulnerability for internet-connected systems across the world. To demonstrate the anatomy of such an attack, Raxis provides a step-by-step demonstration of the exploit in action. Within our demonstration, we make assumptions about the network environment used for the victim server that would allow this attack to take place. There are certainly many ways to prevent this attack from succeeding, such as using more secure firewall configurations or other advanced network security devices, however we selected a common “default” security configuration for purposes of demonstrating this attack.
Victim Server
First, our victim server is a Tomcat 8 web server that uses a vulnerable version of Apache Log4j and is configured and installed within a docker container. The docker container allows us to demonstrate a separate environment for the victim server that is isolated from our test environment. Our Tomcat server is hosting a sample website obtainable from https://github.com/cyberxml/log4j-poc and is configured to expose port 8080 for the vulnerable web server. No other inbound ports for this docker container are exposed other than 8080. The docker container does permit outbound traffic, similar to the default configuration of many server networks.
Note, this particular GitHub repository also featured a built-in version of the Log4j attack code and payload, however, we disabled it for our example in order to provide a view into the screens as seen by an attacker. We are only using the Tomcat 8 web server portions, as shown in the screenshot below.
Next, we need to setup the attacker’s workstation. Using exploit code from https://github.com/kozmer/log4j-shell-poc, Raxis configures three terminal sessions, called Netcat Listener, Python Web Server, and Exploit, as shown below.
Netcat Listener, Port 9001
The Netcat Listener session, indicated in Figure 2, is a Netcat listener running on port 9001. This session is to catch the shell that will be passed to us from the victim server via the exploit.
Python Web Server, Port 80
The Python Web Server session in Figure 3 is a Python web server running on port 80 to distribute the payload to the victim server.
Exploit Code, Port 1389
The Exploit session, shown in Figure 4, is the proof-of-concept Log4j exploit code operating on port 1389, creating a weaponized LDAP server. This code will redirect the victim server to download and execute a Java class that is obtained from our Python Web Server running on port 80 above. The Java class is configured to spawn a shell to port 9001, which is our Netcat listener in Figure 2.
Execute the Attack
Now that the code is staged, it’s time to execute our attack. We’ll connect to the victim webserver using a Chrome web browser. Our attack string, shown in Figure 5, exploits JNDI to make an LDAP query to the Attacker’s Exploit session running on port 1389.
The attack string exploits a vulnerability in Log4j and requests that a lookup be performed against the attacker’s weaponized LDAP server. To do this, an outbound request is made from the victim server to the attacker’s system on port 1389. The Exploit session in Figure 6 indicates the receipt of the inbound LDAP connection and redirection made to our Attacker’s Python Web Server.
The Exploit session has sent a redirect to our Python Web Server, which is serving up a weaponized Java class that contains code to open up a shell. This Java class was actually configured from our Exploit session and is only being served on port 80 by the Python Web Server. The connection log is show in Figure 7 below.
The last step in our attack is where Raxis obtains the shell with control of the victim’s server. The Java class sent to our victim contained code that opened a remote shell to our attacker’s netcat session, as shown in Figure 8. The attacker now has full control of the Tomcat 8 server, although limited to the docker session that we had configured in this test scenario.
Conclusion
As we’ve demonstrated, the Log4j vulnerability is a multi-step process that can be executed once you have the right pieces in place. Raxis is seeing this code implemented into ransomware attack bots that are searching the internet for systems to exploit. This is certainly a critical issue that needs to be addressed as soon as possible, as it is a matter of time before an attacker reaches an exposed system.
