Note to mods: no details are being given in this thread which could assist someone in gaining access to, escalating privileges from, or otherwise harming any server using Lxadmin / Kloxo. Something to please consider before prematurely mashing the "edit post" button.
I like to seek truth in things, which is why I'm compelled to write this. What software someone chooses to use is of no concern to me, and influencing anyone's decision is not the point of this post. I have nothing to gain from posting this. However, someone else reading this might.
Recently someone was plugging Lxadmin / Kloxo on WHT for its stellar reputation for security, presumably partly due to its lack of public history of security problems, and also because of claims made by the vendor on their website. As someone who enjoys looking for bugs in software, this prompted me to install OpenVZ and Kloxo (hostinabox575 on CentOS, specifically). What I found over the course of a few days were numerous issues, both local and remote, that directly contradict many statements made by the vendor on their website.
To be very blunt: the security of Kloxo sucks. Let's start with the following quote from http://lxlabs.com/software/kloxo/security
Kloxo itself runs as user 'lxlabs' which is simply yet another user in the system, who has absolutely no special permissions. All system executions are handled by another process that runs in the background and communicates with kloxo through a socket. This security model works on both Windows and Linux, and makes sure that even if kloxo itself is compromised, the attacker cannot have any access to the system.
Let's take a closer look, shall we?
[root@testing574 ~]# ps -u lxlabs
PID TTY TIME CMD
10054 ? 00:00:00 kloxo.httpd
pid 10054, kloxo.httpd, the only process currently found running under the user "lxlabs". Let's strace that pid while executing the command "id" from the Command Center (this requires being logged in as admin). Here's the output:
[pid 17662] execve("/bin/sh", ["sh", "-c", "id 2>&1"], [/* 34 vars */]) = 0
and here's the output:
Sure looks like kloxo, in that instance, was running with some special permissions to me!
Here's another quote from that site:
User cannot perform any operation on any file other than the one's he own. Before every operation is carried out, it is determined to see if the user fully owns every file that are involved in the operation, and kloxo will fail otherwise. Any attempts by the user to read or copy the system files or any other's files will result in an exception being raised. (That is, IF he manages to break out of the jail).
There are multiple ways append data to or change the permissions of files on the fs that do not belong to the user performing the operation. Imagine what could be done if you were able to take complete control over any file on the box, such as /etc/shadow. You could replace root's password hash with your own, or change your uid to 0, or add other accounts with elevated privileges, etc. There are multiple ways that this can be done via Kloxo as a client or a reseller. Kloxo does not fail when this happens, but freely and blindly allows it.
All program executions are carried out only after the context is switched to that of the user who requested it. Thus even if the user manages to break out of the jail, the maximum privileges that he can achieve is that of the system user consigned to him.
Complete Logging. Kloxo logs every single change that was made to the file system, and also every single execution of any external program. These logs will help you track down any kind of attempts to gain system privileges.
Logs are useless when someone else has the ability to alter them.
Other bugs that exist in this software include:
- the ability for resellers to potentially hijack new accounts before they're even created (all software that offers reseller capabilities is vulnerable to this to some extent. cPanel is the only one I've seen so far that has actually done anything about it. DA might have as well, but I haven't checked. They were informed of this 9 months ago).
- using unprivileged ports for services by default, and doing nothing if something else is binded to them (cPanel checks to make sure that it, and only it, is what's using the ports it listens on. I don't recall what DA does. Kloxo doesn't care). You can change at least 2 of the ports (7777 and 7778), and I would recommend doing so.
- default passwords for root, for the admin user, and for the kloxo db (and for other services? Is this documented anywhere at all?).
- local users (clients or resellers) can quite trivially execute commands as root. This has nothing to do with the Command Center as mentioned above while logged in as the admin user.
- remote, unathenticated users can cause lxguard to block any IP address of their choice
- remote, unathenticated users can cause Kloxo to consume all server memory
- remote, unathenticated users can create directories of their choice anywhere on the filesystem
Now, for those using Kloxo, I have emailed them about this a few days ago. Someone did respond a few days later saying they would look into the issues. As best as I can tell from my webserver logs, nothing yet has been investigated (although that is not the point of this message). I haven't shared the actual details of this information with anyone, nor do I plan to at this time. The fact that the bugs exist is not the point. The incredibly arrogant, egotistical, and belittling statements from the vendor about others is why you are reading this now. They are attempting to profit off of making others look bad, when in fact the ones they so often talk bad about are the ones that generally don't give up root nearly as easily, and nearly as often.
Here is just 1 of a number of such statements posted by the vendor in their own forum, which I just came across earlier, and was the catalyst for making this post:
We are not emulating [competitor panel] dev's lack of programming ability or their incapacity to understand security.
I specifically removed the name of the vendor which they chose to attack, because it is not relevant. What is relevant, in my opinion, is informing people that vendors will be vendors. They spend weeks, months, years into a product for one reason only: to make money. Of course they're going to claim their product is secure and works as expected. That's what they're supposed to say. Making such claims is understandable, and many people fully know and understand this, of course. Intentionally spreading malice and attempting to damage the reputation of others for profit, however, is not something that I feel should let slide, given the knowledge I possess about the software on both sides.
Bottom line: go ahead and use Kloxo. You will either get hacked, or you won't. That holds true for most software. But I'd recommend against buying into the hype and the vitriol from this vendor, at least until their software stops constantly giving up root, and letting people trash the filesystem, and letting people remotely crash the software, etc etc. Kloxo has some good ideas (many of which are just borrowed from actual implementations of other panels), but it is just a baby right now and, as such, has little to no defense against attacks.