- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,156
- Punkte für Reaktionen
- 1,707
- Punkte
- 113
Der "MyFRITZ!"-Dienst war ja vermutlich Ziel von Angriffen, die nachträgliche Einführung von Captchas Ende Januar (damals noch mit eigener Implementierung, bevor der Dienst dann nach einiger Auszeit mit Google's ReCaptcha wiederbelebt wurde) - die ja jeder aktive MyFRITZ!-GUI-Benutzer bemerken mußte - war sicherlich auch nicht nur der (theoretischen) Erkenntnis geschuldet, daß man mit erbeuteten E-Mail-Daten (z.B. von Android-Geräten mit WebView-Lücke, wo man - ich habe es an anderer Stelle schon einmal angemerkt, aber es gehört auch hier her - dann bei vielen Leuten gleich die Information zur E-Mail-Adresse (i.d.R. == Store-Benutzer) und bei Vorhandensein einer FRITZ!-App auch zur Existenz einer FRITZ!Box erhält) vieler Kunden garantiert auch dort ein Login (automatisch) versuchen konnte.
Das liegt zu einem guten Teil eben auch daran, daß die Beschreibung/Information zum MyFRITZ!-Konto sowohl in der Webseite:
Anhang anzeigen 81572(Screenshot von www.myfritz.net vom 20.04.2015)
als auch beim Anlegen eines MyFRITZ!-Kontos in der Box
Anhang anzeigen 81573(aus FRITZ!OS 06.23 für die 7390)
dahingehend ungenügend sind, daß dort nicht ausdrücklich davor gewarnt wurde, für das Login in die FRITZ!Box und das Login in die MyFRITZ!-Seite dasselbe Kennwort zu verwenden. Die Formulierung im FRITZ!OS-GUI
ist zwar sachlich richtig und nicht zu beanstanden, aber erstens liest fast kein Mensch - jedenfalls keiner meiner eigenen Tester - diesen Satz (was wo hin soll, steht ja vor den Eingabefeldern) und zweitens fehlt - meine Ansicht - die explizite und optisch hervorgehobene Warnung, ein an anderer Stelle bereits verwendetes Kennwort hier erneut zu benutzen. Ganz im Gegenteil ... der enge optische Zusammenhang zwischen der Eingabe einer E-Mail-Adresse und eines Kennworts führt bei vielen Benutzern automatisch zu dem Reflex, dort ebenfalls das E-Mail-Kennwort einzugeben, einfach weil ihnen der Unterschied gar nicht klar ist.
Das ist beim Anlegen eines neuen Benutzers in der FRITZ!Box-Oberfläche noch viel krasser, da dort das Formular noch "verwirrender" (für den Laien) ist:
Anhang anzeigen 81575
Die optionale Angabe der E-Mail-Adresse beim Anlegen eines Benutzer assoziiert für viele - so "dumm" das in den Augen mancher auch sein mag - tatsächlich die Angabe des Mail-Kennworts im Formular. Ich bin jedenfalls schon oft genug gefragt worden, ob da das Mail-Kennwort eingegeben werden muß, wenn ich Hilfestellung beim Einrichten eines Benutzers geleistet habe. Auch die oben verwendete Formulierung
ist nicht einmal jedem "FRITZ!Box-Versteher" sofort eingängig, da es aufgrund des Satzbaus nicht eindeutig ist, ob da "... Benutzername [bzw. der E-Mail-Adresse] und des Kennworts ..." oder "Benutzername - bzw. der E-Mail-Adresse und des Kennworts - ..." gemeint sein soll.
Es sind aber zwei (bzw. drei) vollkommen getrennte Konten/Dienste und wer für alle nur ein gemeinsames Kennwort verwendet, muß sich am Ende nicht wundern, wenn er - sollte es tatsächlich mal soweit kommen, daß z.B. die Datenbank hinter MyFRITZ! gehackt wird, es hat schon ganz andere Kaliber der Branche getroffen, daß die Kundendaten zugänglich waren - unerwünschten Besuch auf seiner FRITZ!Box erhält. Gleiches gilt natürlich für die verwendeten E-Mail-Konten, wobei die Sicherheitsvorkehrungen bei den E-Mail-Providern (meist nach Vorfällen) inzwischen ja fast überall entsprechend erweitert wurden.
Nur der MyFRITZ!-Dienst hinkt in meinen Augen hier noch nach ... was nichts über die Sicherheit der Speicherung von MyFRITZ!-Konten bei AVM aussagen soll, da habe ich keine Ahnung, wie das umgesetzt ist und ob das angreifbar ist oder nicht. Aber die "übliche" Vorgehensweise beim MyFRITZ!-Dienst, E-Mails zum Zurücksetzen des Kennworts an die hinterlegte E-Mail-Adresse zu senden (die gleichzeitig der Benutzername bei diesem Dienst ist), läßt das Hacker-Herz höher schlagen, wenn am Ende vom Benutzer für das Login in die FRITZ!Box das Mail-Kennwort verwendet wird und genau dieses Mail-Konto sich bereits unter der Kontrolle des Hackers befindet.
Die oben erläuterte Wahrscheinlichkeit für identische Kennwörter ist - in meinen Augen - ein Lapsus (hinsichtlich Usability), den sich AVM zurechnen lassen muß. Wenn man das Anlegen eines Benutzers im Rahmen eines Usability-Tests nur mal mit 20 "unbelasteten" Testpersonen (das ist eben die schwäbische Hausfrau, bei der sich die Sparsamkeit auch auf die Anzahl der verwendeten Kennwörter auswirkt oder der "Ich muß mir wirklich Wichtigeres merken."-Typ, für den das Einrichten eines Kennwortes an sich schon eine Zumutung ist, weil das ja auch ohne funktionieren würde) ausgeführt hätte, sollte das eigentlich dabei bereits aufgefallen sein. Wenn es solche Tests tatsächlich gab und dieses "Problem" dabei nicht auftrat, waren die Testpersonen vielleicht schlecht gewählt.
Schon eine kleine Änderung im Formular (Verschieben des Kennwort-Felds hinter den Benutzernamen und Ändern der Beschriftung in einen eindeutigen Wert samt passender - farblich hervorgehobener - Erläuterung) würde da wahre Wunder wirken ... aber vielleicht es ist am Ende ja auch die Schuld des Kunden, wenn er sich so blöd anstellt, da kann AVM ja schließlich nichts dafür (auch wenn man keine Vorkehrungen gegen solche "Fehlbedienungen" trifft). Usability geht aber - zumindest meines Erachtens - anders ... und die FRITZ!Box richtet sich sicherlich weniger an Fachleute als an Laien, das muß man dann einfach auch beim Interface-Design berücksichtigen.
Aber auch dann findet ein Angreifer ja erst einmal die FRITZ!Box noch nicht ... selbst wenn die Adresse des E-Mail-Kontos, der MyFRITZ!-Benutzername und der FRITZ!Box-Benutzername (auch da ist die synonyme Angabe der E-Mail-Adresse beim Login ja möglich, solange sie beim Benutzer eingetragen wurde, selbst wenn die in der Select-Box bei der LAN-Anmeldung nicht angezeigt wird) ebenso übereinstimmen wie das E-Mail-Kennwort und das Kennwort für die Anmeldung in der FRITZ!Box. Ich kenne persönlich genug Leute, wo das der Fall ist und eine entsprechende Warnung nur Schulterzucken hervorruft. Solange dann niemand die passende FRITZ!Box lokalisieren kann, ist das sicherlich auch zu verkraften (trotzdem schlechter Stil), aber kommt dann auch noch der MyFRITZ!-Dienst als Bindeglied ins Spiel, ist diese Verbindung im Handumdrehen hergestellt.
Leider nutzt dann auch ein abweichendes MyFRITZ!-Kennwort nichts mehr, wenn man bei diesem Dienst einfach eine E-Mail-basierte Kennwort-Änderung veranlassen kann, ohne irgendwelche zusätzlichen Sicherheitsfragen (das übliche "Wie hieß der Mann der Frau dieses Malers?") beantworten zu müssen. Das Captcha schützt nur vor Bots, nicht vor "Click-Workern", der Rest (Auswertung der Rücksetz-Mail und "Klick" auf den dort angegebenen Link) ginge dann ohnehin wieder automatisch weiter ... das Eintragen eines neuen Kennworts will dann allerdings wieder ein Captcha gelöst sehen, das muß dann eben wieder ein "Click-Worker" übernehmen.
Einen notwendigen Zusammenhang zwischen der IP-Adresse, von der das Rücksetzen ausgelöst wurde und der IP-Adresse, von der der Link in der E-Mail geöffnet wird, konnte ich nicht feststellen - das ist ja manchmal auch nicht ohne weiteres umzusetzen. Ein mehrfaches Aufrufen des Links in der E-Mail ist ebenfalls möglich, allerdings verfällt der in dieser URL enthaltene "activationcode" offenbar bei seiner tatsächlichen Benutzung ordnungsgemäß, so daß eine mehrfache Änderung über diese eine E-Mail nicht funktioniert.
Es ist mir bisher nur ein einziges Mal gelungen, ein bereits gelöstes Captcha auf der Kennwort-Rücksetz-Seite für den Zugriff ohne erneutes Lösen (nur der "Klick" auf das Widget war noch erforderlich) mit anderen Werten in den Eingabefeldern zu verwenden ... das konnte ich nach dem Ende dieser Browser-Session bisher nicht reproduzieren, es könnte sich also auch um ein "Phantom" handeln, weil ich den richtigen Zusammenhang nicht gesehen hatte.
Wenn der Benutzer selbst die MyFRITZ!-Weboberfläche von AVM gar nicht regelmäßig benutzt und die Mail zum Zurücksetzen des MyFRITZ!-Kennworts vom Angreifer gelöscht wird, dann bemerkt das der legitime Benutzer unter Umständen nicht einmal oder erst viel später (sofern er dann nicht immer noch eher an einen eigenen Fehler glaubt, was bei seltener Benutzung ja auch nicht unwahrscheinlich wäre).
Selbst die DynDNS-Änderungen beim MyFRITZ!-Dienst würden meines Wissens weiterhin funktionieren (habe ich allerdings tatsächlich in letzter Zeit nicht mehr getestet), da dort jeweils eine zusätzliche Identität (box_id/box_id_passphrase aus dem "jasonii"-Abschnitt der ar7.cfg) verwendet wird (mindestens jedenfalls "wurde"), ebenso für jede einzelne MyFRITZ!-Freigabe.
Hier würde es Abhilfe schaffen (aber natürlich den "vergesslichen" Kunden zusätzlich fordern), wenn man mit einer solchen Kennwort-Änderung wenigstens auch die mit diesem Konto verbundenen Geräteeinstellungen löschen würde, damit der Kunde das tatsächlich neu einrichten muß.
Auch das wird aber (sicherlich wieder wegen der "unfähigen Kunden") niemand ohne Not so umsetzen, es braucht wahrscheinlich erst wieder die Katastrophe, damit etwas passiert. Dabei hat heutzutage jeder drittklassige Internetdienst mit Kontoverwaltung solche "Sicherheitsfragen". Die sind auch noch kein Allheilmittel, aber wenigstens wird der (von mir ja nur behauptete und nicht bewiesene) direkte Zusammenhang zwischen den E-Mail-Adressen und Kennwörtern bei den meisten "normalen" Benutzern durchbrochen. Selbst wenn diese Deckungsgleichheit bei Benutzername (bzw. E-Mail-Adresse) und Kennwort eines FRITZ!Box-Benutzers nur zum E-Mail-Konto bestehen sollte (Grund s.o.), dann macht sich bei dieser Umsetzung der MyFRITZ!-Service in meinen Augen zum Helfer eines Angreifers, denn spätestens durch den Zugriff auf die MyFRITZ!-Seite nach erfolgreicher Anmeldung liegt die Information zum "DynDNS-Namen" der Box vor, selbst wenn die FRITZ!-App auf unserem hypothetischen Android-Gerät diese Information ordentlich für sich behalten sollte.
Eine solche Sicherheitsfrage ist zwar über das - zum Anlegen eines MyFRITZ!-Kontos ja verwendete - FRITZ!Box-GUI mit zusätzlichen Änderungen in der Firmware verbunden (auch wenn man das in einem IFRAME ja von einem AVM-Server laden könnte, "cross origin resource sharing" (CORS) mit "*.avm.de" ist m.W. immer gesetzt in neueren Versionen des FRITZ!OS), aber in den sauren Apfel müßte man denn eben beißen.
Der Aufwand für solche Sicherungen beim Anbieter tendiert ansonsten gegen Null ... die paar zusätzlichen Datenbank- und Formularfelder sind schnell implementiert. Stimmt dann die Sicherheitsabfrage nicht (und zwar ohne daß der Initiator darüber informiert wird oder mit einem Zähler für Fehlversuche, nach denen dann auch der Rücksetzvorgang gesperrt wird, sonst ist auch da "trial and error" möglich), gibt es keine E-Mail. Das senkt zusätzlich auch (neben dem Captcha) die Begehrlichkeiten eines Angreifers (bzw. die Angreifbarkeit des Dienstes), wenn die beiden Sicherheitsmerkmale (E-Mail-Adresse und Sicherheitsfrage) voneinander unabhängig sind.
Bei einem kostenlosen Dienst wie MyFRITZ! sind alternative Wege für eine Zwei-Faktor-Authentifizierung beim Zurücksetzen eines Kennworts (z.B. die allseits beliebte SMS als zweiter Faktor) sicherlich eine Frage der Kosten ... aber ein Anbieter, der parallel in solch einer SMS auch noch Werbung unterbringen darf (keine Ahnung wofür, das interessiert bei den anderen derartigen Angeboten von "Free-SMS-Diensten" ja in aller Regel auch nicht), wäre vielleicht eine Alternative. Oder auch die Beschränkung auf einen Rücksetzversuch pro Benutzer/IP-Adresse pro Stunde (oder was man auch immer als Intervall wählt) zur Deckelung der potentiellen Kosten eines eigenen SMS-Versands ... eine FRITZ!Box ist ja auch eine Investition des Kunden und wenn AVM auf so einem Weg eine Art "Frühwarndienst" für Angriffe auf den MyFRITZ!-Service (der natürlich wegen der geballten Informationen bis hin zur Version der Box auch Begehrlichkeiten bei einem Angreifer, der sich auf FRITZ!Boxen "spezialisiert", wecken kann) erhalten würde.
Wie weit solche Hürden (Zugriffsbeschränkungen für Konten/IP-Adressen) bereits jetzt umgesetzt sind, kann man nur vermuten ... leider ist die deutsche Gesetzgebung an dieser Stelle etwas unfreundlich für die eigenständige Überprüfung solcher Annahmen und man kann sich unter ungünstigen Umständen schon durch einfache Tests dem Vorwurf eines (notfalls auch nur versuchten) Angriffs aussetzen. Daher sollte man davon die Finger lassen ... StGB §202a-c und 303a-b sind am Ende für ausländische Hacker nur ein schaler Witz, während sie die Untersuchung solcher Probleme wie oben skizziert für Deutsche nahezu unmöglich machen, solange die dazu notwendigen Anstrengungen über das zu erwartende Maß hinausgehen (eine "versehentliche" Eingabe eines falschen Wertes ist sicherlich noch kein Angriff, bei zehn solcher Versuche sieht das mancher StA vor der Anhörung des Beschuldigten vielleicht schon anders).
Ich darf mich zwar davon überzeugen, wie so etwas implementiert ist, soweit man das von außen auch "sehen" kann. Beim MyFRITZ!-Dienst landet man schnell bei JSF2 als Framework, ob das irgendwelche Rückschlüsse auf die TLS-Implementierung zuläßt und wenn ja, was das am Ende bedeuten könnte, muß schon jeder selbst einschätzen. Fakt ist mal, daß der MyFRITZ!-Dienst auf seiner Webseite auch heute mit Cookies arbeitet (für die Session-ID), damit wäre zumindest dieser Dienst ein Kandidat für die Poodle-Lücke (FRITZ!Boxen sind ja nicht betroffen, da dort keine Cookies zum Einsatz kommen). Jetzt kann man aber nicht einfach einen Web-Dienst auf diesen Server loslassen ... allerdings ist es absolut zulässig, die Verfügbarkeit der SSLv3-Methoden auf diesem Server einfach dadurch zu testen, daß man selbst mit einer entsprechenden Version gezielt auf den Server mit SSLv3 zugreift. Wenn dann der Server nicht die neueren TLS-Optionen gegen ein Downgrade der Verbindung unterstützt, dann steigt die Wahrscheinlichkeit eines möglichen Angriffs auf einen Cookie für eine MyFRITZ!-(Web-)Session schon stark an.
Testen darf ich auch, ob meine eigenen Daten bei AVM tatsächlich sicher sind/sein dürften/sein könnten ... wenn man mit fremden Kontodaten auf so einen Dienst (ohne Einwilligung des Konto-Berechtigten) losgeht, wird es aber schon heikel. Wenn tatsächlich ein Benutzer "[email protected]" existieren sollte (was ja offensichlich - trotz neuer gTLDs - keine gültige E-Mail-Adresse, mithin auch kein fremdes Konto ist), wäre das zumindest verwunderlich ... aber selbst ein "[email protected]" könnte ja (zumindest theoretisch) ein gültiger Benutzer sein.
Ab wann dieser schmale Grat überschritten ist, kann man auch nicht immer genau beurteilen. Wenn AVM tatsächlich auf die Idee kommen sollte, anhand der Log-Dateien Anmeldeversuche samt IP-Adresse zu protokollieren und dann aus einem Test der Sicherheit durch einen Kunden einen Angriff zu konstruieren, kann es sicherlich erst einmal ungemütlich werden (bis man die Lage dann klären könnte und sich ggf. dagegen wehren kann). Glücklicherweise werden die in den o.a. Paragraphen beschriebenen Straftaten nur nach Antrag verfolgt (StGB §303c) ... wenn der StA aber erst einmal die Technik beschlagnahmen läßt für die Dauer des Verfahrens, vernichtet das am Ende Existenzen.
Da warte ich lieber auf den nächsten tatsächlichen Angriff auf den Dienst und die Berichterstattung darüber. Wobei man sich darauf offensichtlich auch nicht mehr verlassen kann, selbst heise.de hat zu den Hintergründen des Ausfalls/der Umstellung des MyFRITZ!-Diensten Ende Januar/Anfang Februar meines Wissens keine Recherchen angestellt oder keine Antworten erhalten (das "Server kaputt" aus dem oben verlinkten heise.de-Artikel mag ja stimmen, erklärt aber das geänderte Erscheinungsbild des Dienstes nach der Reparatur des Server nur unzureichend) oder heise.de hat (vielleicht auch nur bisher?) keine auf anderen Antworten basierenden Artikel veröffentlicht.
Minimal-Lösungen sind jedenfalls die eine Sache ... wenn man gleich von Beginn an höhere Hürden setzt, nimmt man einem Angreifer auch zusätzlich etwas Antrieb, weil andere Ziele dann leichter angreifbar sind.
Apropos Google Recaptcha: Ist es schon einmal jemandem gelungen, auf einem Notebook mit durchschnittlich guten Lautsprechern tatsächlich den angesagten Text in einem "Audio-Captcha" zu verstehen? Ich kann nicht einmal genau sagen, ob das (bei deutschem Text im Google-Widget) am Ende Ziffern in Deutsch oder in Englisch sein sollen, da habe ich offenbar heftige kognitive Defizite oder das Audio-Captcha ist tatsächlich unbenutzbar. Das macht den ganzen Dienst dann für Menschen mit "disabilities" unbenutzbar ... was er ansonsten nicht sein müßte, denn die Darstellung verwendet in weiten Teilen tatsächlich CSS und ist somit (wahrscheinlich, ich habe es nicht selbst getestet) abseits des Captchas sogar ScreenReader-/Braille-tauglich.
Wenn sich also jemand durch den vorstehenden Text veranlaßt sehen sollte (weil er es vielleicht ebenso sieht wie ich), bei AVM diese Problematik (mangelnde Aufklärung bzgl. der möglichen und empfehlenswerten "Vielfalt" der Kennwörter bzw. zu einfaches Rücksetzen des MyFRITZ!-Kennworts) ebenfalls nachdrücklich ins Bewußtsein zu rufen, dann hätte ich mir die Arbeit mit diesem Beitrag nicht umsonst gemacht ... aber auch jeder Benutzer, der seine eigenen Daten unter Berücksichtigung meiner Darlegungen ändert (oder zumindest ab heute verschiedene Kennwörter verwendet, wenn er tatsächlich auch in diese Falle gegangen sein sollte), wäre ein Erfolg.
Das liegt zu einem guten Teil eben auch daran, daß die Beschreibung/Information zum MyFRITZ!-Konto sowohl in der Webseite:
Anhang anzeigen 81572(Screenshot von www.myfritz.net vom 20.04.2015)
als auch beim Anlegen eines MyFRITZ!-Kontos in der Box
Anhang anzeigen 81573(aus FRITZ!OS 06.23 für die 7390)
dahingehend ungenügend sind, daß dort nicht ausdrücklich davor gewarnt wurde, für das Login in die FRITZ!Box und das Login in die MyFRITZ!-Seite dasselbe Kennwort zu verwenden. Die Formulierung im FRITZ!OS-GUI
Code:
Geben Sie Ihre E-Mail-Adresse ein und legen Sie ein Kennwort für das MyFRITZ!-Konto fest.ist zwar sachlich richtig und nicht zu beanstanden, aber erstens liest fast kein Mensch - jedenfalls keiner meiner eigenen Tester - diesen Satz (was wo hin soll, steht ja vor den Eingabefeldern) und zweitens fehlt - meine Ansicht - die explizite und optisch hervorgehobene Warnung, ein an anderer Stelle bereits verwendetes Kennwort hier erneut zu benutzen. Ganz im Gegenteil ... der enge optische Zusammenhang zwischen der Eingabe einer E-Mail-Adresse und eines Kennworts führt bei vielen Benutzern automatisch zu dem Reflex, dort ebenfalls das E-Mail-Kennwort einzugeben, einfach weil ihnen der Unterschied gar nicht klar ist.
Das ist beim Anlegen eines neuen Benutzers in der FRITZ!Box-Oberfläche noch viel krasser, da dort das Formular noch "verwirrender" (für den Laien) ist:
Anhang anzeigen 81575
Die optionale Angabe der E-Mail-Adresse beim Anlegen eines Benutzer assoziiert für viele - so "dumm" das in den Augen mancher auch sein mag - tatsächlich die Angabe des Mail-Kennworts im Formular. Ich bin jedenfalls schon oft genug gefragt worden, ob da das Mail-Kennwort eingegeben werden muß, wenn ich Hilfestellung beim Einrichten eines Benutzers geleistet habe. Auch die oben verwendete Formulierung
Code:
Mithilfe des Benutzernamens bzw. der E-Mail-Adresse und des Kennworts kann der Benutzer die jeweils für ihn freigegebenen Bereiche der FRITZ!Box nutzen.ist nicht einmal jedem "FRITZ!Box-Versteher" sofort eingängig, da es aufgrund des Satzbaus nicht eindeutig ist, ob da "... Benutzername [bzw. der E-Mail-Adresse] und des Kennworts ..." oder "Benutzername - bzw. der E-Mail-Adresse und des Kennworts - ..." gemeint sein soll.
Es sind aber zwei (bzw. drei) vollkommen getrennte Konten/Dienste und wer für alle nur ein gemeinsames Kennwort verwendet, muß sich am Ende nicht wundern, wenn er - sollte es tatsächlich mal soweit kommen, daß z.B. die Datenbank hinter MyFRITZ! gehackt wird, es hat schon ganz andere Kaliber der Branche getroffen, daß die Kundendaten zugänglich waren - unerwünschten Besuch auf seiner FRITZ!Box erhält. Gleiches gilt natürlich für die verwendeten E-Mail-Konten, wobei die Sicherheitsvorkehrungen bei den E-Mail-Providern (meist nach Vorfällen) inzwischen ja fast überall entsprechend erweitert wurden.
Nur der MyFRITZ!-Dienst hinkt in meinen Augen hier noch nach ... was nichts über die Sicherheit der Speicherung von MyFRITZ!-Konten bei AVM aussagen soll, da habe ich keine Ahnung, wie das umgesetzt ist und ob das angreifbar ist oder nicht. Aber die "übliche" Vorgehensweise beim MyFRITZ!-Dienst, E-Mails zum Zurücksetzen des Kennworts an die hinterlegte E-Mail-Adresse zu senden (die gleichzeitig der Benutzername bei diesem Dienst ist), läßt das Hacker-Herz höher schlagen, wenn am Ende vom Benutzer für das Login in die FRITZ!Box das Mail-Kennwort verwendet wird und genau dieses Mail-Konto sich bereits unter der Kontrolle des Hackers befindet.
Die oben erläuterte Wahrscheinlichkeit für identische Kennwörter ist - in meinen Augen - ein Lapsus (hinsichtlich Usability), den sich AVM zurechnen lassen muß. Wenn man das Anlegen eines Benutzers im Rahmen eines Usability-Tests nur mal mit 20 "unbelasteten" Testpersonen (das ist eben die schwäbische Hausfrau, bei der sich die Sparsamkeit auch auf die Anzahl der verwendeten Kennwörter auswirkt oder der "Ich muß mir wirklich Wichtigeres merken."-Typ, für den das Einrichten eines Kennwortes an sich schon eine Zumutung ist, weil das ja auch ohne funktionieren würde) ausgeführt hätte, sollte das eigentlich dabei bereits aufgefallen sein. Wenn es solche Tests tatsächlich gab und dieses "Problem" dabei nicht auftrat, waren die Testpersonen vielleicht schlecht gewählt.
Schon eine kleine Änderung im Formular (Verschieben des Kennwort-Felds hinter den Benutzernamen und Ändern der Beschriftung in einen eindeutigen Wert samt passender - farblich hervorgehobener - Erläuterung) würde da wahre Wunder wirken ... aber vielleicht es ist am Ende ja auch die Schuld des Kunden, wenn er sich so blöd anstellt, da kann AVM ja schließlich nichts dafür (auch wenn man keine Vorkehrungen gegen solche "Fehlbedienungen" trifft). Usability geht aber - zumindest meines Erachtens - anders ... und die FRITZ!Box richtet sich sicherlich weniger an Fachleute als an Laien, das muß man dann einfach auch beim Interface-Design berücksichtigen.
Aber auch dann findet ein Angreifer ja erst einmal die FRITZ!Box noch nicht ... selbst wenn die Adresse des E-Mail-Kontos, der MyFRITZ!-Benutzername und der FRITZ!Box-Benutzername (auch da ist die synonyme Angabe der E-Mail-Adresse beim Login ja möglich, solange sie beim Benutzer eingetragen wurde, selbst wenn die in der Select-Box bei der LAN-Anmeldung nicht angezeigt wird) ebenso übereinstimmen wie das E-Mail-Kennwort und das Kennwort für die Anmeldung in der FRITZ!Box. Ich kenne persönlich genug Leute, wo das der Fall ist und eine entsprechende Warnung nur Schulterzucken hervorruft. Solange dann niemand die passende FRITZ!Box lokalisieren kann, ist das sicherlich auch zu verkraften (trotzdem schlechter Stil), aber kommt dann auch noch der MyFRITZ!-Dienst als Bindeglied ins Spiel, ist diese Verbindung im Handumdrehen hergestellt.
Leider nutzt dann auch ein abweichendes MyFRITZ!-Kennwort nichts mehr, wenn man bei diesem Dienst einfach eine E-Mail-basierte Kennwort-Änderung veranlassen kann, ohne irgendwelche zusätzlichen Sicherheitsfragen (das übliche "Wie hieß der Mann der Frau dieses Malers?") beantworten zu müssen. Das Captcha schützt nur vor Bots, nicht vor "Click-Workern", der Rest (Auswertung der Rücksetz-Mail und "Klick" auf den dort angegebenen Link) ginge dann ohnehin wieder automatisch weiter ... das Eintragen eines neuen Kennworts will dann allerdings wieder ein Captcha gelöst sehen, das muß dann eben wieder ein "Click-Worker" übernehmen.
Einen notwendigen Zusammenhang zwischen der IP-Adresse, von der das Rücksetzen ausgelöst wurde und der IP-Adresse, von der der Link in der E-Mail geöffnet wird, konnte ich nicht feststellen - das ist ja manchmal auch nicht ohne weiteres umzusetzen. Ein mehrfaches Aufrufen des Links in der E-Mail ist ebenfalls möglich, allerdings verfällt der in dieser URL enthaltene "activationcode" offenbar bei seiner tatsächlichen Benutzung ordnungsgemäß, so daß eine mehrfache Änderung über diese eine E-Mail nicht funktioniert.
Es ist mir bisher nur ein einziges Mal gelungen, ein bereits gelöstes Captcha auf der Kennwort-Rücksetz-Seite für den Zugriff ohne erneutes Lösen (nur der "Klick" auf das Widget war noch erforderlich) mit anderen Werten in den Eingabefeldern zu verwenden ... das konnte ich nach dem Ende dieser Browser-Session bisher nicht reproduzieren, es könnte sich also auch um ein "Phantom" handeln, weil ich den richtigen Zusammenhang nicht gesehen hatte.
Wenn der Benutzer selbst die MyFRITZ!-Weboberfläche von AVM gar nicht regelmäßig benutzt und die Mail zum Zurücksetzen des MyFRITZ!-Kennworts vom Angreifer gelöscht wird, dann bemerkt das der legitime Benutzer unter Umständen nicht einmal oder erst viel später (sofern er dann nicht immer noch eher an einen eigenen Fehler glaubt, was bei seltener Benutzung ja auch nicht unwahrscheinlich wäre).
Selbst die DynDNS-Änderungen beim MyFRITZ!-Dienst würden meines Wissens weiterhin funktionieren (habe ich allerdings tatsächlich in letzter Zeit nicht mehr getestet), da dort jeweils eine zusätzliche Identität (box_id/box_id_passphrase aus dem "jasonii"-Abschnitt der ar7.cfg) verwendet wird (mindestens jedenfalls "wurde"), ebenso für jede einzelne MyFRITZ!-Freigabe.
Hier würde es Abhilfe schaffen (aber natürlich den "vergesslichen" Kunden zusätzlich fordern), wenn man mit einer solchen Kennwort-Änderung wenigstens auch die mit diesem Konto verbundenen Geräteeinstellungen löschen würde, damit der Kunde das tatsächlich neu einrichten muß.
Auch das wird aber (sicherlich wieder wegen der "unfähigen Kunden") niemand ohne Not so umsetzen, es braucht wahrscheinlich erst wieder die Katastrophe, damit etwas passiert. Dabei hat heutzutage jeder drittklassige Internetdienst mit Kontoverwaltung solche "Sicherheitsfragen". Die sind auch noch kein Allheilmittel, aber wenigstens wird der (von mir ja nur behauptete und nicht bewiesene) direkte Zusammenhang zwischen den E-Mail-Adressen und Kennwörtern bei den meisten "normalen" Benutzern durchbrochen. Selbst wenn diese Deckungsgleichheit bei Benutzername (bzw. E-Mail-Adresse) und Kennwort eines FRITZ!Box-Benutzers nur zum E-Mail-Konto bestehen sollte (Grund s.o.), dann macht sich bei dieser Umsetzung der MyFRITZ!-Service in meinen Augen zum Helfer eines Angreifers, denn spätestens durch den Zugriff auf die MyFRITZ!-Seite nach erfolgreicher Anmeldung liegt die Information zum "DynDNS-Namen" der Box vor, selbst wenn die FRITZ!-App auf unserem hypothetischen Android-Gerät diese Information ordentlich für sich behalten sollte.
Eine solche Sicherheitsfrage ist zwar über das - zum Anlegen eines MyFRITZ!-Kontos ja verwendete - FRITZ!Box-GUI mit zusätzlichen Änderungen in der Firmware verbunden (auch wenn man das in einem IFRAME ja von einem AVM-Server laden könnte, "cross origin resource sharing" (CORS) mit "*.avm.de" ist m.W. immer gesetzt in neueren Versionen des FRITZ!OS), aber in den sauren Apfel müßte man denn eben beißen.
Der Aufwand für solche Sicherungen beim Anbieter tendiert ansonsten gegen Null ... die paar zusätzlichen Datenbank- und Formularfelder sind schnell implementiert. Stimmt dann die Sicherheitsabfrage nicht (und zwar ohne daß der Initiator darüber informiert wird oder mit einem Zähler für Fehlversuche, nach denen dann auch der Rücksetzvorgang gesperrt wird, sonst ist auch da "trial and error" möglich), gibt es keine E-Mail. Das senkt zusätzlich auch (neben dem Captcha) die Begehrlichkeiten eines Angreifers (bzw. die Angreifbarkeit des Dienstes), wenn die beiden Sicherheitsmerkmale (E-Mail-Adresse und Sicherheitsfrage) voneinander unabhängig sind.
Bei einem kostenlosen Dienst wie MyFRITZ! sind alternative Wege für eine Zwei-Faktor-Authentifizierung beim Zurücksetzen eines Kennworts (z.B. die allseits beliebte SMS als zweiter Faktor) sicherlich eine Frage der Kosten ... aber ein Anbieter, der parallel in solch einer SMS auch noch Werbung unterbringen darf (keine Ahnung wofür, das interessiert bei den anderen derartigen Angeboten von "Free-SMS-Diensten" ja in aller Regel auch nicht), wäre vielleicht eine Alternative. Oder auch die Beschränkung auf einen Rücksetzversuch pro Benutzer/IP-Adresse pro Stunde (oder was man auch immer als Intervall wählt) zur Deckelung der potentiellen Kosten eines eigenen SMS-Versands ... eine FRITZ!Box ist ja auch eine Investition des Kunden und wenn AVM auf so einem Weg eine Art "Frühwarndienst" für Angriffe auf den MyFRITZ!-Service (der natürlich wegen der geballten Informationen bis hin zur Version der Box auch Begehrlichkeiten bei einem Angreifer, der sich auf FRITZ!Boxen "spezialisiert", wecken kann) erhalten würde.
Wie weit solche Hürden (Zugriffsbeschränkungen für Konten/IP-Adressen) bereits jetzt umgesetzt sind, kann man nur vermuten ... leider ist die deutsche Gesetzgebung an dieser Stelle etwas unfreundlich für die eigenständige Überprüfung solcher Annahmen und man kann sich unter ungünstigen Umständen schon durch einfache Tests dem Vorwurf eines (notfalls auch nur versuchten) Angriffs aussetzen. Daher sollte man davon die Finger lassen ... StGB §202a-c und 303a-b sind am Ende für ausländische Hacker nur ein schaler Witz, während sie die Untersuchung solcher Probleme wie oben skizziert für Deutsche nahezu unmöglich machen, solange die dazu notwendigen Anstrengungen über das zu erwartende Maß hinausgehen (eine "versehentliche" Eingabe eines falschen Wertes ist sicherlich noch kein Angriff, bei zehn solcher Versuche sieht das mancher StA vor der Anhörung des Beschuldigten vielleicht schon anders).
Ich darf mich zwar davon überzeugen, wie so etwas implementiert ist, soweit man das von außen auch "sehen" kann. Beim MyFRITZ!-Dienst landet man schnell bei JSF2 als Framework, ob das irgendwelche Rückschlüsse auf die TLS-Implementierung zuläßt und wenn ja, was das am Ende bedeuten könnte, muß schon jeder selbst einschätzen. Fakt ist mal, daß der MyFRITZ!-Dienst auf seiner Webseite auch heute mit Cookies arbeitet (für die Session-ID), damit wäre zumindest dieser Dienst ein Kandidat für die Poodle-Lücke (FRITZ!Boxen sind ja nicht betroffen, da dort keine Cookies zum Einsatz kommen). Jetzt kann man aber nicht einfach einen Web-Dienst auf diesen Server loslassen ... allerdings ist es absolut zulässig, die Verfügbarkeit der SSLv3-Methoden auf diesem Server einfach dadurch zu testen, daß man selbst mit einer entsprechenden Version gezielt auf den Server mit SSLv3 zugreift. Wenn dann der Server nicht die neueren TLS-Optionen gegen ein Downgrade der Verbindung unterstützt, dann steigt die Wahrscheinlichkeit eines möglichen Angriffs auf einen Cookie für eine MyFRITZ!-(Web-)Session schon stark an.
Testen darf ich auch, ob meine eigenen Daten bei AVM tatsächlich sicher sind/sein dürften/sein könnten ... wenn man mit fremden Kontodaten auf so einen Dienst (ohne Einwilligung des Konto-Berechtigten) losgeht, wird es aber schon heikel. Wenn tatsächlich ein Benutzer "[email protected]" existieren sollte (was ja offensichlich - trotz neuer gTLDs - keine gültige E-Mail-Adresse, mithin auch kein fremdes Konto ist), wäre das zumindest verwunderlich ... aber selbst ein "[email protected]" könnte ja (zumindest theoretisch) ein gültiger Benutzer sein.
Ab wann dieser schmale Grat überschritten ist, kann man auch nicht immer genau beurteilen. Wenn AVM tatsächlich auf die Idee kommen sollte, anhand der Log-Dateien Anmeldeversuche samt IP-Adresse zu protokollieren und dann aus einem Test der Sicherheit durch einen Kunden einen Angriff zu konstruieren, kann es sicherlich erst einmal ungemütlich werden (bis man die Lage dann klären könnte und sich ggf. dagegen wehren kann). Glücklicherweise werden die in den o.a. Paragraphen beschriebenen Straftaten nur nach Antrag verfolgt (StGB §303c) ... wenn der StA aber erst einmal die Technik beschlagnahmen läßt für die Dauer des Verfahrens, vernichtet das am Ende Existenzen.
Da warte ich lieber auf den nächsten tatsächlichen Angriff auf den Dienst und die Berichterstattung darüber. Wobei man sich darauf offensichtlich auch nicht mehr verlassen kann, selbst heise.de hat zu den Hintergründen des Ausfalls/der Umstellung des MyFRITZ!-Diensten Ende Januar/Anfang Februar meines Wissens keine Recherchen angestellt oder keine Antworten erhalten (das "Server kaputt" aus dem oben verlinkten heise.de-Artikel mag ja stimmen, erklärt aber das geänderte Erscheinungsbild des Dienstes nach der Reparatur des Server nur unzureichend) oder heise.de hat (vielleicht auch nur bisher?) keine auf anderen Antworten basierenden Artikel veröffentlicht.
Minimal-Lösungen sind jedenfalls die eine Sache ... wenn man gleich von Beginn an höhere Hürden setzt, nimmt man einem Angreifer auch zusätzlich etwas Antrieb, weil andere Ziele dann leichter angreifbar sind.
Apropos Google Recaptcha: Ist es schon einmal jemandem gelungen, auf einem Notebook mit durchschnittlich guten Lautsprechern tatsächlich den angesagten Text in einem "Audio-Captcha" zu verstehen? Ich kann nicht einmal genau sagen, ob das (bei deutschem Text im Google-Widget) am Ende Ziffern in Deutsch oder in Englisch sein sollen, da habe ich offenbar heftige kognitive Defizite oder das Audio-Captcha ist tatsächlich unbenutzbar. Das macht den ganzen Dienst dann für Menschen mit "disabilities" unbenutzbar ... was er ansonsten nicht sein müßte, denn die Darstellung verwendet in weiten Teilen tatsächlich CSS und ist somit (wahrscheinlich, ich habe es nicht selbst getestet) abseits des Captchas sogar ScreenReader-/Braille-tauglich.
Wenn sich also jemand durch den vorstehenden Text veranlaßt sehen sollte (weil er es vielleicht ebenso sieht wie ich), bei AVM diese Problematik (mangelnde Aufklärung bzgl. der möglichen und empfehlenswerten "Vielfalt" der Kennwörter bzw. zu einfaches Rücksetzen des MyFRITZ!-Kennworts) ebenfalls nachdrücklich ins Bewußtsein zu rufen, dann hätte ich mir die Arbeit mit diesem Beitrag nicht umsonst gemacht ... aber auch jeder Benutzer, der seine eigenen Daten unter Berücksichtigung meiner Darlegungen ändert (oder zumindest ab heute verschiedene Kennwörter verwendet, wenn er tatsächlich auch in diese Falle gegangen sein sollte), wäre ein Erfolg.
Zuletzt bearbeitet:
