Aerosol Posted January 8, 2015 Report Posted January 8, 2015 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 WiFiAs 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./.hiddenHere 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=windowsThe 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/offset1312768You 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 .........%.....d30 32 34 33 37 38 31 38 32 64 61 34 66 33 37 62 024378182da4f37b30 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 ..............ne78 75 73 2e 64 72 6f 70 63 61 6d 2e 63 6f 6d xus.dropcam.comAck, setup -> dropcamd4 09 ca 11 ff ff 00 01 00 00 ..........Data, dropcam -> setupd4 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 -> dropcamd4 09 ca 11 00 00 00 02 00 00 ..........Data, setup -> dropcamd4 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!.Ofa 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 ...............082 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........0G10b 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 C65 72 74 69 66 69 63 61 74 65 20 41 75 74 68 6f ertificate Autho72 69 74 79 31 10 30 0e 06 03 55 04 0a 13 07 44 rity1.0...U....D72 6f 70 63 61 6d 30 22 18 0f 32 30 30 31 30 31 ropcam0"..20010130 31 30 30 30 30 30 30 5a 18 0f 32 30 35 30 30 01000000Z..2050031 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...U04 03 13 14 6f 63 75 6c 75 73 37 34 2e 64 72 6f ....oculus74.dro70 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 privacySomething 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 connectionsThe 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.Source 1 Quote
