Schnitz schrieb:
Das Sicherheit nur Geld kostet und dem Unternehmen kein Geld einbringt ist jedoch auch ein unumstößliches Gesetz.
Man sollte aber schon die Kirche bisschen im Dorf lassen... Das ist ein verdammter Stick für den Homegebrauch. Das Teil ist "dumm" - zumindest als ich das Teil das letzte mal in den Fingern hatte. Kann nicht über nen Proxy surfen. Kann nicht in ein WLAN was per WPA(2) Enterprise, also über nen Radius anzumelden ist usw.
Und nimmt man es genau - auch in diesem konkreten Fall ist nicht das Device das eigentliche Problem (das Device sorgt nur für die reißerische Überschrift) - das Problem ist wie so oft der User, der einfach nur stumpf nen Link klickt. Leider hält sich CB mal wieder bei Security Themen äußerst bedeckt mit Details, wenigstens ist die Meldung diesmal nicht völlig falsch (entgegen der bis heute nicht berichtigen VPNFilter News zum Botnet, was HTTPS angeblich entschlüsselt), aber trotzdem ist sie schlecht recherchiert und vom Text her stark übertrieben dargestellt... (Erklärung siehe unten)
dpetereit schrieb:
@Huby9 Der Angreifer muss sich nicht im selben Netz befinden. Der muss dich nur dazu bringen, den Link zu klicken, während du im selben Netz bist, wie deine Google-Geräte sind. Nur als kleine Klarstellung.
Doch muss er - hier wäre es hilfreich, wenn CB Details hätte benannt anstatt reißerische Überschriften zu bringen und Text, der sich teils selbst widerspricht
Diese "Attacke", wenn man sie denn so nennen möchte (was ich so erst mal nicht tun würde) setzt voraus, dass:
A) ein DNS Rebinding stattfindet (das allein ist ein Thema für sich - CB erwähnt davon leider gar nichts)
B) der Clientbrowser die IP des Clients auf dem er läuft ermittelt ...
C) ... und dann pauschal für diese IP wohl als Class C Netz alle verfügbaren IPs befragt und guckt, ob die Antwort eins der benannten Devices ist
D) wenn ein Google Device gefunden wurde, nutzt man aus, dass auf diesem Gerät keine Authentication Mechanismen existieren um am Ende Standort abzufragen
-> das alles zusammen wird getriggert durch das Anklicken eines Links, welcher Script Code ausführt.
Das funktioniert aber nicht (mehr), wenn sich der Client und das Google Device in unterschiedlichen Subnetzen befindet. Selbst dann nicht, wenn diese geroutet wären, weil ohne weiteres keine Möglichkeit gegeben ist das Netz des Home/Chromecast zu finden (außer nem vollen Scan auf alle privaten IPs vllt - mit IPv6 wirds noch unmöglicher)
Warum ist das für mich keine Attacke?
Das Gerät soll (warum auch immer) offenbar genau diese Funktion haben - und es gibt keinen Schutz, da man bei Google vllt davon ausgeht, dass im lokalen LAN kein abgreifen derartiger Funktionen zu befürchten ist. (was privat auch nicht ganz von der Hand zu weisen wäre)
Das einzige, was hier im Thema "Attacke" ist, ist das DNS Rebindung. Das ist aber auch ein sehr alter Hut - und hat mit dem Google Device gar nix zu tun. Das funktioniert tendenziell auch bei allen anderen Geräten, die irgendwelche Anfragen beantworten.
Spinnt man das mal weiter - es wäre möglich einfach simpel Ton (Werbung lässt grüßen) abzuspielen, so nach dem Motto, "Alexa, mache xyz". Fruchtet wohl bei so manchem auch
Wenn etwas ohne viel Tam Tam einfach IMMER ansprechen soll, gehts halt nur ohne Authentifizierung.
PS: Authentication ohne Verschlüsslung wäre alterntaiv auch so ne Sache, also rein auth bei HTTP? Machts nur bedingt besser - für SSL brauchts wieder bisschen mehr Bumms auf der CPU des Geräts, es braucht Zertifikate, die Keys müssen/sollten gegen unbefugten Access geschützt sein, die Geräte, die mit dem Device über SSL kommunizieren müssen den Zertifikaten vertrauen usw. usf. Also auch alles nix ganz triviales.
RedDeathKill schrieb:
Als ich die Überschrift gelesen habe, dachte ich, dass die Geräte einfach so die Informationen weiterleiten. Dann las ich mir den Artikel durch und stellte fest, dass die Überschrift wenig Sinn ergibt.
Falls der Benutzer auf einen Link klickt, kann man schon andere Codes ausführen, dies könnte man auch an anderen Geräten durchführen, um beliebige Informationen auf den jeweiligen Geräten und über der Person abzurufen.
Ja, der Autor hat sich irgendwie darauf eingeschossen hier Google an die Karre zu pinkeln. Nicht dass ich das verhindern wöllte - aber die Aussagen sind wirklich nicht so ganz stimmig.
Am schlimmsten ist der mittlere Teil:
So funktioniert der Angriff
Alles, was für die Abfrage des genauen Standorts der Geräte erforderlich ist, ist dafür zu sorgen, dass die Geräte eine Liste der in der Nähe befindlichen Funknetzwerke an die Google-Geolocation-API senden und das Ergebnis empfangen. Da es sich dabei um eine von Google gewollte Funktionalität handelt, stellt das Verhalten noch nicht einmal eine Sicherheitslücke im engeren Sinne dar.
Zu einer solchen wird sie erst, wenn diese Abfrage von einem Angreifer von außerhalb des betroffenen Netzwerks gestartet wird, um mit den so gewonnenen Daten eigene Ziele zu verfolgen. Young konnte nachweisen, dass eben dieser Angriff recht einfach zu konzipieren ist. Sobald es gelingt, den Nutzer solcher Geräte dazu zu bringen, einen Link anzuklicken und für etwa eine Minute geöffnet zu halten, können die Standort-Daten abgefragt werden. Der angegriffene Nutzer muss sich zu diesem Zeitpunkt nur im selben Netz wie sein Home oder Chromecast befinden.
1) so funktioniert der Angriff eben nicht - da es kein Angriff ist. Der "Angriff" funktioniert (siehe oben) über DNS Rebindung, dem auslesen der lokalen Client-IP + das Scannen des lokalen Netzes (scheinbar unter Annahme es sei ein Class C Netz) auf das Vorhandensein der Google Devices. -> DAS wäre der Angriff.
- Eine Sicherheitslücke wird nicht zu einer SIcherheitslücke, wenn das von außerhalb des "betroffenen Netzwerks" gestartet wird.
- Von außerhalb des betroffenen Netzwerks passiert gar nix, wenn sich der Client nicht im selben Netz wie das Gerät befindet.
Wer mehr wissen will klicke bitte auf die Quelle, die CB in der News angibt und landet auf einer Seite die in ihrem Artikel den "Finder" des Problems verlinkt. In diesem Blogpost stehen dann auch paar mehr Details inkl. der Erklärung WIE der Angriff wirklich funktioniert, wenn man das wirklich Angriff nennen möchte...