[Info] Die Geschichte einer alten Sicherheitslücke oder "Was kann man damit schon anfangen?"

Jein ... ich kann so schwer einschätzen, welche Lücken da noch vorhanden sein mögen, weil ich die Version nicht kenne (ich höre hier sogar das erste Mal von einer solchen).

Bleibt also nur reines Raten, welche Lücken dort beseitigt sein mögen ... und die, für die ich "bug bounty rewards" erhalten habe, sind ohnehin aus dem Spiel, weil dort logischerweise Stillschweigen vereinbart wurde.

Wenn ich diese Version als Dump kriege, kann ich gerne mal hineinsehen ... ich glaube ehrlich gesagt nicht, daß AVM da noch riesige Anstrengungen unternehmen wird und Interesse an alten (halbwegs isolierten) Lücken dort hätte.

Wenn die 6490 demnächst in den Handel geht (bei schon ziemlich anderem internen Aufbau, denn die zwei Systeme mit der Notwendigkeit der Kommunikation auch untereinander, machen da schon einiges an Unterschieden aus) und die 6590 in den Startlöchern hocken sollte, dann wird es vermutlich für die 6360 nicht mehr so sehr viele neue Versionen geben und da kann es nicht schaden, wenn man "den letzten Stand" noch soweit kennt, daß man in etwa einschätzen kann, ob später auftauchende Probleme dort enthalten sein mögen oder nicht.

Das wäre dann die Ursache meines Interesses an dieser Version und wenn es da wirklich noch etwas geben sollte, dann kann man ja mal darüber reden. Wobei die allererste Frage eben schon wäre, welches Release-Datum die Firmware dort eigentlich hat ... so eine Versionsnummer ist zwar immer ein ungefährer Anhaltspunkt, aber mit ein wenig Verzögerung beim Rollout durch den Provider (so etwas soll es ja schon das eine oder andere Mal gegeben haben), liegt diese Version auch bei UM schon seit dem Herbst 2015 herum. Von der reinen Nummer her, fällt das jedenfalls gewaltig aus dem Rahmen ... und da bleibt dann eben Neugierde übrig, was da wohin weiterentwickelt wurde. Ich glaube kaum, daß die Version bereits das neue GUI haben wird - also gibt es eher Änderungen unter der Haube.

Wenn im Zuge des Wegfalls des Routerzwangs dann 6360 den Markt schwemmen sollten (weil die Provider die alten Möhren gar nicht mehr haben wollen, auch deren Handling ist ja mit Kosten verbunden, selbst wenn der Kunde die Rücksendung bezahlt), dann kann man ja mal überlegen, was man mit so einem alten Schätzchen noch so anfangen könnte, wenn der eine oder andere dann doch seinen TC7200 loswerden möchte (für einen geringeren Anschaffungspreis als bei einer 6490/6590) - dazu müßte man aber wissen, wie weit die Firmware der 6360 noch gediehen ist - ich bin mir nicht ganz sicher, aber bei der alten 06.0x-Firmware hätte ich sogar noch vermutet, daß die nur RC4 kann und damit kein aktueller Browser mehr auf diese Box per TLS zugreifen kann.

Das sind aber alles diese kleinen Unterschiede, die man erst einmal untersuchen muß ... taucht dabei ein Problem auf, was auf den 06.5x-Versionen quasi nebenbei gefixt wurde, wird das sicherlich längere Zeit bestehen und dann halte ich seine Beschreibung auch wieder für legitim und notwendig, damit der Benutzer selbst einschätzen kann, wie relevant und event. auch gefährlich das für seine eigene Installation wird und er eine fundierte Basis für die Entscheidung hat, sich eventuell doch lieber ein neueres Modell ohne diese Lücke zuzulegen.

Ja, da sollte eigentlich die andere Partition noch die Vorgängerversion enthalten, wenn nicht der Update-Prozess inzwischen so umgestellt wurde, daß das neue System nach ein paar erfolgreichen Starts das alte System löscht. Hier wird ja die Sicherheit beim Updaten der Firmware zum Bumerang bei der Möglichkeit, eine Firmware mit einer bekannten Sicherheitslücke auf diesem Wege wieder zu aktivieren.

In jedem Falle sollte (bei getrennter Verbindung zum Kabel) der 06.04 nichts passieren, wenn man sie wieder aktiviert und man sollte aus diesem System das andere irgendwo auf einen USB-Stick kopieren können (die 6360 hat ja keinen NAND-Flash unter /var/media/ftp). Selbst wenn da ein weiteres Update käme, würde das ja ohnehin wieder die andere Partition verwenden - insofern ist das mit dem Abziehen eines Kabels von der F-Buchse reine Vorsichtsmaßnahme.

Ok, ich hatte da etwas von einer 6360 mit 06.33 gelesen ... wenn es eine 06.35-irgendwas ist, gibt es ja vielleicht doch noch eine 06.50 für die 6360? Wobei die (hoffentlich) dann wieder das neue GUI nutzt, denn sonst kann man aus der Versionsnummer dann endgültig keine sinnvollen Rückschlüsse mehr ziehen. Das Datum einer Version 06.35-xxxxx ist dann sicherlich auch wieder näher an der Gegenwart gelegen, was die potentiellen Schwachstellen entsprechend reduziert.

Inzwischen habe ich das auch gelesen ... das macht dann ggf. die 6360 als (privat erworbene) Ablösung diverser anderer Router bei den KNB sogar wieder attraktiver (für die meisten, denn die Mehrheit findet (meine Einschätzung) das neue GUI schon besser, auch wenn sich einzelne immer wieder darüber empören ... besonders darüber, daß ein 10 Jahre alter Browser nicht mehr zur Bedienung benutzt werden kann).

Da macht dann die Suche in der 6360 vielleicht sogar wieder mehr Sinn, wobei dann wieder das oben von mir unterstellte Desinteresse eher nicht anzunehmen ist und solange der Hersteller an ihn gemeldete Lücken tatsächlich fixt, sollte man ihm auch einen adäquaten Zeitraum dafür einräumen, bevor solche Lücken dann "Allgemeingut" werden, damit eine Chance zu ihrer Beseitigung vorhanden ist.

Allerdings sollte das eben auch keine unendliche Geschichte werden und wenn man die jüngste Warnung von AVM wegen des möglichen Telefonmißbrauchs mal tatsächlich so liest, wie es im VF-Forum vermittelt wird, dann schließt die 06.50 (still) eine solche Lücke.

Hätte der Hersteller hier nach der Verfügbarkeit der 06.5x-Versionen (man kann sicherlich unterstellen, daß die - sofern keine schweren Probleme wie Anfang 2014 dazukommen, die sich tatsächlich ohne denkbare Gegenmaßnahmen ausnutzen lassen - so weit fertig und ausgerollt sind, wie das geplant war) von sich aus darauf hingewiesen, daß ebenfalls eine Möglichkeit zur unberechtigten Telefonie über einen SIP-Client beseitigt wurde (der O-Ton von VF legt das ja nahe, daß es durch ein Update beseitigt wird), dann gäbe es vermutlich auch weniger Kunden mit FRITZ!Boxen, die aus irgendeinem (für sie sicherlich wichtigen) Grund das Update nicht ausführen bzw. es wieder rückgängig gemacht haben.

Hätten die um die potentielle Gefahr in älterer Firmware gewußt (und zwar nicht nur so allgemein, daß "da immer auch Probleme beseitigt werden"), hätten sie selbst eine Abwägung treffen können ... es gibt leider immer noch Leute (gerade auch in der Diskussion bei heise.de kann man das bei der Meldung zur AVM-Warnung verfolgen), die sich ganz der Logik hingeben: Wenn es in der info.txt bei AVM nicht steht, daß eine Lücke beseitigt wurde, dann wurde auch keine solche beseitigt. (Wenn ein Baum im Wald umfällt ...)

Hier sehe ich tatsächlich bei AVM die Notwendigkeit, früher die "Sicherheitsprobleme" der jeweiligen Versionen zu ergänzen. "wird später veröffentlicht" ist eine unkluge Aussage in meinen Augen, weil sie so gar keine Einschäzung erlaubt und eher als "Feigenblatt" wirkt, genauso wie die allgemeine Empfehlung, "immer die neueste Version zu verwenden" (was eben bei Änderungen von Features auch nicht immer so einfach ist, wie AVM sich das vorstellt) - so kann man immer hinterher die Verantwortung von sich schieben, weil man es ja nicht wirklich "verschwiegen" hat. Den mündigen Benutzer (der wirklich die Verantwortung für seinen eigenen Router trägt, was ab dem 01.08.2016 sogar noch weiterreichende Konsequenzen nach sich zieht) erweist man damit aber einen Bärendienst ... er kann einfach nicht fundiert einschätzen, ob eine Lücke vorhanden ist, wie schwer diese wiegt und ob man die ggf. sogar wieder ohne seine Mitwirkung ausnutzen könnte.

So eine Beschreibung einer Lücke bei AVM selbst muß auch nicht immer mit einer genauen Erläuterung, wie das funktioniert, verbunden sein - wie bei den beiden Meldungen von RedTeam am Beginn des Jahres, in denen dann schon konkrete Einzelheiten publiziert wurden ... andererseits machen die Leute, welche die Firmware auf solche Lücken abklopfen (meist aus eigenem Antrieb und Interesse und vielen Herstellern ist das auch ein Dorn um Auge, wenn da jemand den Finger in ihre Wunden legt), den Job von AVM und da gibt es eigentlich für (nicht beauftragte) Ergebnisse dieser Art nur zwei "Belohnungen" - das eine ist eine (bei vielen Firmen konkret ausgelobte) Prämie für gefundene Lücken (BugBounty-Programme) und das andere eben die Anerkennung von anderen (Credits für den Finder), die sich indirekt dann auch wieder in späteren Aufträgen für diesen Personenkreis als Pluspunkt niederschlagen kann und wird. Dazu braucht es dann schon eine etwas ausführlichere Beschreibung, weil eben auch die notwendigen Anstrengungen für das Finden solcher Lücken vollkommen unterschiedlich sein können, je nachdem, wo und wie diese sich ausnutzen lassen, was der Finder ja meist mit einem "proof of concept" für einen Exploit belegt.

Diese Anerkennung (und sei es nur "in Fachkreisen") wird man aber nur dann ernten, wenn man die Ergebnisse auch (als erster) veröffentlicht und da sind dann Zeiträume von 12 Monaten und mehr schon ein ziemlicher Klotz am Bein, weil in dieser Zeit eben der Nächste auf das Problem stoßen und es seinerseits einfach veröffentlichen könnte ... in dieser Branche ist es auch nicht so viel anders als bei irgendwelchen wissenschaftlichen Entdeckungen; wer als Zweiter veröffentlicht ist der erste Verlierer und da gehen dann ggf. schon mal die Ergebnisse von vielen Arbeitsstunden (die sich zu Tagen, Wochen, Monaten addieren) durch den sprichwörtlichen Schornstein, wenn ein Hersteller sich zu lange Zeiträume für solche Fixes einräumen möchte (und der Finder außer dem "Ruhm" nichts zu erwarten hat).

Das ist zwar bei anderen Herstellern auch nicht so viel anders, aber da wird dann eben über "full disclosure" mal so eine Lücke nach 4-12 Wochen publiziert, wenn sich ein Hersteller nicht meldet auf eine entsprechende Information oder sich so gar nicht festlegen lassen will, ob und wann er die Lücke beseitigt haben wird und ob er sie überhaupt in derselben Weise als Gefahr wahrnimmt, wie ihr Entdecker - man braucht sich nur mal die "history" von solchen Nachrichten in der Mailing-Liste genauer anzusehen, auch im Hinblick darauf, wie unterschiedlich die Einschätzungen manchmal sind. Auch bei einer Bewertung mit CVSS kriegt man eben recht unterschiedliche Ergebnisse, je nachdem, wie man die Eingangsfaktoren bewertet und auswählt und schon die Frage, ob eine aus dem LAN zu nutzende Lücke in einem Router nun mit AV=N oder AV=A zu bewerten wäre, macht eine klare Abgrenzung erforderlich, was eine einzelne Lücke ist und was ggf. auch eine Kombination zweier Lücken sein könnte.

Denn kommt dann noch eine weitere Lücke dazu, kann aus einer mit der Bewertung AV=A und UI=N (also nur aus einem benachbarten Netz auszunutzen, aber ohne Mithilfe des Benutzers) schon mal ein AV=N und UI=R werden (von überall auszunutzen, aber nur wenn der Benutzer dabei "behilflich" ist - wozu aber schon das Öffnen einer E-Mail oder das Anklicken eines Links ausreichen können), wobei eben die eigentliche Lücke dann tatsächlich nur die erste Bewertung "verdient" und erst in der Kombination entsteht dann die zweite. Aber hier ist eben so eine Abgrenzung auch schon mal Ansichtssache (wer entscheidet über die "Zerlegung in zwei Teilprobleme"?) und wenn man es sich genau überlegt, war auch die Lücke Anfang 2014 ähnlich einzuordnen. Der Angriff erfolgte über einen Parameter eines HTTP-Requests (mit UI=N) und war aus dem WAN problemlos dadurch zu entschärfen, daß man die Fernwartung ausschaltete. Aus dem LAN über CSRF war die Lücke aber nur dann auszunutzen, wenn der Benutzer (oder sein Browser) die passende URL auf irgendeinem Wege aufrief ... und schon hier ist wieder die Unterscheidung bei der "Mitwirkung" (UI=R) nicht so ganz einfach zu entscheiden. Ist diese Mitwirkung nun schon vorhanden, wenn der Benutzer nur seinen Browser benutzt und irgendeine Seite öffnet, in der dann ggf. ein passender Link versteckt ist (der den Angriff ohne weitere Interaktion ausführt) oder erst dann, wenn er trotz einer Warnung auf einen solchen Link klickt? Da auch hier die Standpunkte auseinander gehen (und jeder für den seinen gute Gründe anführen kann), ist so eine Einschätzung eben bei aller Objektivität, die durch das CVSS-Scoring ja Einzug halten sollte, weiterhin von subjektiven Faktoren bestimmt (genauso wie die Frage nach dem halbvollen oder halbleeren Glas).

Egal ... wenn eine Lücke 12 Monate Zeit bis zu ihrer Beseitigung verkraftet (unabhängig von ihrem CVSS-Wert), dann kann sie ja eigentlich keine akute Gefahr darstellen ... ansonsten wäre das Hinauszögern der Beseitigung und des tatsächlichen Abstellens der Lücke durch Updates beim Kunden ja geradezu fahrlässig und hätte mehr mit "Gottvertrauen" (es wird schon keiner sonst noch finden) zu tun als mit einem seriösen Umgang mit den eigenen Fehlern (und daß Software niemals vollkommen fehlerfrei sein kann und wird, hat sicherlich inzwischen auch jeder begriffen - lassen wir mal speziell gehärtete Software, die "mission critical" im wahrsten Sinne des Wortes ist, außen vor dabei, die kostet um eine Zehnerpotenz mehr in der Entwicklung).

Jedenfalls geht dann bei den meisten Entdeckern ein Countdown los, wenn der Hersteller sich eher stur stellt und es wird eine Deadline für die Veröffentlichung gesetzt ... wenn ein Hersteller per se unkooperativ ist bei der Beseitigung erkannter Lücken, dann kann sich wenigstens der Kunde entsprechend schützen und sei es durch den Wechsel des Gerätes (und dann i.d.R. auch des Herstellers), wenn es einfach keine korrigierte Firmware geben sollte.

Jetzt bin ich zwar etwas vom Thema abgekommen ... aber solange es in der 06.50 für die 6360 dann tatsächlich noch Lücken geben sollte, wird es von mir trotzdem keine (konkreten) Informationen dazu im IPPF geben - jedenfalls nicht, solange AVM reagiert auf Meldungen und die Einschätzungen zu den Auswirkungen so einer Lücke und damit zu dem notwendigen Tempo bei deren Beseitigung nicht total divergieren.

Auch die Auswirkungen der S44-hostname-Lücke, um die es hier ja ursprünglich mal ging, sind ja wieder vollkommen unterschiedlich einzuschätzen ... je nach der Plattform, über die man redet.

Bei Firmware vor 06.3x (bzw. vor dem Wegfall des Telnet-Daemons) konnte man das Ausführen eigener Kommandos auf einer DSL-Box auch wesentlich leichter erreichen und eine gewisse Brisanz (und damit dann auch erst ein Erfordernis, die Lücke zu beseitigen) erhält dieses Problem nur dann, wenn man den Anspruch hinzuzieht, daß eben auf einer DOCSIS-Box der Kunde keine Shell erhalten soll(te).

Schon die Frage, ob der Kunde und die Box vor dem Angriff Dritter geschützt werden sollen oder die Box vor dem Kunden, ist eben ein gewaltiger Unterschied und während es bei AVM mit dem ersten eigentlich im Großen und Ganzen recht gut geklappt hat, ist inzwischen dieser böse Dritte aber auf der falschen Seite des Routers angelangt und daher ist es immer wichtiger, den Benutzer von diesem Dritten zu unterscheiden und auch wirklich nur noch den Berechtigten den Zugriff - auch von der LAN-Seite aus - zu ermöglichen.

Das ist ein geändertes Paradigma, was man eben auch beim Entwurf von Software schon berücksichtigen muß, sonst rennt man einer Dauerbaustelle hinterher und zu den Zeiten, wo man die Wurzeln des FRITZ!OS suchen muß, war das einfach noch kein Thema - da war das LAN noch der "Hort des Guten" und an Benutzer und Besucher mit Smartphones und Tablets war noch nicht zu denken, höchstens mal an ein vagabundierendes Notebook und dort war der denkbare Fernzugriff durch Dritte auf das Gerät (um es für einen Angriff von der LAN-Seite zu nutzen) eher ein sehr exotisches Szenario, wo man auch eher die "Schuld" beim Notebook gesehen hätte, wenn das solche Angriffe unterstützt. Im Angesicht von allen möglichen (bekannten) Lücken in den Betriebssystemen dieser Mobilgeräte ist das heute als Standpunkt kaum noch aufrecht zu erhalten ... auch wenn es vom Prinzip sicherlich immer noch richtig ist (ohne zusätzliches Gerät gibt es keinen Angriff), kann man mit so einem Standpunkt sicherlich keine Consumer(!)-Geräte verkaufen, denn die Kunden wollen eine Lösung und keine Schuldzuweisung bzw. das Zeigen mit dem Finger auf andere und die Reise nach Jerusalem bei der Beseitigung von Problemen (bzw. sogar schon bei der Klärung der Frage, wer denn dafür nun zuständig sein mag).