SickOS is a vulnerable machine which can be found on:,132/

For some reason I couldn’t find the machine with the netdiscover tool. No idea why, but nmapping the whole NAT network worked.

So lets use nmap for the whole machine. We use the -sV parameter to get the version and -sC to use the standard scripts.

root@pentest:~# nmap -sV -sC
Starting Nmap 7.80 ( ) at 2020-01-15 11:03 CET
Nmap scan report for
Host is up (0.00019s latency).
Not shown: 997 filtered ports
22/tcp   open   ssh        OpenSSH 5.9p1 Debian 5ubuntu1.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 09:3d:29:a0:da:48:14:c1:65:14:1e:6a:6c:37:04:09 (DSA)
|   2048 84:63:e9:a8:8e:99:33:48:db:f6:d5:81:ab:f2:08:ec (RSA)
|_  256 51:f6:eb:09:f6:b3:e6:91:ae:36:37:0c:c8:ee:34:27 (ECDSA)
3128/tcp open   http-proxy Squid http proxy 3.1.19
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported: GET HEAD
|_http-server-header: squid/3.1.19
|_http-title: ERROR: The requested URL could not be retrieved
8080/tcp closed http-proxy
MAC Address: 00:0C:29:76:DF:14 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

We found three open ports, 22, 3128 and 8080. Poort 8080 is a closed proxy and 3128 is an open proxy. We can configure this proxy in our Browser. After configuring the proxy and going to we see a webpage with the text BLEHH!!.

Lets run dirb to see if we can find any directories on the website.

root@pentest:~# dirb -p
DIRB v2.22    
By The Dark Raver
START_TIME: Wed Jan 15 11:10:13 2020
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
GENERATED WORDS: 4612                                                          
---- Scanning URL: ----
+ (CODE:403|SIZE:291)                                                                                              
+ (CODE:200|SIZE:109)                                                                                               
+ (CODE:200|SIZE:21)                                                                                                  
+ (CODE:200|SIZE:21)                                                                                              
+ (CODE:200|SIZE:45)                                                                                                 
+ (CODE:200|SIZE:45)                                                                                             
+ (CODE:403|SIZE:296)                                                                                                                                                                                                                                      
END_TIME: Wed Jan 15 11:10:15 2020

We found a couple files. One interesting file is robots.txt which will list directories that the website owner rather not have indexed by search engines. It contains the directory /wolfcms

After looking around I couldn’t find anything interesting. I also ran dirb to find more directories, but nothing to special. So I ran Nikto to see if there are any vulnerabilities.

root@pentest:~# nikto -h -useproxy
- Nikto v2.1.6
+ Target IP:
+ Target Hostname:
+ Target Port:        80
+ Proxy:    
+ Start Time:         2020-01-15 11:20:24 (GMT1)
+ Server: Apache/2.2.22 (Ubuntu)
+ Retrieved via header: 1.0 localhost (squid/3.1.19)
+ Retrieved x-powered-by header: PHP/5.3.10-1ubuntu3.21
+ 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
+ Uncommon header 'x-cache' found, with contents: MISS from localhost
+ Uncommon header 'x-cache-lookup' found, with contents: MISS from localhost:3128
+ 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
+ Server may leak inodes via ETags, header found with file /robots.txt, inode: 265381, size: 45, mtime: Sat Dec  5 01:35:02 2015
+ Server banner has changed from 'Apache/2.2.22 (Ubuntu)' to 'squid/3.1.19' which may suggest a WAF, load balancer or proxy is in place
+ Uncommon header 'x-squid-error' found, with contents: ERR_INVALID_URL 0
+ 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.php
+ 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.
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ Uncommon header '93e4r0-cve-2014-6271' found, with contents: true
+ OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the 'shellshock' vulnerability (
+ 8726 requests: 0 error(s) and 15 item(s) reported on remote host
+ End Time:           2020-01-15 11:20:58 (GMT1) (34 seconds)
+ 1 host(s) tested

As we can see at the bottom, the webserver seems vulnerable to the shellshock vulnerability. Lets use searchsploit to see if there is any exploits available.

Since the webserver is running apache, the highlighted exploit seem interesting. Lets copy the file to our root directory since its easier and read it to see if we have to change anything in the file. After reading the file I saw an option to include a proxy, well we need it so we configured the host and the poort. Lets run the exploit:

And we got a reverse shell. We are logged in as the user www-data, the user that the web application is running on. To read the flag we have to be root. I checked cronjobs, SUID bits etc, but couldn’t find anything. After looking around for some time I found something interesting. I felt stupid that I didn’t check for this file before since dir found it but i couldn’t see the contents. Well, there is a file called config.php in the /var/www/wolfcms folder which contains the user credentials for the database.

I tried logging in with these credentials by sshing into the machine but this didn’t work. There should be more users so lets see. The shell we got is so broken, sometimes i need to hit enter again to get my output. But we have to deal with it or set up another shell. Lets cat the /etc/passwd file to find more users.

So there is two user we might want to try. Whoopsie and sickos, but whoopsie doesn’t have a shell. Interesting name tho. Lets try sickos and the password we found. Bingo we are in, lets see what user it is and if it can run sudo.

sickos@SickOs:~$ id
 uid=1000(sickos) gid=1000(sickos) groups=1000(sickos),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),111(lpadmin),112(sambashare)

It is in the sudo group, we can probably do sudo su to get root access and yup we got root 😀

root@SickOs:/home/sickos# id
uid=0(root) gid=0(root) groups=0(root)

Lets cat the flag file in /root to complete the machine.

root@SickOs:/home/sickos# cat /root/a0216ea4d51874464078c618298b1367.txt
If you are viewing this!!


You have Succesfully completed SickOS1.1.
Thanks for Trying