The “Internet of Things” marketplace has been blowing up recently, and towards the end of last year we began seeing a lot of demand for security assessments of these types of platforms. To practice, we wanted to reverse engineer a consumer platform from scratch and look around for security vulnerabilities. What follows is the first of a three-part series on what we were able to do with the Dropcam. Through this research, we found the Dropcam has a pretty solid security model, so no 0day in this post. That being said, this type of reversing work is the most important prerequisite for finding security vulnerabilities, so we thought it would be great to share our findings and techniques with the security and reverse engineering communities. Hope you enjoy, and leave a comment if you have any further ideas to extend what we’re showing here.
For those that don’t know, the Dropcam is a cloud-based webcam. It connects to the internet over WiFi, and users interact through it entirely via the dropcam.com web interface, or through a mobile app. We purchased some Dropcam cameras to find out more about how it works. In this series, you’ll get an idea of how the process of reversing a device like the Dropcam works including the tools we use and how we use them. This project ultimately ends up going into hardware hacking, but as you’ll see below, you can often gather a lot of information about how a device works before you open the case. Everything in this first post was done without taking the Dropcam apart, while our next posts will discuss taking it apart and some hardware hacking basics.
Getting the Dropcam connected to the WiFi
As I was opening the Dropcam box, one of the first questions I asked was: how does it set up its WiFi connection? It’s supposed to connect to your WiFi and present a configuration interface through dropcam.com, but it must have to learn at least your WiFi SSID first to do that. The documentation tells you to plug the USB cable into your computer and run through setup.
When you plug your Dropcam’s USB cable into your computer, the camera enumerates as a USB mass storage device with a few files on it, including setup binaries for both MacOS and Windows:
$ find . . ./.dcdata ./.dcdata/volume.ico ./.dcdata/offset ./Setup Dropcam (Macintosh).app ./Setup Dropcam (Macintosh).app/Contents ./Setup Dropcam (Macintosh).app/Contents/Resources ./Setup Dropcam (Macintosh).app/Contents/Resources/English.lproj ./Setup Dropcam (Macintosh).app/Contents/Resources/English.lproj/InfoPlist.strings ./Setup Dropcam (Macintosh).app/Contents/Resources/OSXSetup.icns ./Setup Dropcam (Macintosh).app/Contents/Info.plist ./Setup Dropcam (Macintosh).app/Contents/PkgInfo ./Setup Dropcam (Macintosh).app/Contents/MacOS ./Setup Dropcam (Macintosh).app/Contents/MacOS/Setup Dropcam (Macintosh) ./Setup Dropcam (Macintosh).app/winicon.ico ./Setup Dropcam (Macintosh).app/desktop.ini ./Setup Dropcam (Windows).exe ./._Setup Dropcam (Windows).exe ./.VolumeIcon.icns ./._.VolumeIcon.icns ./._? ./autorun.inf ./.hidden
Here are a few lines from the output of lsusb on the host computer:
ID 0525:a4a5 Netchip Technology, Inc. Linux-USB File Storage Gadget ... idVendor 0x0525 Netchip Technology, Inc. idProduct 0xa4a5 Linux-USB File Storage Gadget ... iManufacturer 2 Linux 2.6.38.8 with ambarella_udc iProduct 3 Dropcam Setup ...
When I ran the setup binary, it opened a web browser to
https://www.dropcam.com/setup/d024378182da4f37b0e981946989f40a?cv=140&fv=15&hv=3&platform=windows
The 32-character string in the URL is the unique identifier of my Dropcam. As you go through the web interface to set up the Dropcam, your browser eventually gets sent a JSON blob from a Dropcam web server containing a list of network SSIDs, BSSIDs, and other details of wireless networks near the camera. This data is presented in a list so that the user can pick which access point they want their camera to connect to.
How does the server get the list of WiFi networks? It must be communicating with the Dropcam, but at first it’s not clear how. When the device is plugged in to a USB port, the Dropcam appears only as a mass storage device so somehow a mass storage device is talking to the Internet through my computer?
To investigate further, I set up the testing environment depicted here:
The executable ran in a Windows virtual machine with Process Monitor from the Sysinternals Suite inspecting its behavior, while I captured USB traffic and network traffic from the setup executable using two instances of Wireshark on my Linux host machine. The setup executable also started the Chrome browser in the Windows VM, which I configured to use Burp suite as a proxy.
Process Monitor gave me an initial idea of what was going on:
The setup binary is first reading the .dcdata/offset file (1), then doing reads and writes directly to the “disk” (2). The .dcdata/offset file is simply a text file with a number in it:
$ cat .dcdata/offset 1312768
You can see that 1312768 is the byte-offset into the “disk” where the setup executable is reading and writing (3). Wireshark lets us see the actual data that is being transferred back and forth. Here’s a screenshot of part of the USB capture:
You can see that a SCSI Write command is being made to logical block address 0xa04, with length 4 (1). 0xa04 is 2564, which multiplied by the 512-byte block size is byte 1312768. The length 4 multiplied by 512 is 2048 bytes; this write corresponds to the highlighted WriteFile command in the Process Monitor screenshot. The data being written is shown in the hexdump (2) of the URB_BULK packet (3) following the SCSI Write command packet.
What’s happening is that the setup binary is communicating with the Dropcam by reading and writing network packets from and to a “magic” address on the USB mass storage “disk”. By looking at multiple packets being sent over this USB channel and reading the setup binary in IDA, I was able to get an idea of the protocol.
Above is a screenshot from the IDA Pro disassembly of the Macintosh setup binary (the Mac binary had more symbols and was easier to read than the Windows binary). The screenshot shows a portion of the code involved in decoding received packets. All the packets that I captured started with the magic big-endian number 0xd409ca11. I found this code by searching in IDA for that number. You can see that that number (1) is confirmed to be a magic number by an error message that is reached when the first 4 bytes are non-zero and don’t equal 0xd409ca11 (2). In addition, bytes six and seven (3) appear to be a big-endian sequence number according to another error message (4), and bytes 8 and 9 (5) turn out to be a big-endian length field. Also, the remaining two bytes – 4 and 5 – appear to increment from -1 in packets with no payload from the setup binary to the Dropcam; it is presumed that these are acknowledgment packets.
Here are some packets, extracted from my USB Wireshark capture:
Init packet, setup -> dropcam:
d4 09 ca 11 ff ff 00 00 00 05 00 ff ff 00 00 ..............
Init response packet, dropcam -> setup:
d4 09 ca 11 00 00 00 00 01 25 00 ff ff 01 08 64 .........%.....d 30 32 34 33 37 38 31 38 32 64 61 34 66 33 37 62 024378182da4f37b 30 65 39 38 31 39 34 36 39 38 39 66 34 30 61 00 0e981946989f40a. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 8c 00 00 00 0f 02 00 01 00 13 01 bb 6e 65 ..............ne 78 75 73 2e 64 72 6f 70 63 61 6d 2e 63 6f 6d xus.dropcam.com
Ack, setup -> dropcam
d4 09 ca 11 ff ff 00 01 00 00 ..........
Data, dropcam -> setup
d4 09 ca 11 00 00 00 01 00 81 03 00 01 00 7c 16 ..............|. 03 01 00 77 01 00 00 73 03 01 4d e5 e3 9d c8 16 ...w...s..M..... 17 eb d7 4e 78 42 02 2e ef 7d 4b 14 d9 2b ad fe ...NxB...}K..+.. f2 e4 84 68 49 1f 0f fc 00 ab 00 00 06 c0 13 c0 ...hI........... 14 00 ff 01 00 00 44 00 0b 00 04 03 00 01 02 00 ......D......... 0a 00 34 00 32 00 01 00 02 00 03 00 04 00 05 00 ..4.2........... 06 00 07 00 08 00 09 00 0a 00 0b 00 0c 00 0d 00 ................ 0e 00 0f 00 10 00 11 00 12 00 13 00 14 00 15 00 ................ 16 00 17 00 18 00 19 00 23 00 00 ........#..
Ack, setup -> dropcam
d4 09 ca 11 00 00 00 02 00 00 ..........
Data, setup -> dropcam
d4 09 ca 11 00 01 00 03 06 1b 03 00 01 06 16 16 ................
03 01 06 11 02 00 00 4d 03 01 52 61 ba a6 7f 84 .......M..Ra....
26 84 98 0d ed 96 f2 07 e2 90 30 9c 6d 21 9d 4f &.........0.m!.O
fa 80 8f 91 3f 75 ba bd 01 d6 20 52 61 ba a6 7b ....?u.... Ra..{
f6 97 94 dc 02 28 3c 49 2c 2b c4 18 f8 8d df f3 .....(<I,+......
ac e9 de d3 06 fe bc ed 25 dd 7f c0 13 00 00 05 ........%.......
ff 01 00 01 00 0b 00 03 0b 00 03 08 00 03 05 30 ...............0
82 03 01 30 82 01 e9 02 05 00 ed f7 59 0d 30 0d ...0........Y.0.
06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 47 31 ..*.H........0G1
0b 30 09 06 03 55 04 06 13 02 55 53 31 26 30 24 .0...U....US1&0$
06 03 55 04 03 13 1d 44 72 6f 70 63 61 6d 20 43 ..U....Dropcam C
65 72 74 69 66 69 63 61 74 65 20 41 75 74 68 6f ertificate Autho
72 69 74 79 31 10 30 0e 06 03 55 04 0a 13 07 44 rity1.0...U....D
72 6f 70 63 61 6d 30 22 18 0f 32 30 30 31 30 31 ropcam0"..200101
30 31 30 30 30 30 30 30 5a 18 0f 32 30 35 30 30 01000000Z..20500
31 30 31 30 30 30 30 30 30 5a 30 3e 31 0b 30 09 101000000Z0>1.0.
06 03 55 04 06 13 02 55 53 31 1d 30 1b 06 03 55 ..U....US1.0...U
04 03 13 14 6f 63 75 6c 75 73 37 34 2e 64 72 6f ....oculus74.dro
70 63 61 6d 2e 63 6f 6d 31 10 30 0e 06 03 55 04 pcam.com1.0...U.
0a 13 07 44 72 6f 70 63 61 6d 30 82 01 22 30 0d ...Dropcam0.."0.
(etc.)
The setup binary starts out by sending an initialization command to the Dropcam (command 00 ff ff 00 00). The Dropcam replies with a packet containing its UUID (so the setup binary knows where to point the web browser), and a host for the setup binary to initiate a TCP connection to (nexus.dropcam.com). After that, every packet contains a 5-byte sub-header (the first byte is 0x03, the last two bytes are a length field), followed by data. This same data was captured by my other Wireshark instance which was capturing a TCP connection made from the setup binary to nexus.dropcam.com via a TLSv1 connection. The Dropcam requests a TCP connection be made, and the setup binary tunnels all of that connection’s traffic over the USB mass storage channel.
So this is how the Dropcam connects to the internet: it appears as a USB mass storage device containing a setup executable to the host computer; the setup binary then tunnels a connection from the Dropcam over the USB link by reading and writing at a particular offset into the raw “disk” and connecting out to the internet using the host computer’s internet connection. Meanwhile, the user is presented with a list of WiFi networks that the cloud server obtained over the tunneled connection. The user picks their network in the web interface, and types in their WiFi password. The selected network and password are then sent in a POST request to the cloud server, which pushes the password down to the camera, again over the tunneled connection.
Considerations for WiFi password privacy
Something that users should be aware of is that this approach requires users to upload their network password to the dropcam.com server, and it might not be clear to a non-technical user that they are doing this. Dropcam (the company) probably isn’t doing anything directly with the transmitted WiFi encryption passwords, but there’s no guarantee that an attacker who could compromise the Dropcam cloud servers wouldn’t. It’s always a good practice to avoid sending confidential data to the cloud instead of making the setup binary directly communicate the WiFi information to the camera, so we’re not sure if there is some other product architecture reason to do this that we’re not aware of.
Further exploring the encrypted connections
The Dropcam makes two outgoing TLS connections over the USB tunnel. The first is to nexus.dropcam.com; that connection directs the camera to connect to an “oculus” server; my Dropcam connected to oculus101.dropcam.com. The camera itself makes the same two TLS connections over WiFi once it is configured; a short connection to nexus.dropcam.com followed by a long-term connection to an “oculus” server. The long-term connection is used for all of the camera’s communications including streaming video, configuration changes, and firmware updates.
After understanding how the Dropcam tunnels its TLS connections out over the mass storage interface, the next step was to attempt a man-in-the-middle attack on the TLS connections in order to capture their contents. However, the TLS connections utilize both client and server side certificate verification – when making the outgoing TLS connections, the Dropcam checks the server’s certificate, and the server also checks the Dropcam’s client certificate. Since the TLS connection endpoint is on the camera itself (not in the setup binary), I wasn’t able to inspect the contents of the TLS connection until after I’d taken the Dropcam apart, which I’ll describe in our next Dropcam blog post.
Follow us on twitter @IncludeSecurity and check this blog again next week for subsequent posts in this Reverse Engineering series.
Is there any way of deleting the account associated with the camera? I just bought 2 off of Craigslist , they are apparently useless:( my wife is pissed at me for buying them of CL..:(
I bought one from Home Depot, which was apparently a registered return. I had to scan and email my purchase receipt for dropcam to re activate in my name.
What exact model of dropcam did you reverse?? Could you please provide a picture? Thanks