VunHub: Kioptrix Level 4

Kioptrix Level 4 is a difficult machine. It emphasizes on a numerous things from a not so common SQLi, limited shell to privilege escalation using MySQL function.

So, lets begin!


The first thing to do for enumeration is start an nmap scan against the machine's IP address and check if some webpage is hosted on the server.

The results obtained from nmap are

Here, it can be seen that only 4 ports are open which are 22, 80, 139 and 445. As port 80 is open, we check the web page hosted over there.

Two things can be figured out here, which are:

  1. The login page could be tested for SQLi.
  2. If the “LigGoat Secure Login” is some real application, then we can look for an exploit for the same.

When we search for “LigGoat” using searchsploit or Google, we can't find any useful information. So, we can can for SQLi in the username and password field on the form.

We can begin with the simplest SQLi payload i.e. ' OR 1=1-- in both username and password and in the response to that we get an error

This confirms that there is a SQLi possible. But any query does not provide us access. So, keeping this on help we can look for some other methods to get access to the machine. We know that other than port 80, ports 22, 139 and 445 are also open. So, we can use enum4linux to see if we can find some useful information. Along with that we can also run a directory traversal attack on the target IP.

From the output of enum4linux, we get 3 usernames:

And from the output of ffuf, we get the following directories

From these results, the directory named /john appears to be interesting

The link john.php redirects us back to the login page itself. We can also check if such directory exists for other usernames obtained from enum4linux.

And we can find that a directory /robert also exists, similar to that of /john but nothing for loneferret. Also, the file robert.php redirects to the same login page as john.php did.

We have 3 suspected usernames, so we can try SQLi using them i.e. enter the username as it is and provide ' OR 1=1-- as password but we get the same mysql_num_rows() error. It might be the case due to the trailing --, so we can try to replace it with #. Now our payload would be like ' OR 1=1#.

With username as john and password as ' OR 1=1#, we get logged in as "john" and get his credentials

Looking at the URL, we can see that we can change the passed value of username from john to robert which might reveal the password for "robert" as well. But nothing happens and we still stay on the same. page.

Gaining Access

We can try to use these credentials to get access to the machine via SSH.

But it appears that we are in a limited shell as many of the usual command are not working here. Also, at the beginning it says that we check the allowed commands by entering ? or help.

It is clear that we are allowed to execute a limited set of commands.

From the above output, it is also clear that we are only allowed to run these limited commands in the current directory only and accessing any other directory is forbidden.

After trying multiple command combination, when we enter help help we get the following output

We can search on Google to look for methods to escape lshell and one such article is this. In the article it has been mentioned that this shell can be escaped using echo as

Privilege Escalation

To get an idea of the system, we can run basic commands like

We can look for exploits related to Linux version 2.6.24–24-server. It can be easily found out that this version is susceptible to the Dirty Cow Exploit. So, we can download it on our attacker machine and send it to the target machine with python server and wget. But the issue here is when we try to compile the exploit on the target machine it says that gcc is not present on the system. So, we need to think of some other method and if we don't find anything else then we'll have to create a new VM with this same kernel where we can compile the exploit and then run it on the target machine.

On further enumeration we can find out that there are users named loneferret and robert on the system. We can try to switch to them but as we don't know the password the switching fails.

We can also check the process running as root and as our current user on the machine

From these processes, it can be seen that MySQL, apache2 and cron are being run as root. So, we can first check the cronjobs to see if we can find something useful over there

We can’t see any odd cronjob running over here. Now, we know that MySQL is being run as root and also that this is connected with the webpages because of which we were able to get the credentials of user "john". So, we can go and check the files in /var/www for any information that can be used to access MySQL database on the server.

In the file named as checklogin.php, we can find the credentials to access the MySQL database as root.

It is a not at all a good practice to keep no password for access a database.

Now, we can log into the MySQL database and check for any useful information over here.

The members database appears to be interesting over here. So, we can explore it first.

Now, that we have the password for user “robert” as well we can switch to his account. Also, the password appears to be a base64 encoded but it is not, so we can directly use the value as password.

After switch, again we enter a restricted shell for user “robert” as well. So, we can use the same echo command to escape this shell as well and check if user "robert" has access to some commands as sudo that we can use to escalate our privileges.

But even “robert” does not have access to any commands as sudo. We can check "robert's" home directory and files with SUID bit set but won't find anything useful.

At this point it almost appears as a dead end. But we know that this machine is vulnerable in some or the other way. So, we must keep exploring.

We don’t find any useful process that is running as user “robert” or “john”.

At this point if we reconsider all the information that we have then from that the most important thing is that we have access to MySQL as root. So, we can start looking for methods to use MySQL for privilege escalation.

We can find one article here to gain root as by using the MySQL functions. This can be done by first creating a function named sys_exec.

But it appears that the function sys_exec already exists in the database. We can check these functions in the database mysql in a table called func.

And here it can be seen that sys_exec already exists. So, all we need to do now is use this function to create a copy of /bin/bash and set its SUID bit so that we can access that copied binary as root.

And there we get the access to the machine as root.

Mind Maps

  1. Enumeration

2. Privilege Escalation

Some Key Points to Take Away

  1. Check the password field as well for SQLi. (We usually look for SQLi only in username).
  2. Check the processes running as root and look for privilege escalation using those processes.
  3. When stuck with a restricted shell first determine the type of restricted shell and then search for methods to escape it.

Reference Links

  1. Kioptrix Level 4:,25/
  2. Lshell:
  3. MySQL to System Root:

Do check out my other work and write-ups at

Just another CyberSec Guy