[Info] FRITZ!Box 7490 Labor-Firmware FRITZ!OS 6.69-41049 (09.09.2016)

Status
Für weitere Antworten geschlossen.
Hi,
das mit der GUI intern ist bei mir jetzt auch dazu gekommen. Interessanterweise komme ich über MyFritz noch ran. Zum Glück läuft sie bei mir sonst stabil bis auf die Transferaussetzer.

Ralf
 
Gibt's bei Dir, Wotan, ein IP-Telefon mit der Nr. 620 und der Login-Freigabe aus dem Internet? Falls ja, hast Du Glück, daß die Verbindung anscheinend nicht klappt ...

Natürlich gibt es die, habe ich zur Zeit deaktiviert.
Bei einer 128-Bit Verschlüsselung sollte soviel nicht passieren.
Wenn doch hätte AVM ein richtig großes Problem.
 
Bei mir läuft die Box, seit diese Firmware erschienen ist, ohne Murren. Auch mein Internetradio, das mit Vorgängerversionen Probleme hatte (Aussetzer) läuft klaglos. Sensibilisiert durch diverse Meldungen habe ich auch öfter versucht, die GUI zu erreichen, bisher ohne Probleme. Die Box ist seit 09.09.2016 ohne Restart durchgelaufen. Ausgangspunkt war die offizielle Firmware (hatte von einer vorhergehenden Beta recovert, da Probleme) und nun das Update auf diese Labor.
 
Auch mein Internetradio, das mit Vorgängerversionen Probleme hatte (Aussetzer) läuft klaglos.

Bei mir immer noch nicht.
Internetradios, die im FB-Medienserver eingerichtet sind, machen keine Probleme, jedoch alle, die auf diversen PCs und Smartphones in eigenständigen Apps laufen, haben mehr oder weniger oft diese Ausfälle (egal ob im LAN oder WLAN).
 
Noch nie so viele Resyncs gehabt wie in dieser Labor. Gehe jetzt zurück auf die vorherige DSL.
Wenn das weiter so unstabil läuft an meinem VDSL Vectoring Port, verlasse ich den Laborzweig und bleibe auf der Release hocken bis es rund läuft.
 
Bei mir immer noch nicht.
Internetradios, die im FB-Medienserver eingerichtet sind, machen keine Probleme, jedoch alle, die auf diversen PCs und Smartphones in eigenständigen Apps laufen, haben mehr oder weniger oft diese Ausfälle (egal ob im LAN oder WLAN).
Am Handy oder Tablet habe ich noch nicht längere Zeit Radio gehört, aber meine beiden Internetradios Medion+MusikPal laufen den ganzen Tag, da ist mir bei dieser Firmware noch kein Aussetzer aufgefallen. Beide Geräte laufen über WLAN.
 
Hallo mir ist aufgefallen, das bei angeschlossenen Gigaset modellen nur bis 11 Ziffern einer ankommenden Rufnummer angezeigt werden, wenn es mehr sind steht nur "..."
Kann zufällig einer sagen ob sich daran was geändert hat?
Also ob die Rufnummer komplett angezeigt wird?

Gruß Chris
 
Bei einer 128-Bit Verschlüsselung sollte soviel nicht passieren.
Hacker sind ja findige Leute - und es ist die durchaus interessante Frage, wie ein solcher Angriff funktioniert.
Ich VERMUTE aus eigenen Analysen, dass das über ein Android Smartphone läuft. Wenn dort das Password für die 128bit Verschlüsselung in der SIP App schlecht geschützt abgelegt ist, dann kann es sein, dass man nur relativ wenige Versuche braucht, um das Password herauszufinden.
Welche SIP app verwendest Du? Die FRITZfon von AVM? Oder z.B. Zoiper, ...?
Man hat ja auch noch weitere Apps und weiß nicht, ob möglicherweise eine von diesen anderen auf Daten der SIP-App zugreift und weitermeldet.
 
CSipSimpel und FRITZ!Fon App aber meistens sowiso über VPN.
 
Hallo zusammen,

mir ist in dieser FW eben aufgefallen, dass ich bei der Kindersicherung die Zeiten nicht mehr in der grafischen Übersicht verändern kann.
Ich kann im Zeitgitter zwar "blaue Balken" hinzufügen, jedoch kann ich sie nicht wieder wegnehmen.
Auch bei neu hinzugefügten Profilen funktioniert es nicht.

Lieben Gruß
Andreas
 
Jau, kann ich bestätigen.
 
128-Bit-Verschlüsselung? Wo kommt die hier zum Einsatz?

Kann mal bitte jemand genauer erklären, wer oder was hier mit dieser "128-Bit-Verschlüsselung" gemeint sein soll?

Wo kommt die bei einem externen Versuch der Registrierung eines SIP-Clients überhaupt vor?

Ausgangspunkt war hier doch der Versuch, sich an einem für den Zugriff aus dem Internet freigegebenen "Telefoniegerät" 62X anzumelden oder habe ich da etwas verpaßt?

Da gibt es aber keine "Verschlüsselung" in dem Sinne, daß die Datenübertragung irgendwie nicht mitgelesen werden könnte ... diese Anmeldung und das dort verwendete Kennwort ist nur dadurch geschützt, daß es nicht im Klartext übermittelt wird und an dieser Stelle ein "gesalzener Hash-Wert" über das (beiden Seiten bekannte) Kennwort verwendet wird.

Da sowohl der verwendete "salt"-Wert (als "nonce") bekannt ist als auch das Ergebnis der (kryptographischen) Hash-Funktion (hier könnte man mit viel gutem Willen die 128 Bit finden), kann ein Angreifer problemlos so lange probieren wie er will, um das verwendete Kennwort zu ermitteln. Genau aus diesem Grunde darf/soll das auch keines sein, was man in einem Wörterbuch finden könnte und zwar in keiner Permutation (also rückwärts oder mit "l33t speak" oder etwas ähnlichem).

Nur die Dauer jeder eigenen erneuten Berechnung mit dem nächsten zu probierenden Kennwort limitiert einen Angreifer an dieser Stelle ... angesichts heutiger Möglichkeiten der Berechnung solcher Algorithmen auf spezialisierten Prozessoren (die MD5 in Hardware und kürzester Zeit berechnen) und der Auslagerung "in die Cloud" mit mehr als einer möglichen parallelen Instanz, sind die üblichen früheren Überlegungen zur Dauer solcher Angriffe auch nicht mehr ganz zutreffend.

Insbesondere ein Angreifer, der in der Lage ist, den Verkehr zwischen einem berechtigten Client und dem SIP-Registrar zu belauschen und zu manipulieren (und der ist i.d.R. eben unverschlüsselt), braucht den ganzen Aufwand gar nicht zu betreiben. Hat so ein Angreifer entsprechende "rainbow tables" mit einem bekannten Salt vorliegen und kann den Client dazu bringen, seinerseits das richtige Kennwort und den von ihm verwendeten "nonce"-Wert für einen Hash-Vorgang zu verwenden (der Client bringt in diese Berechnung keinen eigenen zufälligen Wert mehr ein), dann kann mit dem Ergebnis der Berechnung durch den Client wieder das verwendete Kennwort ermittelt werden.

Zwar ist auch das noch nicht trivial, aber dafür gibt es Programme (z.B. hashcat, das kennt auch die "SIP Digest Authentication (MD5)") und so eine Berechnung hat auch keine wirkliche Eile - solange der Angegriffene sein Kennwort nicht regelmäßig wechselt, reicht der einmal ermittelte Hash-Wert bei bekanntem "nonce"-Inhalt aus, um irgendwann später auf das verwendete Kennwort zu kommen.

In diesem Zusammenhang ist auch der von AVM verwendete Weg des Hashens bei der GUI-Anmeldung noch etwas unsicherer ... dort wird in die Berechnung des Hash-Wertes nur noch die "challenge" (32 Bit) als "salt" einbezogen (+ 1 Bindestrich), während bei einer "normalen Digest-Authentifizierung" nach RFC 2617 wenigstens noch ein paar zusätzliche variable Anteile bei der Digest-Berechnung berücksichtigt werden (realm, usw.), was die Nutzung vorberechneter Tabellen für mehrere Dienste erschwert.

Wobei ein Angreifer im Falle des Logins in die FRITZ!Box (das gilt jetzt nicht mehr für SIP (da kommt RFC 2617 zum Einsatz), sondern für Benutzerkonten im GUI) das auch einfacher erreichen kann ... sofern er als MITM zwischen Box und Client kommt und den durchlaufenden Verkehr nicht nur mitlesen, sondern auch verändern bzw. teilweise unterdrücken kann (durch 304 oder auch 301). So ein MITM ist manchmal schneller als Proxy etabliert und akzeptiert, als man es gemeinhin erwarten würde ... z.B. über das "Web Proxy Auto Discovery"-Protokoll (WPAD).

Die gesamte Sicherheit der Anmeldung dort beruht auf zwei Javascript-Dateien (login.js und avmcore.js) und beide könnten von einem Angreifer als Proxy zwischen Client und Box passend manipuliert werden, da ihre Übertragung im Normalfall durch nichts gesichert ist.

Wenn dann in der Folge die MD5-Ermittlung (in avmcore.js) gar keine wirkliche Berechnung vornimmt (bis zu 12 Zeichen Kennwort könnten zusammen mit 4 Byte Challenge 1:1 in den 128 Bit eines angeblichen MD5-Hashes "kodiert" werden und da der Challenge-Wert eigentlich auch nicht gebraucht wird, denn er steht noch einmal direkt vor dem Hash-Wert in der Antwort, könnte man sogar 16 Zeichen Kennwort direkt "verschlüsseln") oder der Code in "login.js" diese (richtige oder angeblich richtige) MD5-Berechnung gar nicht mehr aufruft, dann kriegt der Client (und der Benutzer desselben) das nicht einmal mit, wenn dieser "Proxy" dann einfach anstelle des Clients die Berechnung des richtigen Hash-Wertes nachträglich vornimmt und die Authentifizierung aus Sicht des Servers und des Clients reibungslos abgelaufen ist. Dann hat der Angreifer auf seinem Proxy die Kenntnis des verwendeten Kennworts erlangt und weder Server (FRITZ!Box) noch Client haben davon etwas bemerkt.

Für eine einzelne Session muß natürlich ein derartiger Aufwand auch gar nicht betrieben werden ... da reicht es bereits aus, wenn der Angreifer sich überhaupt als Proxy in die Verbindung zwischen FRITZ!Box und Client einklinken und eine SID für eine gültige Sitzung "erbeuten" kann.

AVM versucht zwar mit der Protokollierung von IP-Adressen beim Login das Gegensteuern gegen solches "Hijacking", aber wer liest denn die Ereignisprotokolle schon so genau, daß er den Unterschied zwischen 192.168.178.22 und 192.168.178.23 bei einer Nachricht für die Anmeldung eines Benutzers registrieren würde ... selbst ich mache das zugegebenermaßen nicht und ich bin nun wirklich paranoid in diesen Dingen.

Selbst bei deutlicher voneinander abweichenden Client-Adressen prüft wohl kein FRITZ!Box-Besitzer ständig, ob die Anmeldung auch wirklich vom richtigen Gerät erfolgte, zumal ja auch nur die IP-Adresse (bei vielen Installationen ohnehin per DHCP eher "zufällig" verteilt) und nicht der Name des Gerätes (aus Sicht der FRITZ!Box) in der Nachricht im Protokoll auftaucht.

Jetzt kann ja mal jeder Leser überlegen, ob er aus dem Stand die von seinem Smartphone gerade verwendete IP-Adresse weiß ... es mag ein paar Wenige geben, die jetzt im Brustton der Überzeugung "aber klar doch" antworten können/dürfen.

Der überwiegende Teil der Benutzer (m.E. braucht es schon Kommastellen nach der Null bei der Angabe in Prozenten für die berühmten "Ausnahmen") kann mit dieser Angabe vielleicht bei der nachträglichen Analyse noch etwas anfangen, aber nicht im täglichen Umgang und ich behaupte mal, daß 95% der FRITZ!Box-Besitzer gar nicht wissen, was die Zahlen in der Nachricht überhaupt sollen ... mit ein wenig Glück wird noch wahrgenommen und unterschieden, ob die Anmeldung von intern oder von extern erfolgte (die Nachricht ist dieselbe, nur die IP-Adresse gibt Auskunft darüber).

Das Einzige, was hier wirklich helfen würde, wäre die Ende-zu-Ende-Verschlüsselung zwischen FRITZ!Box und Client über TLS (das hilft gegen SID-Hijacking und die Änderung von JS-Dateien gleichzeitig) ... aber dazu konnte sich AVM bisher noch nicht durchringen, obwohl es doch inzwischen seit 4 Jahren mit "HSTS" einen Mechanismus für die bequeme Umleitung derartiger Requests in den meisten modernen Browsern gibt und der "Bedienkomfort" kaum leiden würde. Und dann könnte man auch wirklich von "Verschlüsselung" bei diesen Zugriffen reden ... auch wenn der Ausgangspunkt hier ja mal die SIP-Authentifizierung war (die davon unbeeindruckt bleibt).
 
Zusätzlich zur Ende-zu-Ende-Verschlüsselung der Kommunikation zwischen Client und FRITZ!Box ist es m.E. durchaus auch ein Einfallstor für Hacker, wenn in einer App die Zugangsdaten unsicher auf dem Smartphone abgelegt sind.

CsipSimple und FRITZ!App Fon habe ich auf meinem Androiden übrigens auch drauf, genau wie @Wotan.
Ich habe aber zusätzlich noch Zoiper.

Diese Diskussion hat natürlich im Grunde genommen nichts mit der Labor-Firmware zu tun. Außer vielleicht, dass die offizielle Firmware noch nicht den Schutzmechanismus wie die Labor-FW eingebaut hat, dass die FRITZ!Box selbstständig eine Sperre für Auslandsverbindungen setzt, wenn vermehrt solche an- und auffallen. Damit wird der Schaden begrenzt.
 
Und wieder was dazu gelernt, DANKE Peter!!!
 
Das Einzige, was hier wirklich helfen würde, wäre die Ende-zu-Ende-Verschlüsselung zwischen FRITZ!Box und Client über TLS (das hilft gegen SID-Hijacking und die Änderung von JS-Dateien gleichzeitig) ...

Wotan hatte aber doch geschrieben das er es über VPN nutzt, da sollte man doch als "Hacker" gar nichts mehr mitbekommen. :confused:
 
Ja, aber Anmeldung aus dem Internet erlauben war auch aktiv :-(
 
Damit wird der Schaden begrenzt.
Das gilt nur dann, wenn man als Schaden nur materielle Verluste durch Telefonmißbrauch betrachtet.

Jede unautorisierte Benutzung eines administrativen Accounts in der FRITZ!Box ist aber als Totalverlust der Vertraulichkeit aller dort gespeicherten Daten zu bewerten, das zieht sich bei konfiguriertem Push-Mail-Service (bei Anbietern, wo SMTP- und POP3/IMAP4-Kennwort identisch sind) bis zum konfigurierten Mail-Konto und betrifft sämtliche über die Box erreichbaren Dienste.

Im Extremfall reicht so eine Sitzung mit einem administrativen Benutzer-Account sogar aus, um eine manipulierte Firmware zu installieren, womit dann dieser Verlust nicht nur für den aktuellen Stand der Konfiguration der FRITZ!Box eintritt, sondern für alle künftigen und am Ende sind auch alle Clients, die unverschlüsselte Kommunikation über einen solchermaßen manipulierten Router abwickeln, bei dieser Kommunikation davon betroffen.

Mit einer Manipulation des DNS-Servers kann man ggf. sogar wieder TLS-Verbindungen angreifen ... zwar i.d.R. nicht ohne Zertifikatfehler, aber inzwischen sind viele Benutzer ja dankenswerterweise so "konditioniert", daß sie ziemlich genau wissen, wie man derartige "Fehler" umgehen oder ignorieren kann.

Hier hilft eine Sperre für Auslandsverbindungen dann auch nur wenig ... der rein materielle Schaden ist in so einem Falle der weitaus geringere, auch wenn er den meisten vermutlich eher weh tut, weil ihnen der andere Schaden entweder nicht bewußt oder sogar egal ist.
 
Seit gestern habe ich auf einmal so komische einträge im telefonlog, es sind immer anrufe in abwesenheit von der eigenen rufnummer mit SIP0# voran gestellt. Das telefon klingelt nicht in der Zeit.
Telefonie läuft bei mir über IP Telefonie des Internetanbieters, bis jetzt hatte ich so etwas noch nie, am 14.09.16 trat es das erste mal auf.

2016-09-15 11_28_13-FRITZ!Box 7490.jpg

Was noch erwähnt werden sollte es sind keine IP telefone angeschlossen, nur über die normalen analogen FON1 und FON2 anschlüsse.
 
Zuletzt bearbeitet:
Ich nutze mehrere DECT 200 und im Augenblick nimmt eine Steckdose keine neuen Befehle zum Anschalten aus dem Googlekalender an. Einträge zum ausschalten, die schon immer existieren werden ordnungsgemäß ausgeführt, aber neu hinzugeführte "an"-Befehle werden ignoriert. Die tgl. Sync der Dect200 mit dem Kalender wird ausgeführt.
Erst ein erneutes verbinden der DECT200 mit dem Kalender hat Abhilfe gbracht. Mal schauen wie lang das hält.

Weiterhin besteht Probleme mit I-Net-Radios & der MyFritzApp2.

- - - Aktualisiert - - -

So, eben ist die FB abgestürzt &was soll ich sagen, bei der DECT200 wird wieder die Einschaltzeit ignoriert:mad:. Hat ja lange gehalten. Ticket geht raus

Eben ist mir aufgefallen, das es ein DECT200 ist, welche ich zusätzlich bei Geräuschen sich einschalten lasse, die 2. dieser Art funktioniert ohne Probleme.
 
Zuletzt bearbeitet:
Hallo,
schon jemand aufgefallen, dass die Filterung (Blacklist) mit dieser Version nicht mehr funktioniert?
Gesperrte Seiten können ungehindert aufgerufen werden.

MfG

Nachtrag:
Ok, hat sich erledigt.
Unter Zugangsprofile die Blacklist mal im Profil Standard aktiviert und dem betreffenden Gerät das selbstdefinierte Zugangsprofil gegen Standard getauscht - siehe da, Filterung klappt.
Wieder alles rückgängig gemacht und nun klappt auch die Filterung im selbstdefinierten Profil wieder tadelos.

Schon komisch - hatte ich noch nie
MfG
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.