toastking schrieb:
Ich kann ohne Probleme MAC-Adressen mehrerer hochsensibler Systeme oder auch meiner privaten Fritzbox nennen - wer da reinkommt, Ist herzlich eingeladen, alle Daten mitzunehmen. Numerische IDs oder MAC-Adressen sind kein Sicherheitsmerkmal und das zu glauben zeugt von technischem Unverständnis.
Da hilft es ja vielleicht, mal genau zu lesen, was ich meinerseits schrieb ... und da sollte ganz deutlich stehen, daß eindeutige, maschinenlesbare Kennzeichnungen unter dem Aspekt des "Trackings" (das ist das "Verfolgen" eines bestimmten Nutzers, auch über mehrere Plattformen und das funktioniert dann genau anhand solcher eindeutiger Kennzeichnungen wie einer MAC-Adresse) gesehen werden müssen/sollten und solange man diese nicht tatsächlich benötigt (welchen Nutzwert zieht denn hier der Autor aus diesen Daten?), sollte man sie sich auch nicht zusenden lassen.
Es gab schon ganz andere Organisationen, bei denen die komplette E-Mail-Kommunikation abgegriffen und im Nachhinein veröffentlicht wurde - da ist praktisch jedes gespeicherte "Datum" eines Kunden, welches man eigentlich nicht benötigte, auch ein potentielles Risiko für "disclosure" - egal ob das einem selbst, einem Dienstleister oder gar im Ergebnis eines Angriffs passiert.
Um eine Meinung zum generellen Datenschutz und zu einer von Beginn an sichtbaren "Datensparsamkeit" zu haben, muß ich auch die konkrete App nicht kennen. Ich gebe sogar zu, daß ich gar nicht die Absicht habe, sie anzusehen - das ist aber auch nicht notwendig, um eine Meinung zur gezeigten Haltung "Kann ja jeder vor dem Senden löschen ..." haben zu dürfen und diese auch zu äußern. Wie es in dieser konkreten App aussieht, weiß der Autor eben am besten selbst ... das (und nichts anderes) habe ich aber bereits geschrieben.
Ich habe sogar extra sehr deutlich gemacht, daß ich sie nicht kenne und lediglich ein paar "Binsenweisheiten" aus der Security-Ecke (die aber leider auch immer wieder gerne ignoriert werden, falls sie Autoren tatsächlich kennen) zum Besten gegeben habe ... die hier aber offensichtlich (und da stütze ich mich auf das weiter oben gezeigte Template für die E-Mail) nicht berücksichtigt wurden und wo das nun vom App-Anbieter in die Verantwortung des Benutzers delegiert wird, was er aus so einem Template (das dürften für den durchschnittlichen App-User auch nur irgendwelche unverständlichen Zeichenketten sein) streicht und was er dann sendet.
Auf den Aspekt der Speicherung einer SID in einem IMAP-Postfach, das normalerweise die Daten eben nicht verschlüsselt ablegt und eine Kopie der gesendeten Nachrichten auf dem Android-Gerät bereithält (Android war doch die Zielplattform, oder?), ist hier ja leider nicht wirklich eingegangen worden (war ja ein deutliches Beispiel, das zu widerlegen wäre oder auch die Versicherung, daß natürlich die App vor dem "Veröffentlichen" der SID diese zuerst invalidiert, wäre ja denkbar gewesen) ... aber ich kann in Bezug auf eine solche SID in aktueller FRITZ!OS-Firmware (und nur die unterstützt ja die hier notwendigen HKR) zumindest eines versichern: Ein zweites (gültiges) Login von derselben IP-Adresse bei einer FRITZ!Box "zerstört" keine vorher genutzte SID - lediglich ein Login mit ungültiger SID (nicht einmal mit fehlender (alles Nullen), denn dann kommt nur die Aufforderung zur zweiten Anmeldung und das gilt auch für das
API) führt zum Verwerfen bestehender SIDs für dieselbe IP-Adresse. Sollte das in der Dokumentation von AVM tatsächlich anders stehen, wäre ein Verweis auf die konkrete Stelle (nicht den Link, den habe ich alleine (s.o.) ... ich meine Seitenzahl und Absatz, am besten mit Zitat der betreffenden Stelle) nett - dann kann man das ggf. bei AVM monieren und vielleicht sogar korrigieren lassen.
Die angenommene Arbeitsweise würde auch dazu führen, daß das GUI einer FRITZ!Box gar nicht von zwei Geräten hinter einem kaskadierten Router gleichzeitig genutzt werden könnte - wenn der zwischengeschaltete Router seinerseits noch einmal NAT verwendet, sieht die FRITZ!Box für beide Clients dieselbe IP-Adresse (die des externen Interfaces des kaskadierten Routers) und da ein Client nicht die SID des anderen kennt (bzw. kennen sollte),
muß jeder Client im LAN des kaskadierten Routers seine eigene Anmeldung verwenden und solange nicht einer der beiden Clients einen "Sicherheitsverstoß" begeht (das wäre dann z.B. ein Zugriffsversuch mit einer ungültigen SID), können beide Clients problemlos arbeiten. Wird jedoch nur einer der beiden "auffällig", dann "fliegt" auch der zweite - es werden alle aktiven SIDs für die sichtbare IP-Adresse invalidiert.
Insofern ist der Punkt 4 in #21 keinesfalls "erledigt" ... eine aus der App "entlassene" SID ist sehr wohl ein Sicherheitsrisiko, das Szenario mit der parallel zur hier diskutierten App auf dem Gerät installierten Malware
kann nicht mit Gewißheit ausgeschlossen werden und in einer App, die bereits beim Entwurf den Aspekt der Sicherheit gegen Angriffe (auch auf diese App selbst) berücksichtigt, würden so sensible Daten wie die Session-ID für die FRITZ!Box in einer Form gespeichert, daß sie auch ein Angriff auf den Speicher dieser App möglichst nicht auslesen könnte (die Möglichkeiten so eines Angriffs sind vielfältig und die nächste Sicherheitslücke ist nur noch nicht publik geworden) bzw. daß derartige Daten nicht an mehreren Stellen und über die jeweils notwendige Dauer hinaus gespeichert werden - dazu gehört es auch, ein hier ja offensichtlich in irgendeinem Buffer abgelegtes Protokoll der letzten, mit der Box ausgetauschten Daten bereits bei der internen Speicherung von sensiblen Daten zu befreien, sofern diese nicht wirklich benötigt werden (auch hier gilt "Datensparsamkeit" - was nicht im Speicher steht, kann nicht "abgegriffen" werden).
Wenn hier sogar vom App-Autoren aber die Einschätzung getroffen wird, daß wohl nur "technisch versierte Nutzer" die Zugriffe des verwendeten Benutzers auf die "Smart Home"-Funktionen beschränken werden, dann ist der verantwortungsvolle Umgang mit so einem Zugang (von dem man ja dann erst einmal annehmen muß, daß er auch administrative Rechte hat ... oder wird da für die App die
X_AVM-DE_AppSetup-Schnittstelle von AVM verwendet, womit die Speicherung der Credentials eines FRITZ!Box-
Benutzers in der App obsolet ist?) ja erst recht verpflichtend.
Wenn die App hier dieser Verantwortung gerecht wird, ist ja alles in bester Ordnung - dann bräuchte es aber auch die SID in der E-Mail (vermutlich) nicht und die in #13 sichtbare XML-Antwort der Box deutet eher auf die Verwendung von "login_sid.lua" hin als auf die Verwendung der TR-064-Interfaces (X_AVM_Homeauto). Der Vorteil des "RegisterApp" ist es eben auch, daß dabei die Berechtigungen dieser App auf die tatsächlich notwendigen Funktionen beschränkt werden können (wenn hier wirklich nur "HomeautoRight" signifikant ist) und daß auch bei Verlust oder Austausch des Gerätes nur diese spezielle App deregistriert werden muß im GUI und nicht für den, bei der Anmeldung der App verwendeten, administrativen Benutzer ein Tausch der Daten erfolgen muß.
Es gibt genug FRITZ!Boxen da draußen, bei deren Besitzern es eben keine ausgeklügelte Berechtigungsstruktur für die Benutzer gibt - wenn es sich um ein Modell mit einem voreingestellten GUI-Kennwort handelt, ist es häufig sogar so, daß gar keine Benutzer und das voreingestellte Kennwort (i.V.m. @CompatUser als Benutzername, wenn der irgendwo gesondert benötigt wird) Anwendung finden. Ich kenne zwar die genauen Beweggründe von AVM für die AppSetup-Schnittstelle auch nicht - aber ich sehe anhand der beschriebenen API-Funktionen (und auf der Basis der Ansicht im GUI zzgl. einiger Untersuchungen von internen Komponenten) durchaus Vorteile bei der Nutzung dieser Schnittstelle ... und auch die neueren AVM-Apps stellen eben auf diese Schnittstellen um.
Wenn ich mir das zusätzliche
HTTP-Interface für AHA ansehe, fallen mir aber sofort zwei weitere Fragen ein (vorausgesetzt, es wird anstelle der TR-064-Schnittstelle dann diese benutzt). Die erste wäre, warum in der App dann überhaupt die verschlüsselte Kommunikation mit der FRITZ!Box optional ist (lt. #21), wenn doch die AVM-Spezifikation in Punkt 1.1 ausdrücklich eine HTTPS-URL vorgibt. Die zweite Frage wäre dann, wie man ein Datum wie eine AIN als "unkritisch" ansehen kann, wenn genau so eine AIN (oder eine MAC-Adresse) als Parameter für einen Schaltvorgang benötigt wird. Die Tatsache, daß man diese Daten auch von einer FRITZ!Box abfragen kann, kann als alleinige Erklärung ja wohl nicht herhalten ... für wirklich "unkritische" Daten braucht es auch bei der Abfrage keine Authentifizierung (z.B. jason_boxinfo.xml), was hier ja aber wohl der Fall ist, oder?
