[Info] Kennwörter aus der FRITZ!Box-Konfiguration auslesen für Firmware ab 06.10

EDIT: 01.06.2017
Ich habe eine neue Version in einem GitHub-Repository veröffentlicht, die zwar ein OpenSSL-CLI-Programm benötigt (was praktisch auf jeder Linux-Installation vorhanden sein sollte), aber nicht mehr auf irgendwelche speziellen AVM-Dateien angewiesen ist.

EDIT: 12.05.2016
Es gibt in diesem Thread weiter hinten einen Beitrag, der u.a. auch beschreibt, wie man an das benötigte Programm zum Entschlüsseln der AVM-Kennwörter gelangen kann, wenn man das ältere "webdavcfginfo" (und damit das hier beschriebene "decode_passwords") benutzen möchte. Allerdings steht man dann wieder vor dem Problem, die passende ältere Firmware-Version von AVM zu besorgen.

Generell könnte man meiner Meinung nach die Unterscheidung zwischen der Suche nach einem alten "allcfgconv"-Binary und einer passenden Version von "webdavcfginfo" daran festmachen, ob man es zum einmaligen Gebrauch oder zum wiederholten - auch programmgesteuerten - Zugriff auf verschlüsselte Daten in der FRITZ!Box benötigt. Für den ersten Fall sind die Vorbereitungsarbeiten weniger umfangreich, dafür braucht es "speziellere" Firmware-Versionen, während ansonsten etwas mehr Vorbereitung erforderlich ist, aber die mögliche Auswahl an Firmware-Versionen als Quelle für das AVM-Programm größer ist und nach den einmalig auszuführenden Vorbereitungsarbeiten ist der Aufwand für das Entschlüsseln dann sogar wieder geringer (und vermutlich lizenzrechtlich nicht zu beanstanden) als bei der Variante mit der Extraktion von "allcfgconv".

EDIT: 20.04.2016
Da ich immer noch Zugriffe für diese Datei auf "yourfritz.de" registriere, habe ich den nächsten Teil mal deutlich in abweichender Farbe hervorgehoben ... es gibt auf yourfritz.de nichts mehr zu "decode_passwords" (mit kleinen, aber unbedeutenden Abstrichen), das ist alles nur noch über GitHub zu erreichen.

Auch wenn es aus dem FRITZ!OS heraus m.W. derzeit keine Möglichkeit gibt, Inhalte von dort direkt zu laden (das wget-Applet der AVM-Firmware kennt kein HTTPS und das AVM-eigene httpsdl kommt nach meinen Tests nicht damit klar, daß da mehrfache Redirections erfolgen beim Versuch eines Downloads), ist das bei diesem Programm für mich kein Grund, es noch einmal gesondert (und über eine ungesicherte Verbindung) als Archiv-Datei (tgz) bereitzustellen.

Man kann es problemlos aus dem GitHub-Repo laden und auf einen USB-Stick übertragen, den man dann an die FRITZ!Box steckt (oder man speichert es gleich auf einem Stick an der Box - über NAS-Zugriff) oder man lädt die Textversion von yourfritz.de (und da endet die URL nicht auf einen Slash).
EDIT 11.02.2016:
Das Skript ist von meinem Server umgezogen in Richtung GitHub, es ist jetzt unter https://github.com/PeterPawn/YourFritz/tree/master/decode_passwords zu finden. Als Archiv-Datei gibt es das Skript jetzt gar nicht mehr.

Der neue Download-Link wäre dann

https://github.com/PeterPawn/decode_passwords/blob/v0.1_freeze/decode_passwords

für die bisher als Textform verfügbare Version.

Da die FRITZ!Box keinen direkten Download von dieser URL erlaubt (das wget der Busybox kennt keinen "https"-Präfix und mit dem AVM-Programm "httpsdl" klappt das irgendwie auch nicht so richtig - warum das so ist, will ich jetzt nicht erkunden), werde ich die Textform weiterhin über meinen Server unter der URL http://yourfritz.de/decode_passwords/0.1/decode_passwords zugänglich machen. Die Kommandofolge sieht dann - in ihrer einfachsten Form - also so aus:

Code:

cd /var
wget -q http://yourfritz.de/decode_passwords/0.1/decode_passwords
sh /var/decode_passwords < /var/flash/vpn.cfg

Es gibt eine etwas geänderte neue Version, die u.a. der Tatsache Rechnung tragen soll, daß AVM die Funktion von "webdavcfginfo" in Firmware ab 06.25 geändert hat. Die Änderungen gegenüber der Version 0.1 sind in #36 beschrieben, die Version ist ebenfalls über GitHub verfügbar und der Download-Link über den yourfritz.de-Server wäre dann: http://yourfritz.de/decode_passwords/0.2/decode_passwords

---

-EDIT: Beginnend mit dem Labor-Zweig 06.25 für die 7490 hat AVM das Decodieren der WebDAV-Credentials auf ein anderes Interface umgestellt (Shared-Memory), über Sinn und Unsinn würde ich gerne hier weiter diskutieren. Damit gilt aber: Die hier vorgestellte Lösung funktioniert - vermutlich, noch ist das ja nicht offiziell erschienen - ab der ersten Release-Version nach 06.24 nicht mehr in dieser Form.

Mir ist es auch erst jetzt aufgefallen, daß ich die Verwendung von "decode_passwords" tatsächlich noch nie richtig (meint: an einer einzigen Stelle im IPPF) beschrieben habe.

EDIT: Das Skript ist unter dem Namen "decrypt-fritzos-cfg" ab CS 12914 auch Bestandteil des Freetz-Trunks. Die Bedienung hat sich m.W. nicht verändert, es fällt nur der Download und das Entpacken ggf. weg. Dann noch den Namen entsprechend "substituiert" in einem Freetz-Image und die folgenden Zeilen gelten auch dort.

Das Umbenennen der Version von meinem Server werde ich nicht in Angriff nehmen ... bei einem Nicht-Freetz-Image und dem Download gilt also weiterhin der Name "decode_passwords".

Das Skript selbst kann man auf zwei möglichen Wegen laden (wenn es nicht - s.o. - im eigenen Freetz-Image ohnehin enthalten ist):

- aus dem Freetz-Ticket #2558 unter der URL: http://freetz.org/raw-attachment/ticket/2558/decode_passwords.tar.2.gz (der bessere Weg, aber kein Einzeiler)

- von einem meiner eigenen Server (yourfritz.de) unter der URL: http://yourfritz.de/decode_passwords (gepackt unter http://yourfritz.de/decode_passwords.tgz, keine Unterverzeichnisse im Archiv, nur zwei Shell-Files und 4 Dateien mit Hash-Werten für die beiden) siehe "EDIT" vom 11.02.2016 weiter oben, die URL hat sich geändert

Für das Entschlüsseln der Kennwörter wird ein kleines Tool von AVM namens "webdavcfginfo" verwendet oder auch "mißbraucht", wenn das aus irgendeinem Grund nicht in der Firmware enthalten ist (der "Remove WebDAV"-Patch von Freetz entfernt es z.B. im Moment nochin Freetz geändert inzwischen), wird auch das Skript nicht funktionieren.
Im Kopf der Datei ist ein Block aus Shell-Kommentarzeilen enthalten, der einige Informationen zur Verwendung enthält, das Lesen kann eigentlich nicht schaden.

Download und Entpacken des Skripts aus dem Trac erfolgt dann z.B. mit
Das ganze geht - wenn man nicht lesen will - auch als Einzeiler bei der Benutzung der Version aus Trac:
Bevor ich einige Beispiele für die Verwendung gebe, noch Download/Entpacken/Einzeiler für yourfritz.de:
Das wäre die Version für das gepackte Archiv, es geht natürlich noch kürzer, wenn man gleich das Text-File lädt. Da auch ich nicht vor einem gehackten Server gefeit bin, warne ich jedoch noch einmal mit Nachdruck vor der Ausführung von ungeprüftem Shell-Code auf diese Art und Weise. Die bessere Lösung ist in jedem Fall der Download, die Prüfung und dann eine lokale Speicherung, dann braucht man nur noch Angreifer und Modifikationen im eigenen Netz befürchten und mein Server (oder auch Freetz-Trac) ist aus dem Spiel. Aber ich verstehe auch, daß nicht jeder den Code selbst prüfen will und manchmal wirklich nur die Credentials ausgelesen werden müssen, weil der Brief mit den DSL-Zugangsdaten vom Hund gefressen wurde und man die Daten unbedingt für einen anderen Router benötigt. Selbst da kann aber die Aufteilung des gesamtem Vorgangs in - Download/Auspacken, Internet-Verbindung trennen, Skript aufrufen - eine zusätzliche sinnvolle Vorsichtsmaßnahme sein. Da es sich um Shell-Code handelt und jeder selbst einen Blick hineinwerfen kann, machen die von mir dazu gepackten Dateien mit Hash-Werten für die beiden Shell-Files im Archiv auch nur bedingt Sinn, da ich die nirgendwo für einen Vergleich veröffentlicht habe. So, genug der Warnungen ... wenden wir uns wieder dem "direkten Aufruf aus dem Internet" zu:
EDIT: Dieser direkte Aufruf funktioniert mit der aktuellen Version tatsächlich wieder richtig (s. frühere Probleme ab #3 bis #9) , solange die Datei von yourfritz.de geladen wird (die Trac-Version kann ich nur bedingt beeinflussen), auch die Version in Freetz ist entsprechend angepaßt worden. (Hintergrund der "3" in der Zeile: Es wird nun erst einmal getestet, ob die Eingabe auf dem Filedescriptor 3 "angeboten" wird, bevor das "cat"-Kommando fälschlicherweise den Rest des Skripts in die Zwischendatei kopiert, was unweigerlich stattfindet, wenn die Shell mit "stdin=Skript-Datei" aufgerufen wird und somit nicht erst die Abarbeitung des Skript-Codes diesen Descriptor öffnet, sondern schon die Shell selbst. Unter den Bedingungen der Busybox-Shell ist die Reihenfolge des Öffnens von Files offenbar etwas abweichend gelöst - der "Umweg" über FD 3 (und nur ein zusätzliches Zeichen beim Aufruf ) löst das Problem auch dann zuverlässig, wenn die direkte Angabe von /proc/self/fd/0 als "Skript-File" beim Aufruf der Shell nicht dazu führt, daß anstelle von stdin die angegebene Datei als Quelle der auszuführenden Kommandos verwendet wird).

Wer das Problem der Entschlüsselung nicht nur spontan hat, sondern damit eigene Sachen schreiben will, der speichert das komplette 'decode_passwords' ohnehin besser irgendwo auf seiner Box (notfalls auf USB, wenn die keinen NAND-Flash hat) und kann es dann auch ohne Internet-Verbindung jederzeit benutzen. Ich habe es auf Boxen ohne NAND sogar ins NOR-Flash geschrieben unter einer unbenutzten Minor-ID (die 97 ist i.d.R. frei, wenn man nicht selbst damit hantiert), allerdings die wirklich schlanke Version, zu der wir später noch kommen.

Den Teil input_file_name muß man in allen oben gezeigten Kommandofolgen dann natürlich durch die zu dekodierende Datei ersetzen, z.B. /var/flash/voip.cfg für die SIP-Accounts.

Oder auch durch eine passende Shell-Maske wie "/var/flash/*.cfg"; wenn man sich nicht daran stört, daß dabei auch eine kleine binäre Datei (aha.cfg) mit verarbeitet wird, sähe das dann z.B. so aus:
Das gibt dann wirklich alle Konfigurationsdateien mit potentiell verschlüsselten Einstellungen in Textform auf der Konsole aus, was i.d.R. eher unpraktisch sein dürfte und z.B. so
auch in einer Datei mit dem Namen "passwords.txt" auf dem ersten gemounteten USB-Volume (oder als /var/passwords.txt, wenn kein USB-Volume vorhanden ist) gespeichert werden kann für eine spätere Durchsicht.

Ab jetzt nehmen wir mal die Speicherung der Shell-Datei an einer Stelle an, wo sie durch bloße Eingabe des Namens gefunden werden kann (als 'decode_passwords') und auch das "ausführbar" als Dateiattribut soll ab jetzt vorhanden sein. Wenn das nicht der Fall ist, muß man sich eben immer den kompletten Pfad zur Datei da hindenken und ggf. den expliziten Aufruf per "sh".

Da das Skript nur den Teil seiner Standardeingabe, der vom Aufbau her einem verschlüsselten Wert bei AVM entspricht, Wert für Wert dekodiert, kann man sich das Leben auch leichter machen (und die Wartezeit bei der Ausführung verkürzen), wenn man gezielt nur die Werte dekodieren läßt, die einen wirklich interessieren. Dafür gibt es bei AVM ja Tools, die gezielt einzelne Einstellungen aus einer Konfigurationsdatei auslesen können. Die dabei erhaltenen verschlüsselten Daten kann man dann einfach einzeln an 'decode_passwords' verfüttern:
entschlüsselt z.B. nur das einzelne E-Mail-Kennwort für den Versand der Push-Nachrichten. Das ist natürlich weniger etwas für die manuelle Ausführung, aber damit läßt sich eigentlich ganz passabel eigener Shell-Code schreiben. Wenn man z.B. wirklich die kompletten Einstellungen zum Mailversand aus der Box benötigt, kann man das - unter anderem, es gibt bei Shell-Code nicht nur eine Wahrheit - so machen:
Das kann man auch für DynDNS-Accounts und eigentlich jedes beliebige Datum in der AVM-Konfiguration ausführen, wenn einen ansonsten die Verschlüsselung davon abhalten würde. Die bei den AVM-Tools vorhandene Aufteilung in ar7cfgconv, wlancfgconv und usbcfgconv interessiert das Skript nicht, man kann ihm jede beliebige Datei auf stdin servieren. Wenn die Datei keine verschlüsselten Daten enthält, wird sie 1:1 wieder ausgegeben.

Was wäre noch zu sagen ... :gruebel:
Es gibt in der Archiv-Datei noch eine zweite Version (micro_decode), die auch im Kopf von 'decode_passwords' noch einmal enthalten ist. Sie stellt die kleinste - bisher(!) - gefundene Variante dar, die einen analogen Ablauf zu 'decode_passwords' realisiert. Was zuerst nur eine Fingerübung und pures Interesse war, wie weit man das treiben könnte, hat sich bei mir inzwischen zu einem ernsthaften Einsatzzweck entwickelt. Wenn eine FRITZ!Box keinen NAND-Flash hat und damit auch kein yaffs2-Filesystem unter /var/media/ftp einbindet, wo man eigene Dateien ablegen kann, kann man 'micro_decode' problemlos im NOR-Flash irgendwo unterbringen, denn es benötigt insgesamt nur 469 Byte. Damit ist es für mich klein genug, wenn man es mit einer Anrufliste mit 400 Einträgen vergleicht. Je nach Modell kann man das Skript auch unter /data (also im AB-Speicher) ablegen ... der Phantasie sind da nur wenige Grenzen gesetzt. Mit etwas Geschick kann man das tatsächlich noch durch ein 'gzip -9' jagen und es so auf 331 Byte verkleinern. Das ist so winzig, daß man u.U. schon Probleme kriegt, es wiederzufinden . Selbst auf einer Box mit NAND-Flash kann die zusätzliche Ablage im TFFS noch Sinn machen, denn anders als der NAND-Inhalt überlebt es dort bei passend gewählter Minor-ID ja auch ein Werksreset.
legt das Skript im TFFS ab und trägt nicht wirklich auf ... und ja, es bleibt bei einem Werksreset erhalten. Braucht man dann mal seine Dienste, läßt es sich mit
leicht wieder aufrufen. Der Aufruf mit '/proc/self/fd/0' sieht vielleicht auf den ersten Blick etwas wild aus, ich kenne aber (bei der Busybox-ash) keinen anderen Weg, einem per Pipe an 'sh' übergegebenen Shell-Skript wieder eine vernünftige Parameterliste zu übergeben und anders als 'decode_passwords', was Eingaben auf seiner Standardeingabe erwartet, macht 'micro_decode' ein 'cat $*' und verarbeitet damit den Inhalt jeder einzelnen Datei (das kann auch eine Liste sein oder das Ergebnis eines Shell-Patterns), die als Parameter angegeben wurde. Wobei ich selbst ohnehin die nicht noch einmal komprimierte Variante verwende und damit dann auch ein "sh /var/97 /var/flash/vpn.cfg" möglich ist, da man auf das zcat verzichten kann.

Der direkte Aufruf funktioniert mit der Umleitung eines Files natürlich so nicht, ich werde das oben korrigieren. Das war ein falsch angepaßtes micro_decode-Beispiel (am Ende von #1 steht zu Filehandles schon etwas). Da dort automatisch alle cfg-Files dekodiert werden, brauchte es keine Input-Redirection und funktionierte bei direktem Aufruf nach dem wget.

Wie es mit wget + Redirection trotzdem geht (/proc/self/fd) muß ich erst mal ausreichend testen, bevor ich oben ändere. Es kann natürlich nur eine Datei für "sh" als "stdin" verwendet werden, das muß in diesem Falle das Skript-File sein. Erst für dieses darf dann wieder "stdin" auf die Konfigurationsdatei umgeleitet werden.
EDIT 19.06.2015:
Ich habe das jetzt für die "große Version" so gelöst, daß fd3 vor fd0 genutzt wird, wenn er verfügbar ist und #1 entsprechend korrigiert.

@ezflashback:
Ich verstehe nicht so richtig, worauf die Frage hinauslaufen soll. Hier geht es darum, wie man die verschlüsselt gespeicherten Daten einer FRITZ!Box entschlüsseln kann. Wenn die FRITZ!Box irgendwelche Daten gar nicht gespeichert hat (wenn ich das richtig verstehe, ist bei Dir nur ein einzelner SIP-Account konfiguriert, woher diese Konfiguration stammt - ich vermute mal per Fernkonfiguration vom Provider - ist aber eigentlich auch unklar), dann kann man die logischerweise auch nicht entschlüsseln.

Was Du mit

ich habe jedoch ausm dump der 6641 drei nummern mit den jeweiligen passwörtern

Zum Vergrößern anklicken....

sagen willst bzw. was das mit dem Decodieren von Daten einer FRITZ!Box zu tun hat, verstehe ich schlicht nicht ... daher kann ich Dir da auch keine fundierte Antwort geben.

Wenn in der FRITZ!Box entsprechende SIP-Accounts konfiguriert sind, stehen die nach allen bisherigen Erkenntnissen auch in der voip.cfg der Box. Wenn da keine weiteren Accounts existieren, gibt es wohl auch keine weiteren Nummern. Die Möglichkeit, für einen SIP-Account mehrere "Telefonnummern" zu verwenden, habe ich in einer FRITZ!Box noch nie gesehen ... da dort in der Regel die Rufnummer Bestandteil der "SIP-Anmeldung" ist, wäre das auch nicht ohne weiteres möglich (obwohl technisch denk- und realisierbar, ein SIP-Benutzername muß nichts mit einer Rufnummer zu tun haben).

Ab Version 06.25 hat AVM auch bei 'webdavcfginfo' die Möglichkeit des Entschlüsselns der Daten gestrichen. Damit funktioniert das Script ab diesem Stand ebenfalls nicht mehr. Bleibt entweder gleich die Verwendung eines passenden allcfgconv-Binaries aus ganz alter Firmware oder das Ersetzen von webdavcfginfo durch eine Vorgängerversion, wenn man die zusätzliche Möglichkeit des Entschlüsselns einzelner Werte durch "decode_passwords" weiterhin verwenden will.

Ob und wie man (ich) ggf. eine eigene Entschlüsselung baut (baue), ist im Moment noch offen ...

wh17 schrieb:

Telnetzugang tut ja wohl nicht mehr mit 6.24:-(

Zum Vergrößern anklicken....

Woher kommt denn diese Information? Wenn da nicht O2 eine eigene Versionsnummer eingeführt hat, ist das schon mal Unsinn.

Viel spannender ist ja die Frage, wie eine 06.25 (das war eine "Beta"-Version) auf die Box gekommen sein soll.

Nein, das Ausführen der betreffenden AVM-Programme klappt (ohne zusätzlichen Riesenaufwand zur Emulation der richtigen Umgebung) auf einem Emulator (z.B. QEMU) nicht ... und solltest Du eine "native" Ausführung im Auge gehabt haben, wäre eine "Lesereise" durch das Internet unter dem Aspekt "Prozessorarchitekturen" eine gute Idee.

Ich habe eine virtuelle ubuntu Box für freetz und einen mac (unix).

Zum Vergrößern anklicken....

Das ist schön für Dich, wenn eines der beiden Systeme auch einen Browser haben sollte (allerdings geht auch ein beliebiges anderes Gerät), hilft das sicherlich bei der Suche nach den diversen Threads, in denen es um das Extrahieren einer alten "allcfgconv"-Datei aus einer älteren Firmware geht. Wobei Du alle Threads, in denen Dir ein Aufruf des Recovery-Programms empfohlen wird, damit Du aus der alten Version das notwendige Binary extrahieren kannst, schnell vergessen solltest ... so sehr viel komplizierter geht es eigentlich nicht mehr (wenn man ohnehin schon eine VM für Freetz hat), da wäre nur noch der Tipp, eine weitere Box für diesen Zweck zu kaufen, ein höherer (finanzieller) Aufwand.

Und bis zur 06.24 funktioniert sowohl das Entschlüsseln (mit webdavcfginfo) als auch der Telnet-Zugang ... also stimmt entweder etwas an den Basis-Informationen nicht (schon die Versionsfrage ist ja etwas unklar) oder Du hast etwas falsch gemacht. Wobei decode_passwords auf eine exportierte Datei ohnehin keine Anwendung finden kann ... das klappt nur mit den direkt kopierten Dateien aus einer Box und wenn "fbedit" der "FBEditor" sein sollte, dann ist diese Sicherung eine exportierte Datei und keine "boxinterne".

EDIT: Ehe meine fehlende "Kinderstube" wieder auffällt: Willkommen im Forum.

Endlich habe ich mal auf den Beitragszähler gesehen ... passiert mir sonst eher selten, ich mache die Leute sonst unabhängig von ihrem "Alter" runter ...