another Kioptrix walkthrough. Really just trying to keep my brain “pentester-wired” for the upcoming OSCP exam in 3 days 🙂
This challenge was quite nice since there we multiple ways to get root and I had to lookup quite a few stuff in order to own the box. Learning of this box: Don’t skip SQLi form fields just because one isn’t working (because others just might!). I gave up SQLi since username didn’t react on it … later I tried the password field as well and that worked – but see for yourself.
First, netdiscover to find the box’s ip address.
Ah right – 172.16.198.143 is our man. Noted. Next the usual nmap scan.
Ah, something new this time. It’s not only HTTP and SSH but also SMB (Samba) — take a look at port 139 and 445 (and the .nse script output).
First, let’s take a look at the website on port 80.
Guess what. A LigGoat secure Login 🙂 Let’s try the usual SQLi attacks. Going for “Username: username” and “Password: ‘ or 1=1 #” we get the following screen:
Well, that didn’t quite work out. Looks like we need accounts for members that have a “page”. Let’s hunt them down. Two ways are possible to query for user accounts. SMB enumeration and a dirb scan with a big wordlist. Let’s do first an smb enum.
root@kali:~# enum4linux 172.16.198.143 Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Wed Mar 22 05:40:09 2017 ========================== | Target Information | ========================== Target ........... 172.16.198.143 RID Range ........ 500-550,1000-1050 Username ......... '' Password ......... '' Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none ====================================================== | Enumerating Workgroup/Domain on 172.16.198.143 | ====================================================== [+] Got domain/workgroup name: WORKGROUP ============================================== | Nbtstat Information for 172.16.198.143 | ============================================== Looking up status of 172.16.198.143 KIOPTRIX4 - B Workstation Service KIOPTRIX4 - B Messenger Service KIOPTRIX4 - B File Server Service ..__MSBROWSE__. - B Master Browser WORKGROUP - B Master Browser WORKGROUP - B Browser Service Elections WORKGROUP - B Domain/Workgroup Name MAC Address = 00-00-00-00-00-00 ======================================= | Session Check on 172.16.198.143 | ======================================= [+] Server 172.16.198.143 allows sessions using username '', password '' ============================================= | Getting domain SID for 172.16.198.143 | ============================================= Domain Name: WORKGROUP Domain Sid: (NULL SID) [+] Can't determine if host is part of domain or part of a workgroup ======================================== | OS information on 172.16.198.143 | ======================================== [+] Got OS info for 172.16.198.143 from smbclient: Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.28a] [+] Got OS info for 172.16.198.143 from srvinfo: KIOPTRIX4 Wk Sv PrQ Unx NT SNT Kioptrix4 server (Samba, Ubuntu) platform_id : 500 os version : 4.9 server type : 0x809a03 =============================== | Users on 172.16.198.143 | =============================== index: 0x1 RID: 0x1f5 acb: 0x00000010 Account: nobody Name: nobody Desc: (null) index: 0x2 RID: 0xbbc acb: 0x00000010 Account: robert Name: ,,, Desc: (null) index: 0x3 RID: 0x3e8 acb: 0x00000010 Account: root Name: root Desc: (null) index: 0x4 RID: 0xbba acb: 0x00000010 Account: john Name: ,,, Desc: (null) index: 0x5 RID: 0xbb8 acb: 0x00000010 Account: loneferret Name: loneferret,,, Desc: (null) user:[nobody] rid:[0x1f5] user:[robert] rid:[0xbbc] user:[root] rid:[0x3e8] user:[john] rid:[0xbba] user:[loneferret] rid:[0xbb8]
Here we go. Users robert, john and loneferret sound promising. Let’s check if dirb is able to find these “member pages” on the webserver.
root@kali:~# dirb http://172.16.198.143 /usr/share/wordlists/dirb/big.txt
Two “real” directories found. “john” and “robert”. Let’s go with these two and retry the SQL injection in the form. Using “Username: robert” and “Password: ‘ or 1=1#” we get this:
Great! Looks like we just found Robert’s password. Let’s SSH into the server.
Oh f00k. A limited shell (basically limiting the shell commands you’re allowed to use). This will definitely hinder us pwning the box. So, let’s break out of this. Luckily, this is usually quite easy (with a Python based lshell).
Done. Full bash shell acquired.
The next task will be privilege escalation (i.e. “become root”). I found two ways to get this on this box. Let’s first go for the quick and dirty version.
System is an Ubuntu 8 and running a kernel 2.6. Searching ExploitDB for a matching privilege escalation exploit.
After some trial&error, I found that ExploitDB ID 9545 works on this machine. Let’s compile the source code and host it on our machine.
Now download the exploit binary to the kioptrix4 server (yeah, because gcc isn’t installed there). Luckily, wget is installed which makes our life very easy. Please note the port I am using to serve my files. I picked 443 since 80 was blocked by an outgoing-firewall and 443 wasn’t.
Running this exploit gives us a root shell. System OWNED! Easy.
Now variant 2 which is a bit more work (but also like 10000% more interesting/fun).
As a pentester you’re always on the lookout for exploitable services – services, that have root/system privileges and hence, when exploited, allow us to run arbitrary commands as root user.
So, let’s check the process list for services running as root.
john@Kioptrix4:/tmp$ ps auxwww | grep root
Ok, that sounds interesting. mySQL running as root? I think I’ve read about a possible exploit for mySQL in that case….
Let’s verify our assumption by taking a look at the (world readable – sigh) my.cnf.
Yes, it’s true. mySQL is run as root user. There’s a nice exploit out there, you can find the code and details here: https://www.exploit-db.com/exploits/1518/
Following the details, we compile the code and create a shared lib. Please note that there was already a ‘raptor_udf2.so’ on the kioptrix4 server – so i picked a new uber-l33t name.
Now we transfer the shared object (.so) to the target machine (wget -> /tmp) and install it via mysql. Great that there’s no root password set for the mysql ‘root’ user which allows us easy access into the database. This setup can be found quite often since everyone thinks that it’s enough to restrict the mysql root login to localhost only – and there’s no need to set a password (since only root and legit users log in locally). Mhhh….
(Following screenshot isn’t 100% accurate since I had some tries before that and the foo table was already there when I did this final, working attempt – check the exploit link above the see full details of the required commands).
By completing the above commands, we now have a root-running mysql that is able to issue arbitrary system calls (as root, obviously). Here an example:
See? We’re able to create files on the filesystem with root ownership. Awesome.
Now it’s time for the final exploit. We’ll compile a bit of suid code, make it belong to root and set the suid bit (+s). John (or Bob, Peter or his wife, Mary) can then execute this file to become root.
Transfer the suid binary to the kioptrix4 machine (wget…) and continue messing around with the mysql do_system function.
This should have worked. Check out and execute the /tmp/suid file to become root.
Done! Game over. Ah, wait – the flag. Here we go.
Good fun! 🙂