Unitymedia Fritz.Box wurde gehackt

[SpaceRat]

Ich hatte die FB auf dem Port 450 offen. Zum Zeitpunkt des öffnen des Fernzugangs (Version 5.50 oder früher) war nur eine Portrange bis 450 möglich, den ich dann insoweit ausgenutzt habe. Diese Beschränkung ist dann irgendwann mit OS 5.50+ (??) entfallen.

Insofern hat diese "security by obscurity"-Maßnahme doch etwas gebracht: Vor mir hat es einfach andere getroffen.

"security by obscurity" hat versagt: Der https-Teil ist closed source, was unter "security by obscurity" fällt.

Der Non-Standard-Port ist klassisches St.-Florian-Prinzip:
Heiliger St. Florian,
verschon' mein Haus, zünd' and're an!

Lenkradkrallen sind bzw. waren z.B. auch St.-Florian-Prinzip:
Wer dieses Auto will, der kriegt es auch. Aber wenn es nur darum geht, irgendein Fahrzeug für eine Fahrt zu erbeuten (Vollasi hat mal wieder den Bus verpaßt), dann ist die Lenkradkralle zumindest lästig genug, damit der Täter zum Auto daneben ohne Lenkradkralle greift.

 

[johnripper]

OK, diese im Internet gefundene Boxen können dann auch nicht gekackt werden, weil sie ja auf Port 443 bzw. auf einem anderen Port mit dem Dienst der für den Port 443 vorgesehen ist, nicht lauschen.

Der Fehler lag nicht in dem Protokoll 443 selbst, sondern im Fernzugang. Auf welchen Port der läuft dürfte m.E. ziemlich egal sein. Diesbezüglich ist die Pressemitteilung von AVM etwas ungenau. Aber AVM hat ja schon immer versucht komplizierte technische Begrifflichkeiten zu vermeiden (was es für mir immer schwierig macht zu verstehen, was sie genau meinen).

Da es vermutlich Portscans waren und weniger die öffentlich findbaren Boxen hatte man (sofern man sich nicht googeln lässt) einfach glück.

 

[johnripper]

Ich hatte die FB auf dem Port 450 offen. Zum Zeitpunkt des öffnen des Fernzugangs (Version 5.50 oder früher) war nur eine Portrange bis 450 möglich, den ich dann insoweit ausgenutzt habe. Diese Beschränkung ist dann irgendwann mit OS 5.50+ (??) entfallen.

Insofern hat diese "security by obscurity"-Maßnahme doch etwas gebracht: Vor mir hat es einfach andere getroffen.

"security by obscurity" hat versagt: Der https-Teil ist closed source, was unter "security by obscurity" fällt.

Was den Dienst angeht haste Recht.

Was das auffinden angeht, sehe ich das anders. Ich glaube kaum, dass die Ressourcen gehabt hätten für jede IP den vollen Portbereich zu scannen. Zumal dies wahrscheinlich aufgefallen wäre. Insofern hat es sehr gut funktioniert.

Im übrigen gebe ich dir natürlich recht, auch wenn ich das Prinzip erst mal googlen musste : )

 

[tq1199]

Der Fehler lag nicht in dem Protokoll 443 selbst, ...

Du meinst das HTTPS-Protokoll. Nein, das wurde nicht gehackt, dieses Protokoll ist auch nicht "closed source". Es geht um einen Dienst (closed source), für den AVM standardmäßig den Port 443, als Port zum lauschen vorgesehen hat und der mit dem HTTPS-Protokoll erreicht werden soll.

 

[eazrael]

johntheripper hat verstanden, was ich meinte. Wie würdet ihr denn die jetzige web-basierte Application-Authentifizierung nennen?

Die Fernwartung mit der vorgeschalteten HTTP-Authentifizierung wäre doch vermutlich gegen den Remote-Angriff immun gewesen, sofern die kritischen Skripte nicht von der Auth ausgenommen waren. Sofern sollte man doch die verwundbaren ziemlich hart eingrenzen können. Was uns Zwangsrouter-Nutzern natürlich eh nix hilft, da wir auf Gedeih und Verderben UM ausgeliefert sind.

Das wäre doch auch eine interssante Haftungsfrage. Bin ich verpflichtet die Fernwartung abzuschalten bis sich UM bequemt den Fix auszurollen oder haftet UM für den Missbrauch, weil die Config eigentlich deren Domäne fällt und sie den Fix nicht zeitnah ausgerollt haben?

Vor 2 Jahren gab's dann schon mal diese Lücke hiier:
http://www.unitymediakabelbwforum.de/viewtopic.php?f=53&t=20665

Danach gab's die vorgeschaltete HTTP-Auth für die Fernwarting (sofern man http deaktivierte und https aktivierte)

 

[SpaceRat]

Denn im Internet werden mit "site:myfritz.net" auch FritzBoxen angzeigt, die weder auf Port 80 noch auf Port 443 lauschen, sondern z. B. auf Port 81 oder 85 oder irgend ein anderer Port. OK, diese im Internet gefundene Boxen können dann auch nicht gekackt werden, weil sie ja auf Port 443 bzw. auf einem anderen Port mit dem Dienst der für den Port 443 vorgesehen ist, nicht lauschen.

Ich würde mich da jetzt nicht zu 110% drauf festlegen, aber doch zu 99%:

Jain.
Für den Google-Index sind Web-Seiten (http/https) und ggf. noch FTP-Server relevant. Wenn unter der Adresse xyz.myfritz.net nun nichts davon zu finden ist, dann sollte diese Fritz!Box auch nicht bei Google auftauchen.

Einschränkung: Für die Aufnahme in den Such-Index muß nicht unbedingt die Fritz!Box diesen ftp/http/https-Server darstellen, sondern es kann sich eben auch um ein angeschlossenes Gerät oder einen reingefreezten Apache handeln.

Erweiterung: Ist keiner der o.g. Server zu öffnen, erfolgt auch dann keine Aufnahme, wenn die Server vorhanden sind.

Test, Schritt 1:

• Suche auf Google nach site:myfritz.net
  Jede Menge Treffer
• Kopieren einer spezifischen Adresse aus den Suchtreffern, z.B. abcdefghij.myfritz.net und Wiederholen der Suche mit site:abcdefghij.myfritz.net
  Wir erhalten als Suchtreffer die gesamte Seitenstruktur

Fazit: Wir können durch Angabe der vollständigen MyFritz!-URL überprüfen, ob überhaupt etwas indiziert wurde.
Ich will jetzt nicht eine echte myfritz.net-Adresse als Beweis anführen, aber glaubt mir einfach, daß das durchaus auch dann funktioniert, wenn auf der Fritz!Box-Adresse selber nichts offen ist, aber auf einem angeschlossenen Gerät (Also <Gerät>.abcdefghijklm.myfritz.net).

Test, Schritt 2:

• Suche nach der eigenen MyFritz!-Adresse mit site:<eigene-MyFritz-Addy>.myfritz.net
  Es wurden keine mit Ihrer Suchanfrage - site:xxxxxxxxxxxxxxxx.myfritz.net - übereinstimmenden Dokumente gefunden.

Und das, obwohl unter dieser Adresse
- ein FTPS-Server
und
- drei bis vier HTTPS-Server (Darunter zwei Enigma-Receiver und der Fritz!Box-Fernzugang)
erreichbar sind.

M.a.W.: Da Google bereits jeweils am Auth/der Key-Challenge scheitert, wird auch genau gar nichts indiziert.
Dies gilt auch, wenn der Fernzugang auf Non-Standard-Port läuft, da Google dort niemals zu suchen anfängt. Suchtreffer auf Nicht-Standard-Ports resultieren aus Links auf regulär (Standardport) erreichbaren Seiten.

q.e.d.: Der Fritz!Box-Fernzugang wird nur deshalb überhaupt in den Google-Index übernommen, weil es dort auf dem Standard-Port eine Login-Seite zu indizieren gibt.
Gibt es aufgrund einer Key-Challenge oder wegen Basic Auth nichts zu indizieren, bleibt man für diese Suche unerkannt, ebenso, wenn man Google nicht durch Verlinkung auf einen Fernzugang auf den Non-Standard-Port stößt.

Bei einem Port-Scan auf die schon bekannte MyFritz!-Adresse würde der Fernzugang allerdings auch weiterhin gefunden werden und wäre auch angreifbar (Nicht bei mir, da schon Firmware 06.03 installiert).

 

[tq1199]

..., aber glaubt mir einfach, daß das durchaus auch dann funktioniert, wenn auf der Fritz!Box-Adresse selber nichts offen ist, aber auf einem angeschlossenen Gerät (Also <Gerät>.abcdefghijklm.myfritz.net).

Das müssen wir nicht "glauben", das ist so und das kann jeder der My!Fritz (bzw. einen anderen dyndns-Dienst) und z. B. FRITZ!App Cam auf seinem Smartphone/Tablet mit der FritzBox benutzt, testen.

 

[johnripper]

Die Fernwartung mit der vorgeschalteten HTTP-Authentifizierung wäre doch vermutlich gegen den Remote-Angriff immun gewesen, sofern die kritischen Skripte nicht von der Auth ausgenommen waren.

Es hätte mind. größeren Aufwand bedeutet. Ob damit das Leck vollständig abgedichtet gewesen wäre kann man nicht sagen, da man nichts über den Angriff weiß und ich nichts über die Wirkungsweise von HTTP-AUTH.
Ich bin auch der Meinung, dass die Identifizierung der Boxen schwieriger geworden wäre, da HTTP-AUTH keinen Rückschluss auf das gerät zugelassen hat. Aber da wurde ich anderer Stelle korrigiert, dass die Loginmaske durchaus etwas über eine Fritzbox gesagt hat.

Das wäre doch auch eine interssante Haftungsfrage. Bin ich verpflichtet die Fernwartung abzuschalten bis sich UM bequemt den Fix auszurollen oder haftet UM für den Missbrauch, weil die Config eigentlich deren Domäne fällt und sie den Fix nicht zeitnah ausgerollt haben?

Ja, m.E. schon. Schau mal in deine AGBs. Du bist zur "Schadensabwehr" verpflichtet. Deswegen verstehe ich nicht warum die KBW Kunden nicht per Email informiert wurden.

M.a.W.: Da Google bereits jeweils am Auth/der Key-Challenge scheitert, wird auch genau gar nichts indiziert.

Richtig.

 

[SpaceRat]

Vor 2 Jahren gab's dann schon mal diese Lücke hiier:
http://www.unitymediakabelbwforum.de/viewtopic.php?f=53&t=20665

Nicht wirklich.

Die Fritz!Boxen war noch nie über http von außen erreichbar, nur per https und das war schon immer standardmäßig aus.
Beständiges Wiederholen anderslautender falscher Behauptungen machen sie auch nicht wahrer.

Danach gab's die vorgeschaltete HTTP-Auth für die Fernwarting (sofern man http deaktivierte und https aktivierte)

Falsch.

Richtig ist:

1. Die Fritz!Boxen sind netzintern und nicht abschaltbar per http ansprechbar und das ist auch gut so, wie sollte man sie auch sonst einrichten?
2. Die Fritz!Boxen sind netzintern optional zusätzlich per telnet erreichbar (Nicht bei Kabel-Fritten)
3. Von außen sind alle Fritz!Boxen von außen standardmäßig nicht erreichbar.
4. Man kann Fritz!Boxen von außen optional ausschließlich per https erreichbar machen.

Details:

• Zu Punkt 1:
  Lokal und bei physischem Zugriff auf die Box ist es durchaus möglich, die Fritz!Box auf Werkseinstellungen zurückzusetzen.
  Genauso gut kann man die Fritz!Box (Außer Kabel-Modellen) mit einer Recovery-Firmware flashen, den Start-Vorgang anhalten udgl.
  Auch das ist gut so, oder wollt Ihr Eure Geräte wegwerfen/einschicken müssen, wenn Ihr das Passwort vergeßt?
  
  Physisch zugängliche Geräte sind niemals für irgendeine Sicherheitsstufe zertifizierbar.
  Ein Geldautomat ist auch immer nur so sicher, wie der Tresor, in den er eingebaut ist. Nimmt man den darin enthaltenen PC raus und stellt Ihn auf den Schreibtisch, könnte ihn mein Kater hacken.
• Zu Punkt 2+3:
  Telnet und auch das normale http-Interface sind standardmäßig und mit Werksmitteln nicht nach außen zu öffnen.
• zu Punkt 4:
  Der https-Zugang hat in der Vergangenheit (Firmware 04.55-04.xx, ggf. auch länger) Basic Auth zum Login benutzt, d.h. Login und Kennwort wurden in einem vom Browser dargestellten Popup eingegeben (oder mittels loginasswort@URL gleich beim Aufruf mit übergeben, diese Syntax wird aber von manchen Browser standardmäßig nicht mehr unterstützt, weil man auf diese Weise Vollhonks falsche URLs vorgaukeln konnte) und nach wohl definierten Standards an den Server übertragen.
  Hierbei ist ein "Passwort vergessen"-Link gar nicht möglich.
  
  In neueren Firmwares wurde Basic Auth durch eine von der Fritz!Box dargestellte Login-Seite ersetzt (Die der Grund ist, wieso die Fritz!Boxen im Google-Index indiziert werden, da diese Seite immer lesbar ist). Ein Passwort-Reset ist hier aber nicht möglich. Den "Passwort-Reset"-Link erreicht man erst, wenn man diese Login-Seite passiert hat und sich dann mit dem normalen Fritz!Box-Kennwort nochmals authentifizieren muß.

Den "Passwort vergessen"-Link erreicht man also nur, wenn man sich entweder lokal anmelden will oder die Authentifizierung für den Fernzugang bereits geschafft hat, nicht aber - wie behauptet - "einfach so aus dem Internet".

Für den Zugriff von außen kommt noch ein Aspekt etwas hinzu:
Selbst wenn der Link von außen erreichbar wäre, wäre er für einen Angreifer wertlos, da nach dem Reset der Zugriff von außen gesperrt wäre (Fernzugang ist standardmäßig aus) und ein Großteil der Boxen wäre danach sogar komplett offline, da bei DSL i.d.R. ja nun einmal Zugangsdaten benötigt werden, die dann mit weg sind.
Schlimmstenfalls wäre es also lästig, wenn es denn überhaupt ginge, was ja nun schlichtweg gelogen ist.

Für den Zugriff von innen kann man sich jetzt darüber streiten, ob der "Passwort vergessen"-Link so clever ist oder ob nicht ein physischer Reset-Knopf besser gewesen wäre.
Sicherlich hat sich die Fritz!Box damit als Firmen-Router in gewisser Weise disqualifiziert, denn mit physischem Reset-Knopf wäre sie in einem abgeschlossenen 19"-Rack vor Angriffen von innen sicher, während sie mit dem Link von innen angreifbar ist.

Diese Diskussion ist aber eher akademischer Natur:
Die Fritz!Box ist eben kein Profi-Router, sondern für private Internet-Anschlüsse konzipiert. Ein "richtiger" Router wird ja aus gutem Grund nicht per http/https gewartet, sondern per ssh oder sogar ausschließlich per serieller Konsole ...
Die einzige Gefahr, die bei einer Fritz!Box von innen droht, ist der Sproß der Familie, der unbedingt statt auf Pornoseiten auf irgendwelchen Lernseiten surfen will, die die Eltern ihm gesperrt haben, damit er kein Streber wird sondern sich normal entwickelt. Und vor dem ist die Fritz!Box so oder so nicht sicher, da sie für ihn physisch erreichbar ist.
Genauso kann er auch einfach per ethercap den normalen http-Login mitloggen ...

Und in besseren Zeiten gab es dafür eine ganz einfache und wirksame Methode: Über's Knie legen.

 

[johnripper]

• zu Punkt 4:
  Der https-Zugang hat in der Vergangenheit (Firmware 04.55-04.xx, ggf. auch länger) Basic Auth zum Login benutzt, d.h. Login und Kennwort wurden in einem vom Browser dargestellten Popup eingegeben (oder mittels loginasswort@URL gleich beim Aufruf mit übergeben, diese Syntax wird aber von manchen Browser standardmäßig nicht mehr unterstützt, weil man auf diese Weise Vollhonks falsche URLs vorgaukeln konnte) und nach wohl definierten Standards an den Server übertragen.
  Hierbei ist ein "Passwort vergessen"-Link gar nicht möglich.
  
  In neueren Firmwares wurde Basic Auth durch eine von der Fritz!Box dargestellte Login-Seite ersetzt (Die der Grund ist, wieso die Fritz!Boxen im Google-Index indiziert werden, da diese Seite immer lesbar ist). Ein Passwort-Reset ist hier aber nicht möglich. Den "Passwort-Reset"-Link erreicht man erst, wenn man diese Login-Seite passiert hat und sich dann mit dem normalen Fritz!Box-Kennwort nochmals authentifizieren muß.

Hierzu eine Anmerkung:
Soweit ich mich erinnern kann wurde die HTTP-Auth stets vor die Loginseite geschaltet. Möglich, dass es in noch früheren Version nur den HTTP-Auth gab. Dazu kann ich nicht sagen.

Konkrekt:
- Man musste sich zuerst mittels HTTP-Auth einloggen. Dazu konnte man in dem Menü "Fernwartung" einen Benutzernamen und ein Passwort festlegen, so wie es einem gefällt.
- Im zweiten Schritt musst man das Admin Passwort der Box auf der Login Seite die mittels HTTP/HTML dargestellt wurde eingeben.

Dies war zumindest so, sofern es um die Fernwartung über WAN ging. Welche FW Versionen dies betraf kann ich leider nicht sagen. Auch wann dieses Feature ersatzlos gestrichen wurde weiß ich leider nicht mehr. War aber bei der 85.50.50 schon so implementiert, dass man nur noch die Loginseite erhalten hat.

 

[SpaceRat]

Die Fernwartung mit der vorgeschalteten HTTP-Authentifizierung wäre doch vermutlich gegen den Remote-Angriff immun gewesen, sofern die kritischen Skripte nicht von der Auth ausgenommen waren.

Es hätte mind. größeren Aufwand bedeutet. Ob damit das Leck vollständig abgedichtet gewesen wäre kann man nicht sagen,

Doch, kann man und das sogar mit Bestimmtheit: Es hat den Angriff als solchen nicht verhindert.

Das kann man ganz einfach daran sehen ...

AVM Update News
FRITZ!Box 7170 Version 29.04.88
Neue Features: - Sicherheit: Unberechtigte Zugriffsmöglichkeit auf FRITZ!Box behoben. Beachten Sie dringend die aktuellen Hinweise unter http://www.avm.de/sicherheit
Sprache: Deutsch Dateigröße: 8340 KB
Version: 29.04.88 Datum: 10.02.2014
...
AVM Update News English
FRITZ!Box 7570 VDSL Version 75.04.92
New Features : -Security: removes possibility for unauthorized access to FRITZ!Box. Please check for important information here: http://www.avm.de/en/Sicherheit
Sprache: English Dateigröße: 12340 KB
Version: 75.04.92 Datum: Feb 10, 2014

... daß AVM auch uralte und eigentlich gar nicht mehr gepflegte Boxen aktualisiert hat, deren Firmware noch vorgeschaltetes Basic Auth verwendet haben.

Laut meiner Anfrage vom 9.2.2014 bei AVM gab es übrigens keine dokumentierten Fälle von Betroffenen bei diesen Boxen:

Generell kann ich ein Eindringen über den Https-Fernzugriff derzeit für
diese älteren Boxen noch nicht ausschließen (wenngleich uns zu diesen
älteren FRITZ!Boxen noch keine Fälle bekannt geworden sind). Daher empfehle
ich auch Nutzern von FRITZ!Boxen dieser Gerätegeneration, den
https-Fernzugriff zu deaktivieren, sowie die weiteren empfohlenen Maßnahmen
soweit in der betreffenden FRITZ!Box relevant, umzusetzen.

Dafür muß man AVM einfach mal ein riesenfettes Lob aussprechen.
Erstens hat man sich die Mühe gemacht ein EOL-Produkt überhaupt noch mal anzufassen, um es gegen eine aktuelle Lücke auszutesten und zweitens hat man sogar noch ein Update hinterhergeliefert.
Das würde so gut wie kein anderer Hersteller machen.

Tatsächlich scheint es aber, daß allein der zusätzliche Aufwand in diesem Fall zumindest vorerst Schutz "genug" war. Was nur zu gut beweist, daß auch Hacker faule Säcke sind.

 

[SpaceRat]

Ja, m.E. schon. Schau mal in deine AGBs. Du bist zur "Schadensabwehr" verpflichtet. Deswegen verstehe ich nicht warum die KBW Kunden nicht per Email informiert wurden.

In dem Punkt wäre ich ja kackendreist:

An: Unitymedia/KabelBW (Unzutreffendes bitte streicheln)
Sehr geehrte Vollpfostinnen und Vollpfosten,
da ich gemäß Abschnitt B, Punkt 1.4 Ihrer AGB zum Schutz der Zugangsdaten verpflichtet bin, diese aber aufgrund aktueller Kenntnisse über Sicherheitslücken in dem von Ihnen gestellten Fritz!Box-Router als ungeschützt zu betrachten sind, fordere ich Sie hiermit auf, die vorgenannte Sicherheitslücke durch schnellstmögliches - d.h. umgehendes - Aufspielen der Ihnen nachweislich vorliegenden aktualisierten Firmware Version 06.04 zu schließen.
Das Deaktivieren des Fernzugriffs stellt hierzu keine Alternative dar, da die Gestellung einer Fritz!Box 6360 und somit auch der aus diesen bekannte Funktionsumfang zu den zugesicherten Eigenschaften meines Vertrages gehört, von denen der Fernzugriff entscheidend für den Vertragsabschluß war.
Der Erledigung der Angelegenheit sehe ich bis zum 13.3.2014 entgegen und verbleibe
Mit freundlichen Grüssen,
(Unleserliche Unterschrift)
Unity Opfer

Für DS-lite-Kunden optional frech zu ergänzen:
s/(Fernzugriff )(entscheidend)/$1 sowie der MyFritz!-Dienst - als Alternative zur DS-lite-bedingten Unmöglichkeit, ein VPN zu errichten - $2/g;
s/(abschluß war)/${1}en/g;

 

[SpaceRat]

Soweit ich mich erinnern kann wurde die HTTP-Auth stets vor die Loginseite geschaltet. Möglich, dass es in noch früheren Version nur den HTTP-Auth gab. Dazu kann ich nicht sagen.

Bevor wir das noch ein paar Stunden ausdiskutieren, hier einfach der Bildbeweis, wie's wirklich war und jetzt ist:

• Alte Box mit Basic Auth (Zweischritt-Verfahren):
  1. Schritt: Basic-Auth (Hier im IE):
     
     
     
     Rot markiert: Der "realm", ausgestrichen: Die Adresse
  2. Schritt: "Lokaler" Login (Derselbe, wie bei einer lokalen Anmeldung, aber remote eben erst im 2. Schritt):
     
     
     
     Erst hier ist der "Passwort vergessen"-Link verfügbar.
• Neue Box mit Form-Login (Einschritt-Verfahren):
  
  
  
  Hier gibt es gar keinen "Passwort vergessen"-Link.

 

[SpaceRat]

- Man musste sich zuerst mittels HTTP-Auth einloggen. Dazu konnte man in dem Menü "Fernwartung" einen Benutzernamen und ein Passwort festlegen, so wie es einem gefällt.
- Im zweiten Schritt musst man das Admin Passwort der Box auf der Login Seite die mittels HTTP/HTML dargestellt wurde eingeben.

Korrekt.
Und erst beim zweiten Schritt gab es einen "Passwort vergessen"-Link, also genau nicht ungeschützt im Internet.

Dies war zumindest so, sofern es um die Fernwartung über WAN ging.

Lokal entfällt einfach der HTTPS-Basic-Auth und man landet direkt im Formular für die Anmeldung.

Welche FW Versionen dies betraf kann ich leider nicht sagen. Auch wann dieses Feature ersatzlos gestrichen wurde weiß ich leider nicht mehr. War aber bei der 85.50.50 schon so implementiert, dass man nur noch die Loginseite erhalten hat.

Richtig.
Und auch auf der gibt es keinen "Passwort vergessen"-Link.

 

[eazrael]

- Man musste sich zuerst mittels HTTP-Auth einloggen. Dazu konnte man in dem Menü "Fernwartung" einen Benutzernamen und ein Passwort festlegen, so wie es einem gefällt.
- Im zweiten Schritt musst man das Admin Passwort der Box auf der Login Seite die mittels HTTP/HTML dargestellt wurde eingeben.

Korrekt.
Und erst beim zweiten Schritt gab es einen "Passwort vergessen"-Link, also genau nicht ungeschützt im Internet.

Nein, die Zwei-Schritt-Authentifizierung gab es damals nur,wenn man https explizit aktivierte, was es nicht per Default war, asonsten war die Login-Seite ungeschützt aus dem Netz erreichbar. Das war auch der Grund warum ich das damals als Sicherheitslücke ansah. Es gab ein 10min (- Sync-Dauer) wo die Passwort Zurücksetz-Funktion wohl von aussen zugänglich war.

Das auch evt. ältere Modelle gepatcht werden, ist meiner Meinung nach kein Beweis, dass es auch mit der http-auth geklappt hätte. Wenn's ne gemeinse Source ist, dann kann eine Änderung einen Build/Release in allen möglichen Modellen triggern.

Hab mich nichh so richtig dafür interessiert, gibt's eigentlich ne öffentliche Beschreibung wie der Hack funktioniert, bzw welche URLs betroffen sind?

 

[johnripper]

Cool danke. Beweist auch dass am HTTP-Auth nicht zu erkennen ist ob es sich um eine Fritzbox handelt.
Außer man verwendet den myfritz.net DyDns Dienst wodurch man es am Hostnamen erkennt.

 

[SpaceRat]

Cool danke. Beweist auch dass am HTTP-Auth nicht zu erkennen ist ob es sich um eine Fritzbox handelt.

Kann man sehen wie man will.
Ich habe den realm extra mal rot markiert.
Da steht zwar nicht dick und fett "Fritz!Box", aber eben "HTTPS Access" und das ist eben kein generischer Text der bei jedem HTTPS-Sever kommt, sondern etwas Spezielles.

Auch die Fehlermeldung nach Fehllogin kann man als Indiz nehmen:

401 Unauthorized
ERR_ACCESS_DENIED
Webserver Tue, 11 Feb 2014 11:33:56 GMT

Bei diesem HTTPS-Server ist der realm z.B. "ANAA" und die Fehlermeldung erfolgt in XML-Form:

<response __fvdSurfCanyonInserted="1">
<error id="authRequired" text="Authentifizierung erforderlich!" debug="Authentifizierung erforderlich!"/>
</response>

Bei einem E2-Receiver mit OpenWebIf lautet der Realm "OpenWebif" und als Fehlermeldung kommt nur

Unauthorized
401 Authentication required

usw. usf.

Somit kann man aus realm und Fehlermeldung schon den Fingerabdruck einer Fritz!Box erkennen.

Außer man verwendet den myfritz.net DyDns Dienst wodurch man es am Hostnamen erkennt.

Den gab es damals noch nicht.

 

[-Pirat-]

mich wurde gerne jetzt Interessieren, wer die Rechnung beim UM zahlen muss? Bis jetzt hatte ich nix bekomme, mein Abrechnung war am 10.02.
Wie ich gehört habe, bleiben Telekom Kunden an der Rechnung sitzen.

 

[SpaceRat]

Nein, die Zwei-Schritt-Authentifizierung gab es damals nur,wenn man https explizit aktivierte,

Richtig.

was es nicht per Default war, asonsten war die Login-Seite ungeschützt aus dem Netz erreichbar.

Falsch.
Du schaltest eben nicht https an oder aus, sondern den Fernzugriff.

Das war auch der Grund warum ich das damals als Sicherheitslücke ansah.

So. Und jetzt habe ich mir den ganzen Thread nochmal angetan und auch die verlinkten Artikel durchgelesen und erst dann wird einem überhaupt klar, worauf Du hinaus willst:
Gemeint ist der Sonderfall Business-Anschluß mit statischer IP.

Dort kam es zu einer unglücklichen Verkettung von Umständen:
Bei dieser Betriebsart ist die Firewall der Fritz!Box aus und daher das eigentlich nur lokal erreichbare HTTP-Web-Interface auch von außen erreichbar und damit hat man dann den lustigen Effekt, daß man die Fernwartung über https zwar munter ein- und ausschalten kann, die lokale Zugriffsmöglichkeit aber trotzdem immer offen bleibt. Der lokale Zugang wurde mangels Firewall also zur 2. Fernwartung ...

Das ist bzw. war zwar in der Tat ein Problem, hat aber für meine Begriffe eher mit einem Fehler in der von UM übermittelten Konfiguration zu tun statt mit der Fritz!Box:
Wenn man die Firewall der Fritz!Box abschaltet (Und das kann man nur durch direkten Eingriff in die Konfiguration, das kann also in der Häufung nur UM selber gemacht haben), dann fällt das unter "works as designed" wenn man daraufhin alles auf der Fritz!Box erreichen kann, was man ansonsten nur von intern erreichen könnte. Ich würde mal schätzen, daß man dadurch auch einen auf der Fritz!Box ggf. aktivieren Samba-Server von außen hätte erreichen können ...

Sprich: Die Fritz!Box hat dabei einfach nur genau das gemacht, was von ihr gefordert wurde.
Ich hab das auch mal gegoogelt und wirklich nur Treffer im Zusammenhang mit Unitymedia gefunden, obwohl man statische IPs z.B. auch von NetCologne kriegt oder von Alice kriegen konnte.
Vielleicht sollten die Hobby-Netzwerker bei Unitymedia wirklich mal aufhören die Kunden zu bevormunden und die Konfiguration in deren Hände legen ...

 

[johnripper]

Wie ich gehört habe, bleiben Telekom Kunden an der Rechnung sitzen.

Ja weil die Telekom keine FBen verwaltet. UMKBW und KD sowie die anderen Kabelprovider schon.

 

[Joerg123]

Kann ich seitens der Telekom schon verstehen, die vertreiben ja ihre Speedport-Router = wer da ne Fritzbox nutzt muss sich diese selbst besorgt haben.

Immerhin ist das Problem nun auch bei Unitymedia offiziell angekommen und man hat es geschafft eine Info bereit zu stellen:
http://www.unitymedia.de/hilfe_service/aktuelles_anderungen/
aber auch nur der Hinweis Fernwartung und MyFritz zu deaktivieren, sowie unbekannte IP-Telefone zu löschen. Eine Info wann ein Update erwartet werden kann findet sich nirgends

 

[eazrael]

Erstmal danke für die Erklärungen. Wusste gar nicht dass ich ein Sonderfall bin...

Vielleicht sollten die Hobby-Netzwerker bei Unitymedia wirklich mal aufhören die Kunden zu bevormunden und die Konfiguration in deren Hände legen ...

Das würde ich auch toll finden. (hoffentlich war das nicht ironisch gemeint)
Find's immer noch lustig und erschreckend dass nach dem Deaktivieren meines WLANs durch UM nach einem FW Update mir die Support-Mitarbeiter immer noch erzählen, dass das WLAN bei Business Kunden mit statischer IP-Adresse nicht funktioniert und auch nie funktioniert haben kann. Klar, hab mir ein Jahr lang ein funktionierendes WLAN eingebildet. :hirnbump:
Wobei nach dem letzten Sommer bin ich wieder froh, nicht mehr das WLAN der FB zu nutzen.

Sorry, aber bei den geschlossenen Zwangsrouter der Kabel-Netzbetreiber muss man sich echt fragen wer für das Ding verantwortlich ist. Vermutlich niemand oder immer der andere.

 

[johnripper]

Auch UM kommt nicht für alle Schäden auf. Wenn es keine UM FB ist dann übernehmen die den Schaden nicht.
Auch das macht Sinn, da sie ja mit dem Gerä nichts zu tun haben.

 

[SpaceRat]

Sorry, aber bei den geschlossenen Zwangsrouter der Kabel-Netzbetreiber muss man sich echt fragen wer für das Ding verantwortlich ist. Vermutlich niemand oder immer der andere.

Siehst Du doch: "Immer der andere" ist richtig vermutet.

UM schiebt's auf AVM und AVM auf UM.
Siehe Gigaset-DECT-Teile, siehe AFTR-loss, siehe einseitige VoIP-Telefonie-Verbindung bei VPN, ...

Sicher baut AVM mehr als genug Fehler, das tut fast jeder, es sei denn er tut nichts.
Alle o.g. Fehler hat AVM ja auch tatsächlich verbrochen, nur daß jetzt jeder eine Ahnung hat, wie lange UM wie eine Glucke auf den Firmwares sitzt, die diese Fehler beheben würden ...

Mich juckt es relativ wenig, wenn in FW 05.51 ein Fehlerchen drin ist, solange ich frei entscheiden darf zur 05.50 zurückzukehren und auch 2 Tage später die 05.52 aufspielen kann.

Durch die Release Notes aus der vorliegenden FW 06.04 können wir ja inzwischen sehen, daß der VPN<>VoIP-Bug am 31.01.2014 behoben wurde und den Fix für Gigaset-DECT-Teile gab's am 17.7.2013 ....

Und halten wir einfach mal fest, daß AVM die FW 06.04 mit dem Security Fix bereits am 8.2.2014 zur Verfügung gestellt hat, heute ist der 11.2.2014 ...
... wenn ich bei AVM arbeiten würde, käme ich mir ehrlich gesagt ver*rscht vor, wenn ich wegen der Angelegenheit am Wochenende durchwirken müßte und einer der hauptsächlich betroffenen Anbieter dann die Ruhe weg hat ...

 

[SpaceRat]

Auch UM kommt nicht für alle Schäden auf. Wenn es keine UM FB ist dann übernehmen die den Schaden nicht.
Auch das macht Sinn, da sie ja mit dem Gerä nichts zu tun haben.

In dem Fall wäre es ja auch wirklich der Kunde selber schuld, ich habe meine Fritz!Box 7390 jedenfalls umgehend aktualisiert.