HTB Shocker Writeup
By abusing a known exploit named Shellshock, I was able to get initial access onto HackTheBox’s Shocker machine. For this, I used the metasploit exploit module apache_mod_cgi_bash_env_exec. Privilege escalation was pretty simple, did more enumeration to find suggested metasploit modules which one ended up privilege escalating my permissions to root.
Enumeration
Starting of with a standard enumeration scan: nmap -sC -sV -oA shocker 10.10.10.56. Bellow is the output:
Port 80 which is used for HTTP is open to us. Checking out what the main page is to see if there’s any clues:
We see that the home page is just an image. Next, I decide to enumerate to see if there’s any interesting directories.
The first tools I use is gobuster which is a CLI tool to bruteforce the websites files/directories. Here are the results:
Since gobuster didn’t pick anything up, I decide to use dirbuster, which is a similar tool excepted it has a graphical interace to see if it picks up anything. Here are the settings that I used:
Here’s what dirbuster finds:
There are a coupe interesting directories that dirbuster finds:
/cgi-bin//server-status/
Why gobuster didn’t pick up /cgi-bin/
Because of the way gobuster checks for files/directories, it doesn’t add a / at the end of the file name. So when visiting 10.10.10.56/cgi-bin, the page does not exist. However on dirbuster, this is account for so it also tries 10.10.10.56/cgi-bin/ which is a valid. This can be confirmed because if you use the wordlist in /usr/share/wordlists/dirb/small.txt it contains both cgi-bin and cgi-bin/ in the list of words so it picks it up the cgi-bin/. For gobuster, you can add the -f flag to append / at the end.
It looks like dirbuster didn’t find any files in each of those directories though. Doing research on the [cgi-bin directory and reading into the CGI wiki page I learned a bit how it works. Basically everytime there’s an HTTP call to a script file in the address.com/cgi-bin directory, instead of sending the file from the local server, the server runs that file locally and then returns the output to the web page. Reading into the security part of the wiki page In common with a number of other scripts at the time, this script made use of a function: escape_shell_cmd(). The function was supposed to sanitize its argument, which came from user input and then pass the input to the Unix shell, to be run in the security context of the web server. The script did not correctly sanitize all input and allowed new lines to be passed to the shell, which effectively allowed multiple commands to be run. The results of these commands were then displayed on the web server. If the security context of the web server allowed it, malicious commands could be executed by attackers.
Doing further research I come across the Shellshock wiki page. This is because one of the attack vectors for Shellshock is CGI. According to the wiki page When a web server uses the Common Gateway Interface (CGI) to handle a document request, it copies certain information from the request into the environment variable list and then delegates the request to a handler program. If the handler is a Bash script, or if it executes one for example using the system call, Bash will receive the environment variables passed by the server and will process them as described above. This provides a means for an attacker to trigger the Shellshock vulnerability with a specially crafted document request.
With this information I decide to do a new dirbuster scan in that directory:
In the picture above, I start the directory/file scanning in the URL: http://10.10.10.56/cgi-bin. And given what is read in the wiki pages, I add some file extensions: python, perl, and bash.
Here are the results of the scan:
This time, we see there’s a user.sh inside the cgi-bin directory!
Doing some research I come across this Rapid7 page with a metasploit module.
Here’s setting the correct options:
Running the module, we get a meterpreter session! Doing getuid and sysinfo outputs the following:
Doing the meterpreter command shell gives us a local shell to work with. Doing a whoami check shows we are user shelly. Looking around the computer, eventually I land in /home/shelly and doing an ls -la check there reveals the user.txt flag!
Privesc
To get a list of potential exploits that can work against this box, I use metasploit’s suggester module:
Running the module we get a few results:
I try the first module that the box appears to be vulnerable by: linux/local/bpf_sign_extension_priv_esc.
Setting the correct options:
At first, when I run the exploit, I get a [*] Exploit completed, but no session was created.. Looking into the settings I try something different by setting the LHOST (local host) to my HackTheBox address:
Then rerunning the exploit, this time we get a second meterpreter session!
Doing a getuid in meterpreter or whoami in the local shell, it shows we have root access:
Looking around the box, I come across the root flag in /root/root.txt
Flags
user:
/home/shelly/user.txtroot:
/root/root.txt
Sources
Last updated