Factory Reset Vulnerability in Netgear ARLO – NewSky Security
Update: CVE-2016–10115 and CVE-2016–10116 have been enlisted by MITRE. Refer to the following CVE entries:
In our ongoing curiosity of IoT products, we took a look at ARLO, a home security camera system from Netgear. ARLO is Netgear’s competing product to the Google Nest Dropcam. When I first researched network security cameras last summer ahead of a planned and lengthy vacation, ARLO, Bigo Live Apk Download was one of the security systems I had narrowed down. I installed it and it worked fairly well for me. In addition to having it for use, and with an increasing interest in IoT device security, I had a chance to reverse engineer ARLO.
After opening up the case, the board is fairly straightforward and uses Broadcom Wireless Router SoC.
Fig. 1 — ARLO system board with Broadcom SoC
UART Console Access
For my testing, I wanted to gain access to the console. I noticed a promising location on the left side of the board. After fiddling around a little bit with a multimeter, I identified 4 pins for UART. Basically, identifying UART pins is a simple process, especially when there are not many pinouts to probe (you can follow steps outlined here). From a vendor’s point of view, removing or disabling UART or JTAG pins can be a risky proposition as it will also remove the chances of debugging problematic devices. From the attacker’s point of view, it is a good entry point for further attacks.
Fig. 2 — ARLO UART pins
After soldering the UART pins, I connected it to a USB-to-TTL adapter so that I could easily access the console from a host machine.
Fig. 3 — ARLO board mod
After covering up the board with UART cables out, I am ready for testing and debugging ARLO’s security system.
Fig. 4 — Prepared system for testing and debugging with Netgear ARLO camera
Before I go further, let me explain the basic network connections that ARLO uses. Between the base station (which is a big white Netgear box) and individual cameras, they establish their own wifi network. This is not the network that is intended to be used by home users; it is created by the base station and each camera will join the network. The base station and each camera have sync buttons and when you press them, a WPS system is invoked. There is a potential security issue during the sync process and I will cover that issue in our next blog. Between the base station and the ARLO cloud, it mostly uses a wired connection.
Below is a concept diagram of an ARLO network.
Fig. 5 — Concept diagram of camera network
After you connect the UART cable and boot up the system, it shows a boot-up screen like the one shown below.
Fig. 6 — ARLO boot-up console
This is a common setup with embedded routers or network products. It uses an open-source boot manager and modified Linux system. It loads the main OS system from flash memory into main memory. One interesting aspect is that commonly, these IoT or embedded systems put password login at the console so that only the person who knows the password can get into the system. But with this product, there is no login or password protection. I could just get into BusyBox with root privilege. Now I am ready to explore the internal workings of the system.
Fig. 7 — Root access granted
Factory Reset Vulnerability
While investigating the security of this IoT device, I identified a simple bug. As similar with other router products, the Netgear ARLO base station has a reset button which restores the system to factory default settings. This is used most often when configurations are corrupted, or a problem occurs and a reset is required.
Fig. 8 — View of Netgear ARLO reset port
Personally, I was using ARLO system since last summer (2015), which is almost a year by now. During that time, I did numerous system resets whenever I felt like the system was unreliable or unstable. Presumably, it could be a common occurrence of others using this same system to have also performed factory resets. Below is an example of the system log file after a factory reset was initiated.
Fig. 9 — ARLO factory reset log
While experimenting with the ARLO security camera, I noticed that when the base station is factory reset, it loads a default wifi passphrase — which is 12345678 with a pseudo-random SSID in the format “NTGR_VMB_<10 digit numbers>”.
loaddefault finished
Passphrase — 12345678
BurnPassphrase OK
SSID — NTGR_VMB_1462245431
BurnSSID OK
This operation is performed by an executable that is run on the system by default “/bin/vzdaemon”. The following disassembly shows the routine performs the passphrase and SSID reset operation — I observed that the SSID reset is based upon the current date and time of the system.
Fig. 10 — VZDaemon routine
After the factory reset, you can confirm that the wpa_psk and other values are reset to the default 12345678 string.
# nvram show|grep 12345
size: 25206 bytes (40330 left)
wl_wpa_psk=12345678
wl0_wpa_psk=12345678
wla_preset_passphrase=12345678
wla_passphrase=12345678
With basic Wi-Fi tools, one can easily locate these systems. Any systems with an SSID format of “NTGR_VMB_<10 random digits>” would more than likely be a Netgear device that was factory reset. The device that was implemented with some preset configurations uses an SSID with a format of “NETGEAR< 2 random digits>”. There are some man-made generated passwords with it, but we don’t have enough collections of base stations yet to discuss whether the passphrase is randomly generated or not.
Fig. 11 — View of camera network SSID
Clearly, the Wi-Fi network is visible from the machines other than the ARLO cameras and can be joined using the default password of “12345678”.
After joining this network, I could access the ARLO base station. As I know the passphrase for this network, after collecting Wi-Fi packets from this network, I could decrypt the traffic to an unencrypted state which contained various JSON traffic between the base station and ARLO cameras. Beyond this basic communications traffic, I could also capture RTSP traffic — this is a protocol that carries the images and video stream from the ARLO cameras. This poses serious threats to physical security and safety of the consumers of the ARLO device.
To perform this Wi-Fi packet decryption, you need to capture Wi-Fi packets using monitoring mode. After that, generate PSK string using the wpa_passphrase tool from Linux.
Fig. 12 — Generate Pre-Shared Key (PSK)
With the Wi-Fi packet dumps opened from Wireshark, select Edit -> Preferences -> Protocols -> IEEE 802.11 -> Edit menu and add the PSK generated from the previous command.
Fig. 13 — Wireshark view of PSK
Now you can see the list of decrypted network connections between the base station and cameras.
Fig. 14 — Wireshark list of decrypted connections
Replaying RTP Sessions
I saw various JSON traffic data, but on destination port 554 of the cameras, the base station actually sends RTSP requests.
Fig. 15 — Wireshark view of RTSP session
From the RTSP protocol session, I could identify the UDP-based RSTP stream that contains actual camera footage. From the following log, I could deduce that the client is using 1038,1039 and server is using 9418 and 9419 as their UDP ports.
SETUP rtsp://172.14.1.101/live/track1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=1038–1039
If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMTRTSP/1.0 200 OK
CSeq: 3
Server: NgcRtspService/1.0
Date: Tue, Jul 16 2014 20:10:37 GMT
Transport: RTP/AVP/UDP;unicast;client_port=1038–1039;server_port=9418-
419;ssrc=1766339330;mode=play
Session: 1103527590;timeout=60
Content-Length: 0
From the list from UDP RTP sessions, I could easily locate the matching session.
Fig. 16 — RTP UDP stream list
Each UDP packets are sending RTP packets using standard RTP format.
Fig. 17 — RTP packets
I found that there is no easy or straightforward way to convert Wireshark PCAP data to a video file (MP4 file) that can be played on my machine. I wrote a simple python script that functions as an RTSP and RTP server. I extracted actual streams from the PCAP file and extracted video streams using the script, and replayed them on our own test machine. The following snapshot shows the result of the replay, and it showed fairly good image quality from the video footage replay — I intentionally pixelated the image to protect privacy.
Fig. 19 — Replay of video stream from PCAP file
Summary
The vulnerability I discovered only applies to systems that were factory reset at least once. To test the process required purchasing two camera systems. The new unit was already configured with a hard-coded passphrase set in the NVRAM (probably EPROM). But, when we performed a factory reset, the vzdaemon process will set factory default passphrase of “12345678” with an easily identifiable SSID pattern, and this passphrase can’t be reverted to any other passphrase! Ironically, only way to fix this yourself is that
Ironically, the only way to fix this yourself is for you to open up your box and run the NVRAM command yourself unless a vendor firmware update is provided.
Hypothetically, an attacker could snoop Wi-Fi SSID names to locate a system using the factory reset SSID, and join in the Wi-Fi camera network using the default password. They could then monitor the video stream, or potentially inject another video stream.
We notified the vendor of this issue and we are working together for the fix. In our next blog, we will discuss other potential security risks and attack vectors of the Netgear Arlo.
Update: Netgear addresses the vulnerability with a firmware update. For more information, see this link:
- Hacking
- IoT
- PoC
- Security