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:

if (isset($c))
        {
        $c=clogin_d(base64_decode($c));

        $query="select ";
        $query.="username, ";
        $query.="password ";
        $query.="from ";
        $query.="user ";
        $query.="where ";
        $query.="uid='".addslashes(trim($c))."' ";
        $query.="limit 0, 1";

        $rs=mysql_fetch_row(mysql_query($query));

        $username=$rs[0];
        $password=clogin_d(base64_decode($rs[1]));
        }

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.


Vendor Contact:
Benchmark Designs' WHM Autopilot
URL: http://www.whmautopilot.com/
E-Mail: [EMAIL PROTECTED]
Mailing Address:
  WHM AutoPilot HCMS
  P.O. Box 401
  Secretary, Maryland 21664


Disclosure Timeline:
Problem Discovered: July 30, 2004
Vendor Notified: August 1, 2004
Public Release: August 1, 2004


About the Author:
The author is a student at the Rochester Institute of Technology, majoring in Software 
Engineering.
When he's not contracting programming projects, he enjoys fishing, soccer, basketball, 
and 
computer gaming. The author has a passion for anything UNIX, and has grown to detest 
Microsoft 
beyond his ability to represent that detest in text.

The author is posting this message anonymously due to the draconian license of the 
product. Being 
wary of legal consequences, the author decided it was best to release this message 
anonymously and forfeit credit for the find. Perhaps the vendor should persue one of 
two paths; 
The 
vendor should either release their product under a more open license, or charge less 
money for a 
product that can so easily jeopardize the stability of a business.


Greets:
I'd like to say hi to George, swoolley, and tautology, and to thank swoolley and 
tautology for 
helping to make this post possible.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Reply via email to