Security Review of Nest Camera

I love tinkering with home automation and security solutions.  The simplicity of turning on a light bulb with a voice command makes me giddy, and I totally geek out over building scripts with more complex interactions between multiple devices.  So, I recently purchased an Outdoor Nest Camera to point at my driveway for monitoring purposes (I’m not paranoid, but my driveway and mailbox are at the back of my house so I would like to see when strangers are there).  This was my first time playing with a Nest Camera device, so I was naturally curious about how it worked.

I am certain Nest (or Google) has done a fantastic job in designing and testing the security of their devices, but I like to see for myself how things work. I want to understand a bit more about what it is doing before attaching it as a permanent member of my home automation family.

Scope

My testing was limited to what can be done without damaging the camera, altering the device (I did want to use it after), or breaking the law.  Please look elsewhere if you are expecting a zero-days or DIY hardware hacking instructions. Here were my rules for this “engagement”:

• The Nest application itself was treated as out of scope for testing since I don’t have a contract to do so, meaning no tampering or fuzzing against it, but observing its network requests on my network (i.e. via a web proxy) is fine.  Any modification of the application code was strictly out of scope.
• Port-scanning the device and interacting with any interfaces is ok
• Any attack against the device that is plausible from a would-be attacker is in scope (e.g. deauth from my network to a rogue access point).
• Modification of requests going to Nest’s network services was treated out-of-scope. This is one of the biggest areas that would be in-scope during a penetration test.
• Physically cracking open and modifying the device was treated as out-of-scope (that usually just becomes a matter of time and effort).

Configuration

• My camera was set up on an internal lab network and received a DHCP IP of 192.168.86.41
• I set up the Nest app on an old Nexus 7 (Asus) tablet which received IP address 192.168.86.28.  The reason I used an older tablet for this was so that I could easily add a new trusted Certificate Authority (CA) in order to view encrypted web traffic through my proxy.  Starting with the Nougat release, Android disabled the capability to load a custom CA on non-rooted devices.
• I was Proxying web traffic through Burp Suite Pro on a laptop at 192.168.86.43:8080

Observations

By observing the web traffic and performing port scans across the device, it appears that the device does not accept any kind of input unless it is in setup mode.  So if you are trying to picture the architecture, basically what happens is the camera talks to the cloud and your mobile app talks to the cloud. So something like this:

Information is exchanged on the server (i.e. in the cloud) rather than establishing a direct connection from your application to your camera.  I see this as a good choice for an architecture because it makes the camera, in any normal scenario, inherently resistant to typical probing and fuzzing attacks. Your options are pretty limited when the device doesn’t expose a single port to the network.

The camera was seen making web requests to the following hosts:

• webapi.camera.home.nest.com
• nexusapi-us1.dropcam.com
• transport.home.next.com

I didn’t find any traffic that was super exciting.  It included an access token (good for 30 days) and a cookie, as might be expected, but was otherwise unremarkable.  It should also be noted that the initial call during pairing failed over my Burp proxy. I had to temporarily disable to proxy for that to complete.  I didn’t dig into this further but my guess is that it likely is using some form of certificate pinning.

Additional app features that are good for this device’s security:

1 – The application supports two-step verification.  You have to turn it on, but at least it’s there to make things harder for someone trying to brute-force their way through authentication.

2 – The application supports the concept of family accounts.  You can share Nest devices with other family members without having to share a password. This is a good thing, as traditional web cameras tend to default to a single account, encouraging people to share credentials.

One feature I noticed that is not favorable is the default (On) status of the microphone. My understanding is that in general it is legal to record video but illegal to record conversation without at least one party’s consent. I think those rules are a little different when you step on private property, but still: Google does not know where you are going to mount that camera. I was concerned about whether or not the camera will pick up conversation from people walking by who are not aware of it.  So to test this out, I used the very scientific method of recording myself (yes, talking to myself) at what would be a normal conversational volume at various distances from the device. What I found was that the microphone did not seem to record my voice when I was more than about 12 feet away. So this is less concerning than I thought it might be, but it was still enough of a concern that I turned the microphone off.

Conclusion

From a security perspective, the Nest camera solution seems to be very well thought out and architected to reduce attack surface. Also, the application includes the security features we would expect. The only thing I would caution users about is that the microphone will be on by default, so they should consider turning it off if the camera is positioned near a public area where people might have conversations.