HestiaCP Admin Takeover & RCE
A low privileged user in HestiaCP can exploit a Broken Authorisation flaw to takeover Admin accounts.
HestiaCP allows low-privileged users to create cron jobs for themselves and, by extension, achieve code execution by default. This is expected behaviour. The permission model is designed around each web panel user corresponding to a Linux user, with filesystem access and process isolation enforced at the operating system level. Any cron jobs created by a low-privileged user execute as that same low-privileged Linux user.
The control panel itself, however, runs under a more privileged account. This account has passwordless sudo access to a number of administrative scripts required for managing the system.
The "panel cron jobs" are different. They can only be created or modified by administrators and execute as the more privileged panel user rather than an individual low-privileged account.
The authorisation code to prevent low privileged users from changing the "panel cron jobs" is implemented in the form of an if statement that redirects users away.
Unfortunately it's broken.
// This is supposed to check if the user is an Admin.
// Check user
if ($_SESSION["userContext"] !== "admin" && $user_plain === "$ROOT_USER") {
header("Location: /list/user");
exit();
}In the if statement, $ROOT_USER evaluates to "" because its undefined.
This means the if statement always evaluates to false and unauthorised users never get redirected.
As panel cronjobs can execute hestia/bin/scripts as sudo without a password, a low privileged user can add a call to a maintenance script which will change any user's password to one they specify to take over their account.
* * * * * sudo /usr/local/hestia/bin/v-change-user-password admin toor
After waiting at most 1 minute, the admin account's password will be changed to toor.
A patch can be found here. This currently needs to be applied manually until HestiaCP decide to create a release.
hestiacp