Subject: Benchmark Designs' WHM Autopilot (Probably all versions up to 2.4.5) vulerable to plain-text credential leakage via backdoor.
Preamble: Benchmark Designs' WHM Autopilot is a client management system made for webhosts, in order to simplify webhosting business management. It manages CPanel (http://www.cpanel.net/) and WHM (http://www.cpanel.net/) accounts, including account creation, maintenance, and removal. It is meant to be a solution to automate account billing and account creation.
(Taken from http://www.whmautopilot.com/index.php) Started by a webhost looking for more out of a simple managment script, Brandee Diggs (Owner of Spinn A Web Cafe, Founder of Benchmark Designs) setout to build an internal management system that could handle the day to day operations of a normal hosting company. The key was to remove the need to constantly watch your orders and mange the installs. Alas, WHM AutoPilot was born.
Knowing that the industry is constantly changing and the demands and needs of every webhost is different, the developers decided to pull in most of the suggestions from the licensee webhosts and add those requests as features into the script. Essential making the WHM AutoPilot the script built for webhosts, by webhosts - and it is still built that way today.
Problem: Benchmark Designs' WHM Autopilot is vulnerable to plain-text credential leakage due to a bug in client logins. In the client login page (/clogin.php) there is a built in backdoor for administrators to login as standard user accounts. This backdoor is accessed using the GET var 'c'. This variable is nothing more than an encrypted user ID, which is an automatically incremented field in the database. Using WHM Autopilot's encryption functions clogin_e(), and the PHP method base64_encode(), one can generate the hash required to get a user's username and plain-text password. The required WHM Autopilot functions are found in /inc/client_functions.php. Since the user ID field is automatically incremented, one can generate keys for as many accounts as desired. The code to generate these keys would be:
<?php $numAccounts = 5; // Set to any # for($i=1; $i <= $numAccounts; $i++) { echo base64_encode(clogin_e($i))."<br />";
?>
This code creates a list of values to feed to clogin.php as the GET variable 'c'. Once the complete URI is requested, including the GET var (e.g. http://somedomain/accounts/clogin.php?c=KEY), the login form will automatically take on the plain-text values of the account's username and password. Note that the passwords are stored using the same encryption methods as we find for the user ID here. I have found that you do not always get a fully working key on the first try. Sometimes the key you generate is only good enough to get you a plaintext username, but an encrypted password. If this is the case, continue generating the keys until you get one that gives you the plain-text password. Once the username and password are achieved, a simple click of the login button accesses an entire user account, including CPanel access, account cancellation access, and payment functions access.
Workaround: This bug can be fixed by removing the backdoor. Since clogin.php is thankfully not encoded with the Zend Optimizer, the backdoor code can be removed. The backdoor code needing to be removed is the following:
On version 2.4.5, this code is from line 77 to line 94. Simply removing this code, and saving the file, will remove this vulnerability. Removing this code will disable Administrative logins for standard users, but the vendor could easily conjure a workaround for that. Ultimately however, user credentials should not be stored in a form that can be resolved to plain-text, one way hashes should be used for added security, and no backdoors should exist.
An alternative workaround would be to use another vendor, that doesn't put backdoors in their code. Perhaps an open-source solution should be saught.
