Kioptrix 3 Walkthrough

George Chen
4 min readMay 5, 2019

link to VM

As with all VMs, the first thing I did was to scan the IP space.

root@kali:~# netdiscover
Currently scanning: 192.168.68.0/16 | Screen View: Unique Hosts

5 Captured ARP Req/Rep packets, from 3 hosts. Total size: 300
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname red ARP Req/Rep packets, from ----- -----------------------------------------------------------------------------
192.168.50.155 00:0c:29:bf:e3:e7 1 60 VMware, Inc.

With the IP address, I went on to enumerate the services behind it.

root@kali:~# ip=192.168.50.155
root@kali:~# nmap -T4 -sS -A $ip

From the results, I took note of a few key items:

  • Port 22 is open — brute force when username is available
  • Port 80 is open — enumerate pages
  • Kernel version is available — Search remote exploits
Heading over to the webpage, I was presented with the home screen

Navigating around showed links to kioptrix3.com, so I pointed the ip to the host in my /etc/hosts file.

Enumerating the webpages, I found some interesting phpinfo pages but what caught my eye was http://192.168.50.155/phpmyadmin/.

root@kali:~# dirb http://$ip

Being presented with the login page, I decided to find exploits on phpMyAdmin 2.11.3 on exploit-db, and while I didn’t manage to use the available payloads, I found that a few mentioned SQLI, and so I decided to test that out.

Didn’t manage to find any sensitive or helpful data in this

I wasn’t able to find a GET endpoint for injection, so I tried the union statement union all select 1,2,3,4,load_file("/etc/passwd"),6 on one of the tables but it didn’t work, neither did I think it would have.

Putting that aside, and given that this was an entry-level VM, I decided to look through the web pages for additional clue.

In one of the blog entry, a string that resembled a username was referenced. I wasn’t able to verify the username via finger, nor were there any other useful information in the source files. I thought I should give brute-forcing a shot while I hunt for other avenues.

root@kali:~#hydra -l loneferret -P /usr/share/wordlists/rockyou.txt $ip ssh -t 4

While waiting, I checked out the images hosted in the gallery for any hidden text that might have been packaged, or file names if they meant anything, but came up empty. By then, hydra returned with some promising results:

true blue star wars fan

With that, I got my first foothold into the server:

loneferret@Kioptrix3:~$ sudo -l  
User loneferret may run the following commands on this host:
(root) NOPASSWD: !/usr/bin/su
(root) NOPASSWD: /usr/local/bin/ht

Checking on my privileges, I see that I am able to tap on password-less access to root on the above two files. /usr/bin/su didn’t exist, so I tried to copy a version of su over to the path above:

loneferret@Kioptrix3:~$ sudo /usr/local/bin/ht -exec /bin/su
Error opening terminal: xterm-256color.
loneferret@Kioptrix3:~$ export TERM=xterm
loneferret@Kioptrix3:~$ sudo /usr/local/bin/ht -exec /bin/su

Once in the HT editor, I did an option + 7, save-as, and specified the new path as /usr/bin/su, but I did not manage to execute that.

I then tried to pull up /etc/passwd and /etc/shadow files using the same method above and saving-as different files on /tmp. Extracting these two files out and unshadowing them:

root@kali:~# unshadow ./passwd.txt ./shadow.txt > ./unshadow.txt
root@kali:~# john --wordlist=/usr/share/wordlists/rockyou.txt unshadow.txt

I found user dreg's plaintext password Mast3r, but that was not promising given that the user had even less privilege than the former.

With very limited Linux knowledge, I thought I should remove the root password from shadow file, so I edited my copy of it, with the root entry from root:$1$QAKvVJey$6rRkAMGKq1u62yfDaenUr1:0:0:root:/root:/bin/bash to root:x:0:0:root:/root:/bin/bash, using the same method above to save-as and overwriting the original /etc/shadow file:

loneferret@Kioptrix3:~$ sudo /usr/local/bin/ht -exec /tmp/shadow

I had to do a restart of the VM (perhaps there was a better way), but once that is done, I attempted to login to the Kioptrix box with root user, and was prompted to change my UNIX password. Once that is done, voila!

--

--

George Chen

Global Threat Hunting Manager at PayPal. George is a site lead for Innovation Lab & Community Impact. In his spare cycles, he lectures cybersec at a University.