| I was lookin for something else when i came acorss this,
What's your opinions of this?
Summary
"Started by a webhost looking for more out of a simple management 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 manage the installs. Alas, WHM AutoPilot was born".
Multiple security vulnerabilities have been discovered in WHM AutoPilot ranging from Cross Site Scripting to PHP Code Injection.
Credit:
The information has been provided by GulfTech Security.
The original article can be found at: http://www.gulftech.org/?node=resear...00059-12272004
------------
Details
Cross Site Scripting:
There are a significant number of cross site scripting issues in WHM AutoPilot. Most of these are caused by calling scripts directly and specifying particular variable values yourself. Below are a few examples, though there are many more XSS holes than just the examples am showing below.
http://path/inc/header.php?site_titl...3E%3Ciframe%3E
http://path/admin/themes/blue/header.php?http_images='%3E%3Ciframe%3E
We believe that every file in the /themes/blue/ directory can be manipulated in this way, and of course this can be used to steal a users credentials or render hostile code.
File Inclusion Vulnerability:
WHM AutoPilot is susceptible to several potentially very dangerous file include vulnerabilities. Below are several examples of how files can be included and possibly executed remotely.
http://path/inc/header.php/step_one....one_tables.php
http://path/inc/step_one_tables.php?..._functions.php
http://path/inc/step_two_tables.php?..._functions.php
This can be used to include php scripts and possibly take control of the webserver and more. A user does not have to be logged in to exploit this vulnerability either so that just makes it even more dangerous.
Notice in the first sample, the "header.php/step_one.php"? Well, that was done to get around a piece of code that looked something like what is pasted just below.
if (ereg("test.php", $PHP_SELF)==true)
{
include $server_inc."/step_one_tables.php";
}
Which works because $PHP_SELF will return the value of "header.php/step_one.php" expectedly. The below excerpt was taken from the PHP manual.
"PHP_SELF
The filename of the currently executing script, relative to the document root. For instance, $_SERVER['PHP_SELF'] in a script at the address http://example.com/test.php/foo.bar would be /test.php/foo.bar. The __FILE__ constant contains the full path and filename of the current (i.e. included) file."
Information Disclosure:
By default WHM AutoPilot is shipped with a phpinfo() script that is accessible to anyone. As far as I know WHM AutoPilot needs register globals to work, but if you want to check php settings anyway the file can be found in the root directory as "phpinfo.php".
Found at: http://www.securiteam.com/unixfocus/6A00N2KC0E.html
----------
Found at: http://www.securiteam.com/unixfocus/5TP030UDPI.html
Benchmark Designs' WHM Autopilot Backdoor Allows Plaintext Credential Leakage 3 Aug. 2004
Summary
Benchmark Designs' WHM Autopilot is a client management system made for webhosts, in order to simplify webhosting business management. It manages CPanel and WHM accounts, including account creation, maintenance, and removal. It is meant to be a solution to automate account billing and account creation.
Due to a bug in client login code and the builtin login backdoor it is possible to generate the hash required to get a user's username and plain-text password.
Credit:
The information has been provided by MS Blows.
Details
Vulnerable Systems:
* Benchmark Designs WHM Autopilot versions 2.4.5 and prior
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:
--------------------------------- Begin Code ---------------------------------
";
}
?>
---------------------------------- End Code ----------------------------------
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 variable:
http://somedomain/accounts/clogin.php?c=KEY
The result is that 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 not 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:
--------------------------------- Begin Code ---------------------------------
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]));
}
---------------------------------- End Code ----------------------------------
In version 2.4.5, the code spans lines 77 to 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.
Disclosure Timeline
Problem Discovered: July 30, 2004
Vendor Notified: August 1, 2004
Public Release: August 1, 2004
Last edited by sounds; 02-01-2005 at 03:43 PM.
|
Add to Favourites 
Print this Article