muhammad-ali007/log4j_cve-2021-44228Hands-on lab exercise for exploiting Log4Shell (CVE-2021-44228) with JNDI injection, LDAP referral servers, and reverse shell payloads. Includes detection, bypass techniques, and post-exploitation guidance.
The Log4j vulnerability, also known as "Log4Shell" or "CVE-2021-44228," is a critical security flaw in the Apache Log4j library. Log4j is a widely used Java-based logging framework that allows developers to log messages from applications to various destinations, such as files, databases, and console outputs.
The vulnerability was discovered in December 2021 and has gained significant attention due to its severity and potential for exploitation. It affects Log4j versions 2.x, and in some cases, even previous versions. The Log4j vulnerability is a Remote Code Execution (RCE) vulnerability, meaning that an attacker can execute arbitrary code on a targeted system by exploiting the flaw. The vulnerability is caused by a design flaw in the Log4j library related to the processing of log messages that contain specially crafted data.
The exploitation of the vulnerability relies on the ability to inject malicious code into the log message. This can be achieved through various vectors, such as user-controlled input fields, HTTP request headers, or other user-provided data that is passed to the log statement.
When a vulnerable application processes a log message containing the specially crafted data, Log4j interprets the data as a Java Naming and Directory Interface (JNDI) lookup. By exploiting this behavior, an attacker can craft a payload that triggers a JNDI lookup to a malicious server controlled by the attacker. This server can then respond with a payload that is executed on the targeted system, allowing the attacker to achieve remote code execution.
The impact of the Log4j vulnerability is severe because Log4j is widely used across various Java-based applications, including web servers, applications, and cloud services. The vulnerability allows attackers to gain unauthorized access to affected systems, potentially leading to data breaches, system compromise, and further exploitation of the compromised environment.
Today, log4j version 2.16.0 is available and patches this vulnerability (JNDI is fully disabled, support for Message Lookups is removed, and the new DoS vulnerability CVE-2021-45046 is not present). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)
However, the sheer danger of this vulnerability is due to how ubiquitous the logging package is. Millions of applications as well as software providers use this package as a dependency in their own code. While you may be able to patch your own codebase using log4j, other vendors and manufacturers will still need to push their own security updates downstream. Many security researchers have likened this vulnerability to that of Shellshock by the nature of its enormous attack surface. We will see this vulnerability for years to come.
For a growing community-supported list of software and services vulnerable to CVE-2021-44228, check out this GitHub repository (https://github.com/YfryTchsGD/Log4jAttackSurface)
While there are a number of other articles, blogs, resources and learning material surrounding CVE-2021-44228, I (the author of this exercise) am particularly partial to these:
The log4j package adds extra logic to logs by "parsing" entries, ultimately to enrich the data -- but may additionally take actions and even evaluate code based off the entry data. This is the gist of CVE-2021-44228. Other syntax might be in fact executed just as it is entered into log files. Some examples of this syntax are:
You may already know the general payload to abuse this log4j vulnerability. The format of the usual syntax that takes advantage of this looks like so:
This syntax indicates that the log4j will invoke functionality from "JNDI", or the "Java Naming and Directory Interface." Ultimately, this can be used to access external resources, or "references," which is what is weaponized in this attack.
Notice the "ldap://" schema. This indicates that the target will reach out to an endpoint (an attacker controlled location, in the case of this attack) via the LDAP protocol. For the sake of brevity, we will not need to cover all the ins-and-outs and details of LDAP here, but know that this is something we will need to work with as we refine our attack. For now, know that the target will in fact make a connection to an external location. This is indicated by the ATTACKERCONTROLLEDHOST placeholder in the above syntax. You, acting as the attacker in this scenario, can host a simple listener to view this connection.
The next question is, where could we enter this syntax? Anywhere that has data logged by the application.
This is the crux of this vulnerability. Unfortunately, it is very hard to determine where the attack surface is for different applications, and ergo, what applications are in fact vulnerable. Simply seeing the presence of log4j files doesn't clue in on the exact version number, or even where or how the application might use the package.
Other locations you might supply this JNDI syntax:
If you would like more information on this JNDI attack vector, please review this Black Hat USA presentation from 2016. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
POC
Exploitation At this point, you have verified the target is in fact vulnerable by seeing this connection caught in your netcat listener. However, it made an LDAP request... so all your netcat listener may have seen was non-printable characters (strange looking bytes). We can now build upon this foundation to respond with a real LDAP handler.
We will utilize a open-source and public utility to stage an "LDAP Referral Server". This will be used to essentially redirect the initial request of the victim to another location, where you can host a secondary payload that will ultimately run code on the target. This breaks down like so:
This means we will need an HTTP server, which we could simply host with any of the following options (serving on port 8000):
