[Erledigt] Sinn und Unsinn der AVM-Verschlüsselung, allcfgconv, webdavcfginfo, usw.

[PeterPawn]

Nachdem AVM ja nun seit längerer Zeit schon die Möglichkeit des Dekodierens von Kennwörtern mit "allcfgconv -c" aus der Firmware entfernt, geht es jetzt auch dem "mißbrauchten" 'webdavcfginfo' an den Kragen. In der aktuellen Labor-Version für die 7490 funktioniert das Decodieren des WebDAV-Kennworts damit nicht mehr, das wurde jetzt auf ein anderes Interface (Shared Memory) umgestellt, mit dem das entschlüsselte Kennwort nur noch im Hauptspeicher abgelegt wird, wo es sich andere Komponenten dann abholen können.

Das SharedMemory-Interface zwischen AVM-Komponenten und davfs2 gibt es schon länger, zu finden ist es in den GPL-Paketen von AVM in GPL-davfs2.tar.gz - die Version für den aktuellen Labor-Zweig steht natürlich noch nicht zur Verfügung. Somit muß man noch etwas warten, bis auch diese Quellen verfügbar sind ... es betrifft im Moment ja "nur" den aktuellen 7490-Laborzweig.

Am Ende stellt sich mir die Frage, ob es tatsächlich lohnt, sich erneut auf dieses Interface zu stürzen ... das sind ja alles nur Hilfsmittel.

Auf der anderen Seite sehe ich schon eine Notwendigkeit, die in der AVM-Firmware vorgenommenen Einstellungen auch mal im Klartext zu kontrollieren und/oder zusätzlich für andere Pakete benutzen zu können. Es ist einfach nur vollkommen unnütz, wenn es am Ende zwei verschiedene Benutzerverwaltungen geben muß, nur weil man von der AVM-Seite weder die Sitzungsverwaltung (mangels Doku, das könnte man aber sicherlich forensisch lösen) benutzen kann noch auf die Benutzer samt Kennwort für eine eigene Verwaltung zurückgreifen kann. Und die Benutzerverwaltung ist ja nur ein einzelnes Beispiel, das geht mit Mail weiter und hört bei VPN nicht auf.

Ich habe prinzipiell auch nichts gegen eine "second line of defense", wo man die Angriffsfläche in einem Standard-Image so weit wie möglich reduziert, das begrüße ich sogar. Aber gleichzeitig muß es dann eben auch für solche Projekte wie Freetz die Möglichkeit geben, auf definierte Schnittstellen zuzugreifen und die "abgeschafften Funktionen" wieder mit Leben zu erfüllen. Das erfolgt dann ja durch den Benutzer/Besitzer selbst und auf seinen ausdrücklichen Wunsch hin - nur so bleibt er am Ende tatsächlich "Besitzer" der Box (das ist ähnlich wie mit den Traktoren in den USA).

Übrig bleibt für mich die Frage, ob man nicht auch hier lieber ein Ende mit Schrecken herbeiführt und die AVM-Verschlüsselung tatsächlich komplett nachbaut, anstatt immer nur auf Fehler seitens AVM zu setzen oder irgendwelche Schwachstellen auszunutzen. Wenn AVM nicht mehr möchte, daß jemand die von ihnen verschlüsselten Daten auch wieder entschlüsseln kann, mit Ausnahme ihrer eigenen Komponenten, dann wird sich immer wieder ein Weg finden, fremde Zugriffe zu behindern und auszusperren.

Da auf der anderen Seite wohl eher nicht mit einer dokumentierten Schnittstelle zu rechnen ist, wo dann - nach Entscheidung des Besitzers der Box für ein anderes "Krypto-Plugin" - mit einem einheitlichen Zugriff für alle Komponenten gearbeitet werden kann, treibt mich die Überlegung um, ob es den (anzunehmenden) Ärger mit AVM nun wert ist oder nicht bzw. ob es "moralisch" vertretbar ist oder nicht, die AVM-Verschlüsselung praktisch offenzulegen.

Da wird es viele Meinungen pro und contra geben ... mein Standpunkt ist klar und ich halte die "bad guys" grundsätzlich nicht für dümmer als andere, nur für gewissenloser.

Somit vergibt man sich m.E. nur die eigene Chance auf Übersichtlichkeit durch gemeinsame Nutzung von Daten (und ggf. auch Transparenz bei einigen Einstellungen) zugunsten einer Verschleierung, die die wirklichen Angreifer trotzdem nicht davon abhalten wird, den AVM-Mechanismus zu benutzen (und sei es durch die lizenzwidrige Nutzung einer früheren Version von allcfgconv oder sogar einer alten Box nur für das Decodieren solcher Daten).

Was AVM am Ende damit erreichen will, ist mir ohnehin nicht klar ... ich kann es mir nur so erklären, daß nach der Benutzung von "allcfgconv -c" bei den Angriffen Anfang 2014 die pure Panik ausgebrochen ist, ohne daß man mal tatsächlich eine Gefahrenanalyse gemacht hat und aus dieser Panik heraus die Entscheidung getroffen wurde: "Das allcfgconv darf kein -c mehr machen.". Der Witz daran ist aber leider, daß es einen Angreifer nicht wirklich behindert. Warum ist das so?

Wenn ein Angreifer die Daten nicht direkt auf der Box entschlüsseln kann, nimmt er sie eben als Dump des TFFS (es reicht eine Partition), da stehen einerseits die Konfigurationsdaten drin und andererseits auch gleich noch die notwendigen Angaben aus dem Urlader-Environment, um die Daten auch auf einer anderen Box zu entschlüsseln.

Mit einem einzigen solchen Dump hat er also - zugegebenermaßen erst nach Nachbearbeitung, die aber definitiv nicht manuell erfolgen muß - genau dieselben Daten wieder in der Hand, die er nach einem "allcfgconv -c" hatte, ja sogar noch mehr, da ein einzelner Aufruf von allcfgconv ja nur eine Datei verarbeiten kann.

Das ist also einfach nur Stuss als Lösung ... da hat AVM nicht bis zum Ende mitgedacht und ist in einen für mein Empfinden blinden Aktionismus verfallen, der zwar die offensichtlichen und altbekannten Möglichkeiten verbaut, aber keinen ernsthaften Angreifer abhalten kann.

Ganz im Gegenteil ... bei meiner 7490 erzeugt ein regulärer Export aller Daten im TFFS (soweit sie in einem Export-File auftauchen) eine Datei mit einer Größe von 566500 Byte im Textformat. Das TFFS speichert hingegen die Daten von Beginn an komprimiert und benötigt damit für die Speicherung derselben Daten (sogar mehr, denn das Urlader-Environment ist da auch noch drin, außerdem jede Menge unbenutzter Platz im Regelfall) nur max. 384 KB (384 * 1024 = 393216), denn größer ist eine der beiden - alternativ beschriebenen - Partitionen nun einmal nicht bei einer 7490.

Am Ende hat ein Angreifer mit einem einfachen "cat /dev/mtd7" (oder mtd8) also sogar mehr Informationen mit einem geringeren Platzbedarf, als wenn er sich tatsächlich mühsam mit "allcfgconv" die Daten zusammensucht. Letzten Endes zeigt die von den Angreifern Anfang 2014 verwendete Methode eigentlich auch nur, daß eben viele Wege nach Rom führen. Sogar mit einem Aufruf von "tr069fwupdate configexport meinpasswort" hätten sie sich jederzeit einen kompletten Dump der Einstellungen machen lassen können (hier wieder in Textform, das ist das Kommando, mit dem auch ein Export der Einstellungen für den Provider über TR-069 erzeugt wird, das ist genau dasselbe Format, das auch beim GUI-Export erzeugt wird), obendrein noch mit einem definierten Kennwort verschlüsselt und somit problemlos dazu geeignet, mit "cfgtakeover" auch in einer vollkommen anderen Box entschlüsselt zu werden.

Bleibt also die Frage, ob AVM diese Möglichkeiten auch noch "entsorgen" will oder ob es nicht vielleicht doch besser ist, die "first line of defense" besser im Auge zu behalten und den Zugriff auf die FRITZ!Box durch unautorisierte Fremde wirksam(er) zu verhindern.

Man kann natürlich auch annehmen (würde man AVM damit Unrecht tun?), daß am Ende nur die Kunden behindert werden sollen, wenn sie sich bei per TR-069 konfigurierten Boxen ("Zwangsrouter" lassen grüßen) auf die Suche nach den korrekten Credentials machen wollen. Ob das nicht im Widerspruch zur Forderung nach "freier Routerwahl" (und der damit zwangsläufigen Offenlegung solcher Daten schon durch den Provider) steht - die von AVM meines Wissens ja vehement mitgetragen wird -, mag ich wieder nicht alleine beurteilen.

 

[krda79]

Da hier niemand was zu sagt, muss ich mal meinen Senf als zukünftig Betroffener dazu abgeben (bin Nutzer von Freetz mit Callmonitor).

Die Verschlüsselung von Zugangsdaten in solchen Geräten, die autark arbeiten, kann immer nur "Security by Obscurity" sein. Das Gerät muss ja autonom Zugriff auf die Zugangsdaten im Klartext haben, um sie an Dritte zur Authentifizierung zu übermitteln. Etwas anderes sind die Passwörter der eigenen Benutzer. Diese könnten als Hashwert und damit nicht entschlüsselbar gespeichert werden. Die Fritzbox verwendet aber ein Challenge-Response-Verfahren bei der Benutzeranmeldung, wobei das Passwort nicht im Klartext zwischen Fritzbox und Webbrowser ausgetauscht wird. Für dieses Verfahren ist es AFAIK notwendig, dass die Fritzbox das Passwort im Klartext kennt.

Bleibt die Frage, welchen tatsächlichen Sicherheitsverlust hat man, wenn die Obscurity durch Offenlegung der AVM-Verschlüsselung auf Null reduziert wird? Die "Security by Obscurity" ist ja kein unüberwindbares Hindernis, sondern erhöht nur Aufwand für einen Angreifer.
Solange allcfgconv oder webdavcfginfo aus alten Firmwareversion in den neueren Firmwareversionen funktionieren und Klartextzugangsdaten ausgeben, ist es für einen Angreifer ein Klax diese auch einzusetzen. Ein Angreifer, der irgendwie eine Sicherheitslücke ausnutzt oder sonstwie einen Shellzugang auf die Box bekommt, wird sich nicht an Lizenzbedingungen stören. Da ist der Dump von /dev/mtd7, wie du ihn beschreibst, vielleicht etwas einfacher. Aber ein riesiger Aufwandsunterschied zwischen den beiden Varianten eines Angriffs besteht IMHO nicht.

Wenn das alte allcfgconv in den neuen Firmwareversionen nicht mehr funktioniert, müsste ein Angreifer den Aufwand betreiben, die AVM-Verschlüsselung zu analysieren, um den Dump von /dev/mtd7 entschlüsseln zu können. Das erfordert ein "klein wenig" Knowhow (siehe http://www.ip-phone-forum.de/showthread.php?t=273569& ). Letztendlich reduziert die Offenlegung der AVM-Verschlüsselung nur die Einstiegsschwelle für Skript-Kiddies.

Nichtsdestotrotz reden wir immer von einer "second line of defense". Ohne irgendeine Art von Shellzugang nützt auch einem potentiellen Angreifer die Offenlegung nichts.

Bei Android z.B. ist die Lage eigentlich ähnlich. Hier ist das WLAN-Passwort auch im Smartphone gespeichert (sogar direkt im Klartext ohne weitere Verschlüsselung). Nur komme ich als normaler Nutzer ohne Rootzugriff da nicht ran. Sobald ich durch eine Sicherheitlücke Rootzugriff erlangen kann (und das Rooting von Android-Geräten basiert meistens auf einer Sicherheitslücke), kann ich auch z.B. die WLAN-Passwörter im Klartext auslesen (beim Rooting über die offiziellen Wege nicht, da damit der Gerätespeicher zuerst gelöscht wird).

Neben dem Nutzen für die Angreifer sehe ich für die Offenlegung der AVM-Verschlüsselung zwei "legale" Anwendungsfälle:
1. Das Auslesen von (verlorengegangenen) Zugangsdaten.
2. Zugriff auf AVM-interne Dienste durch Freetz-Pakete wie Callmonitor.

Für letzteres hätte ich noch einen Alternativvorschlag: Könnte man nicht auch das Benutzerpasswort neben dem Benutzernamen für z.B. Callmonitor im Freetz-Webinterface abfragen und hinterlegen? Das reduziert eigentlich nicht das Sicherheitsniveau und ist für den Anwender auch keine riesige Hürde. Das Freetz-Webinterface sollte keine Möglichkeit bieten das Benutzerpasswort auszulesen, sondern nur dieses zu setzen. Dann gilt bzgl. des Sicherheitsniveaus die gleiche Argument wie für die Offenlegung der AVM-Verschlüsselung. Es ist wahrscheinlich nur einfacher und ohne großen Aufschrei realisierbar.

Nur Anwendungsfall 1 ist damit noch nicht abgedeckt :-(

 

[PeterPawn]

Für letzteres hätte ich noch einen Alternativvorschlag: Könnte man nicht auch das Benutzerpasswort neben dem Benutzernamen für z.B. Callmonitor im Freetz-Webinterface abfragen und hinterlegen?

Bis hierher stimme ich Dir natürlich fast vorbehaltlos zu, denn das sehe ich weitgehend genauso. Ich hatte ja mehr auf "Gegenwind" gehofft, der vielleicht noch nicht berücksichtigte Gesichtspunkte in die Diskussion einbringen würde. Trotzdem danke ich Dir natürlich für die Mühe des Schreibens, so sind wir ja schon mal zu zweit.

Aber den Alternativvorschlag kann ich nicht so richtig nachvollziehen ... wenn Du da die Credentials in der Freetz-Oberfläche noch einmal eingegeben hast, gehst Du doch sicherlich davon aus, daß der Callmonitor diese Daten auch nach weiteren Neustarts immer noch zur Verfügung hat, oder?

Dann muß er sie aber auch irgendwo persistent ablegen und auch das dann wieder in einer Form, die ihm das Lesen dieser Daten auch ohne Eingriff des Benutzers ermöglicht. Macht er das im Klartext (also die Ablage), ist es ein zusätzliches Sicherheitsrisiko, denn es können ja auch andere Komponenten dann auslesen. Macht er das mit irgendeiner Verschlüsselung, kann man auch gleich wieder auf die von AVM zurückgreifen. Die hat zwar einige planerische Defizite, z.B. die Tatsache, daß alles auf dieselbe Art und Weise verschlüsselt wird, also auch Daten, die man im Klartext per Kommando aus der Firmware auslesen kann und damit ein Angriff durch das "Vertauschen" von Chiffraten möglich ist. Aber andererseits würde ich sogar vermuten, daß sich der Autor dieses Codes der Einschränkungen durchaus klar gewesen sein dürfte und nur jemand anderes aus Kostengründen (sowas haben wir doch schon, brauchen wir nicht noch einmal, nehmen wir für alles) diesen Fauxpas "organisiert" hat. Denn eigentlich ist das schon ziemlich gut durchdacht ... wenn auch manchmal weit weg von Standards (das fängt beim Base32-Zeichenvorrat an). Leider habe ich nicht wirklich herausfinden können, wie weit in der Vergangenheit diese Verschlüsselung mal eingeführt wurde.

Mich reizt es ja eigentlich, das Zertifikat der Box samt privatem Schlüssel auch für Freetz-Pakete nachzunutzen, z.B. für den Apache, Dropbear (nach Konvertierung bzw. Extrahieren des Keys) oder auch für ShellInABox (da ist das fast Pflicht, wenn man keinen Herzkasper bei seinem Browser riskieren will). Das könnte man dann (mit passendem OpenSSL-Binary, wobei das auch ziemlich aufträgt) sogar mit diesem privaten Schlüssel weitere Daten auf der Box verschlüsseln. Es ist auch hier wieder kein großes Geheimnis (keine 20 Zeilen C-Code), mit welchem Kennwort der private Schlüssel der Box gesichert ist (was ihn gegen einen einfachen Dump der TFFS-Partition immunisiert) ... auch wenn sich AVM redlich müht, das dafür verwendbare Programm (wenn man nicht gleich auch die intern verwendete Funktion losgehen will) mit dem "unklaren" Namen "getprivkeypass" so weit zu verkomplizieren, daß ein "normaler" Aufruf nur Bullshit produziert. Aber auch das hält einen ernsthaften Angreifer eben nicht ab ... wieder nur die "Skript-Kiddies" und das ist - nach meiner Meinung - eine aussterbende Spezies. Heute erfolgen Angriffe in der Regel in aller Stille und ohne Krawall, weil ein argwöhnisches Opfer wesentlich schlechter zu übertölpeln ist.

 

[krda79]

Dann muß er sie aber auch irgendwo persistent ablegen und auch das dann wieder in einer Form, die ihm das Lesen dieser Daten auch ohne Eingriff des Benutzers ermöglicht. Macht er das im Klartext (also die Ablage), ist es ein zusätzliches Sicherheitsrisiko, denn es können ja auch andere Komponenten dann auslesen.

Klar muss dieses Benutzerpasswort irgendwo im nichtflüchtigen Dateisystem abgelegt werden (als Klartext). Klar können auch andere Komponenten dieses auslesen. Aber genauso können alle Komponenten jetzt schon /dev/mtd7 auslesen. Dass das Entschlüsseln letzteres nur ein Hindernis für Skript-Kiddies ist, waren wir uns ja schon einig. Deswegen hoffe ich, dass es in den AVM- und Freetz-Komponenten keine Sicherheitslücke gibt, die den Zugriff auf /dev/mtd7 und andere kritische Dateien (wie evtl. das eben diskutierte Benutzerpasswort) erlauben. Deshalb ist es aus meiner Sicht kein riesiges erhöhtes Sicherheitsriskio dieses Benutzerpasswort im Klartext abzulegen. Außerdem könnte man diesem Benutzer in der Fritzbox nur eingeschränkte Rechte geben, so dass kein Zugriff auf die gesamte Konfiguration darüber möglich ist.

Es ist auch hier wieder kein großes Geheimnis (keine 20 Zeilen C-Code), mit welchem Kennwort der private Schlüssel der Box gesichert ist (was ihn gegen einen einfachen Dump der TFFS-Partition immunisiert)

Diesen Satz verstehe ich noch nicht. Was benötigt man außer dem Dump der TFFS-Partition noch?

Tschüss,
Daniel

 

[PeterPawn]

Klar können auch andere Komponenten dieses auslesen.

Ok, dann ist aber immer noch die "natürliche Speicherung" mit AVM-Verschlüsselung und nicht im Klartext die sicherere Variante. Das wäre zwar ein Argument für das "Ausnutzen" der AVM-Verschlüsselung (und in der Folge für das Implementieren einer Lösung, die sich nicht auf "mißbrauchte" AVM-Komponenten stützen muß), aber eine zusätzliche Speicherung im Klartext erhöht schon die Gefahr "zufälliger" Funde (das geht beim Export-File los, je nachdem, wo und wie man das Kennwort zusätzlich ablegt).

Aber genauso können alle Komponenten jetzt schon /dev/mtd7 auslesen.

Das ist zwar wahr - wegen des fehlenden Rechtekonzepts der FRITZ!Box - aber es ist wenigstens noch mit Aufwand verbunden, die Daten aus einer TFFS-Partition zu extrahieren. Und da meine ich jetzt nicht nur den intellektuellen Aufwand für einen Angreifer, selbst eine entsprechende Software zu programmieren - die Quellen für das TFFS stehen zur Verfügung und auch AVM nutzt das offenbar (in Abwandlungen) sogar unter Windows, um im Recovery-Programm ein passendes Abbild des TFFS für die zu bearbeitende Box "on the fly" mit den richtigen Werten aus dem Urlader-Environment zu versehen.

Ein solches "Klartext-Passwort" könnte man höchstens dadurch ein ganz klein wenig sicherer machen, indem man es von den anderen Einstellungen separiert und es eben nicht im TFFS ablegt. Das setzt dann einen anderen persistenten Speicher voraus, z.B. einen USB-Stick.

Deshalb ist es aus meiner Sicht kein riesiges erhöhtes Sicherheitsriskio dieses Benutzerpasswort im Klartext abzulegen.

Riesig sicherlich nicht ... aber auch unnötig. Wenn AVM das ohnehin schon speichert, kann man eben auch darauf zurückgreifen und muß/soll keine eigene zusätzliche Lösung implementieren, solange diese nicht andere Probleme der AVM-Lösung beseitigt, weil sie schlicht besser ist.

Diesen Satz verstehe ich noch nicht. Was benötigt man außer dem Dump der TFFS-Partition noch?

Das weiß ich nicht einmal genau ... wie von AVM in der Funktion "securestore_get" in der libboxlib.so das Kennwort für den privaten Schlüssel (/var/flash/websrv_ssl_key.pem) gebildet wird, spielt auch keine entscheidende Rolle, wenn man das nachnutzen will. Wahrscheinlich wird auch diese Berechnung auf den Daten aus dem Urlader-Environment basieren ... aber das ist ohne genaue Analyse der genannten Funktion nicht zu ermitteln und solange man sie nur nutzen will (oder sogar nur AVM-Komponenten, die darauf zugreifen, wie das erwähnte getprivkeypass), ist das auch uninteressant.

Ansonsten ist eben der private Schlüssel noch einmal mit diesem Kennwort verschlüsselt, so daß ein einfaches "cat /var/flash/websrv_ssl_key.pem" noch nicht zu einem erfolgreichen "Angriff" ausreicht. Das meinte ich mit dem "Schutz" gegen einfaches Dumpen des TFFS - ohne die Berechnung des korrekten Kennworts (bei meiner alten 6360 war das z.B. "uJyDQJK9") nutzt das nichts. Das wird zwar mit einiger Wahrscheinlichkeit auch bloß eine ASCII-Darstellung irgendeines Hash-Wertes über boxspezifische Einstellungen sein (das kann sich jeder mit ein wenig Phantasie ja selbst ausmalen, welche Möglichkeiten AVM da nur bleiben), aber das muß ein Angreifer außerhalb der ursprünglichen Box dann auch erst einmal "nachbauen" (wenn er nicht gleich das komplette Urlader-Environment ersetzt, an anderen Stellen ist das Speichern von dauerhaften Werten ja eher schwer bis unmöglich).

Ich will hier ja auch das Für und Wider diskutieren, daß sich aus der Frage ergibt, ob man die AVM-Funktionen nachnutzen will oder auf eigene Entwicklungen setzen sollte. Der entscheidende Punkt z.B. bei der Benutzerverwaltung (auch i.V.m. dem heutigen Freetz-Stand) ist es in meinen Augen, daß die Verwaltung von unterschiedlichen Konten und Rechten bei AVM erst spät Einzug gehalten hat und da gab es den "Freetz-Admin" schon. Theoretisch wäre es heute sogar denkbar, die Freetz-Anmeldung (bzw. Berechtigungsprüfung) so umzuschreiben, daß sie die AVM-Konten verwendet und nur Benutzer mit "Adminrechten" akzeptiert, das geht auch über "Schnittstellen" von AVM. Dann hat man eine gemeinsame Benutzerverwaltung (gegen die von AVM ist erst mal nicht so sehr viel einzuwenden) und damit auch nur eine potentielle Stelle für einen Angriff - d.h. man muß nicht zwei Stellen gleichzeitig sichern, aber der Schaden ist eben auch komplett, wenn ein Angriff erfolgreich sein sollte.

 

[PeterPawn]

Dieser Thread war mir schon komplett entfallen ... es gab ja keine Gegenargumente und inzwischen gibt es dann auch den passenden Thread zum Hintergrund der Verschlüsselung (ich habe mir halt etwas Zeit gelassen) und auch für das "Geräte-Kennwort" für die Datei mit dem privaten Schlüssel (das war das mit "privatekeypassword" gelesene) habe ich zumindest schon mal die "Ausgangsdaten" präzisiert im entsprechenden Repository.

Damit hat sich aber auch die Diskussion (zumindest in Bezug auf "Contra") erledigt und hier könnte eigentlich zugemacht werden.