Fritzbox 6490 Cable Firmware Update?

Es kann zwar schon mal vorkommen, daß es bis zum EOF auf der Datei etwas länger dauert (60 Sekunden bis zum Timeout, siehe Zeile 95), wenn da kein richtiges "close" erfolgte ... aber nicht 30 Minuten. Ansonsten gibt es ohnehin ein Protokoll der FTP-Verbindung in einer Datei - da sollte dann auch enthalten sein, ob die Datenverbindung nun "normal" geschlossen und quittiert wurde.

Wenn das mit der Kommunikation mit der Box beim Upload unter Linux nicht funktionieren will (das kann alles mögliche sein, angefangen bei TCP-Einstellungen über das sysfs bis zum Treiber für die Netzwerkkarte oder eine falsche iptables-Konfiguration), kann man auch noch das PowerShell-Skript nehmen und unter Windows die MTD-Partitionen schreiben.

Hier kommt ja offensichtlich keine Antwort im "control channel" der FTP-Verbindung nach dem Upload - wenn auf die erste zusätzliche "Meldung" unmittelbar die zweite folgt, ist das ja normal und erwartbar, denn das "cat" läuft asychron zum Rest des Skripts (daher das & am Ende der Zeile) und wird erst nach dem Lesen der nächsten Antwort auf dem Steuerkanal wieder eingefangen (wenn das eine "226" war), indem das "nc" gekillt wird (da ist allerdings wirklich ein Kommando zuviel in der Datei, jedoch ohne echte Auswirkungen).

- - - Aktualisiert - - -

@stoney0815:
Warum ist das interessant und nicht ohnehin vollkommen logisch und erwartbar?

Die 06.22 enthielt noch keinen Code zur Auswertung, welche Zertifikate da nun vorhanden sind -> damit tauchen diese Angaben gar nicht erst in den Support-Daten auf; die Zertifikate bleiben trotzdem vorhanden, es wird halt nur nichts angezeigt (und sie werden vermutlich auch nicht benutzt, wobei man dazu in die 06.22 hineinsehen müßte, um das sicher zu wissen).

Solange die Firmware das jeweils verwendete Branding enthält, gilt die Firmware auch für alle Brandings (mit sehr minimalen Abweichungen bei internen Abläufen, die hier aber gar nicht im Spiel sind) -> damit sollte eine Firmware-Version auch mit allen Brandings dieselben Angaben zu den Zertifikaten anzeigen (oder diese Anzeige eben auch auslassen).

Die 06.26 enthält (soweit das bisher bekannt ist) noch alle drei Brandings (avm, lgi, kdg), daher ist die funktionierende Umschaltung auch wenig verblüffend -> das geht erst bei "kdg"-Branding und ab 06.3x schief, wenn man auf "avm" stellen will.

Was man dann noch festhalten könnte, wäre die Tatsache, daß eine Box auch schon Anfang Juli 2015 (da war das neue Herstellerzertifikat knapp 4 Monate alt) die neuen Zertifikate enthielt - und es ziemlich unklar ist, welche Firmware da bei der Produktion installiert wurde. Wenn die 06.22 (die kleinere der beiden) in der Partition mit "linux_fs_start=1" liegt, dann kann das entweder nur ein Downgrade einer zuvor installierten höheren Version sein oder die Box hatte eine nicht mehr auffindbare andere Version bei der Produktion erhalten (die inzwischen von der 06.26 beim Update überschrieben wurde). Wobei das mit den "neuen Zertifikaten ab Werk" auch nur dann gelten würde, wenn man für diese Box einmal die Werkseinstellungen "abgerufen" hätte ... ansonsten kann man zwischen Download und Finalisierung als "Quelle" für die neuen Zertifikaten nur anhand der "/var/tmp/urladerirgendwas"-Datei in den Support-Daten unterscheiden.

@Micha0815: Diese "Schnäppchen" sind seit Anfang Oktober auch so ziemlich ausgestorben oder zumindest nie lange im Angebot - hat sich wohl herumgesprochen, daß man da richtig sparen kann.

- - - Aktualisiert - - -

@Flole:
Einfach dei FTP-Verbindung ohne "QUIT" beenden (spielt beim REBOOT ohnehin keine Geige) ... u.a. deshalb sollte auch keines meiner Skripte es heutzutage noch anders machen. Es gab mal eine Version von "eva_discover", die bei "HOLD=1" mit "QUIT" arbeitete ... da das bei der 6490 dann nicht funktionierte (was bei einer 7412 problemlos war), wurde es geändert und heute sollte da nur noch ein EOF "gesendet" werden (also praktisch nur ein FIN-Paket ohne jede weitere Formalität).

EDIT: Ich habe gerade gesehen, daß das im YourFritz-Repo beim "eva_discover" tatsächlich noch falsch war ... ist geändert.

PeterPawn schrieb:

Es kann zwar schon mal vorkommen, daß es bis zum EOF auf der Datei etwas länger dauert (60 Sekunden bis zum Timeout, siehe Zeile 95), wenn da kein richtiges "close" erfolgte ... aber nicht 30 Minuten. Ansonsten gibt es ohnehin ein Protokoll der FTP-Verbindung in einer Datei - da sollte dann auch enthalten sein, ob die Datenverbindung nun "normal" geschlossen und quittiert wurde.

Wenn das mit der Kommunikation mit der Box beim Upload unter Linux nicht funktionieren will (das kann alles mögliche sein, angefangen bei TCP-Einstellungen über das sysfs bis zum Treiber für die Netzwerkkarte oder eine falsche iptables-Konfiguration), kann man auch noch das PowerShell-Skript nehmen und unter Windows die MTD-Partitionen schreiben.

Zum Vergrößern anklicken....

Auch mit Powershell kein Erfolg, dafür ne Menge Debug Infos:

Also irgendwas läuft auch da schief. Habs mit mtd3 und mtd4 versucht, immer der selbe Fehler. Übersehe ich da irgendwas oder ist die Lücke doch tatsächlich dicht (da glaub ich aber nicht so wirklich dran, dann würde der Fehler bestimmt auch anders aussehen).

Nun wird ja bei so einem Schreibkommando für SPI- oder NOR-Flash vorher erst noch der zu beschreibende Bereich mittels "erase"-Kommando gelöscht, so daß da erst einmal nur binäre Einsen stehen. Das ist auch der Grund, warum es nach einem "STOR mtdX" erst einmal eine kurze Pause gibt, bis dann die "150" als Bestätigung kommt und man mit dem Upload auch wirklich beginnen kann. Anschließend sollte das aber kein Problem sein, da die Daten auf die Box zu schaufeln und dann auch zu schreiben ... ob für jeden geschriebenen Block unmittelbar geprüft wird durch nachfolgendes Lesen, weiß ich nicht.

Vielleicht ist ja wirklich der Flash hin und so ein Vergleich schlägt fehl - das sollte aber auch eine Fehlermeldung geben, ebenso ein zu großes Image im Upload oder was da sonst noch denkbar ist. Eigentlich müßten diese Antworten dann auch protokolliert werden.

Bei Dir fehlt aber schon irgendwo das passende "STOR"-Kommando in der Auflistung.

Warum das bei der Linux-Version so sein könnte, habe ich gefunden und gerade korrigiert (da war es nur die falsche Variable für die Log-Datei) - aber warum das beim PowerShell jetzt auch noch schiefgeht, kann ich nicht so richtig verstehen.

Außer es handelt sich um ein W7-System und dort ist das Update auf PowerShell 3 und CLR (common language runtime) 4.0 nicht installiert ($PSVersionTable anzeigen lassen) - für das Kopieren wird eine Methode verwendet, die erst ab 4.0 implementiert ist (CopyToAsync). Für frühere PS-Versionen gibt es irgendwo einen alten Branch mit einer Version, die ab PS2 funktionieren sollte.

So, wie ich das sehe, kann es sich hier auch nicht um ein Flash-Problem handeln, denn es wurde ja noch gar kein "STOR"-Kommando gesendet, weil schon der Verbindungsaufbau für die passive Datenverbindung scheitert. Das "IOException" an sich ist aber zu wenig aussagekräftig, da müßtest Du in das "catch" ab Zeile 337 noch die Anzeige der aktuellen Exception einbauen (die interessiert ansonsten nicht so sehr, ist ohnehin alles ein Fehler).

Ich will auch nicht beschwören, daß ich das "WriteFile" tatsächlich mit einer 6490 getestet habe ... entwickelt wurde das mit einer 7412 und bei der 6490 schreibe ich selbst in der Regel auch unter Linux. Das werde ich also gleich mal testen ... sofern man eine "segment ID" verwendet, die größer als die aktuelle eigene ist, ändert das ja auch nichts an den verwendeten Einstellungen.

Ansonsten hat die "provideradditive.tar"-Lücke mit dem Bootloader gar nichts zu tun ... der wird nur "verwendet" und wenn AVM das Schreiben aus dem Bootloader ausbauen sollte (glaube ich nicht wirklich), dann kann das Recovery-Programm (auch wenn es das für die 6490 nicht frei verfügbar gibt, existiert ja eines) es ebenfalls nicht mehr nutzen.

- - - Aktualisiert - - -

Ok, bei der 6490 kam die Bestätigung für das "STOR"-Kommando zu spät (100 ms waren wohl zu wenig, wenn der Flash erst noch gelöscht werden muß) - das habe ich jetzt angepaßt für das PowerShell-Skript. Beim Testen mit dem Debugger ist das eventuell unter den Tisch gefallen, weil immer genug Zeit zwischen dem Schreiben und dem Lesen verging.

Jetzt sieht es jedenfalls bei mir so aus:

Falls jemandem der Weg über die Änderung der "provideradditive.tar" zu kompliziert ist, kann er bei einigermaßen aktuellen Versionen der Firmware (ab wann genau, muß jeder selbst sehen) auch einfach eine weitere, relativ neue Lücke in der Firmware benutzen, die ich heute mal etwas genauer unter die Lupe genommen habe: https://github.com/PeterPawn/YourFritz/tree/master/reported_threats/796851

Man braucht also nur die eigenen Kommandos irgendwie als (Skript-)Datei auf den NAS-Speicher der Box zu bringen und dann kann man - über einen "Zusatz" zum Kennwort für den Versand der Einstellungen vor einem Update - diese auch ausführen, indem man einfach irgendwie das Update aufruft. Das kann auch mit einer unsignierten Datei oder einer älteren Version erfolgen, denn der Versand der Einstellungen erfolgt noch vor dem "prepare_fwupgrade" und es spielt gar keine Rolle, ob das Update danach klappt oder nicht. Allerdings müßte man - wenn man den ansonsten fälligen Neustart vermeiden will - den Rest des "Update-Prozesses" auch wieder abbrechen, so wie es das Pseudo-Image für den Telnet-Start machte. Wobei man hier tatsächlich noch früher unterbrechen kann und es somit gar nicht erst zum Beenden von Diensten kommen muß, die man dann hinterher wieder mühsam neu startet.

Die Lücke habe ich aber parallel auch an AVM gemeldet - ich gehe mal davon aus, daß sie damit direkt in der nächsten Version geschlossen wird. Für die 6490 interessiert das mich persönlich wieder weniger ... aber die anderen Modelle sind auf diesem Weg ebenfalls angreifbar und das wieder (bei geeigneten Voraussetzungen) ohne jede Notwendigkeit zur Authentifizierung (bei der 6490 ist es ja nicht so einfach wie bei den VR9-Modellen, einfach ein Image aus dem RAM zu starten - damit ist die weniger exponiert). Ansonsten reicht dann wieder ein einziges lokales Gerät (passend infiziert), um den kompletten Router zu kompromittieren.

EDIT:
Nachdem AVM geantwortet hatte, habe ich den Verzeichnisnamen im Repo noch einmal geändert, dadurch stimmte der Link nicht mehr so ganz ... sollte zwar immer noch kein Problem gewesen sein, aber ich habe ihn oben korrigiert.

PeterPawn schrieb:

Falls jemandem der Weg über die Änderung der "provideradditive.tar" zu kompliziert ist,
...
https://github.com/PeterPawn/YourFritz/tree/master/reported_threats/796851

Zum Vergrößern anklicken....

ich denke Besitzer von Non-Retail-Boxen mit "Provider-Firmware", z.B. FB6490 FW 06.31 (kdg) wird die "Push-Mail" Methode keinen wesentliche Vereinfachung bei Wunsch nach Firmware-Update auf 06.6x oder unbranding bringen, da der User hier warten müßte bis Provider ein FW-Update pushen möchte;
oder habe ich hier etwas überlesen und diese Lücke greift auch in Kombination mit "fesc-Methode" #83

Keine Ahnung, seit wann genau das dateibasierte Update nicht mehr "zweigeteilt" ist (erst der Download der Settings, dann der Upload der Image-Datei). Solange das so war, wurde intern immer die normale "Export-Funktion" aus "firmwarecfg" aufgerufen und diese ist (soweit es mir bekannt ist) nicht anfällig gewesen. Daher habe ich ja auch versucht, die Tatsache herauszuarbeiten (im README.md im Repo), daß das erst nach neueren Änderungen wirklich (unabhängig von der Existenz einer neueren Firmware-Version bei AVM) gezielt auszunutzen ist.

Selbstverständlich gehörte das schon lange vorher zu den "üblichen Tests", ob da ein normaler Aufruf von "firmwarecfg" für "ConfigExport" anfällig wäre ... das ist aber nicht der Fall. Ein Test mit Push-Mail erforderte dann immer das "Hacken" der Update-Prüfung oder die Installation einer bekanntermaßen älteren Firmware, wenn diese Funktion (die es ja schon seit der 06.2x gibt) einer Prüfung unterziehen wollte.

So ist das im Laufe der Zeit ein wenig unter die Räder gekommen bei den regelmäßigen Tests ... da ich auch nur sehr selten die Update-Funktion des FRITZ!OS verwende (logischerweise nehme ich i.d.R. "modfs"), bin ich gar nicht sicher, seit wann beim dateibasierten Update das gespeicherte Kennwort und die Push-Mail zum Einsatz kommen. Bei der 113.06.60 war es wohl schon der Fall - weiter zurück suche ich jetzt nicht.

Hi @ll,

ich habe jetzt den ganzen Thread (zumindest quer-)gelesen und leider keine Lösung für mein Problem gesehen, daher meine Anfrage:

Ich habe eine 6490 die ich wegen old/old Zertifikaten Nachdem dem Update mit Fehler 106 mit per Start-Partitionsumstellung von der 6.26 über 6.62 zu 6.63 geupdatet habe. Es handelt sich um eine alte KDG Box, die auf AVM "Branding" umgestellt wurde. Leider wird sie nicht ins Netz von Telecolumbus gelassen. Eine alternative 6490 (ebenfalls alte KDG Box) mit new/new Zertifikaten hingegen schon.
Jetzt meine Fragen:
Gibt es eine Möglichkeit (und wie ist sie), mit der 6.63 mit old/old zu neuen Zertifikaten zu kommen, damit die Box in Netzen die dies verlangen, nutzbar gemacht werden kann? Ich fände sehr ärgerlich, wenn die Box jetzt nicht mehr sinnvoll zu verwenden wäre.

Ich hatte auch gerade versucht, nochmal die vorherige Version einzustellen, komme jedoch per adam2 und ftp nicht mehr drauf...

Und wieder mal die ollen certs...

Ausgangslage: Box gekauft bei Ebay Kleinanzeigen (kdg) FW: 6.22
Seriennummer beginnt mit F174
CM MAC beginnt mit 34:31
Artikelnummer 2000 2691


Zuerst habe ich für die Box das Branding von kdg auf avm umgestellt. Per ftp in den ersten 5 Sekunden (quote SETENV firmware_version avm) – Box neu gestartet – alles tadellos.
Gleich im Anschluss hab ich dann eine Anleitung für das Update gesucht, und nach einigem durchstöbern in diesem Thread auch gefunden. #682
„Fritz.box im Browser aufrufen (ich habe IE V11 benutzt)
a) Nach System/Sicherung/Wiederherstellen navigieren
b) "Entwickler-Tools"im Browser aktivieren
c) Rechtsklick auf den "Datei auswählen" Button --> Inspect
d) Folgende Elemente im HTML code ändern:
name=ConfigImportFile ändern in name=UploadFile
und
id=uiImportändern in id=uiFile
e) "Wiederherstellen" drücken (Bitte unbedingt warten, am Anfang hat sich bei mir nichts getan, dann hat die INFO LED angefangen zu blinken und die FW 6.61 wurde eingespielt. Habe dann solange gewartet bis die 6490 komplett neugestartet hat (WLAN LED ist dann wieder eingeschaltet).

4. Wenn keine Fehlermeldung erscheint, habt ihr das Update auf 6.61 erfolgreich vollzogen dann bitte zu Schritt 6 gehen

5. Wenn eine Fehlermeldung „Fehler 106 (Ein nicht näher spezifizierter Fehler traf während des Updates auf.)“ erscheint (war bei mir mit der Firmware 6.23 auch so) dann half folgendes“

Da sich kein einziges Update bei mir ohne Fehler installieren hat lassen (Fehler 106), habe ich nach jedem Update den Bootloader gewechselt(quote SETENV linux_fs_start 1 oder quote SETENV linux_fs_start 0). Zumindest bin ich so in den Genuss des 6.61 gekommen und hab dann auf 6.63 upgedated (via Webif) – aber auch in der Update Funktion des 6.61 hab ich den "Fehler 106" bekommen und hab danach den Bootloader wieder gewechselt – 6.63 war dann installiert.
Ob das jetzt so gut war – kann ich ned sagen - nervig war es allemal

Meine Certs sind jedenfalls beide auf old/old, ehrlich gesagt habe ich aber in den vielen Posts nicht genau rauslesen können, ob es jetzt ne Möglichkeit gibt, diese durch AVM erneuern zu lassen. Von selber, quasi nur weil ich die Box im Internet hängen hab, wird dies ja leide rnicht geschehen…
Meine Fragen sind nun, welch eine Überraschung, kriegt man das irgendwie gebacken, oder gibt es da im Moment noch keine Chance?
Könnte mir jemand liebenswürdiger Weise in die Syntax Welt der Abfragen, hinsichtlich Staus der sich vielleicht noch auf der Box befindlichen Zertifikate , ein wenig behilflich sein? Ich wäre für jede Hilfe dankbar.

Ein Update der Zertifikate scheint aktuell nur noch im Unitymedia-Netz möglich zu sein, da der Downloadserver nur Verbindungen von dort akzeptiert.
Mit folgendem Befehl von einem System mit openssl kann überprüft werden ob der AVM-Server auf Anfragen reagiert:
Kommt eine Antwort so ist ein Update der Zertifikate an diesem Anschluss möglich (und wird durch ein Onlineupdate ausgelöst).
Der Zertifikatsdownload klappt genau einmal.
Sollte also das Zertifikat bereits geladen worden sein und (warum auch immer) gelöscht worden, so ist ein erneuter Download nicht möglich.

Im Übrigen ist es durch Kentniss der MAC-Adresse auch ohne Fritzbox möglich das Zertifikat zu beziehen.
(Es muss dann natürlich noch irgendwie auf die Box kommen)

@PeterPawn
Der exploit über Export-Passwort wird im übrigen auch beim Zurücksetzen auf Werkseinstellungen ausgelöst

Mir war gar nicht bewußt, daß dabei auch eine Mail mit den gesicherten Einstellungen vor dem Reset verschickt wird - muß auch irgendwie neu sein.

Aufgefallen war es mir auch nur durch Zufall, da ich den Exploit noch aktiv hatte und bei einem Werksreset plötzlich eine weiße Seite hatte.
War glaube ich bei der 06.62

k4y0z schrieb:

Ein Update der Zertifikate scheint aktuell nur noch im Unitymedia-Netz möglich zu sein, da der Downloadserver nur Verbindungen von dort akzeptiert.
Mit folgendem Befehl von einer Linuxkiste kann überprüft werden ob der AVM-Server auf Anfragen reagiert:

Code:

openssl s_client -connect c4.avm.de:51443

Zum Vergrößern anklicken....

FYI: bei meinem KDG-Anschluss kommt eine Antwort

Dann sollte ein Zertifikatsupdate an deinem Anschluss funktionieren.
Vorrausgesetzt natürlich er hat noch nicht stattgefunden und die Zertifikate wurden gelöscht.
Wie das zum Beispiel passieren könnte, hatte PeterPawn glaube ich hier irgendwo erklärt.

Der Postbote hat mein neues Vodafone-Paket vor ca. 30 Minuten gebracht ... mal sehen, was da heute nacht noch geht. Vielleicht kann ich ja auch aus dem VF-Netz dem AVM-Service genauer auf den Zahn fühlen und mal die Kommunikation genauer beleuchten, aus meinem Telekom-Netz wollte er ja nie so richtig antworten.

Dann wünsche ich dir viel Spaß

k4y0z schrieb:

Mit folgendem Befehl von einer Linuxkiste kann überprüft werden ob der AVM-Server auf Anfragen reagiert:

Code:

openssl s_client -connect c4.avm.de:51443

Zum Vergrößern anklicken....

da lag der "Buschfunk" wohl richtig ;-)

PeterPawn schrieb:

Soweit ich weiß (das ist hier wirklich nur "Buschfunk" und ich habe es niemals selbst gesehen/gemacht), erfolgt(e) das Update über einen speziellen Server bei AVM (der irgendwo mal erwähnte c4.avm.de) und der rückte die neuen Daten nur dann heraus, wenn das CM auf einer vorher "angemeldeten" Liste stand.

Das lief auch (soweit man das im "cm_dl_cert" sehen kann) nicht über TR-069, sondern über einen HTTPS-Request (x-www-form-urlencoded) auf Port 51443.

Zum Vergrößern anklicken....

hab hier nen komischen Patienten... meine box ist aktuell auf 6.62 bei mir am um anschluss mit old/old im Einsatz, soweit so gut, funktioniert.
über diese box hab ich jetzt schon mehrere boxen mit neuen certs versorgt (meistens von 6.62 mit onlineupdate auf 6.63 und dann wars new/new).
heut will ich meine eigene dann endlich mal mit new/new versorgen und es klappt nicht. wollte auch den weg von 6.62 auf 6.63 via lan1 an einem anderen um anschluss (direkt am modem) gehen. rennt jedesmal in den bekannten fehler rein.
hat vielleicht avm den server heut abgedreht? bzw an was kann es sonst noch liegen? ich hab spasseshalber als die 6.63 rauskam einfach mal das onlineupdate ausprobiert direkt am Kabelanschluss - hat (natürlich) nicht geklappt. war das vllt ein fehler das vorher auszuprobieren?

Wenn die Box doch mit den alten Zertifikaten noch online kommt, warum dann der Umweg über LAN1?

weil das onlineupdate mit old/old direkt am cable leider nicht funktioniert hat...dachte mir auch dass das eigentlich gehen müsste :-(