@Shirocco88:
Ja und nein. Ich möchte das eigentlich nicht im Repository haben.
Warum?
Es ist eigentlich eine ziemlich fette Sicherheitslücke. Ich habe die Anfang Juni an AVM gemeldet (nur als Beschreibung, ohne PoC für einen Exploit) und hatte am Beginn noch die Idee, daß AVM alles daran setzen würde, sie zu schließen.
Das war offensichtlich zu naiv meinerseits ... trotzdem habe ich noch ziemlich lange mit mir gerungen, ob ich jemanden in die richtige Richtung schubsen soll oder nicht.
Nachdem das dann geklärt war, wie es funktionieren kann, habe ich nur ein paar Skript-Dateien, die ich ohnehin schon länger in der Schublade hatte und bisher für andere Boxen als die 6490 benutzt habe, etwas aufgehübscht und eingecheckt. Die haben per se auch nichts unmittelbar mit der "provideradditive.tar"-Lücke zu tun. Das funktioniert auch noch, wenn man das "run_update" nicht aus der "/var/post_install" startet - auch das ist wieder nur ein möglicher Ansatzpunkt gewesen. Das "nachgereichte" "tffs_add_file" ist am Ende auch "dual use" und wird nicht automatisch obsolet, wenn AVM die Lücke endlich schließt.
Wenn das mit den anderen Tools in der Beschreibung nicht so kompliziert geklungen hätte, hätte ich das Skript vermutlich auch nicht erstellt und zuvor habe ich tatsächlich die eigenen Box-Zertifikate (für das GUI, die haben nichts mit den CM-Zertifikaten zu tun) immer von Hand mit "privatekeypassword" verschlüsselt und per "cat" in die passenden Dateien im TFFS geschrieben, auch mit eigenen DH-Parametern, weil das AVM nicht gebacken kriegt beim Import.
Man müßte also sehr genau zwischen dem Ausnutzen der (hoffentlich früher oder später mal gefixten) Lücke und dem eigentlichen Zweck der Skript-Dateien unterscheiden - ich bin skeptisch, ob das gelingen kann, wenn es so eine "Anleitung" im Repo gäbe. Ich will das immer noch in erster Linie als Toolkit zum Realisieren eigener Idee auf einer FRITZ!Box sehen bzw. zum Bau von Demo-Exploits, damit man das Wesen von entdeckten Schwachstellen besser nachvollziehen kann.
Wenn ich das Repo gleichzeitig zur Dokumentation der gemeldeten Schwachstellen nutze, ist das schon grenzwertig (und auch der Tatsache geschuldet, daß AVM so etwas nicht wirklich selbst macht, wie es bei anderen Herstellern üblich ist).
Aber ich wollte kein weiteres Repository einrichten - schlimm genug, das "modfs" ein gesondertes ist - jedoch gibt es wohl keine Möglichkeit bei GitHub, weitere "Contributors" auf ein Unterverzeichnis zu beschränken (ein weiterer Grund, warum mir das im YourFritz-Repo nicht wirklich passen würde).
Da paßt dann eine
Anleitung zum "Hacken" einer FRITZ!Box nicht so richtig dazu - die Demonstration, warum und in welchem Umfang das eine ziemlich derbe Schwachstelle ist, würde ich selbst eher anhand eines anderen Modells vornehmen (wo das wirklich auch "unauffällig" komplett zu automatisieren ist
ohne Kenntnis von Credentials, weil das immer noch ein erheblicher Unterschied ist) und wenn diese Lücke nicht ohnehin "reif" für die Veröffentlichung gewesen wäre, hätte ich vermutlich auch dazu geschwiegen.
Ich wollte nur keinen Rückzieher machen, nachdem ich (mehr oder weniger in Rage) in einem
Nebensatz die Behauptung aufgestellt hatte, man könne auch eine Box von routermiete.de mit eigenen Firmware-Modifikationen verwenden, wenn man das unbedingt wolle und ich dann darauf angesprochen wurde.
Da ich bei der Lücke ohnehin die Hoffnung auf eine Reaktion von AVM schon aufgegeben hatte (keine Ahnung, ob man dort das Potential und die Gefahr dieser Lücke wirklich so krass unterschätzt hat oder doch der Meinung war, ich meinte meine "90-Tage-Policy" nicht wirklich ernst und man daher einfach mal die Nagelprobe machen wollte) und da ich das tatsächlich von Beginn an für eine Schande hielt, daß die DVB-C-Funktionen bei Provider-Branding deaktiviert sind (s. Thread aus dem Jan. 2015), hatte ich den ersten Demo-Exploit für die Lücke sogar für das Freischalten der DVB-C-Funktionen bei Provider-Branding erstellt und bereits am 20.09.2016 an AVM gesendet - auch hier erwartete ich immer noch, daß AVM die letzte Chance für eine Reaktion / einen Einspruch nutzen würde (wenn es auch einer wirklich guten Erklärung bedurft hätte, warum man das bisher praktisch ignoriert und auf keinen der wiederholten Hinweise in dieser Richtung reagiert hatte).
Trotzdem hoffe/erwarte ich, daß AVM sich irgendwann an die Beseitigung auch dieser Lücke machen wird - die läßt sich nämlich auch zum unbemerkten Einbringen fremder Kommandos in die ganzen anderen Modelle (selbst solche mit NAND-TFFS, auch wenn da das Auslesen anders läuft) mißbrauchen und das will (hoffentlich) am Ende keiner auf Dauer in einer FRITZ!Box haben. Wenn dann das Ganze ohnehin nicht mehr auf diesem Weg funktioniert, braucht es auch die Anleitung nicht mehr und so eine Versionsverwaltung wie Git "vergißt" so etwas dann (absichtlich) trotzdem nicht.
Und ganz ehrlich: Ich hege die Befürchtung, daß dann früher oder später irgendwelche Nachfragen zu so einer Anleitung als "Issues" im Repository landen und am Ende (selbst bei weiteren Contributors, die ich hinzufügen könnte) die Beantwortung von solchen Fragen doch an mir hängenbleiben würde.
Warum kann man das nicht erst einmal in der von mir
angesprochenen Form eines eigenen Threads machen? Wenn da jemand den ersten Beitrag ordentlich pflegt, sollte es auch so funktionieren. Macht der TE das dann nicht, auch gut - aber dann auch nicht mein Problem, wie es das im Repo wäre.
-Ich selbst habe nicht den geringsten Ehrgeiz, meine "Produkte" jenseits der (einmaligen) technischen Beschreibung in einer Form zu dokumentieren oder zu aggregieren, die auch nur im Ansatz an ein "HowTo" heranreicht. Ich will auch nicht verhehlen, daß ich in Bezug auf allzu einfache Modifikationen von Leuten so vollkommen ohne jeden Schimmer eher skeptisch bin ... wenn es AVM nicht gar so leicht gemacht hätte an dieser Stelle, weil man selbst so gar keine zusätzlichen Maßnahmen getroffen hat, hätte ich sogar ein Interesse bei AVM vermutet, daß eine Änderung der Firmware einer DOCSIS-Box nicht so ohne weiteres möglich ist.
Aber da hat man ja nun wirklich auf jedwede Gegenmaßnahme verzichtet (das Entfernen des Links für den Telnet-Daemon ist ja nun keine wirkliche Hürde, das ist reines Schaulaufen und wenn die Firmware für jeden zu laden ist, dann ist es auch klar, daß diese auseinandergenommen und modifiziert werden kann - das kann niemanden wirklich überraschen) und damit darf man auch unterstellen, daß es nicht wirklich als Problem gesehen wird, wenn es solche Diskussionen wie hier gibt. Das hätte man wesentlich besser schützen können - ich kann praktisch keine zusätzlichen Sicherheitsvorkehrungen (die ich immer wieder "prognostiziert" und tatsächlich erwartet habe) erkennen, ganz im Gegenteil. Das Veröffentlichen von Firmware mit dem "cm_dl_cert" an Bord ist so offensichtlich ein "auch laßt sie doch machen" oder ohne jede vorherige Überlegung erfolgt, daß ich im Innersten auf Lösung A hoffe.
Und trotzdem erleben wir immer wieder, daß es Leute gibt, die ohne Plan und ohne die geringste Vorbereitung mit ihrem Vorhaben beginnen und sich selbst dabei ins Knie schießen. Meine Hilfsbereitschaft und mein Mitleid geht an dieser Stelle noch genau bis zum Update auf eine Retail-Version (bei der Unterstützung beim Zertifikate-Update wird es schon deutlich enger), damit die Besitzer älterer Boxen diese nicht verschrotten müssen (oder sie - noch schlimmer - über eBay wieder abstoßen und dann steht hier der nächste Eigentümer im IPPF auf der Matte und fragt, was er machen könne), solange die Boxen die Chance auf ein Zertifikate-Update haben.
Da sie dann offenbar beim jeweiligen Besitzer selbst mit alten Zertifikaten noch eingesetzt werden können (und sei es - wie bei mir - als 4-fach-Tuner für Kodi, was bei alten kdg-Boxen ab 06.3x ansonsten nicht möglich wäre), sehe ich darin auch so ein wenig meine Anerkennung der ja durchaus von den einzelnen Hardware-Entwicklern und Programmierern bei AVM geleisteten guten Arbeit - es ist irgendwie schade, wenn ein ansonsten doch sehr ordentliches Stück Hardware einfach verschrottet werden soll ... schon das Verkrüppeln als Provider-Box ist eine Schande. Wenn ich nicht eine entscheidende Entwicklung verpaßt habe, gibt es auch kein vergleichbares Gerät zu kaufen und in der Regel hat auch mindestens der Vorbesitzer dafür 160 EUR an den Provider gezahlt (zumindest war das bei KDG so) und nur weil es keinen Plan bei AVM gibt/gab (oder man den sehr gut zu verbergen wußte), wie man mit dem alten Fehler in Bezug auf die Zertifikate umgehen wollte, ist die Hardware ja noch kein Schrott.
Das habe ich am Beginn auch noch anders gesehen, da glaubte ich aber auch noch daran, daß AVM bei den Retail-Modellen tatsächlich zusätzlichen Aufwand (in erheblichem Maße und zwar bei der Hard- und Software und nicht nur im Marketing) getrieben hätte.
Wer sich dann auch noch ein OpenVPN auf den x86-Core zaubert, kann die Box sogar recht gut als VPN-Gateway hinter einem DSL-Router benutzen ... man muß das integrierte CM ja nicht unbedingt auch nutzen wollen. Ich habe z.B. einen KDG/VF-Anschluß, aber nur noch das TV-Programm und keinen Internet-Zugang. Trotzdem kann ich eben die Tuner in mein Netz einbinden und die 6490 per Portforwarding zum VPN-Gateway machen ... die beiden x86-Cores sind im Vergleich zu den beiden MIPS-Cores bei der 7490 sogar richtige Sprinter und sogar die Priorisierung klappt ordentlich, wenn der gesamte Traffic, der über "dev dsl" gesendet werden muß, auch schon über "dev lan" ankommt und das nicht erst auf der Box noch durch die Verschlüsselung "aufgeblasen" wird vom Volumen her.
Es gäbe also auch für ältere 6490 (mit oder ohne neues Zertifikat) noch ein Leben nach dem Tode (beim Provider) und genau weil auch das bei einer KDG-Box mit Firmware >= 06.3x nicht funktionieren würde, brauchte es eine solche Lücke (die AVM ja auch rechtzeitig ordentlich untersuchen und bestätigen hätte können - sie hatten mind. sechs Wochen nach der Meldung Zeit für eine erste ernsthafte Reaktion). Gerade die erwähnten KDG-Boxen wären nämlich tatsächlich vollkommen nutzlos geworden ... sie haben einerseits kein Branding "avm", mit dem sie DVB-C verwenden könnten, sie werden nicht im Netz von KDG provisioniert (egal, ob die Zertifikate alt oder neu sind) und sie würden mit ihrem KDG-Branding (zumindest darf man das vermuten) auch im Netz von UM nicht akzeptiert (bei kleineren weiß ich es nicht). Da ist dann so etwas die letzte Chance ... und ich gehe tatsächlich davon aus, daß die überwiegende Mehrheit einfach nur die 6490 sinnvoll nutzen will und gar nicht an weiteren Modifikationen (die das eCM betreffen könnten) interessiert ist.
Ggf. noch ein SSH-Server (zur Steuerung) und das erwähnte OpenVPN auf den x86-Core (ich würde den ARM-Core gar nicht weiter beachten, der ist eben ohnehin recht lahm - daher hätte ich auch eher den "dropbear" für den x86-Core gebaut als für den ARM-Core) und dann noch den NFS-Server dort etwas aufgebohrt (das funktioniert auch problemlos) und man hat ein recht nettes "Zusatzgerät" (bei einer gebrauchten FRITZ!Box 6490 auch für kleines Geld), das einem 4 Tuner, einen NFS-Server und ein VPN-Gateway bereitstellen kann. Dann noch pro TV-Gerät einen RasPi mit Kodi und man hat (mit der 6490 als "Server") ein kleines Media-Netzwerk aufgebaut für einen Preis, für den man keine zwei DVB-C-Repeater (UVP) kriegen würde.
-Wenn dann jemand hingeht und aus dem Update ein Geschäft macht, finde ich das zwar nicht wirklich gut, jedenfalls wenn man es dann bei der Preisdifferenz übertreiben sollte ... aber zumindest hat so jemand dann offenbar verstanden, wie es geht. Wenn er dann für den Aufwand bis zu 20 EUR pro Box einnimmt, ist das meinetwegen auch noch in Ordnung.
Wobei das für 10 Minuten Arbeit pro Box schon recht nett wäre (5-6 x 20 EUR = 100-120 EUR und das ist schon kein schlechter Stundensatz) - so lange dauert es (nach entsprechenden Vorbereitungen zur Automatisierung der Arbeitsschritte) maximal, die Box direkt beim Einschalten auslesen zu lassen (Environment und Counter), ein leeres TFFS-Image (zzgl. Node 29) daraus zu erstellen und das in beide Partitionen zu flashen. Dann die Box neu starten, gleich direkt auf den (NAS-)FTP-Server zugreifen (das Kennwort braucht es normalerweise gar nicht) und die notwendigen Dateien auf den NAS-Speicher kopieren. Dann noch einen Restart (auch der geht direkt, man muß gar nicht manuell durch den Assistenten - zumindest nicht bis zur 06.50) hingelegt und die Box aktualisiert sich von alleine. Nach dem nächsten Neustart noch einmalig auf Werkseinstellungen setzen und fertig ist die Laube - könnte man denken, aber das ist eben ein Irrtum.
Wenn das tatsächlich jemand als Geschäftsidee für sich entdeckt haben sollte (einige aktuelle und beendete Angebote mind. eines
Verkäufers bei eBay sehen schon schwer danach aus, vor allem sind es alles Boxen, die im Netz von KDG nicht verwendet werden können und ich mag nicht so richtig glauben, daß jemand 20+ Boxen mal so "auf Lager" hatte), dann will ich nur hoffen, daß derjenige entweder tatsächlich seinen eigenen Weg für das Update gefunden hat (oder bei einem KNB arbeitet) oder daß er hinterher wenigstens so verantwortungsbewußt ist, auch den Node 29 wieder aus dem TFFS zu entfernen, wenn er den hier gezeigten Weg beschreitet.
Jemand anderem eine FRITZ!Box 6490 mit einem Inhalt in Node 29 zu verkaufen, den derjenige gar nicht löschen kann, wäre ziemlich unverantwortlich. Ich war zwischenzeitlich schon mal versucht, so eine Box meinerseits abzustauben und das zu überprüfen ... seitdem derartige Boxen (mit Version 06.62) angeboten werden. Ich denke mal, daß so ein Überbleibsel im Node 29 einen erheblichen Mangel darstellt und - Privatverkauf hin oder her - die Beschreibung dann nicht so richtig der tatsächlichen Beschaffenheit entspricht - das wäre ganz klar eine Backdoor, die man in so einem Gerät hinterlassen würde.
