The rise of web hosting control panels has changed the landscape of the web hosting industry dramatically. They reduce the barrier to entry for server administration by automating configuration and management tasks within a web-based GUI. Before this, server administrators had to configure their systems by hand, or through a suite of their own custom shell scripts and such.

While this has allowed more people to enter into the business and become resellers and administrators, it has its drawbacks. Some would argue that this has been damaging to the industry as it’s ushered in a wave of administrators who aren’t qualified enough or knowledgable enough to properly manage a server. In the right hands though, these panels can actually be a big help to both camps.

That argument aside, something has never felt right to me about a web interface that you log into as root to run commands. It’s essentially a root kit with a pretty front-end. That said, there are protections in place to prevent exploitation, and cPanel in particular has a great security track record, and their security team from my experience was responsive, and a pleasure to work with.

One problem that I don’t think gets enough attention with these control panels like cPanel, Plesk, Webmin, DirectAdmin, and others, is the possibility for self-induced Cross Site Request Forgery, for lack of a better term.

Consider this hypothetical attack:

1) Compromise one or more vulnerable sites on the server (perhaps an outdated Joomla or WordPress site), and inject code like the following:
[php]
if( preg_match(‘/https?:\/\/.*\/sess_token[0-9]{10}/’, $ref, $matches) ) {
$url=$matches[0].”/api/create_reseller_account.php?resources=unlimited”;
echo ““;
}
[/php]
2) Wait for a systems administrator, logged into the panel as root to click on the URL link for the hacked domain from the control panel. The above would have the sysadmin unknowngly create an account with full privileges. It doesn’t take much creativity to do far worse, like adding a public ssh key through the panel, changing the root password, or anything else they are allowed to do.

The CSRF session token, designed to prevent this type of attack will be useless because the administrator just provided it to the hacked site via the referer (if their browser is configured to pass referers, which is the default in most browsers). The method above creates a new tab in the victim administrator’s browser to make the malicious control panel request, but you could easily make this action less transparent. Note also that my regular experession matches an optional https, but I believe this attack will only work if the administrator is using non-secure access to the panel. * – See #2 below.

I submitted a very similar, and working POC to cPanel’s security team, and they corrected the issue ( Case 74889 ) within a few weeks. I am willing to bet however that it’s a problem in other panels like Plesk, and perhaps other parts of cPanel that provide URL links to sites on the server. In this case, the POC was very similar to the code above, and it the vulnerability was in URLs in the “Manage SSL Hosts” section of the panel. They corrected it by cleansing the requests before redirecting you to the destination domain so as to remove the referer.

The reason I call it a self-induced CSRF is because it’s not exactly a plain-vanilla CSRF attack. Typically you would post a malicious link to a remote forum, chat, or email it to them, hoping they already has an active session at some other site. For example:
[html]
Funny Cat Gifs LOL
[/html]

The above could be easily mitigated if the router’s admin panel used a randomized csrf token in the url.

However, in the case of the control panel attack, it bypasses any CSRF protections because the malicious link is clicked from the same origin being exploited, and the token is provided to us free of charge. If there’s a correct name for this type of attack, I don’t know it.

The moral of the story is:

1) Server Admin Control Panels will never really be secure.
2) * – Always use https if you have to use them. This is because browsers will IIRC, never pass a referer if the scheme changes from https to http, OR if the scheme remains https to https, but the origin changes.
3) Just don’t click on any remote urls from within a control panel if you don’t have to. Copy/paste to a new tab, or ‘middle click’ to open a new tab. (referer should not send this way)