Fritzbox 6490 Cable Firmware Update?

@Flole @PeterPawn
An so eine richtige Voranmeldung glaube ich nicht, aber in gewisserweise eingeschränkt scheint es schon zu sein.
Mit einer internationalen retail 6320 bekam ich zum Beispiel auch ein Zertifikat.
Bei einer Retail-box mit Zertifikaten im Urlader kam keins.
Eine alte KDG-Box mit Zertifikaten im Urlader konnte trotzdem nochmal Zertifikate laden (glücklicherweise mit anderem Inhalt, denn es ist ja auch ein neuer private-key enthalten)

Im Übrigen, scheinen die Parameter des Requests nicht wirklich überprüft zu werden (Bis auf die MAC), ich vermute diese dienen nur der Aufzeichnung/Logging.
 
Zuletzt bearbeitet:
Im Übrigen, scheinen die Parameter des Requests nicht wirklich überprüft zu werden (Bis auf die MAC), ich vermute diese dienen nur der Aufzeichnung/Logging.
Und genau dann, wenn das tatsächlich so sein sollte, verstehe ich die ganze Welt nicht mehr.

Man sollte doch wohl annehmen können, daß AVM bei einem so kapitalen Bock wie dem "cmcertgen" im Anschluß hingeht und sich einen wirklich sicheren Weg für eine solche Aktion überlegt. Dabei sollte ja dann auch jemand ein Mitspracherecht gehabt haben, der sich mit "Security" im Allgemeinen recht gut auskennt. Wenn der dann nicht sofort interveniert hat, wenn es wirklich nur solche Einschränkungen geben sollte (das sieht ja schon wieder wie "Duldungsstarre" aus und wie "Wird schon keiner merken ..."), dann kann man nur sagen: "Selbst schuld ... wenn das Kind schon im Brunnen ist, muß man es ja nicht noch einmal gezielt untertauchen.".

Nun habe ich bei einigen Überlegungen, was ich anstelle von AVM machen würde, immer wieder danebengelegen (und das auch schon, bevor ich wußte, wie AVM es wirklich umgesetzt hat, das war also nicht alles nur "hinterher hat es halt jeder bessergewußt") und daher sind meine Erwartungen tatsächlich auch sukzessive gesunken, aber bei einem so essentiellen Problem (man will das Klonen von Geräten verhindern und ersetzt daher das alte Herstellerzertifikat durch ein neues), kann doch eigentlich niemand auf die Idee kommen, das durch einen Mechanismus zu ersetzen, wo dann eben das notwendige Zertifikat nicht mehr lokal erstellt wird, sondern von einem externen Host (und auch noch beliebig oft und mit wechselnden privaten Schlüsseln, wobei das zumindest mal das "Abhören" erschwert) geladen wird und am Ende hat man - mangels wirklich umfassender Überprüfung solcher Requests - dasselbe Problem in grün.

Nun mag es gute Gründe geben, das "Protokoll" für ein solches Update so einfach wie möglich zu halten ... aber wenn so ein Request tatsächlich mit "curl" und zwei oder drei halbwegs richtig gesetzten Parametern möglich ist (noch dazu, wo sich eben die CM-MAC "vorhersagen" läßt anhand eines WLANs), dann grenzt das ja fast an Vorsatz. Die "Vorlaufzeit" für den 01.08.2016 war auch nicht so kurz und die Entscheidung (für die sich AVM selbst eingesetzt hatte) kam auch nicht so überraschend, daß man nicht hätte nachbessern können.

Vermutlich kam auch hier wieder das "Prinzip Hoffnung" zum Einsatz, daß es schon niemand merken würde ... und das ist genau eine Haltung (die "Hacker" müssen automatisch dümmer als wir sein, denn wir sind ja "die Guten"), die man in meinen Augen immer wieder bei AVM an vielen Stellen finden kann. Das geht bei der generellen "Informationspolitik" los (wenn sich schon die KNB über fehlende Infos zum Zertifikate-Problem beschweren) und zieht sich über die Priorisierung (bzw. Verzögerung) von Updates für Sicherheitsprobleme bis zum "Eingeständnis" gemachter Fehler (und die kann einfach niemand vermeiden, damit wirkt das Verschweigen solcher Fehler nicht besonders vertrauenserweckend) durch die gesamte AVM-Welt.

Dann noch jede Menge "Vaporware" und am Schluß reißt eigentlich nur noch fehlende Konkurrenz das Ganze wieder raus - von dem, wofür AVM früher mal stand, ist in meinen Augen nicht mehr so richtig viel übrig. Wenn nicht das Marketing in dem Maße zugenommen hätte, wie die Qualität der Produkte (und bei den Routern beurteile ich die nach der Firmware) abnahm (auch wegen der Zersplitterung mit offensichtlich zu wenig Personal), dann sähe es vermutlich inzwischen schon düster aus.

Dabei könnte man mit dem Pfund "einheimischer Hersteller mit direktem, auch gutem Kundensupport" so richtig wuchern ... im Moment kann man als "Experte" im Bekannten- oder Kundenkreis nicht mal mehr sinnvolle Empfehlungen geben. Die 7580 macht auf mich (ohne daß ich eine bisher getestet hätte, nur anhand der Berichte von Besitzern, die man hier finden kann) genau denselben Eindruck, den die 7490 bei ihrem Erscheinen hinterlassen hatte ... es mag zwar üblich sein, daß es "Kinderkrankheiten" in so einem Gerät gibt, aber irgendwie schafft es AVM immer wieder, die Vorstellung neuer Produkte so richtig in den Sand zu setzen (oder zu verk***en könnte man auch schreiben) und bei den "early adopters" schälen sich auch immer mehr zwei Extreme heraus ... den "Fanboys" kann ein Gerät gar nicht schlecht genug funktionieren und teuer genug sein, sie finden immer noch etwas, was sie begeistert und am anderen Ende des Spektrums stehen dann die Leute, die eigentlich nur ein funktionierendes, modernes Gerät haben wollten, mit dem sie die nächsten 3-4 Jahre auf der sicheren Seite sind und die nun mit "Bananenfirmware" erst mal vor Problemen stehen.

Vielleicht ist mir ja die "Beta-Phase" für die 7580 "durchgerutscht", aber ich bin für mich eigentlich zu der Überzeugung gekommen, daß es AVM offensichtlich gar nicht mehr für nötig hält, solche Geräte "in der Breite" mal vor der (offiziellen) Veröffentlichung auf Herz und Nieren testen zu lassen und daß man es inzwischen offenbar als normal ansieht, wenn der Kunde erst 6 Monate und mehr nach der Verfügbarkeit eines neuen Produkts dieses dann auch wirklich reibungslos benutzen kann. Das zieht sich für mich inzwischen durch sämtliche Neuvorstellungen von AVM seit ca. 5-6 Jahren und ist offenbar "Firmenphilosophie" geworden. Man denke nur an die ersten FRITZ!DECT 200, an den DVB-C-Repeater, die 7490 und nunmehr an die 7580 (und wohl auch die 7560) - von den COMET-Teilen mal ganz zu schweigen. Bis das alles "beim Kunden gereift" war (beim DVB-C-Repeater würden einige Besitzer heute noch bestreiten, daß die Firmware etwas taugt), hat es immer gedauert (das erste Firmware-Update bei der 7580 kam keine fünf Wochen nach der ersten Version - da fragt man sich schon, warum man das nicht "gleich richtig" machen konnte) und ich mußte gerade in der vergangenen Woche wieder eine defekte ältere FRITZ!Box ersetzen lassen ... dabei habe ich aus gutem Grund von der "neuesten Box" abgeraten bzw. abraten müssen.

Insofern unterscheidet sich AVM so langsam aber sicher kaum noch von irgendwelchen chinesischen Herstellern, von "Gründlichkeit" oder besonderem Augenmerk auf Sicherheit merkt man praktisch nichts mehr - weder bei neuen Geräten noch bei diversen anderen Vorgängen, wie eben diesem Zertifikate-Update. Das macht irgendwie alles keinen besonders professionellen Eindruck und auch wenn sich so etwas hinterher immer leicht konstatieren und/oder behaupten läßt (auch ich hasse es, wenn jemand es hinterher immer schon vorher ganz genau wußte und nur verabsäumt hatte, bereits vorher etwas dazu zu sagen), so kommen in jüngster Zeit immer mehr Stellen ans Licht, wo man (zumindest als Außenstehender) nur mit dem Kopf schütteln kann, wie einige Dinge bei AVM angegangen werden.

Wenigstens empfand ich (persönlich) die Reaktion von AVM auf das Speedport-Problem der Telekom ausnahmsweise mal als "angenehm zurückhaltend" ... das habe ich (gefühlt) auch schon anders erlebt. Aber vermutlich war die Erinnerung an das DOCSIS-Zertifikat-Debakel noch zu frisch, so daß man sich zuviel Triumph wohl besser verkniffen hat. Wobei ich der Meldung bei AVM vom 10.11.2016 zum "Zertifikatwechsel bei Kabelroutern" schon wieder einiges abgewinnen kann ... das hat ja schon fast satirische Züge, was dort geschrieben steht - vor allem würde mich ja interessieren, wie man denn "verbesserte Zertifikate" verwenden kann.

Das alte und das neue Herstellerzertifikat verwenden beide einen 2048-Bit-RSA-Schlüssel und bei beiden kommt SHA1 für die Signatur zur Anwendung (was auch vom BSI schon seit einigen Jahren nicht mehr als Verfahren empfohlen wird). Was da also "verbessert" wurde, würde ich zu gerne wissen wollen ... aber vermutlich mußte es ja "einen Grund" geben, warum man es überhaupt machen mußte ... aber gerade solche "Behauptungen" lassen mich dann auch an der Ernsthaftigkeit von Sicherheitsbestrebungen bei AVM zweifeln. Offenbar gewinnt hier immer noch "Marketing" und "Was sollen die Leute/Kunden denn von uns denken?" über wirkliche Offenheit und transparentes Handling für Security-Probleme - allem Marketing-Geblubber, wie wichtig man solche Themen doch nehmen würde, zum Trotz.
 
Zuletzt bearbeitet:
aber bei einem so essentiellen Problem (man will das Klonen von Geräten verhindern und ersetzt daher das alte Herstellerzertifikat durch ein neues), kann doch eigentlich niemand auf die Idee kommen, das durch einen Mechanismus zu ersetzen, wo dann eben das notwendige Zertifikat nicht mehr lokal erstellt wird, sondern von einem externen Host (und auch noch beliebig oft und mit wechselnden privaten Schlüsseln, wobei das zumindest mal das "Abhören" erschwert)

Zumindest bei dem Teil "beliebig oft" muss ich widersprechen, ein Download scheint immer nur einmal pro MAC möglich zu sein.
Ansonsten volle Zustimmung.

Nun mag es gute Gründe geben, das "Protokoll" für ein solches Update so einfach wie möglich zu halten ... aber wenn so ein Request tatsächlich mit "curl" und zwei oder drei halbwegs richtig gesetzten Parametern möglich ist (noch dazu, wo sich eben die CM-MAC "vorhersagen" läßt anhand eines WLANs), dann grenzt das ja fast an Vorsatz.

Ich verstehe auch nicht, warum man hier nicht auf eine Art CSR-Mechanismuss gesetzt hat, oder eine Challenge die mit dem alten privaten Schlüssel zu signieren wäre um zumindest das einfache Herunterladen ohne weiteren Schutz zu unterbinden.
Zwar wüsste ich nicht, wie man ein "gefälschtes" Zertifikat erkennen sollte, aber zumindest wäre damit eine Hürde geschaffen.

Wobei ich der Meldung bei AVM vom 10.11.2016 zum "Zertifikatwechsel bei Kabelroutern" schon wieder einiges abgewinnen kann ... das hat ja schon fast satirische Züge, was dort geschrieben steht - vor allem würde mich ja interessieren, wie man denn "verbesserte Zertifikate" verwenden kann.

Das hatte ich auch gelesen und musste dabei doch sehr Schmunzeln.
 
Ich finde deine Posts zum Thema "Sicherheitspolitik von AVM" immer sehr interessant, Peter.
Sehe ich das richtig, dass du dann in einer Woche veröffentlichen willst, wie man ein DoS-Angriff auf eine Fritz!Box macht über einen einfachen HTTP-Request (den man z.B. per AJAX machen kann, mein Opfer muss nur eine Website von mir aufrufen)? :-(
Ich verstehe deine Überlegungen voll und ganz, aber ich würde von AVM schon erwarten, dass sie für alle Boxen einfach eine FW 6.64 oder so veröffentlichen, bei der das Problem gefixt ist. Genau so mache ich das ja auch, mit Git muss man da ja auch nur ein paar Befehle tippen... :mad:
Und die "Baustelle Labor" ist halt vermutlich immernoch zu weit davon entfernt, bald für alle Boxen veröffentlicht zu werden!? :-(
 
@foolproof:
Im Prinzip ja ... die Lücke ist seit fünf Monaten gemeldet und im Labor-Zweig seit Ende Oktober gefixt. Bei der 6490 ist sie gar nicht vorhanden gewesen, liegt wohl an der anderen Architektur.

Ich hätte ja bis zur Veröffentlichung der ersten Release-Version gewartet ... ab diesem Zeitpunkt kann aber wirklich jeder durch Vergleich feststellen, wo das Problem liegt/lag und da noch mit einer Veröffentlichung zu warten, bis AVM in einem Jahr dann endlich alle anfälligen Versionen gefixt hat (abgesehen davon, daß man eben auch bei der (m.E. legitimen) Frage nach derartigen Plänen nur auf taube Ohren stößt), halte ich für wenig zielführend.

Meine erneute Anfrage, ob in diesem Jahr noch das Erscheinen der Release-Version geplant ist (weil ich nicht kurz vor oder gar über die Feiertage davon "überrascht" werden will), ist ohne Reaktion verhallt ... damit gibt es die Einzelheiten in der nächsten Woche (war auch noch einmal so angekündigt in meiner Nachfrage bei AVM).

Seit der in der Timeline angegebenen Labor-Version ist es wohl endlich gefixt ... wie weit das auf andere Modelle nun zutreffen mag (für die wichtigsten gibt es dann ja auch inziwschen Labor-Versionen), weiß ich nicht. Zumindest ist das dann mal ein triftiger Grund, auch beim "Normaluser" eine Labor-Version zu verwenden - denn so ein JS-Angriff über irgendeine Werbung (auch wenn man ohnehin einen AdBlocker verwenden sollte), wäre schon recht unangenehm.

Zwar wird das Routing wohl nicht beeinträchtigt (zumindest vordergründig nicht, so genau habe ich das nun auch wieder nicht in allen Einzelheiten untersucht, ich hatte auch nur drei Modelle, wo das funktionierte und keines davon war wirklich mit dem Routing beschäftigt), aber selbst die TCP-basierten SIP-Verbindungen zur App im LAN funktionieren dann offenbar nicht mehr - das Ergebnis dürfte früher oder später der manuell ausgelöste Neustart per "Stromstecker" sein (auch wenn das Teil hinterm Schrank hängt).

Die reine Beschreibung im Text (die habe ich irgendwo sogar schon mal ausführlicher gegeben als im GitHub-Repo) krankt auch immer an der Nachvollziehbarkeit/Glaubwürdigkeit ("so einfach kann das doch gar nicht sein") und daher lasse ich mir auch die Veröffentlichung des passenden Exploits dazu nicht nehmen.
 
Nun habe ich bei einigen Überlegungen, was ich anstelle von AVM machen würde, immer wieder danebengelegen (und das auch schon, bevor ich wußte, wie AVM es wirklich umgesetzt hat, das war also nicht alles nur "hinterher hat es halt jeder bessergewußt") und daher sind meine Erwartungen tatsächlich auch sukzessive gesunken, aber bei einem so essentiellen Problem (man will das Klonen von Geräten verhindern und ersetzt daher das alte Herstellerzertifikat durch ein neues), kann doch eigentlich niemand auf die Idee kommen, das durch einen Mechanismus zu ersetzen, wo dann eben das notwendige Zertifikat nicht mehr lokal erstellt wird, sondern von einem externen Host (und auch noch beliebig oft und mit wechselnden privaten Schlüsseln, wobei das zumindest mal das "Abhören" erschwert) geladen wird und am Ende hat man - mangels wirklich umfassender Überprüfung solcher Requests - dasselbe Problem in grün.
Wie jetzt, dieser Zertifikats-Update-Service liefert nicht nur ein neues Zertifikat, sondern auch einen neuen privaten Schlüssel mit aus? :shock:

Das wäre allerdings mehr als sträflich. Die richtige Vorgehensweise bei einem zurückgezogenen Herstellerzertifikat ist, für den Gerätebestand einmalig neue Zertifikate mit deren vorhandenen Schlüsselpaaren auszustellen. Das ist dann völlig sicher, selbst wenn Unbefugte sich das neue Zertifikat erhaschen - das ist ja eh öffentlich. Setzt natürlich voraus, dass bei der Herstellung für jedes personalisierte Gerät dessen öffentlicher Schlüssel in den Systemen des Herstellers gespeichert wird. Wenn AVM das versäumt hat, ist die Sache eh verloren - dann müsste AVM eigentlich den Gerätebestand komplett tauschen.
 
@robert_s:
Das setzt wieder voraus, daß der private Schlüssel auf dem CM unveränderlich ist ... genau das war er aber beim ersten Anlauf gerade nicht - sonst hätte es das "cmcertgen" nicht gebraucht. Der private Schlüssel wurde bei der ersten Benutzung generiert und beim Zurücksetzen auf Werkseinstellungen auch wieder gelöscht, wie der gesamte Inhalt von /nvram. Daher wurde der in der Firmware hinterlegte private Schlüssel des Herstellers benutzt, um das Zertifikat für diesen generierten, privaten Schlüssel auf dem CM zu signieren.

So weit, so schlecht ... das sollte aber tatsächlich nicht davon abhalten, den neuen (und dann auch "finalen") privaten Schlüssel auf dem CM zu generieren und den AVM-Service nur mit einem passenden CSR zu belästigen. Dann würde der private Schlüssel tatsächlich nur auf dem CM liegen und dieses auch nicht verlassen.

Das ist aber - nach dem, was man so im "cm_dl_cert" sehen kann - genau nicht der Fall, dort wird ein kompletter "Satz" geladen vom Hersteller. Jedenfalls wird der Ansicht nach (ich habe das auch noch nicht "live" beobachtet) ein Request (application/x-www-form-urlencoded, also auch kein "multipart-formdata", wo der öffentliche Schlüssel gesendet werden könnte als Datei) erzeugt, dem die Parameter
Code:
hwid=
&mac=
&oem=
&version=
&type=
mit auf den Weg gegeben werden. Das Ergebnis ist dann (nach anderen Zeichenketten zu urteilen) ein Tarball und wird entsprechend auf der Box extrahiert.


-Ich habe bei den auf dem Gerät erzeugten privaten Schlüsseln (soweit es die direkt beim ersten Start erzeugten angeht) allerdings auch meine Vorbehalte, ohne das Problem (mangels Zugriff auf ausreichende Mengen an Geräten) beweisen zu können ... aber so eine FRITZ!Box (egal ob es eine 63x0 oder 6490 ist) hat beim Start praktisch keine realistische Möglichkeit, irgendwoher genug Entropie "einzusammeln", damit die bei der Generierung des privaten Schlüssels verwendeten Zufallszahlen wirklich "gut" sind.

Der Box fehlen praktisch alle Quellen, die für die Initialisierung des "pseudo random number generator" (PRNG) im Kernel herangezogen werden könnten - beginnend bei Festplatten, wo sich aus der nicht vorhersagbaren Zugriffszeit auf einen bestimmten Sektor bei rotierenden Medien ein "Zufall" ableiten ließe oder Tastatureingaben durch den Benutzer oder am Ende sogar das Timing von Interrupts - die vom Kernel herangezogenen Quellen sind jedenfalls hier aufgelistet.

Da die Boxen auch keine Echtzeituhren haben, startet selbst die Uhrzeit immer am 01.01.1970 und solange die Operationen bis zur ersten Benutzung von /dev/random einigermaßen stabil vorhersagbar sind, haben auch die erzeugten Zufallszahlen an dieser Stelle nur eine beschränkte "Güte".

Da die Generierung des privaten CM-Keys auch ziemlich am Beginn der ersten Inbetriebnahme erfolgte, könnte man vermuten, daß es gar nicht soo viele verschiedene private Schlüssel (selbst 100.000 wären eben extrem wenige) gibt und das ist dann tatsächlich wieder ein Problem. Aus genau diesem Grund (die Kenntnis des verwendeten privaten Schlüssels sollte das (passive) Abhören der Kommunikation zwischen CM und CMTS ermöglichen) ist es auch nicht zielführend, wenn AVM tatsächlich (bei der derzeit offenbar verwendeten Vorgehensweise) die privaten Schlüssel ebenfalls speichern würde. Ich hoffe jedenfalls stark, daß sie das nicht machen ... sollte es tatsächlich eine zweite Möglichkeit für einen Zertifikat-Request geben, gibt es hoffentlich auch einen neuen privaten (und damit auch einen anderen öffentlichen) Schlüssel von AVM.

@k4y0z verneint die wiederholte Möglichkeit des Downloads ja, aber ich habe auch immer noch die Theorie, daß der von AVM geladene Schlüssel bis einschließlich 06.50 dann beim Werksreset wieder gelöscht wird - dort ist nach wie vor (bei den Versionen, die ich gesehen habe und für die ich das weiter vorne gezeigt habe) das komplette Löschen von /nvram über den Zugriff auf /proc/mtd enthalten. Wenn dann nicht das Zurücksetzen auf Werkseinstellungen die Box zum Support-Fall machen soll, muß es auch eine weitere Möglichkeit für den Download geben - woher auch immer.

Solange nicht die Box nach so einem Update auf ein "cat /proc/sys/urlader/config" hin auch "ZERTIFIKATE" aufzählt (das würde auf eine Aktualisierung des Bootloaders hinweisen und ist m.W. bisher nie beobachtet worden, es würde auch den Code in /bin/supportdata.kabel unnötig kompliziert erscheinen lassen), solange kann das nur in /nvram abgelegt werden (wenn es nicht im TFFS liegt und da wüßte ich nicht, wo das sein soll).


-Es ist also nicht wirklich "alles verloren", aber der für das Update der Zertifikate verwendete Vorgang hat schon noch so seine Ecken und Kanten, die ihn - bis zur endgültigen Klärung einiger offener Punkte - etwas komisch aussehen lassen.

Gegen einen zu irgendeinem beliebigen Zeitpunkt auf dem CM erzeugten privaten Schlüssel ist auch nichts einzuwenden (der müßte das CM wirklich nicht verlassen), das (von mir vermutete) Problem ist der "definierte Zeitpunkt", zu dem das bei der Inbetriebnahme (beim ersten Mal oder auch nach Werksreset) erfolgt(e) - den Zeitpunkt für ein Update über TR-069 oder das CMTS kann man wieder nicht vorhersehen, abgesehen davon, daß zu diesem Zeitpunkt i.d.R. auch eine Angabe zur aktuellen Uhrzeit vorhanden ist, die dann schon wieder als Entropie-Quelle herangezogen werden kann.

Ich kann das Entsetzen ob des (vermutlich) auch extern generierten, privaten Schlüssels verstehen (und hoffe inständig, daß AVM die privaten Schlüssel nicht wirklich speichert), aber das in #1241 beschriebene Vorgehen mit der Verwendung der "alten" Schlüssel wäre vermutlich auch nicht wirklich sicher gewesen.

Ich kann es zwar nicht beweisen (dazu müßte man als KNB eine Liste der öffentlichen Schlüssel der CM (aus deren Zertifikaten) abgleichen, in einer idealen Welt verwenden keine zwei CM denselben Schlüssel und in der realen nur eine kleine Anzahl), aber ich finde einfach keine zusätzliche Entropie-Quelle in den Sourcen. Sollte es die tatsächlich geben, müßte ich Abbitte leisten ... aber es gibt sogar entsprechende Forschung zu dem Thema der mangelnden Entropie auf "embedded devices" (weil das auch die häufig eingebauten SSH-Server angreifbar macht, wenn die vorhersagbare Schlüssel beim Start generieren) und die ist teilweise jünger als die DOCSIS-Geräte von AVM.

Es wäre also eine (positive) Überraschung, wenn diese Aspekte von AVM beim Entwurf schon berücksichtigt wurden ... das glaube ich aber erst, wenn ich die entsprechenden Stellen in den Quellen sehe. Der verwendete Kernel (bei der 6490 ja auch noch einer aus der 2.6-Reihe) trifft jedenfalls von sich aus noch keine zusätzlichen Vorbereitungen (auch dafür gibt es Vorschläge, wie man dieses Manko auf "embedded devices" umgehen könnte, die sind ebenfalls nicht so alt, daß sie bereits berücksichtigt werden könnten) und da die Generierung des Schlüssels ziemlich unmittelbar beim Start erfolgt, gibt es nicht so viele zufällige Faktoren, die den Ablauf bis zu diesem Zeitpunkt beeinflussen könnten.
 
Das ist aber - nach dem, was man so im "cm_dl_cert" sehen kann - genau nicht der Fall, dort wird ein kompletter "Satz" geladen vom Hersteller. Jedenfalls wird der Ansicht nach (ich habe das auch noch nicht "live" beobachtet) ein Request (application/x-www-form-urlencoded, also auch kein "multipart-formdata", wo der öffentliche Schlüssel gesendet werden könnte als Datei) erzeugt, dem die Parameter
Code:
hwid=
&mac=
&oem=
&version=
&type=
mit auf den Weg gegeben werden. Das Ergebnis ist dann (nach anderen Zeichenketten zu urteilen) ein Tarball und wird entsprechend auf der Box extrahiert.
Genau so ist es, was ja auch der curl Befehl zeigt.
Ich habe die Kommunikation des cm_dl_cert mitgeschnitten, sowie das Binary analysiert und daraus die entsprechende Syntax für curl abgeleitet.

@k4y0z verneint die wiederholte Möglichkeit des Downloads ja, aber ich habe auch immer noch die Theorie, daß der von AVM geladene Schlüssel bis einschließlich 06.50 dann beim Werksreset wieder gelöscht wird - dort ist nach wie vor (bei den Versionen, die ich gesehen habe und für die ich das weiter vorne gezeigt habe) das komplette Löschen von /nvram über den Zugriff auf /proc/mtd enthalten. Wenn dann nicht das Zurücksetzen auf Werkseinstellungen die Box zum Support-Fall machen soll, muß es auch eine weitere Möglichkeit für den Download geben - woher auch immer.


Für den Parameter type git es außer dem Wert "req" auch noch "ack", ich hatte zunächst vermutet, ein erfolgreicher Download wird mit einem "ack" im Anschluss bestätigt, ein erneuter Download scheint aber trotz des fehlenden "ack" nicht erfolgreich.

Bei Unitymedia ist das Zertifikatsupdate übrigens bei den 6320er Boxen mit der Firmware 6.05 (vorher lief dort 6.04) erfolgt.
Auch die nvramdontremove wurde dort hinzugefügt.

Aktuell habe ich leider nur eine ehemalige KDG-Box mit Zertifikaten im Urlader hier, sonst würde ich das mit dem Löschen der Zertifikate beim Zurücksetzen mal testen (Bräuchte dann allerdings auch die Firmware nochmal, da ich inzwischen in beiden Partitionen die Retail-Firmware habe).
 
Zuletzt bearbeitet:
Bei Unitymedia ist das Zertifikatsupdate übrigens bei den 6320er Boxen mit der Firmware 6.05 (vorher lief dort 6.04) erfolgt.
Auch die nvramdontremove wurde dort hinzugefügt.

Hallo k4y0z,
könntest Du "nvramdontremove" genauer erklären;
in welcher Datei befindet sich diese Option ?
...

Gruß
Pokemon20021
 
Nach der 06.50 kam eine Option dazu, bestimmte Teile des Speichers unter /nvram nicht mehr zu löschen bzw. das stimmt nicht 100%, der Mechanismus kam schon früher (m.W. spätestens in 06.3x), wurde nur praktisch nicht aktiv, weil die Datei /etc/docsis/nvramdontremove leer war.

In der /bin/docsisfactorydefaults wird mittels "find"-Kommando jede Datei unterhalb von /nvram gesucht, aus der Ergebnisliste alle Dateien entfernt, deren Name einem Pfad in der /etc/docsis/nvramdontremove entspricht und der Rest wird dann mit "rm" wirklich entsorgt.

Wie gesagt ... gibt es schon länger, bis einschließlich 06.50 war aber die Datei leer und damit bewirkte die Filterung keine Änderung der Liste der zu löschenden Dateien - das ist inzwischen anders (bei den Retail-Versionen).
 
Nach der 06.50 kam eine Option dazu, bestimmte Teile des Speichers unter /nvram nicht mehr zu löschen bzw. das stimmt nicht 100%, der Mechanismus kam schon früher (m.W. spätestens in 06.3x), wurde nur praktisch nicht aktiv, weil die Datei /etc/docsis/nvramdontremove leer war.
Zur Ergänzung:

Code:
# grep -e firmware_info -e firmware_version /proc/sys/urlader/environment 
firmware_version        unity
firmware_info   110.06.05
# cat /etc/docsis/nvramdontremove 
/nvram/1/security
/nvram/2/certificates
 
Ich habe bei den auf dem Gerät erzeugten privaten Schlüsseln (soweit es die direkt beim ersten Start erzeugten angeht) allerdings auch meine Vorbehalte, ohne das Problem (mangels Zugriff auf ausreichende Mengen an Geräten) beweisen zu können ... aber so eine FRITZ!Box (egal ob es eine 63x0 oder 6490 ist) hat beim Start praktisch keine realistische Möglichkeit, irgendwoher genug Entropie "einzusammeln", damit die bei der Generierung des privaten Schlüssels verwendeten Zufallszahlen wirklich "gut" sind.
Man könnte mal ein "Hello World" für den ATOM zusammenhacken, in welches man den Maschinenbefehl 0x0F 0xC7 (https://en.wikipedia.org/wiki/RdRand) einfügt, und schauen, ob der ATOM-Kern des Puma-Chipsatzes das ausführt. Dann hätte man die Quelle für "gute" Zufallszahlen. Alternativ könnte man auch nach entsprechenden Erweiterungen im ARM-Kern schauen...
 
Oh ... gerade das Einbeziehen einer "Hardware-Source" mit RDRAND ist aber sehr kontrovers gesehen in der Diskussion/Entwicklung von Linux (und wohl auch bei FreeBSD).

Zusammengefaßt wurde das auch schon sehr schön (vor 2 1/2 Jahren): http://cr.yp.to/talks/2014.05.16/slides-dan+tanja-20140516-4x3.pdf

Gerade beim Fehlen zusätzlicher Entropie-Quellen bildet so ein Hardware-RNG dann die einzige wirkliche Quelle für Entropie und die Diskussion um denkbare Backdoors in diesen HRNGs mag zwar auch nur "theoretisch" sein (auch wenn ein PoC existiert), aber das waren alle "big brother"-Szenarien vor Snowden auch - zumindest für die breite Öffentlichkeit.

Abgesehen davon läuft das bei AVM auf dem ARM-Core (und ist vermutlich 1:1 vom Puma5 übernommen) ... da hat der x86-Core erst mal keinen Einfluß.
 
Gibt es für die 6490 eine komplette Übersicht der dazugehörigen Artikelnummern?
 
Vielen Dank für die ganzen Beiträge. Ich möchte auch meine Erfolgstory loswerden.

Ausgangslage:

Kabel Deutschland Fritzbox 2000 2691 (via Auktion ...)
Seriennummer E452.547.....
Flash 0: 06.31 (kdg) (Zertifikate nicht geprüft)
Flash 1: 06.26 (kdg) (Zertifikate new/new)

Vorgehensweise (alles ohne Internetzugriff):
per FTP den Bootflash von 0 auf 1 geändert - Neustart
per FTP das Branding auf avm geändert - Neustart
Fritzbox auf Werkseinstellungen zurückgesetzt - Neustart

Flash 1 06.26 (jetzt avm): per Entwicklertools auf 06.61 geupdatet, alles ohne Fehler (106). - Neustart

Ergebnis:
Fritzbox 6490 jetzt auf 06.61 mit new/new


Ich versuche die Box diese Woche am Kabel Deutschland-Anschluss in Betrieb zu nehmen, denke aber das die MAC-Adresse gesperrt sein wird.
Mein Ziel war aber nur ein AVM Router mit WLAN AC und DVB-C-Streaming.

Nochmals vielen Dank für alle Beiträge
 
Zuletzt bearbeitet:
Der Fehler 0 oder 106 trat bei mir nur auf wenn die certs old/old waren
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.