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).
