Kioptrix Level 1.3 (VM #4) Walkthrough

In my efforts to self-study in preparation for the OSCP certification later this year, I’ve been going through some of the intentionally vulnerable Virtual Machines (VMs) on vulnhub.com to sharpen and broaden my penetration testing and hacking skills. Among others I’ve completed, the Kioptrix series of VMs is allegedly similar to what you see in the actual OSCP test, so I’ve been going through them in order.

Part of completing the OSCP is providing a write-up of your hacking adventures to explain how and what you did to hack a server, so I figured I better start now. Other folks do similar write-ups on the VMs on vulnub.com, and I’ll see if they will add this to Kioptrix 1.3 page soon.

Hopefully, someone will find this useful either way.

It should be noted that this VM was known to have at least two possible paths to getting root on the system, and this writeup outline just one.

Discovery

On my local network, this VM turned up with the IP address of 192.168.0.110.

nmap

Running an nmap scan revealed some open ports and running services:

Poking Around

Checking things out by hand based on the nmap scan results, I found there was a login page running on port 80 at http://192.168.0.110

No basic SQL injection working from any initial attempts.

Nothing in the source code of note. Some other basic manual fuzzing and poking around didn’t reveal much either.

Nikto

Nikto turned up some basic stuff about Apache that I thought might be worth looking into later:

dirb and dirsearch

A basic dirb scan turned up a directory:
http://192.168.0.110/john/

I though that could be a username. Running dirb with a bigger wordlist (big.txt in Kali) turned up another one:
http://192.168.0.110/robert/

Both of those directories contained a file (robert.php and john.php) that, when clicked, would just redirect you back to the main login page.

I also ran DIRSEARCH, a python tool that also works well for finding directories and files.
found file: database.sql

(Note: Dirsearch is not included in Kali by default. Requires you to setup Python 3 in a virtual environment to run it.)

enum4linux

Since ports 139 and 445 were being used, I went on try enum4linux

acccheck

I ran acccheck on the ‘robert’ user with the big.txt pw list, to no avail. Can circle back to try the other usernames if needed.

THC Hydra

You can use Hydra to brute force FTP, SSH, POP3, and SMTP account. Let’s try Hydra with those usernames to find SSH accounts! Trying the usernames found via acccheck with SSH logins:

robert
root
loneferret
john

hydra -L users -P 10_million_password_list_top_100000.txt -t 4 192.168.0.110 ssh -vv

Nothing turned up! Bummer.

database.sql

This was found during discover with dirsearch, and it appears to be a short MySQL dump file. Since other avenues were turning out to be fruitless, I thought I’d give this a closer look.

Immediately, the first thing to note is that there’s a username and password shown in the dump file.

john
1234

Let’s try it on the HTML login form at http://192.168.0.110/index.php?. No luck!
I thought maybe that was a default password, so I tested it on the other known users as well (robert, root, loneferret), but still no luck.

Perhaps it’d work with SSH or SMB?
Negatory

The file at least led me to believe MySQL was in place, so perhaps some more SQLi exploration would help.

After a number of failed attempts and errors by trying various SQL injection strings, using this worked:

That took me to the User Admin Panel and showed the actual password.

That seemed kinda easy. But this is when things got hard, actually.

I logged out and confirmed that the password worked. It logged me back into that same page. But what good is that? Let’s try SSH again!

Shell obtained. However, the shell seemed to be extremely limited. As instructed at login, typing ? or ‘help’ gets you a list of allowed commands:

I was warned about trying to cd into the root directory, and getting kicked out if I tried again.

lpath is the same as pwd.

The only available command that looks somewhat useful is echo. Let’s see if we can echo the contents of .profile


Uh oh. It really did kick me out! Luckily, all I had to do was reconnect via SSH. Let’s try a different file:

Bummer. How about getting around now that we know it is possible to simply re-log via SSH if you get kicked out? No luck.

Must break out of the restricted “LigGoat” shell. To the Google!

Searching for “escape restricted shell echo” I found a handy article:
https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells

Trying a number of things, I finally found the right trick, which is to use Python to switch shells:

That was weird, but it worked, and I got a less restricted shell. This website was of much help to find the specific command needed: http://netsec.ws/?p=337

Finally, a useful shell. Well, more useful. It still seems to be a basic user account with no real privileges. So where to next? MySQL exists and can be leveraged to take over a box under the right circumstances, so before exploring other vectors, I decided to start with it.

MySQL

Revisiting the web directory and the application running on the website, I found a handy SQL statement in checklogin.php. This statement had the mysql connection string, including the username and password, which were simply:

user: root
pass: (empty)

That suggested the root password was never changed when MySQL was installed, so this was probably a default installation with few tweaks or security enhancements. Sure enough, I was able to log in:

Things got off track for a while here, as I wasn’t really sure what to do from this point. However, this Google search helped me:

That led me to a Facebook post, of all things:

https://www.facebook.com/notes/security-training-share/mysql-root-to-system-root-with-lib_mysqludf_sys-for-windows-and-linux/865458806817957/

It described the situation perfectly:

“We may have MySQL root access but not system root access for a number of reasons including having a shell account on the target whilst MySQL’s root user has been left unpassworded by default, or alternatively gaining access via SQL injection through a web application connecting to the database as root, which is something I see far too often.”

The necessary lib file was already at /usr/lib/lib_mysqludf_sys.so which meant I didn’t need to grab it from sqlmap and upload it to the system.

Modifying those instructions a little, there was no need to compile a c script (which I was unable to do as user ‘john’ anyway.

Where that article has this line:

Just do this instead:

Then drop out of MySQL and run this:

It should drop you into a root shell!

Root obtained. Mission complete!

 

About Will Chatham

Will Chatham is an Information Security Analyst, OSCP, Ethical Hacker, and Penetration Tester at a federal data center in Asheville, NC. Since Netscape 2.0, he has worked in a wide array of environments including non-profit, corporate, small business, and government. His varied background, from developer to search engine optimizer to security professional, has helped him build a wide range of skills that help those with whom he works and teaches.
Bookmark the permalink.

Leave a Reply