[Info] keine Signaturprüfung für Firmware-Updates in FRITZ!OS 06.05 für 7270v3

Es gibt ja in der Firmware normalerweise drei Dateien - /etc/avm_firmware_public_key[1-3] -, die wohl unterschiedliche öffentliche Schlüssel sind, mit denen die Signatur-Dateien in einem Firmware-Image entschlüsselt und dann mit einer über das zu flashende Image gebildeten Prüfsumme (oder vielleicht auch einem Hash-Wert) verglichen werden können. Ob da Leichen dabei sind oder es notfalls mit allen drei Keys nacheinander versucht wird, wenn einer nicht paßt, weiß ich nicht, das war mir aber mal einen Test wert.

Mein Interesse geht final in die Richtung, einen der AVM-Keys gegen einen eigenen auszutauschen, damit nur noch beim ersten "falsch signierten" Update eine Fehlermeldung erscheint und ich ansonsten die Möglichkeit habe, Boxen im Bekanntenkreis (bzw. die Bekannten selbst, damit sie die Updates machen) auch mit eigenen Updates/Änderungen zu versorgen, ohne daß jedes Mal beim Update die Warnmeldung "nicht von AVM freigegebene Firmware" erscheint, die ein Update per Fernwartung ja eigentlich ausschließt.

Wie auch immer ... ich hoffe mal, daß AVM tatsächlich auch die Hand auf den entsprechenden privaten Schlüsseln hat und die nicht einfach an OEM-Kunden (also Provider) herausgibt, denn dann könnte tatsächlich jeder Provider mit TR-069-Zugriff auch Boxen modifizieren, die gar nicht in seine Zuständigkeit fallen sollten. Das ist - auf die Firmware bezogen - dann sicherlich noch eine andere Qualität des Zugriffs, wenn ein Provider auch über das von AVM per TR-069 schon "eingeräumte" Maß auf einer FRITZ!Box schalten und walten kann, wie er will - einfach weil er eigene Firmware einspielen kann, ohne daß die Box daran etwas auszusetzen hätte.

Weil mich dann abseits dieser Überlegungen zur möglichen "Streuung" dieser Keys auch interessierte, ob beim Firmware-Update seitens des Providers über TR-069 überhaupt ordentlich geprüft wird, daß es sich um eine originale Version von AVM handelt oder ob der Provider da problemlos seine eigene unsignierte Version unterbringen könnte und es gar keine Weitergabe von Keys geben muß (bei DOCSIS-Boxen ist es offenbar/vermutlich Usus, daß die Provider tatsächlich selbst die CVC-Files signieren können, das ist auch ein etwas anderer Mechanismus, der in der DOCSIS-Spezifikation und nicht im TR-069 zu finden ist), habe ich einen entsprechenden Versuch mit einer 7270v3 (AVM-Original in rot), die gerade zur Hand war, gestartet.

Als die Box ein mit Freetz entpacktes und (nach Modifikation der rc.tail.sh) wieder zusammengepacktes Image klaglos akzeptierte, vermutete ich schon, daß das tatsächlich immer so sein könnte. Zur Vorsicht habe ich dann noch einen weiteren Test ausgeführt (das "firmwarecfg"-Binary ist - nach meiner Erfahrung - für Updates durch den Benutzer und über TR-069 zuständig) und da erwartete mich dann eine herbe Überraschung.

Die These der generellen Möglichkeit unsignierter Updates über TR-069 kann man mit der aktuellen Firmware-Version 06.05 für die 7270v3 tatsächlich nicht mit letzter Sicherheit bestätigen oder widerlegen, denn diese Firmware-Version führt offenbar gar keine Signatur-Prüfung für Firmware-Updates mehr aus.

Was habe ich getestet, um zu dieser Feststellung zu gelangen?

1. Recovery mit der frisch vom AVM-FTP-Server geladenen Version von "fritz.box_fon_wlan_7270_v3.06.05.recover-image.exe" (vom 17.06.2014, SHA1: cf2972a070eb0ec64d19d280f6c7d3651a3683ba)
2. nur GUI-Kennwort gesetzt, Assistenten abgebrochen, Ansicht: Erweitert und Update mit meinem unsignierten Image
3. die Box schluckte das Image ohne die übliche Meldung "von AVM nicht freigegebene Firmware" und führte das Update aus

4. Um sicherzugehen, daß das nicht nur ein Problem der per Recovery in die Box geladenen Version ist, habe ich anschließend noch einmal Recovery auf die 05.54 (vom März 2014) - ebenfalls frisch vom AVM-Server - ausgeführt.
5. Beim dann folgenden Versuch mit dem unsignierten Image kam auch die erwartete Meldung und ich habe das Update mit diesem Image abgebrochen und neu starten lassen.
6. Anschließend dann mit der Version 06.05 vom AVM-Server (FRITZ.Box_Fon_WLAN_7270_v3.74.06.05.image vom 27.05.2014, SHA1: 432bffd942ea6f5914571bf350fd575ea55371c5) ein normales Update ... klappt reibungslos, ist ja auch signiert.

7. In der nunmehr auf "normalem" Weg aktualisierten Box (aktueller geht bei diesem Modell ja nicht) dann erneut der Test mit dem unsignierten Image, auch hier wird das klaglos akzeptiert.

Damit weiß ich nun zwar immer noch nicht, ob beim Firmware-Update durch den Provider eine ordentliche Signaturprüfung stattfindet, aber für die 7270v3 mit der erwähnten Firmware-Version kann ich die Behauptung aufstellen, daß da irgendwas bei der Überprüfung von Firmware-Updates nicht stimmt.

Das ist nun kein riesiger Skandal, aber es ermöglichte mir immerhin (als ich Provider spielte) das Einspielen einer modifizierten Firmware vollkommen ohne die Notwendigkeit irgendwelcher Exploits. Das sollte - nach meinem Verständnis - nicht ohne weiteres möglich sein.

"Schlimm" genug, wenn man AVM bei der Signatur (bei aktiviertem Auto-Update) vertrauen muß ... bei "lawful interception"-Request (Stichwort: Quellen-TKÜ im Router) könnten die sich sicherlich ohnehin nicht wehren und müßten wahrscheinlich auch eine Trojaner-Firmware auf Aufforderung signieren. Das muß aber gegenüber dem eigenen Provider nun nicht auch noch sein ... ob die 7270v3 beim Einstellen von "1&1" als Provider TR-069 auch zwangsaktiviert (enabled vs. litemode), habe ich noch gar nicht getestet. Wenn ich einen Tipp abgeben müßte, hätte ich allerdings einen ...

Auch jeder Andere mit Admin-Zugriff auf das GUI (der zwar ohnehin nicht möglich sein sollte, aber beim externen Zugriff ist - bei korrekter Umsetzung der Signaturprüfung - wenigstens kein Update mit einer modifizierten Firmware möglich, da bei der Ansage "nicht freigegebene Firmware" der dsld schon nicht mehr läuft und das "Update fortsetzen" somit nur lokal zu bestätigen ist) kann damit ohne Prüfung die Firmware von extern modifizieren ... so wie bei jedem anderen Firmware-Update per Fernwartung, wenn die Firmware halt die Signaturprüfung besteht und die zusätzliche Nachfrage entfallen kann. Mit einer passenden Firmware ist da eine 7270v3 auch schnell in einen Bot verwandelt, der auch keine schlechte Prognose für sein "Überleben" hätte, wenn AVM keine weiteren Versionen für die 7270v[23] nachschiebt, wovon ja die meisten sicherlich ausgehen. Dafür braucht man dann bloß die passenden Admin-Credentials ... was - an anderer Stelle schon dargelegt - nicht immer eine unüberwindliche Hürde sein muß.

Ob AVM hier noch einmal Abhilfe schaffen wird, mag ich nicht prognostizieren ... schon die 06.05 kam für mich persönlich sehr überraschend, die Motive lagen vermutlich im AHA-Bereich. Wenn das allerdings tatsächlich nur ein Versehen und keine Absicht ist, dann wirft das in meinen Augen einmal mehr kein allzu gutes Licht auf die QS. Meine Vermutung/Spekulation zur Ursache geht in die Richtung, daß es für Entwicklungsversionen einen Schalter für die Signaturprüfung gibt, damit die Entwickler nicht immer selbst genervt werden und hier könnte man dann nur vergessen haben, diesen wieder richtig zu setzen. Es stellt sich am Ende aber trotzdem die Frage, bei wievielen/welchen Firmware-Versionen und -Modellen das noch der Fall sein könnte oder schon früher war. Bei dem inzwischen eingetretenen "Wildwuchs" blicken offenbar auch die Entwickler nicht mehr immer durch, wir hatten ja auch schon veröffentlichte "Labor-Versionen", die eigentlich eher interne Entwickler-Versionen waren und z.B. den Log-Daemon und die AVM-Version von "shellinabox" (inkl. der Verlinkung in der Support-Seite der Box) enthielten. Wenn das allerdings bei einem Release passiert, deutet das für mich auf fehlende (auch automatisch mögliche) Tests hin.

Von einem extern auszunutzenden Problem in der 05.54 weiß ich nichts ... aber AVM beseitigt ja Sicherheitslücken eher klammheimlich und somit kann man das nur schwer beurteilen.

Es gibt einige von intern auszunutzende Lücken in der Firmware, von denen ich weiß und die von AVM peu a peu geschlossen wurden und werden. In aller Regel stört sich AVM an diesen Problemen nach meinem Eindruck aber am ehesten dann, wenn man darüber die DOCSIS-Modelle "rooten" kann bzw. dort Shell-Zugriff erhält.

Was nun genau an Sicherheitsrisiken von 05.54 zu 06.05 behoben wurde, kriegt man also nur durch Analyse der geänderten Stellen heraus, was gerade beim Wechsel von 05.xx auf FRITZ!OS 6 ein ziemlich aufwändiges Unterfangen ist, da sich ja vieles geändert hat, was nichts mit Sicherheitslücken zu tun hatte.

Ich kann (und will) also keine Empfehlung geben, ich habe auf der produktiven 7270v3 (die macht Internet/Telefonie über VPN per UMTS auf dem Wochenendgrundstück) die 06.05 im Einsatz. Ist da auch kein Problem, die ist ohnehin hinter einem Provider-NAT und hat natürlich ordentliche Konteneinstellungen, da macht kein Fremder ein Update.

An eine TR-064-Lücke kann ich mich derzeit gar nicht erinnern (jedenfalls an keine per "tr064cgi" extern auszunutzende) ... ich habe nur inzwischen "Beweise" (oder zumindest belegbare Indizien), daß die auch schon aufgestellte Behauptung, ein Provider könne über TR-069 zwar Einstellungen setzen, aber die Einstellungen einer Box nicht auslesen (womit er dann ggf. auch Mail-, WebDAV- und was weiß ich noch für Kennwörter abgreifen kann), wohl nicht so ganz der Wahrheit entsprechen dürfte; jedenfalls ist es in der Firmware explizit vorgesehen, daß eine Export-Datei über TR-069 auch per FTP oder HTTP(S) ins Internet hochgeladen werden kann (dazu aber an anderer Stelle demnächst mehr und ausführlicher). Das hat auch mit der Firmware der 7270v3 im Speziellen nichts zu tun, das gilt für alle von mir bisher getesteten Boxen.

Daß die 06.05 bei der 7270v[23] bereits die neuen "Sicherheitsfeatures" hat (keine debug.cfg, keine /var/calllog, vermutlich auch kein Import mit "NoChecks=yes", aber - wenn ich mich recht erinnere, ist aber nur aus dem Gedächtnis - noch die Abarbeitung von /var/tmp/onlinechanged), weißt Du sicherlich selbst ... wenn man etwas davon braucht, muß man also die Firmware vorher wieder passend modifizieren. Solltest Du das tatsächlich irgendwann mal ausführen (und dafür den Freetz-Trunk mit "fwmod", jedoch ohne ein komplettes Freetz-Image, benutzen), kann ich nur aus eigener leidvoller Erfahrung berichten, daß man da mit etwas Vorsicht herangehen muß, sonst hat man wegen irgendwelcher Ungereimtheiten mit dem verwendeten "fakeroot" ziemlich schnell ein ungültiges Image nach dem Einpacken.

Ich habe Updates für meine 6490 bisher nur als CVC-File gesehen, allerdings waren es auch nur 2 Updates seitens des Providers. Nachdem ich das erste Mal das Update erst einmal unterbrochen hatte, kam dann 2 Tage später ein weiterer Versuch, den ich dann passieren ließ.

Bei DOCSIS (CVC steht nebenbei bemerkt für "Code Verification Certificate") wird meines Wissens eine "Chain of Trust" benutzt, wobei das DOCSIS-Gremium seinerseits der Anchor dieser Kette ist.

Auf der anderen Seite werden offenbar auch Konfigurationseinstellungen manchmal signiert, irgendwo habe ich zu Motorola-Modems etwas derartiges gelesen.

Ich weiß auch nicht sicher, ob tatsächlich nur der Hersteller ein entsprechendes Zertifikat erhält (s. Link weiter vorne) oder ob auch ein Provider ein solches erhalten kann. Ich habe nur aus den in der Firmware der 6490 hinterlegten Zertifikaten meine Schlüsse gezogen, die müssen nicht zwangsläufig richtig sein.

Wenn auch Konfigurationseinstellungen signiert werden und der Provider damit ein Zertifikat von der richtigen CA hat, stellt sich für mich die Frage, wie genau die Firmware beim Update diese Zertifikate prüft, d.h. ob also getestet wird, daß eine neue Firmware tatsächlich mit einem AVM-Zertifikat signiert ist und nicht nur mit einem beliebigen, von der Root-CA signierten. Das meinte ich mit dem anderen Mechanismus ... der ist m.W. auch im Rahmen der DOCSIS-Spezifikationen vorgegeben, während sich in der TR-069-Spezifikation meines Wissens nichts zur Identitätssicherung des Urhebers eines darüber eingeleiteten Firmware-Updates findet.

Leider habe ich es damals versäumt, das komplette Update-File aufzuheben, als ich den ersten Update-Versuch unterbrochen hatte. Ich war nur am Inhalt des Filesystems interessiert ... aus heutiger Sicht etwas zu kurz gedacht. Bleibt mir nur die Möglichkeit, beim Update auf 06.20 besser aufzupassen ...

EDIT: Früher bei der 6360 kamen meines Wissens Updates tatsächlich noch per TR-069 oder per CVC-File. Da aber die 6490 ja die höheren "DOCSIS-Weihen" erhalten hat (sie ist offiziell zertifiziert), denke ich mal, daß AVM auf TR-069-Updates dort verzichtet, gemäß Punkt 3.5 des Abkommens mit CableLabs. Aber alles nur Vermutung und aus Beobachtungen der realen Welt abgeleitet, kein sicheres (und schon gar kein beweisbares) Wissen.

Weil mir seitens AVM Vorhaltungen gemacht wurden, ich hätte diesen Bug erst einmal bei ihnen melden sollen, will ich hier noch einmal kurz auf die Historie dieses Problems hinweisen.

Erstmals festgestellt habe ich das bereits im Frühjahr 2014 für die Labor-Version, aus der die 06.05 hervorgegangen ist, der entsprechende Beitrag ist hier zu finden.

Zum damaligen Zeitpunkt waren alle Feststellungen mit Bezug auf die debug.cfg, allcfgconv und die diversen "Sicherheitsänderungen" ja nur Spekulationen, da - wie immer - ein konkretes Changelog nicht vorhanden war.

Aber schon damals hielt ich das ja für einen Bug (noch deutlicher konnte man das wohl kaum schreiben), den ich selbstverständlich über das Feedback-Formular zur Labor-Version bereits gemeldet hatte, als ich den Beitrag schrieb.

Zwar hatte ich das dann auch selbst aus den Augen verloren, aber bei der Revision der offenen Lücken fiel es mir eben wieder auf, daß da ja schon einmal etwas war. Daß dieser Fehler auf meiner Liste als "gemeldet" notiert war, war Anlaß genug, das nach entsprechend langer Zeit dann auch offenzulegen ohne mich erneut erst an AVM zu wenden.

Dieser frühere Fund ändert aber auch überhaupt nichts daran, daß ich das beim Test der Firmware-Update-Möglichkeiten im Zusammenhang mit den TR-069-Untersuchungen dann auch wie oben beschrieben erst wieder entdeckt habe, auch wenn diese Tests natürlich nicht in den 24 Stunden vor dem Schreiben von #1 erfolgten. Die dort dargelegten Überlegungen sind schon etwas älter, das habe ich aber auch nie (absichtlich) anders dargestellt. Ich teste ja nicht auf der einen Console und schreibe parallel auf der anderen die Beiträge im IPPF.

Und ich bin ja nun beim besten Willen nicht dafür verantwortlich, jede von AVM neu herausgegebene Version auf nicht beseitigte Probleme abzuklopfen (und mich dann wieder darüber zu ärgern, wenn meine investierte Arbeit ergebnislos blieb), daher war mir dann tatsächlich auch bis zum November 2014 nicht klar, daß AVM es nicht geschafft hatte, im Zeitraum vom 17.04.2014 (die Meldung lag ja davor) bis zum 27.05.2014 (da erschien 06.05 als Release) diesen Bug zu fixen.

Erschwerend kommt dann noch hinzu, daß die einzige 7270v3, mit der ich das hätte testen können, sich vom Frühjahr bis zum Herbst auf dem Wochenendgrundstück befindet und ich damit gar kein Gerät für weitere Tests bis zum Herbstende 2014 hatte.

Also AVM ... bitte die Kirche im Dorf lassen und das Bug-Tracking-System vielleicht etwas optimaler nutzen oder ausbauen. Wenn den Testern bei einer Labor-Version gleich von Beginn an sinngemäß gesagt wird: "Schreibt was ihr wollt, es gibt keine Reaktionen.", dann muß man sich auch nicht wundern, wenn sie nicht jedesmal ihre persönlichen Daten dort eingeben (und in der Folge solche Meldungen nicht zuzuordnen sind).
Das sollte aber noch lange kein Grund sein, daß die dort gemeldeten Probleme am Ende irgendwo "runterfallen", nur weil es vielleicht nur eine einzige Meldung dazu gibt. Es ist ja leider auch nicht das erste Mal, daß so etwas geschieht bzw. geschehen ist ...