Motorola - Directory Traversal Investigation

Summary

A directory traversal vulnerability exists on what appears to be many Motorola network enabled baby monitor cameras. The issue is made worse since it appears that the web service running is running as root, resulting in the ability to view any file on the device.

A investigation into this vulnerability resulted in the following findings (all findings below require the attacker to be on the same network as the camera):

Ability to view the video feed of the camera (no authentication required).
Ability to control the camera (no authentication required).
Ability to update the firmware of the device (no authentication required).
Ability to obtain the SSID as well as associate security key.
Ability to obtain the user's master key.

This issue appears to be a flaw in the base OS/architecture used by these cameras since I have found similar issues documented online (see below in the Other Links section) with other models as well as references to some of the content in files on the device indicating other models.

Based on findings from 2016, it appears that some of the identified issues have not been resolved.

Details

It all started when I decided to view the reported vulnerability findings from my AlienVault instance, one of the High findings was a HTTP Directory Traversal vulnerability:

AlienVault reported HTTP Directory Traversal vulnerability.

So I decided to proceed an check on this, and determine if this was a true positive finding, and if so what other information could I gather. Using BurpSuite I ran preliminary ran through a bunch of checks for the obvious files (basing that this was running some form of unix based OS):

Screenshot of sitemap from Burp Suite scan (with word-list).

However using this approach was not getting me very far, even throwing some word-lists to attempt to do iterate and find files was not using all that useful. So I tried another approach, build the file system outside of the device itself. This involved using curl to download the files from the device and build the directory structure only local system. My thinking that this would then make it a lot easier to reverse engineer what was going on. I decided to work from the log file /var/log/messages and work my way from there.

Using curl to download /var/log/messages to local system.

Snippet from /var/log/messages from the device.

The next step was to start using files from logs and work my way from there. Eventually I ended up with all the possible files which I could identify from the files from logs as well as downloaded binaries and scripts:

Snippet of directory structure of download files from the device.

This was all good however, I still wanted to probe further since I felt there was more to uncover. So one approach I decided to use was to try intercept the traffic to the device, I know from a previous finding that they did not perform validation on the certificates for their TLS traffic. Unfortunately for me, it appears that they have fixed this issue since I could not intercept the traffic (I received TLS errors which is a strong indication that the client dropped the TLS handshake, thus performing the appropriate certificate validation).

A side note, I did some across to 2 alarming cases of credentials being stored in files.

In the first case I came across some FTP credentials (which I assume is used by the device in some manner):

Configuration file containing ftp credentials.

But perhaps more alarming, there were GMail as well as DropBox credentials as well:

Another side note, the device serves a few pages which are of interest. The first being a control page for the device:

The next page also allows one to interact with the device. I did confirm that it does work when you enable to the different options (such as "Play Lullaby"):

Control panel allowing for interaction with controls on the camera.

Perhaps most worrying was a page which allows one to upload firmware to the device (bearing in mind that all these pages do not require any form of authentication):

Control panel for the camera allowing for firmware upload.

Finally there is no image shown, I was not sure if this was an issue with the page or simply because I did not have Java installed. None the less I was able to get a video feed without requiring any authentication:

So my next plan of attack was to try obtain the firmware for the device. One of the binaries which I came across was called ota_upgrade. This obviously looked like a suitable candidate to look into further. Performing a strings on the binary resulted in some further information.

Snippet of performing strings on the binary ota_upgrade.

In the output I identified a URL: hxxps://<redacted>/ota1/0854_patch. Hitting this URL resulted in a 403. However after a Google search I managed to workout the format of the URL which was used for the firmware download (based off another URL for older firmware). And soon I was in possession of the latest firmware for the device.

My next goal was to see if I could get the WiFi key of the wireless network which the device is connected to. After a bit of looking around the firmware I was able to achieve this:

WiFi SSID and authentication key for wireless network.

Further investigation also resulted in the ability for one to be able to get the master key for the device:

My next task is to see if I can get root on the device. I will update this page with my progress over the coming weeks.

Internet Exposed Devices

In order to be able to exploit any of these findings, the attacker needs to be on the same network as the device. A Shodan and Censys search reveals that there are several hundreds of these devices open on the Internet:

Search results from Censys (on port 80).

Search results from Censys (on port 8080).

Vendor Disclosure

I tried several times to disclose the directory traversal vulnerability to the vendor, but they did not once acknowledge the issue. Below is the collection of correspondence with the vendor.