Shocker Writeup w/o Metasploit
Last updated
Last updated
First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.
-sC: run default nmap scripts
-sV: detect service version
-O: detect OS
-oA: output all formats and store in file nmap/initial
We get back the following result showing that two ports are open:
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.
Let’s run an nmap scan that covers all ports.
We get back the following result. No other ports are open.
Similarly, we run an nmap scan with the -sU flag enabled to run a UDP scan.
I managed to root the box and write this blog, while this UDP scan still did not terminate. So for this blog, I don’t have the UDP scan results.
Let’s enumerate more on the open ports.
SearchSploit does not generate any useful exploits that we can use.
Next, visit the Apache server on the browser.
We get a page that does not have links to any other pages. Therefore, we’ll run Gobuster to enumerate directories.
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.
It finds the directory!
Now we need to enumerate more on the /cgi-bin/ directory. I’ll look for files with extensions “sh” and “cgi”.
-x: file extensions to search for
I get back a bash script (user.sh). When I visit the URL, it prompts me to download the file.
Opening the file shows us the following content.
Fire up burp and intercept the request to the bash script. The send it to Repeater.
The above image 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.
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.
First add the following string in the User Agent field in Burp.
Then start up a listener on your attack machine using the same configuration in the above string.
Go back to Burp and execute the request.
Burp shouldn’t give you a response if the exploit worked. Go back to your listener and check if you got a shell back.
We got back a low privileged shell! Grab the user flag.
It’s time to escalate privileges.
Run the following command to determine what permissions you have.
Yikes, I can run perl as root! Well, it’s yay for me and yikes for the system administrator. If I use perl to send a reverse shell back to my machine it will get executed with the same privileges that perl is running in. So if I run perl with sudo privileges, I’ll get back a reverse shell with root privileges.
Go to pentestmonkey and grab the perl code for a reverse shell. Don’t forget to add sudo at the beginning.
Before you execute the code, start up a listener on your attack machine with the same configuration as the above code.
Execute the code and we have root!
Grab the root flag.
I’ve never seen or had to use the “-f” flag with Gobuster, so that was something new that I learned while solving this box. I’ll definitely keep it in mind when I solve future boxes.
As for vulnerabilities, I counted three. The first being a web server insecure misconfiguration. I wasn’t allowed to access the /cgi-bin directory but for some reason I was allowed to access the user.sh file inside of that directory. The administrator should have restricted access to all the files in the directory.
The second vulnerability is that the web server was executing bash commands on a system that was running a version of Bash that was vulnerable to the Shellshock vulnerability. This allowed us to gain initial access to the system. Of course a patch is available and the administrator should have patched his system.
The third vulnerability is insecure system configuration. You should always conform to the principle of least privilege and the concept of separation of privileges. Giving the user sudo access to run perl, allowed me (the attacker) to escalate privileges.
