[Info] Weitere Lücke in der AVM Fernwartungsfunktion geschlossen

[andiling]

Nun ja...

http://m.heise.de/newsticker/meldun...er-FritzBox-Fernwartungsfunktion-2296040.html

 

[informerex]

wobei die Lücke durch das App-Update geschlossen wurde ... wie man dem Artikel entnehmen kann

nicht dass hier gleich die nächste Panik ausbricht

 

[andiling]

Und trotzdem war es wohl eine Berichterstattung wert...

Und es werden mit der Zeit weitere Sicherheitslücken auftreten, die hinterher geschlossen werden.

Wir sind doch zu belesen um panisch zu reagieren.

 

[informerex]

ich finde es gut, dass die ganze Angelegenheit "im Fluss" ist und die Presse/Spezialisten am Ball bleiben.
nur die Headline hatte Bild-Charakter

PS: diesbzgl. läßt mich sowieso alles kalt, weil wir können es nicht ändern - wenn nur schauen, dass man weitestgehend up-to-date ist und versucht das "bißchen brain" wo man hat zum Einsatz bringt.

 

[andiling]

Die Headline ist von heiße, werde sie überarbeiten wenn ich am PC bin, geht wohl in TT nicht.

 

[informerex]

hier die Antwort von AVM: Neue Version der MyFRITZ!App für mehr Sicherheit

Auszug:

... Demnach erhält das Sicherheitsrisiko auf einer Skala von 0 (niedrig) bis 10 (hoch) einen Wert von 0,8.

Der MITM-Angriff wäre nur in wenigen Konstellationen möglich gewesen. Beispielsweise wenn ein möglicher Angreifer im selben WLAN wie der App-Anwender eingebucht gewesen wäre. Wäre dann die MyFRITZ!App aufgerufen worden, hätte der Angreifer den Datenverkehr auf seinen Proxy-Server umleiten und mitlesen können.
Mit der neuen Version der MyFRITZ!App ist diese Möglichkeit ausgeschlossen. Ein Update von FRITZ!OS ist dafür nicht notwendig.

//edit:
hm, bei mir geht og. Link, aber hier noch ein anderer: http://avm.de/aktuelles/kurz-notiert/2014/neue-version-der-myfritzapp-fuer-mehr-sicherheit/

 

[andiling]

Cool, page not found (wohl bei Mobilzugriff)

 

[PeterPawn]

Der MITM-Angriff wäre nur in wenigen Konstellationen möglich gewesen. Beispielsweise wenn ein möglicher Angreifer im selben WLAN wie der App-Anwender eingebucht gewesen wäre. Wäre dann die MyFRITZ!App aufgerufen worden, hätte der Angreifer den Datenverkehr auf seinen Proxy-Server umleiten und mitlesen können.

Ich lach mich scheckig ... was ist denn, wenn dem potentiellen Angreifer das WLAN gehört ? Wieviele Punkte werden es dann auf einer Scala von 1 bis 2 ? Oder bei einem öffentlichen WLAN, wie hier bei uns in Berlin ? Oder einem "offenen" Cafe-WLAN ohne WEP/WPA(2) und einem Tischnachbarn mit einem Laptop und passender Software ? Und wie läuft ein MITM-Angriff denn eigentlich sonst ab, wenn nicht der Angreifer in demselben Netz ist wie das Opfers ? Da bleibt ja dann nur noch DNS-Hijacking als mögliche Antwort übrig.

Das nenne ich auch mal wieder gekonnt heruntergespielt. Den CVSS-Wert mit 0.8 anzugeben, ist eine rhetorische Glanzleistung - und natürlich den "Wertebereich" deutlich herausstellen, sonst sieht es ja nicht so winzig aus.
Wer nicht weiß, das sich dieser Score erst einmal aus 6 Basis-Kriterien für eine Lücke errechnet und dabei für jedes Kriterium nur 3 Wahlmöglichkeiten bestehen - wobei die Zuordnung des Problems zu einem Wert auch noch einigermaßen subjektiv ist, der wird sich angesichts dieses Scores einfach achselzuckend abwenden und denken: "Na toll, haben die nichts Besseres zu tun ...".

Ich würde das Szenario ja nur zu gerne einmal durchspielen wollen und einen eigenen Score ermitteln ... wer möchte, kann sich hier den Calculator der zuständigen US-amerikanischen Institution selbst ansehen.
Als Vorbemerkung muß ich allerdings noch loswerden, daß der CVSS-Score eigentlich mit seinen Kriterien gar nicht so gut auf das Problem paßt, denn er soll eher die Folgen einer Lücke auf einem System abschätzen helfen und bei der nun von AVM geschlossenen Nicht-Lücke konnte ja ein - eigentlich nicht verwundbares - System (die FRITZ!Box) durch das Abfangen eines "Access Tokens" beim Zugriff von einem anderen System (der App) durch einen Dritten angegriffen werden. Wie wir gleich sehen werden, macht das die Wahl der korrekten "Einstellung" etwas schwierig und seehr subjektiv.

Kriterium 1: Access Vector
- Hier geht es darum, welchen Zugriff der Angreifer auf das System haben muß, um den Angriff durchführen zu können.
- die Wahlmöglichkeiten:
a) lokaler Zugriff erforderlich -> das würde heißen, für die Durchführung des Angriffs benötigt der Angreifer lokalen Zugang zum System, z.B. einen eigenen Account, für den er dann die Rechte ausweiten könnte o.ä.
b) Zugriff auf ein Netzwerk in unmittelbarer Umgebung des angegriffenen Systems (Broadcast Domain, wenn damit jemand etwas anfangen kann)
c) beliebiger Zugriff über ein Netzwerk

Schon hier zeigt sich sehr deutlich, daß man erst einmal festlegen muß, was denn nun eigentlich das angegriffene System ist. Wenn es die FRITZ!Box sein soll, dann wäre sicherlich c) die "richtige Wahl", da der Angreifer in einem beliebigen entfernten WLAN (nur die App muß auch dort sein) die SID für den Zugriff abgreifen könnte. Betrachtet man das Smartphone mit der App als Angriffsziel, ist eindeutig b) der richtige Score, da der Angreifer sich im selben WLAN wie das Smartphone befinden muß. Eine "mal so, mal so"-Möglichkeit gibt es nun einmal nicht.

Kriterium 2: Access Complexity
- Hier geht es darum, wie schwierig der Angriff ist und wieviele Voraussetzungen dafür erfüllt sein müssen, daß er durchgeführt werden kann.
- Die Erläuterung der einzelnen Punkte schenke ich mir hier, bei "medium" würde ich es sehen, ich nehme aber mal an, AVM hat hier auf "high" entschieden, obwohl die Komplexität eines Angriffs nun wirklich nicht soo hoch ist ... da kommt wieder die mangelnde Phantasie beim Entwurf solcher Szenarien ins Spiel.

Kriterium 3: Authentication
- Muß sich der Angreifer gar nicht, einmal oder mehrmals authentifizieren, damit der Angriff durchführbar ist ?

Da scheiden sich sicherlich auch wieder die Geister. Da der Angriff ja auf das Abgreifen eines "Access Tokens" in Form einer SID zielt, muß sich der Angreifer an sich gar nicht authentifizieren. Allerdings muß er abwarten, bis sich die FRITZ!App bei der Box authentifiziert hat, also ist "single" wohl gerechtfertigt.

Kriterium 4: Confidentiality Impact
- Welche Auswirkungen hat ein erfolgreicher Angriff auf die Vertraulichkeit des angegriffenen Systems ?

Diese Antwort hängt ganz klar davon ab, welche Rechte der Account hat, den man mißbraucht. Die Antwort "none" ist eindeutig falsch, bei einem eingeschränkten Account (ohne Zugriffsrechte auf das GUI - Punkt FRITZ!Box-Einstellungen) lasse ich "partial" gelten. Bei allen anderen ist nach meinem Dafürhalten aber von "complete" auszugehen, da man sich mit einem entsprechenden Account weiter vorarbeiten kann (und auch genug Zeit haben dürfte, da der Angriff nicht sofort bemerkt werden würde).

Kriterium 5: Integrity Impact
- Welche Möglichkeiten hat der Angreifer, das System zu verändern und ihm (dauerhaft) zu schaden ?

Eindeutig auch vom Account abhängig, von "partial" bis "complete" ist alles denkbar. Ein gekaperter Admin-Account, der die Einrichtung weiterer Nutzer oder das Flashen eines neuen Images oder das Einspielen eines Exploits auf einem USB-Speicher (als Sprungbrett für weitere Ziele) ermöglicht, ist schon ein "complete integrity impact".

Bleibt noch Kriterium 6: Availability Impact
- Hat der Angriff Auswirkungen auf die Verfügbarkeit der Dienste für andere oder künftige Nutzer ?

Hier punkten dann DoS-Attacken besonders. In unserem Fall hängt es stark vom Ziel des Angreifers ab, da wir bisher von einer "stillen" Übernahme ausgegangen sind, würde ich jetzt glatt "none" sagen.

Jetzt nehmen wir mal den kleinsten und einen realistischen Wert und vergleichen diesen mit der Bewertung durch AVM.

Access Vector: Network
Access Complexity: High
Authentication: Single
Confidentiality Impact: Partial
Integrity Impact: Partial
Availability Impact: None

Das macht einen Base Score von 3.6, was sicherlich auch nicht die Welt ist, aber bei der Komplexität schon heftige Zugeständnisse macht und von einem eingeschränkten Account ausgeht. Trotzdem ist das meilenweit von den 0.8 von AVM entfernt.

Realistischer (in meinen Augen) ist:

Access Vector: Network
Access Complexity: Medium
Authentication: Single
Confidentiality Impact: Complete
Integrity Impact: Complete
Availability Impact: None

was dann schon mal den stolzen Base Score von 7.9 ergibt.

Die anderen Faktoren (Temporal Score und Environmental Score) lasse ich jetzt mal weg, die drücken zwar den Base Score, aber die kann AVM unmöglich seriös beantworten. Dabei geht es nämlich u.a. um solche Fragen wie die nach dem Schadenspotential (CDR) und das ist nun einmal nicht von AVM, sondern vom Besitzer der Box abhängig. Sicherlich ist der Verlust der kompletten Kindervideos des Nachwuchses auf der angeschlossenen USB-Platte (es gibt kein Backup, warum auch immer) nichts im Vergleich zur Kernschmelze im AKW, aber da liegt auch deutlich die Sujektivität jeder dieser Einschätzungen auf der Hand. Schon in einem kleinen Architekturbüro kann das ganz anders aussehen ...

Also AVM: Bitte nicht nur die 0.8 plakativ in den Vordergrund rücken, schreibt doch einfach noch dazu, wie Ihr diesen Wert ermittelt habt.

Die jetzt von heise-Security "entdeckte Lücke" habe ich vor einem halben Jahr in deren Forum beschrieben (inkl. Zertifikat-Pinning als Lösung, auch wenn ich es als "Pairing" bezeichnet habe), nachdem ich sie im November 2013 an AVM gemeldet und auch in einer E-Mail an Jürgen S. von heise Security am 13.11.2013 aufgezeigt hatte, zusammen mit der RC4-only-Verschlüsselung der FRITZ!OS-Versionen zwischen 05.60 und 06.10 (es gab es mehrere Mails dazu, auch zwei Antworten seinerseits). Vielleicht hat er die letzten E-Mails ja jetzt "entdeckt" ? :crazy:
Der einzige, der damals auf das Thema überhaupt anspringen wollte und ab und an per PN bei mir nachgehakt hat, ob ich etwas von AVM oder heise gehört habe, war RAMler ... ansonsten interessierte das keine Sau und AVM hat auch nie explizit zum MITM-Szenario Stellung bezogen (zur RC4-Frage schon, aber auch erst nach 3x nachhaken). Nur deshalb habe ich das mit der Lücke in der App schließlich bei heise im Forum irgendwann mal geschrieben - ich war schlicht der Überzeugung, es interessiert bei AVM niemanden wirklich und keiner kümmert sich darum.

[EDIT]Das Mißverständnis mit heise.de wurde inzwischen ausgeräumt, mein Dank geht an Hr. Eikenberg für das Update der Meldung.[/EDIT]

Aber wenn es AVM jetzt schon gelungen ist, dafür eine Lösung zu finden ... Hut ab.

Auch wenn ich natürlich nachvollziehen kann, daß dafür erst einmal das "semi-stabile" Zertifikate-Handling der 06.20 vorhanden sein mußte ... daß es von AVM nicht einmal eine Eingangsbestätigung gab und von Hrn. S. dann auch auf zwei Nachfragen per E-Mail keine Antwort mehr kam (was mich - ob zu Recht oder Unrecht will ich gar nicht bewertet wissen - in wilde Spekulationen anderer einstimmen ließ, vielleicht gab es ja bei Hrn. S. auch nur eine ProtonMail-Panne schon im Dez./Jan. ?) ist schon eine eher schwache Leistung. Aber egal, Schwamm drüber ... weiter im Text.
Das mußte ich aber mal loswerden, man kommt sich ja als "Rufer in der Wüste" schon richtig blöd vor, wenn man immer nur von den irgendwelchen abstrakten Gefahren schreibt, um dem Hersteller die Möglichkeit zur Lösung einzuräumen, für die er sich dann aber extrem viel Zeit nimmt (fast von IFA zu IFA - ich habe schon nicht mehr dran geglaubt).

Die neue iOS-Version der MyFRITZ!App (nur die konnte ich damals testen und auch nur für die habe ich das Problem jemals behauptet) ist seit 3 Tagen verfügbar.
Danke AVM, allmählich kehrt mein Glaube an Euch zurück.

Wie es bei den anderen Android-Apps aussieht (Wie kommen die eigentlich vom Internet auf die Box ?), kann ich mangels Endgerät nicht testen. Aber warum es nun ausgerechnet bei einer Ticker-App oder dieser CAM-App so vollkommen anders aussehen soll beim Zugriff auf die Box, würde ich erst einmal nicht verstehen. Kann die CAM-App überhaupt über das Internet ? Vielleicht kann ja ein Besitzer/Benutzer eines dieser Geräte und der Apps mal etwas dazu schreiben, wie die auf ein neues Zertifikat "ihrer" Box reagieren.