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

Nachdem seit meiner Meldung einer bestimmten Lücke in der Firmware an AVM (am 06.09.2014) inzwischen mehr als 8 Monate ins Land gegangen sind und diese Lücke in den neueren Firmware-Versionen geschlossen wurde, finde ich es nun höchste Zeit, einmal Bilanz zu ziehen und dabei festzustellen, welche Modelle und Firmware-Versionen von der Lücke weiterhin betroffen sind und es - vielleicht - auch immer bleiben werden.

Die Lücke ist von der Schwere her nicht einmal annähernd vergleichbar mit einer der bisher von AVM eingeräumten (ich kenne nur zwei), denn sie läßt sich ohne gültige Credentials bzw. ohne TR-069-Zugriff für den Provider, der im Prinzip immer wie ein berechtigter - meist unerbetener - Benutzer angesehen werden sollte, nicht ausnutzen nach bisherigem Kenntnisstand.

Die Ursache, warum das überhaupt als "Lücke" bezeichnet werden kann, ist das Ausführen (fast) beliebiger Kommandos auf diesem Weg, auch wenn der dafür nicht vorgesehen war oder ist und es - zumindest auf den üblichen AVM-Modellen - auch andere einfachere Möglichkeiten gibt, solche Kommandos ausführen zu lassen.

Aber genauso wie sich über diesen Weg auf einer FRITZ!Box ohne "offiziellen" Telnet-Zugang vom Besitzer Kommandos ausführen lassen, genauso kann der Provider vermutlich (hier verweise ich auf den Beitrag zum TR-069, ob das nun nur Spekulation ist oder schon als "verdächtig" gelten sollte, kann jeder selbst entscheiden) die komplette Konfigurationsdatei ersetzen und damit in der Folge auch solche Kommandos auf der FRITZ!Box ausführen lassen.

Worin liegt denn nun diese Verwundbarkeit der Firmware?

Ich habe das zwar schon vor langer Zeit mal in einem Beitrag hier im IPPF angerissen, aber ich schreibe es lieber erneut ... bitte nicht schlagen.

In der Datei /etc/init.d/S44-hostname wird beim Start des FRITZ!OS der in der ar7.cfg konfigurierte Hostname ausgelesen und - unnötigerweise, das hat AVM beim Fix ja dann auch beseitigt - mit einem "eval"-Kommando "getrimmt":
(/etc/init.d/S44-hostname aus FRITZ!OS-Versionen bis ca. Okt. 2014)
Entscheidend ist die rote Zeile. Wenn ein Hostname ein geeignetes Format hat, werden in dieser Zeichenkette enthaltene Kommandos im Rahmen der Ausführung des "eval"-Statements ebenfalls ausgeführt.

AVM hat insofern ordentlich Vorsorge getroffen, als es nicht möglich ist, einen solchen Hostnamen über das GUI einzustellen, da wird vernünftigerweise auf einen beschränkten Zeichensatz getestet, bevor ein Wert akzeptiert wird.

Aber direkt in einer Sicherungsdatei oder auch beim Aufruf von "ctlmgr_ctl" läßt sich problemlos auch ein solcher gefährlicher Wert einrichten. Das einzige Problem für einen Angreifer auf diesem Weg ist es, daß dieses Kommando zu einem Zeitpunkt im Startprozess der Firmware aufgerufen wird, wo die normalen Funktionen des FRITZ!OS noch gar nicht zur Verfügung stehen. Es ist also nicht ohne weiteres möglich, bereits in den Hostnamen eine Übertragung der Einstellungen auf einen externen Server "einzubauen", wie es bei der webcm-Lücke ja überwiegend geschah (abgesehen davon hat ein erfolgreicher Angreifer diese Informationen eigentlich schon, aber vielleicht nicht immer mit aktuellem Stand). Aber es gibt ja durchaus auch noch andere denkbare Angriffe, für die so eine Möglichkeit auch die Voraussetzung ist. Ein externer Zugriff auf die Kommandozeile ist (ohne Verrenkungen) ja per se nicht machbar, ein externer GUI-Zugriff (mit dem das prinzipiell auch geht, was ich hier beschreibe) hingegen schon.

Es steht einem Angreifer aber trotz der frühen Ausführung der Kommandos frei, sich - im Rahmen der maximalen Länge des Hostnamens, wo die genau liegt, habe ich nicht exakt ermittelt - mit den eingeschleusten Kommandos bereits so im System zu verankern, daß er später erneut zum Zuge kommt, wenn die Umgebung etwas "freundlicher" ist für ihn. Dazu muß er lediglich einige Startdateien entsprechend modifizieren, notfalls läßt er mit dieser Modifikation dann schon zusätzlichen Code aus dem Internet nachladen, wenn das schon verfügbar ist zu diesem Zeitpunkt.

Da ich diesen wunden Punkt der Firmware in einem Telefonat zu einem anderen möglichen Angriff eher nebenbei erwähnt hatte, wurde ich Anfang Sept. 2014 ausdrücklich gebeten, die Vorgehensweise mit einem "proof of concept" darzulegen und dabei zu zeigen, daß auf diesem Weg auch ein Angriff auf eine FRITZ!Box Cable 6360 realistisch ist, in dessen Ergebnis dann wieder ein Telnet-Zugang zu diesem Gerät möglich wird.

Die Vorgehensweise mit "nc" und /bin/sh als "Server" für eine Art "rcmd"-Zugang war ja schon etwas älter (irgendwann im Sommer 2014 hatte ich sie hier mal erwähnt), die stammte aber in Wirklichkeit schon aus dem Herbst 2013, als ich es zwischenzeitlich aufgegeben hatte, AVM über Lücken in der Software zu informieren, da ohnehin nie eine belastbare Reaktion erfolgte, nicht einmal für eindeutig sicherheitskritische Probleme (SSL-Algorithmen, Zertifikatprüfung in Apps, usw.).

Ich hatte diese Lücke zwar mal selbst für das Eindringen in die 6360 genutzt, fand sie jedoch - wegen der notwendigen Rechte und in (damaliger) Unkenntnis der TR-069-Implementierung - eher bedeutungslos (für normale Boxen) und damit einer gesonderten Meldung eigentlich nicht wert ... ich hatte genug andere ernsthafte Probleme "am Köcheln".

Das in Erfüllung dieser Bitte Anfang Sept. 2014 entstandene Skript stelle ich jetzt vor und in der Folge auch zum Download bereit. Schon die Tatsache, daß für die Abarbeitung ein Linux-System erforderlich ist, limitiert die Verbreitung in meinen Augen ausreichend, um das massenhafte Auftreten von Telnet-Zugängen auf "FRITZ!Box 6360"-Geräten für unwahrscheinlich zu halten. Außerdem stünde es nach meinem Verständnis jedem Kabelanbieter frei, endlich die aktuelle Firmware auch für die 6360 auszurollen und damit diesem "Angriff" die Wirkung zu nehmen. Warum das nicht längst erfolgt ist (meines Wissens ist die 6360 bei KBW/UM immer noch bei 06.04 und bei KDG bei 06.05), ist mir ohnehin ein absolutes Rätsel ... ich vermute mal, den KNB ist die Dringlichkeit eines Updates gar nicht richtig bewußt und wenn ich mit dieser Veröffentlichung zu einer Beschleunigung des Updates beitragen kann, hätte ich mein Ziel ja auch in gewisser Weise erreicht.

Und damit auch gleich schon einmal zur "Bilanz" ... die Lücke wurde AVM wie gesagt am 06.09.2014 "demonstriert" (Montag war der 08.09.) und wurde dann irgendwann in den ab Anfang Oktober 2014 veröffentlichten Firmware-Versionen geschlossen. Damit ist und bleibt meines Wissens die gesamte 7270-Familie angreifbar (ob als Homebox 1 bei KDG oder noch bei 1&1-Bestandskunden im Einsatz) und natürlich auch alle früheren Modelle. Da inzwischen die bis Oktober 2014 erschienenen 06.20-Versionen für die 7390 und 7490 durch neuere ersetzt wurden, sollte die Aussage "geschlossen ab 06.2x" hinreichend genau sein, auch wenn ich nicht jedes Release-Datum von AVM-Firmware auf dem Schirm habe. Inzwischen ist hoffentlich auch überall bei den KNB für die neuere 6490 eine Firmware-Version im Einsatz, die diese Lücke nicht mehr enthält. Beim Erscheinen der 6490 (die 06.10 ist vom 04.09.2014 - zufällig erfolgte da auch das erste sinnvolle Telefonat mit AVM) war sie jedenfalls noch auf genau demselben Weg verwundbar, daher enthält der Code auch noch die Behandlung der 6490 bis zur Firmware-Version 06.10 - aber der sollte ohnehin nicht mehr funktionieren auf "aktiven" Boxen.

Nun zur Arbeitsweise des PoC ... um das Ganze für AVM weitgehend automatisch ablaufen zu lassen (meine mündlichen und schriftlichen Meldungen sind i.d.R. nicht weniger ausführlich als viele meiner Beiträge hier und meine Zuhörer bzw. Leser ermüden offenbar leicht), habe ich den gesamten Ablauf in den Download, das Modifizieren und den anschließenden Upload einer Sicherungsdatei der FRITZ!OS-Einstellungen eingebettet.

Basis der permanenten Modifikation ist die Überlegung, daß in den verwundbaren Versionen der 6360 die Abarbeitung einer debug.cfg-Datei tatsächlich noch genauso angelegt ist, wie sie es früher in den DSL-Versionen war. Damit reicht es eigentlich aus, für einen Telnet-Zugang die passenden Kommandos über geeignete "hostname"-Werte in die "debug.cfg" zu schreiben und sich auf den Start des Telnet-Daemons beim nächsten Start der Box zu verlassen.

Das Problem an der Sache ist nun aber, daß die "debug.cfg" ja eigentlich kein Bestandteil einer Export-Datei ist und das Einbetten aller notwendigen Kommandos direkt in den Hostnamen wahrscheinlich eher zu lang geraten wäre. Also habe ich nach einer Datei gesucht, die in einem solchen Export enthalten ist, eine Text-Datei ist (auch wenn sie vielleicht hexadezimal exportiert wird) und die im Normalfall eher ungenutzt ist. Zuerst hatte ich dazu die "phonebook" ausersehen, aber da fummelte dann beim Import irgendjemand dazwischen, der unbedingt in der Datei eine gültige XML-Struktur suchen wollte und mein Vorhaben zunichte machte.

Letztlich bin ich dann bei der "calllog" hängen geblieben und - da es ja nicht immer gesagt ist, daß diese Datei unbenutzt ist - bei einer anschließenden Restaurierung des ursprünglichen Inhalts dieser Datei, wenn alles notwendigen Schritte abgeschlossen sind. Ziel der Aktion war es nun also, eine "calllog" in die Export-Datei einzubauen, die als Shell-Skript durch wenige Kommandos im "hostname"-Wert zur Ausführung gebracht werden könnte und dann alles weitere übernehmen sollte, um am Ende bei einer "debug.cfg" und dem ursprünglichen Inhalt der "calllog" zu landen.

Schließlich bleibt als neuer Hostname etwas wie dieses über, was dann beim Neustart nach dem Import auch ausgeführt wird:
Es wird also der komplette Inhalt der "calllog" bei diesem Start nach "debug.cfg" kopiert (das Anlegen von char-Devices inkl. "cat" und Löschen des Nodes ist oft genug an anderen Stellen schon erörtert worden) und die importierte "calllog" gelöscht (durch das "echo -n"). Damit stehen dann, wenn es später im Boot-Prozess an die Abarbeitung der "debug.cfg" gehen kann, die Kommandos nicht mehr in der "calllog", wohin wir sie importiert hatten, sondern richtigerweise in der "debug.cfg" und somit werden sie auch ausgeführt.

Nun müssen wir nur noch einen passenden Inhalt für die zu importierende "calllog" erstellen. Dazu wird aus der exportierten Sicherungsdatei als erstes der Inhalt der ursprünglichen "calllog" extrahiert und wir merken uns, was da bisher drin steht, damit wir es bei Bedarf am Ende wieder restaurieren können:
Jetzt gehen wir hin und erstellen eine neue Datei, die wir - nach einigen Verrenkungen - am Ende als "debug.cfg" beim Start nach dem Import der Einstellungen ausführen lassen wollen. Der eigentliche Inhalt der (zeitweisen, wie wir gleich sehen werden) "debug.cfg" sind die blauen Zeilen, die schwarzen sind die Kommandos, die auf dem Linux-System bei der Generierung des passenden Files ausgeführt werden:
Der mittlere Teil der auszuführenden Kommandos unterscheidet sich bei der 6490 etwas von der 6360, da bei der 6490 das Starten eines Telnet-Daemon deutlich weniger aufwändig ist.

Was passiert denn da nun eigentlich? Als erstes kopieren wir (es ist immer noch der erste Start der Box nach dem Import und wir sind immer noch beim "Ummodeln" der Dateien) die "debug.cfg" mal an eine Stelle, von wo wir sie später - nach entsprechender Kürzung um die nur beim ersten Mal notwendigen Aktionen - in der endgültigen Form in den Flash-Speicher schreiben können.
Jetzt löschen wir aus dieser gesicherten Datei (in /var können wir auch "inline" editieren mit dem sed - das ist die "-i"-Option, alternativ hätte man auch gleich mit sed anstelle von cat arbeiten können - ich will aber keine Diskussion der verschiedenen Shell-Befehle führen, nur Einwänden zuvorkommen) den gesamten Anfang (bis einschließlich des "if") und das abschließende "fi", denn das gehört zum gelöschten "if".
Die so gekürzte Datei lassen wir dann nach 15 Sekunden vom FRITZ!OS starten:
Um das noch einmal kurz zu zeigen, was da noch drin steht:
Es wird also zunächst ein neuer Inhalt in die "debug.cfg" geschrieben, der auch bei jedem nachfolgenden Start die notwendigen Kommandos zum Start eines Telnet-Daemons ausführt. Warum muß man das denn so kompliziert machen? Wir dürfen nicht aus den Augen verlieren, daß die ganzen Kommandos, die hier gerade ausgeführt werden, ja aus der "debug.cfg" stammen. Wenn man die jetzt direkt modifiziert, dann werden - wegen der zeichen- bzw. zeilenweisen Verarbeitung durch die Shell - in aller Regel ungültige Kommandos entstehen bzw. beim Kürzen ein unerwartetes Dateiende auftreten, wenn die Shell die vorher dort stehenden Kommandos lesen will. Wenn wir die "debug.cfg" erst nach 15 Sekunden mit dem endgültigen Inhalt überschreiben, ist die aktuelle Shell-Instanz damit schon lange durch.

Nach dem Schreiben der endgültigen "debug.cfg" restauriert das gekürzte Skript dann einen event. vorher vorhandenen alten Inhalt der "calllog" (die grünen Zeilen), was aber nur erforderlich ist und auch nur erfolgt, wenn da vorher tatsächlich etwas drin stand.

Dann noch ein Eintrag im Eventlog der FRITZ!Box, damit wir den Erfolg auch sehen können und anschließend wird (mit einer Sekunde Verzögerung und asynchron zum Rest) die Abarbeitung der "debug.cfg" (die haben wir ja eben erst geschrieben) noch einmal gestartet, denn die "reguläre Abarbeitung" im Rahmen des Systemstarts ist ja schon Vergangenheit für diesen Start. Das schreiben wir auch noch schnell ins Eventlog und dann - nach weiteren 10 Sekunden, damit sich die AVM-Komponenten erst einmal etwas beruhigen können - setzen wir als krönenden Abschluß noch den Hostnamen wieder auf den ursprünglichen Wert, denn beim nächsten Start der Box brauchen wir diese untergeschobenen Kommandos ja nicht mehr, da reicht der neue Inhalt der "debug.cfg".

Aber eigentlich sind wir ja - nach dem "delay"-Kommando mit den 15 Sekunden Wartezeit - noch mitten in der Abarbeitung der ersten Instanz der "debug.cfg" und hier greifen wir jetzt tatsächlich zu einem "Trick" ... wir löschen einfach den aktuellen Inhalt der "debug.cfg", damit beendet auch die aktuelle Shell-Instanz die Abarbeitung der dort hinterlegten Kommandos, den sie kriegt einen Lesefehler bzw. das Dateiende angezeigt.

Der ganze Zinnober mit dem "if" dient also eigentlich nur als "Anker", um die richtigen Zeilen zum Löschen für die verzögerten Aktionen zu finden. Aber damit bleibt die Datei wenigstens syntaktisch korrekt und man erlebt keine unliebsamen Überraschungen.

Noch kurz etwas zum merkwürdigen Starten des Telnet-Daemons bei der 6360: AVM ergänzt den Telnet-Daemon beim Start um eine Prüfung, ob es sich bei der Datei /usr/sbin/telnetd um einem Symlink handelt (wohin ist eigentlich egal), wie man hier sieht:
(telnetd.patch von AVM für diverse Versionen, aus den OSS-Paketen)

Will man also den Telnet-Daemon aus der AVM-Busybox benutzen, muß man einen Link /usr/sbin/telnetd anlegen. Der existiert nämlich bei den DOCSIS-Boxen nicht und ist der eigentliche Grund, warum sich da der Telnet-Daemon nicht starten läßt. Alles andere (inkl. Start über den telefon-Daemon) ist eigentlich vorhanden und funktioniert auch tatsächlich. Da sich das Verzeichnis /usr/sbin aber im SquashFS befindet und nicht beschreibbar ist, muß man sich erst einmal den originalen Inhalt dieses Verzeichnisses (das ist glücklicherweise nicht so viel) an eine beschreibbare Stelle kopieren und dann dieses Verzeichnis mit einem bind-Mount anstelle des Verzeichnisses im SquashFS verwenden. Dann kann man dort auch den notwendigen Link anlegen und damit auch den Telnet-Daemon erfolgreich starten.
Das geht - wie schon einmal bemerkt - bei der 6490 wesentlich einfacher, da es dort auch einen zweiten Telnet-Daemon gibt. Wofür der gut ist und warum der zwar bei der 6360 auch "bekannt" - aber nicht vorhanden - ist, kläre ich vielleicht mal bei einer anderen Gelegenheit, es spielt hier erst einmal keine Rolle.

Eine andere Besonderheit der 6490 müssen wir hier aber schon berücksichtigen ... da läuft auf zwei verschiedenen "Prozessorteilen" jeweils ein getrenntes System, eines auf dem ARM- und eines auf einem ATOM-Core (eigentlich sind sogar beide Architekturen jeweils als "DualCore" ausgelegt). Um jetzt zu verhindern, daß dieselben Aktionen beim ersten Start nach dem Import auf beiden Systemen ausgeführt werden (auch wenn erfolgreiche Schreibzugriffe auf das TFFS mir bisher nur vom ARM-Kern aus geglückt sind), ist es besser, wenn man die Abarbeitung auf den ARM-Kern begrenzt. Dazu hat AVM selbst ein paar kleine Hilfsfunktionen in der Datei /etc/puma6_helper.sh untergebracht, wenn man diese Datei "sourced", kann man mit "is_puma6_arm" feststellen, ob man auf dem richtigen System ist und anderenfalls einfach die Arbeit verweigern. Auch den Start des Telnet-Daemons habe ich auf den ARM-Kern beschränkt, im Dateisystem für den ATOM-Kern ist ohnehin "utelnetd" nicht vorhanden und man müßte dort wieder - analog zur 6360 - den Daemon der Busybox benutzen.

EDIT 12.05.2015:
Ich bin tatsächlich meiner eigenen Modifikation aufgesessen bei der 6490. Da die originale 06.08 von AVM schon die "debug.cfg" nicht mehr "abarbeitet", geht das bei der 6490 mit originaler AVM-Firmware tatsächlich auf diesem Weg nicht in "einem Aufwasch", wie das Skript es versucht. Das klappt nur, wenn man vorher schon die 6490 so modifiziert hat, daß sie die "debug.cfg" wieder in den Bootprozess einbindet. Die Lücke in S44-hostname ist vorhanden ... und um die geht es hier ja eigentlich auch. Man kann sie auch nutzen, um über den Umweg des ATOM-Kerns (da ist das SquashFS leichter zu ändern) das System so zu ändern, daß die "debug.cfg" wieder berücksichtigt wird. Das war bei meinen Tests der 6490 schon der Fall, nur deshalb hat das Skript auch auf diesem Modell funktioniert. Aber - wie gesagt - das ändert nur etwas an der Verwendbarkeit des Skripts bei der 6490 ... an der Natur und den Auswirkungen der Lücke (und darum geht es hier ja) ändert es nichts.
Ende EDIT 12.05.2015

Ach so ... weil wir eine "ordentliche" Anmeldung an der Box für eine Telnet-Session wollen, verwenden wir das richtige Programm dafür. Wenn das jemand mit "/bin/sh" anstelle des "/sbin/ar7login" macht, braucht ein solcher Angreifer nicht einmal ein gültiges Benutzerkonto in der FRITZ!Box zu kennen, um so eine Telnet-Session direkt mit einer Shell zu benutzen.

Das war jetzt die Erläuterung der Funktionsweise meines Skripts, zu finden ist das ganze Paket unter der Adresse: http://yourfritz.de/telnet_DOCSIS.tgz

Es handelt(e) sich - wie gesagt - um eine Demonstration auf explizite Bitte hin, ich hatte mich selbst vorher immer mit einzelnen Kommandos und dem "langsamen Aufbau" der notwendigen Änderungen in meiner damaligen 6360 zufrieden gegeben. Daher hatte ich jetzt auch keine Lust, da noch großartig zu ändern und die Demonstration der möglichen Eingriffe in das FRITZ!OS über diese Lücke an einem weniger interessanten Thema zu zeigen.

Wobei ich natürlich auch nicht verhehlen will, daß ich schon einen solchen Einstieg in (m)eine 6360 gezielt suchen wollte, als ich im Sommer 2013 hier im Forum nach Mitstreitern für die Untersuchung des FRITZ!OS der 6360 suchte - ich hatte die Nase voll von sinnlosen Aktionen meines Providers und wollte denen einen Riegel vorschieben. Die anderen Möglichkeiten wie das Einrichten eigener SIP-Accounts oder was man sonst noch so machen kann, wenn man den ctlmgr auch ohne Änderung des Brandings zu einer voll funktionsfähigen 6360 "überreden" kann (inkl. Rufbehandlungen), interessierten mich nie so wirklich ... ich wollte immer nur wissen, was denn nun der Provider in einer DOCSIS-Box tatsächlich kann und auf Nachfrage erhielt man keine oder nur erkennbar falsche Antworten.

Noch etwas zur Weiterverbreitung ... ich habe kein Problem, wenn jemand sich das Paket holt und sich damit den Zugang zu seiner eigenen DOCSIS-Box verschafft. Es gab in den letzten 8 Monaten auch immer wieder Anfragen, wie das denn nun genau funktionieren würde und was man da machen müsse. Ich habe das absichtlich zurückgehalten, bis die 6490 nicht mehr auf diesem Wege verwundbar war (zumindest sollte sie es nicht mehr sein für diese Lücke) ... wenn es die 6360 nach wie vor ist, verstehe ich das ja ohnehin nicht.

Bisher haben nur ein Handvoll Leute aus diesem Forum das Paket erhalten, u.a. um seine Funktion auch außerhalb meiner eigenen Umgebung zu verifizieren. Da es sich aber absichtlich nicht um freie Software handelt, bitte ich jeden den Haftungsausschluß in der README-Datei auch zur Kenntnis zu nehmen. Wer damit seine Box brickt - auch wenn das fast unmöglich ist bei einer 6360 oder 6490 -, der möge bitte hinterher nicht rumheulen.

Zusätzlich ist das Bereitstellen des Pakets auf einem anderen Server als dem meinen unerwünscht, ja eigentlich sogar "verboten". Auch wenn ich das naturgemäß weder kontrollieren noch ahnden lassen will, würde ich doch darum bitten, diesen Wunsch zu akzeptieren. Es ist auch so, daß ich einige Änderungen tatsächlich erst im Nachhinein vorgenommen habe (z.B. die zusätzliche Versionsprüfung für die vorliegende Firmware, falls jemand des Lesens nicht mächtig ist) und ich es lieber sähe, wenn ich die Möglichkeit der Korrektur von Fehlern an einer einzigen Quelle hätte.

Und um auch das gleich vorab zu klären: Das Skript dient - inkl. meiner Erläuterung - mehr zur Beschreibung eines möglichen Angriffs als dazu, nun jedem einzelnen den Zugang zum Telnet-Daemon einer DOCSIS-Box zu verschaffen. Sollte es tatsächlich irgendwo im Skript einen Fehler geben (wie gesagt, einige Anpassungen habe ich "trocken" vorgenommen), dann sollten meine Erläuterungen ausreichend sein, damit jeder diesen Fehler selbst abstellen kann (über eine PM mit der fertigen Änderung freue ich mich dann). Wenn es aber auf "ich mache das und das und es funktioniert einfach nicht, was kann das sein"-Fragen hinausläuft, kann sich jeder potentielle Kontakt das Schreiben von PMs auch gleich schenken, solche Fragen beantworte ich ab jetzt nicht einmal mehr mit einem Link auf diesen Beitrag.

Wer mit den gelieferten Erläuterungen nicht in der Lage ist, das richtig umzusetzen, sollte da wirklich ein Fehler enthalten sein, der sollte auch die Finger von der Shell in einer DOCSIS-Box lassen (und nicht nur da). Das mag zwar hart klingen, aber für Leute, die nur stur nach irgendwelchen Anleitungen so etwas benutzen können, ist es definitiv nicht gedacht.

Ach so, fast hätte ich es noch vergessen ... wegen der Prüfsumme einer Import-Datei (ich habe die Verwendung von "NoChecks=yes" nie in Erwägung gezogen, ging bei DOCSIS-Boxen ja ohnehin noch nie) braucht es ein passendes Programm zum Berechnen einer CRC32-Summe. Es ist ein kurzes von mir im Paket enthalten, zur Übersetzung benötigt man einen funktionierenden "gcc" und eine C-Standard-Library. Das sollte aber kein großes Problem sein, irgendwelche Zusatzpakete werden nicht benötigt. Alternativ kann man auch ein anderes Programm für die Berechnung des CRC32-Wertes verwenden, das steht wieder in der README.

Alles andere ist nur Shell-Code, den jeder problemlos kontrollieren kann. Gerade auch das Verarbeiten der Export-Datei arbeitet absichtlich mit Shell-Skripten und nimmt dabei Geschwindigkeitsnachteile bewußt in Kauf zugunsten einer entsprechenden Transparenz. In gewissen Grenzen funktioniert das sogar auf einer anderen FRITZ!Box (allerdings braucht es eine Bash als Shell), daher habe ich auch bewußt auf die Verwendung einiger zusätzlicher Pakete wie "curl" o.ä. verzichtet. Mit diesem läßt sich das vielleicht noch einfacher umsetzen, das war aber nicht mein ursprüngliches Ziel beim Erstellen der verwendeten Hilfs-Skripte.

Und um das als Abschluß auch noch einmal zu betonen ... das "Einbrechen" in DOCSIS-Boxen dient hier eigentlich nur als Beispiel dafür, was man mit der Ausführung beliebiger Kommandos auch anstellen kann auf so einer FRITZ!Box. Anstelle des berechtigten Besitzers wäre eben auch ein Einbruch über TR-069 zumindest denkbar, wo sich dann - wenn man mich nicht bzgl. TR-069 widerlegt - auch genau derselbe Vorgang ausführen läßt, wie ich ihn mit diesem Skript demonstriere. Ob da dann ein Telnet-Daemon gestartet wird oder eine beliebige andere aus dem Netz nachgeladene Software, ist auch nur eine Frage der "eingeimpften" Kommandos. Das gilt in erster Linie wieder für die älteren FRITZ!Box-Modelle, die noch immer ziemlich klaglos ihren Dienst mit aktiviertem TR-069 bei einigen Providern tun.

Ob das nun Paranoia meinerseits ist oder eine realistische Gefahr für die eigene FRITZ!Box ist (ich teste gerne mal die Homebox1 eines KDG-Kunden auf passende Probleme, wenn der mich schriftlich dazu ermächtigt), muß jeder selbst entscheiden. Zumindest für die DOCSIS-Modelle könnten das die KNB meiner Meinung nach auch recht schnell abstellen (wenn AVM keine neue Firmware für andere ältere Modelle bereitstellt, bleiben die aber "angreifbar", wobei da ja auch das Abstellen von TR-069 ein Weg wäre, der bei DOCSIS-Boxen dem Kunden selbst verwehrt bleibt) ... wenn die Kunden dann parallel in den Genuß weiterer sinnvoller Änderungen der 06.2x-Versionen auch auf der 6360 kommen, ist das ein angenehmer Nebeneffekt.

Wenn jetzt jemand der Meinung ist, ein potentielles Opfer brauche diese ganzen Informationen eigentlich gar nicht bzw. würde diese ohnehin nie erhalten, dann ist das vielleicht wahr, aber auch nicht wirklich mein Problem.

Wenn man sich nur die allerersten Reaktionen im Zusammenhang mit "webcm"-Gate Anfang 2014 ansieht, merkt man auch sehr schnell, daß da ebenfalls zuerst mal - auch in der Presse - die Ursache immer beim Angegriffenen gesucht wurde (oder in großen Listen gestohlener E-Mail-Accounts) und sich erst nach und nach herauskristallisierte, daß es wohl doch die Firmware ist.

Daher darf man meiner Meinung nach als Hersteller auch im Nachhinein nicht besonders zurückhaltend sein mit den Informationen zu bisher beseitigten Lücken ... der Verweis auf noch existierende verwundbare Geräte ist für mich nur eine Ausrede, denn es wird - absichtlich und mit Kenntnis des Herstellers, wenn so ein Gerät EOS ist - immer Geräte geben, die angreifbar bleiben. Solange man aber die Natur dieser Probleme nicht offen legt, beraubt man auch den mündigen Kunden jeder eigenen Entscheidung, welches Risiko er selbst für tragbar hält (das übernimmt indirekt der Hersteller für ihn) und verwehrt es ihm in der Folge auch, eigene Vorsichtsmaßnahmen zu ergreifen.

Passiert dann tatsächlich etwas, macht auch der Hersteller erst einmal große Augen und hebt abwehrend die Hände, weil es ja bisher erst zwei Probleme mit der Sicherheit der FRITZ!Box-Firmware gab. Wenn dann der Kunde in der "Beweispflicht" steht, ist zumindest die Kenntnis (und die Belegbarkeit) anderer Lücken für ihn eben nicht von Nachteil.

Wenn die beschriebene Lücke jedoch auch nach Meinung des Herstellers ein echtes Problem darstellt, wenn sie bekannt wird, dann sollte man sie wohl eher fixen und - unter Verweis auf diesen Fix - die Kunden auf die Notwendigkeit eines Updates hinweisen.

Stellt sie kein wirkliches Problem dar (oder gibt es z.B. mit der Abschaltung von TR-069 einen Workaround), kann auch die Kenntnis der Lücke keinen zusätzlichen Schaden anrichten ... sich nur darauf zu verlassen, daß eine Lücke schon nicht bekannt wird, funktioniert nur in den seltensten Fällen.

Schon der einfache Vergleich "vorher<->nachher" bringt bei partiell verfügbaren Fixes einen Angreifer auf die richtige Spur, dafür braucht der kein "Security Advisory" ... einem Kunden würde das aber sicherlich helfen, wenn er bei Problemen eine Liste solcher Veröffentlichungen auf sein eigenes hin durchsuchen könnte. Warum sich der Hersteller (ich nenne ihn mal AVM) da so standhaft weigert, ist und bleibt für mich ein Rätsel, ich gebe hier auch wieder auf und ziehe meine eigenen Konsequenzen. Eine schnelle Fehlerbehebung wie bei "webcm"-Gate in allen Ehren, aber die ersetzt kein "ordentliches Bug-Management", wenn es um Probleme geht, die die Sicherheit einer FRITZ!Box beeinträchtigen können (und seien sie auch noch so theoretisch ... alles was machbar ist, wird auch gemacht) und erst recht keine Warnung an die eigenen Kunden.

Wenn man der Meinung ist, die würde man ohnehin nicht erreichen können, dann liegt das zu einem guten Teil sicherlich auch daran, daß diese Kunden es gar nicht gewohnt sind, daß AVM entsprechende Hinweise veröffentlicht und deshalb nicht mal danach suchen würden. Wenn die Anzahl der direkt durch AVM erreichbaren Kunden (z.B. der mit MyFRITZ!-Accounts) zu gering ist, muß man eben die Provider mit einspannen (für Updates und da meine ich jetzt aber nicht diese Lücke, die in diesem Kontext eher eine Petitesse ist) und notfalls auch den richtigen Gang in die "Öffentlichkeit" nicht scheuen. Wenn es darum geht, warum eine FRITZ!Box von einem bestimmten Problem bei anderen Herstellern mal wieder nicht betroffen ist, ist da ja auch keine überbordende Schüchternheit vorhanden.

Nun steht die Forderung nach dem Einspannen der Provider (über Remote-Updates) zwar in krassem Gegensatz zu meiner sonstigen "Warnung" vor TR-069, das liegt aber auch nur an der Implementierung von AVM. Wenn da keine Konfigurationsdateien komplett übertragen werden können und auch der Zugriff auf Protokolle (Support-Daten) nur mit Kenntnis und Einverständnis des Besitzers möglich ist, dann ist TR-069 eher harmlos und sehr nützlich. Dann sollte es aber auch keine Notwendigkeit geben, dem Kunden ein X für ein U vorzumachen und ihn über die tatsächlichem Möglichkeiten des TR-069 im Dunkeln zu lassen bzw. da "Das Sandmännchen" zu geben.

@DieWilde13:
Mit ist die "Schuldfrage" am Ende eigentlich egal ... Fakt ist einfach, daß die KNB die neue Version nicht ausgerollt haben und daß AVM auf der anderen Seite (wie für weitere Lücken auch, deshalb habe ich auch mal an anderer Stelle hier geschrieben, daß die "Verweigerung" von Updates gut überlegt sein will) eine Information der Kunden bzw. eine Liste der behobenen Probleme (inkl. zugehöriger Versionsnummern) offensichtlich für unnötig hält. Im Ergebnis bleibt der Kunde angreifbar ... und zwar ohne es zu wissen und damit ohne die Möglichkeit, sich selbst zu schützen.

Ich bin sogar bereit zu attestieren, daß AVM das wahrscheinlich in dem guten Glauben macht, im besten Interesse der Kunden zu handeln. Ich sehe das aber anders ... ich persönlich möchte nicht wie ein unmündiges Kind, dem man nicht alles sagen oder erklären kann, vom Hersteller behandelt werden und nach meiner Ansicht ist er auch nicht berechtigt, solche Entscheidungen für andere Kunden zu treffen. Ich bin dazu zwar auch nicht berechtigt ... aber so wie AVM die eigene Haltung vertritt und umsetzt, mache ich das eben auch mit meiner.

Und es ist nun wirklich nicht so, daß sich solche Lücken nicht finden lassen, wenn man nur danach sucht ... ich betone ja immer wieder, daß es auf der WAN-Seite wohl gar nicht so schlecht aussieht (ist aber eher nicht mein Tisch), dafür auf der LAN-Seite um so finsterer und der Provider per TR-069 ist zwar theoretisch "WAN", aber praktisch hat er häufig dieselben Möglichkeiten wie ein LAN-Angreifer, wenn erst mal eine Internetverbindung aktiv ist und die notwendigen TR-069-Settings vorhanden sind.

Mal was ganz anderes ... weißt Du eigentlich, daß Dein Nickname (zumindest partiell und das muß ja auch nichts mit Dir zu tun haben, vielleicht verwendet jemand bei AVM den ja auch) in den AVM-Sourcen erwähnt wird?
Nicht daß ich Dich als AVM-Mitarbeiter im Verdacht hätte ... ich mußte nur schmunzeln, nachdem ich schon vor einiger Zeit auf diese Stelle gestoßen war und irgendwann vor einen knappen Jahr Deinen Nickname zur Kenntnis nahm (die Datei ist definitiv älter).

Stitch626 schrieb:

dass Lücken in Software (Firmware ist ja nichts anderes) eher privat gehalten werden, statt diese in Listen zu führen, die man einsehen könnte, ist eher normal.

Zum Vergrößern anklicken....

Das kann man durchaus kontrovers sehen, schau Dir einfach die Security Advisories von Software-Herstellern an. Dort werden Lücken aufgeführt (gefixte ohnehin) und es ist genauso üblich, vor der Nutzung von bestimmten Funktionen zu warnen, wenn diese nicht gleich die gesamte Funktion der Software komplett in Frage stellen, aber durchaus für Angriffe auf den Benutzer der Software verwendet werden könnten. Das muß ja nicht gleich mit einem PoC untermauert werden, aber die gesamte CVE-Liste besteht im Prinzip nur aus solchen offengelegten Lücken.

Am Ende ist das der alte Diskurs zwischen "No Disclosure", "Responsible Disclore" und "Full Disclosure". Jeder Standpunkt hat - meine Meinung - gute Argumente für und wider ... das ist dann mehr eine "Glaubensfrage", was man selbst für sinnvoller hält.

Um einer - vielleicht aufkommenden - Diskussion über die verschiedenen Disclosure-Strategien mal eine - allgemein verständliche - Grundlage zu geben:

https://www.allianz-fuer-cybersiche.../materialien/sensibilisierung/BSI-CS_027.html

leseratte10 schrieb:

Könnte man nicht die Befehle, die den Telnet-Daemon aktivieren, einfach in die "calllog" schreiben?

Zum Vergrößern anklicken....

Wenn die "/var/flash/calllog" tatsächlich abgearbeitet werden sollte, könnte man das sicherlich machen ... ich weiß allerdings nicht, ob das tatsächlich der Fall ist.

Dann wäre Telnet zwar erst nach einem Anruf da, aber immerhin ohne Ausnutzung eines Bugs, der evtl. demnächst gepatcht wird.

Zum Vergrößern anklicken....

Warum denn dann nicht gleich den Telnet-Daemon über die debug.cfg starten lassen, sondern erst auf einen Anruf warten? Der entscheidende Punkt bei diesem ganzen Thema hier (soweit es 06.04/06.05 betrifft) ist ja das Befüllen der "debug.cfg", die wird dann bei diesen Versionen beim Systemstart schon noch brav abgearbeitet. Wenn die Kommandos da erst einmal drinstehen, ist es egal, wie sie dorthin gelangt sind. Das Problem ist es also, erst einmal Kommandos zur Ausführung zu bringen, die überhaupt etwas in die "debug.cfg" hineinschreiben.

Oder habe ich irgendwas überlesen, warum das nicht geht?

Zum Vergrößern anklicken....

Ich denke schon ... werden denn bei Dir Kommandos in der /var/flash/calllog bei einem Anruf ausgeführt? Wenn nicht, ist das doch rein akademisch ... außer Du hast das Vorgehen eben doch nicht verstanden und bist der Meinung, die Kommandos in der /var/flash/calllog würden praktisch automatisch ausgeführt. Ohne Ausnutzung der Lücke (durch den passenden Hostnamen) interessiert das FRITZ!OS überhaupt nicht, was da in der /var/flash/calllog steht - jedenfalls nach meiner Erfahrung.

Wenn AVM die debug.cfg stillgelegt hat, war dabei auch immer die /var/flash/calllog ebenfalls betroffen (das ging schon bei der - zeitlich wohl wesentlich früher einzuordnenden - 06.05-Laborversion für die 7270v2/v3 im Mai 2014 los, nur noch "onlinechanged" blieb als "Hook" übrig) und - meines Wissens, das muß aber nicht für jede 6360-Firmware gelten - wurde die /var/flash/calllog (anders als /var/calllog, bei der man aber wieder vor der Frage steht, wie man die befüllen soll) bei der 6360 schon länger nicht mehr berücksichtigt (wenn überhaupt jemals). Wie kommst Du also auf die Idee, die /var/flash/calllog würde länger Bestand haben (als möglicher Angriffspunkt), als die "debug.cfg"?

Und warum probierst Du denn die Idee mit der /var/flash/calllog nicht einfach aus und läßt uns dann am Ergebnis teilhaben?

NemoN schrieb:

So wie ich es verstanden habe muss [...] ein/angefügt werden?

Zum Vergrößern anklicken....

Na ja, "muß" ist etwas zu absolut. "Kann" wäre mir lieber, es ist halt genau ein möglicher Weg, um in der rc.tail.sh die Abarbeitung der Kommandos im TFFS-Node mit der Minor-ID 98 (der heißt/hieß bei anderen Modellen bei AVM eben "debug.cfg", aber der Name ist nur Schall und Rauch) zu veranlassen.

Noch mal detaillierter zu diesem Einzeiler (das geht natürlich auch übersichtlicher, wenn man den Platz hat beim Injizieren des Kommandos):

1. Zuweisung einer Variablen (mit ohnehin sehr langem Namen, auch da reicht natürlich "r=/var/tmp/r", wenn man dann entsprechend "$r" in der Folge verwendet)
2. Anlegen eines char-Devices für den Node 98 (mit einem AVM-Skript, das uns die Arbeit des Ermittelns der Major-ID des TFFS abnimmt - wenn man das auf eine bestimmte Box zuschneidet, reicht auch ein "mknod c major 98 $r.t" (s. 1.) aus)
3. Kopieren des Inhalts aus dem TFFS in eine temporäre Datei (mit "character oriented i/o", theoretisch könnte man sogar direkt aus dem TFFS die Kommandos ausführen lassen)
4. Test, ob da überhaupt etwas drin steht (dafür gibt es von AVM auch ein Tool (checkempty), aber das geht so eben auch und baut nicht auf die Existenz von checkempty)
5. wenn da Inhalt vorhanden ist, wird als letztes eine asynchrone Shell gestartet, die diese Kommandos ausführt

Wenn man das also noch kürzer haben will (das ist u.U. nützlich, wenn man es noch in ein sed-Kommandos zur Modifikation irgendwo einbauen muß), dann ginge das auch so:
Das ist natürlich noch unübersichtlicher, aber es soll ja auch nur für den ersten Einstieg in das System sein ... selbst die 98 ist ja nur unter der Voraussetzung richtig, daß man die Kommandos dort schon untergebracht hat. Wenn man die "nur" per Import in der "calllog" abgelegt hat, ist das ja die Minor-ID 141 ... dahin schreibt ja der Import direkt und das erste injizierte Kommando sollte ja sinnvollerweise die dort stehende Liste abarbeiten.

Nebenbei: Ist die S44-hostname-Lücke denn in der 06.10 der 6490 überhaupt vorhanden? Das ist inzwischen alles schon wieder sehr lange her ... wenn ich bei mir in diese Firmware-Version schaue, ist dort (trotz "Build-Datum" 04.09.2014 14:21:09) kein "eval" zur Auswertung des Hostnamens mehr zu finden - das geht jetzt über Variablen-Zuweisungen/-Manipulationen. Das kommt mir zwar in der Chronologie meiner Meldung an AVM auch etwas komisch vor, könnte aber tatsächlich als "last minute change" noch passen ... jedoch habe ich inzwischen so viel an den 6490-Images herumgedoktert, daß ich da für eine Übereinstimmung mit dem Original von AVM nicht mehr die Hand ins Feuer legen würde.

Insofern bleibt die einzufügende Zeile zwar richtig, aber die S44-Lücke kann (vermutlich) nicht mehr genutzt werden, um eine (beschreibbare) Version der rc.tail.sh im tmpfs zu modifizieren und das Original damit zu "überblenden".

Vielleicht befindet sich ja in Deiner 6490 (die ist ja dann vermutlich nicht vom Provider, denn da ist m.W. inzwischen überall 06.2x in Benutzung) noch eine ältere Version als 06.10 in der anderen Partition? Wenn ja, könnte diese natürlich noch für die Hostname-Injection anfällig sein und Du müßtest vielleicht mal mit der booten (ohne Verbindung zum Kabelnetz selbstverständlich und das ist nicht nur so ein Spruch) als Test. Über weitere Lücken rede ich (aus hoffentlich nachvollziehbaren Gründen) nicht.

NemoN schrieb:

Kann das sein?

Zum Vergrößern anklicken....

Ja, durchaus ... hatte ich bei der 6490 an Weihnachten 2014 auch so, daß da seitens des Providers einfach noch einmal versucht wurde, ein 06.10-Update "drüberzuspielen", obwohl die Box schon (bei der Auslieferung) 06.10 hatte.

@koy:
Das wäre ja machbar ... aber die 6490 hat nun mal keine Möglichkeit, ein Pseudo-Image für das Update zu laden. Der gesamte "Update-Teil" des GUI fehlt dort und die "hostname"-Lücke ist ja eben schon geschlossen in der 06.10, darum geht es ja bei NemoN gerade.

@NemoN:
Da kann und will ich Dir jetzt dann auch nicht mehr weiterhelfen ... wenn ich Dir jetzt mit Allgemeinplätzen wie "Es gibt bestimmt noch andere Lücken." komme, hilft Dir das nicht und über andere mögliche Angriffe will (und darf) ich nicht reden; da gibt es von mir nicht einmal mehr einen Fingerzeig, in welcher Richtung man suchen könnte. Sorry.

Ich weiß es ehrlich gesagt auch nicht ... ich habe hier einen Dump einer ARM-Partition der 6490 vom 26.10.2014 vorliegen, den ich extra noch einmal ausgepackt habe, um Veränderungen meinerseits auszuschließen:
Wenn ich darin dann nachschaue, sehe ich folgendes:
Nach dieser Anzeige ist dort die Lücke noch vorhanden. Wenn AVM bei anderen Anbietern nach meiner Meldung (das fiel ja praktisch zeitlich zusammen) noch eine geänderte 06.10 nachgeschoben hat, dann müßte die eine höhere "Projektnummer" haben. Diese ist m.W. u.a. auch in der Datei "http://fritz.box/jason_boxinfo.xml" enthalten und sollte sich leicht feststellen lassen.
Das ist zwar die Ausgabe einer 7490, aber die sollte bei der 6490 nicht wesentlich anders funktionieren und sich mit jedem Browser abrufen lassen.

EDIT: Der Grund, warum das Skript in #1 nicht auf Anhieb bei der 6490 (auch nicht mit 06.08 vom 17.07.2014) funktioniert, ist ja (bei mir jedenfalls) nicht das Fehlen der S44-hostname-Lücke. AVM hat die Abarbeitung der debug.cfg schon im Sommer 2014 gekippt und das natürlich auch bei den DOCSIS-Modellen. Wenn also eine Modifikation auf die Abarbeitung der debug.cfg setzt, dann muß man sich entweder etwas anderes einfallen lassen oder irgendwie dafür sorgen (modfs macht auch nichts anderes), daß der Inhalt dieser Datei wieder berücksichtigt wird. Das war - wie schon in #1 ergänzt vor langer Zeit - der eigentliche Punkt, den ich schon vorher auf der 6490 umgesetzt hatte und der dort anders abläuft als bei der 6360. Nur in diesem Punkt stimmt #1 nicht, solange man nicht vorher schon für die Abarbeitung der debug.cfg sorgt - auch das geht natürlich als temporäre Lösung über den Hostnamen, aber das Setzen/Rücksetzen des Wertes für "hostname" muß man dann doch etwas anpassen.