[Problem] WebUI Passwort vergessen FB7390 mit original FW

[KunterBunter]

Wenn ja, warum ist es nicht möglich, den relevanten Thread hier zu verlinken?

Natürlich ist das möglich: [Info] 17.2.2014 Hack gegen AVM-Router auch ohne Fernzugang

 

[cmonty14]

Sageinmal, Monty, hast du auch keinen ssh Zugriff auf die Box?
Ich mein, du hast doch freetz drauf.
Bist du erstmal im System, ists kinderleicht.

Nein nein... es handelt sich nicht um eine der FB, die in meiner Signatur aufgeführt sind.
Wie ich bereits ganz am Anfang erwähnte, läuft die FB mit der original Firmware (keine Modifikation mit Freetz o.ä.).

 

[eisbaerin]

Frag mal Herrn Snowden, der müßte wissen wie das geht.

 

[SF1975]

Hallo,
Sei nicht böse, aber warum soll man hier Tipps geben, wie man eine Box "knackt"?? Vor allen Dingen (nicht persönlich), wenn man Dich nicht kennt und nicht sicher gehen kann, das Du Deine eigene Box "hacken" willst.

Was spricht gegen Recover und händische Neuinstallation?

 

[PeterPawn]

Natürlich ist das möglich: [Info] 17.2.2014 Hack gegen AVM-Router auch ohne Fernzugang

http://www.heise.de/artikel-archiv/ct/2014/13/174_CSI-Fritzbox

dürfte der richtige Link sein. Die 1,50 € für die Paywall muß er dann eben investieren ... wenn er kein Abonnent ist.

Die Diskussion und Analyse dieser Lücke wurde auch hier im Forum ausgiebig geführt, bis hin zur ins Auge springenden Antwort.

Auf wenn "Urgestein" ein gewisses Gewicht hat, wäre mir eine "offizielle" Antwort einfach lieber ... Du müßtest nach meiner PM-Historie doch wissen, worauf ich damit hinaus will.

 

[cmonty14]

Ich habe eine Anleitung gefunden, die möglicherweise funktioniert...
Ich werde meinen Thread entsprechend aktualisieren.

 

[KunterBunter]

Hier im Forum und auch bei heise hat jemand eine Testseite veröffentlicht, mit der man überprüfen kann, ob die FritzBox die Sicherheitslücke enthält. Also steht im Quelltext der Seite, wie auf die Fritzbox zugegriffen wird.

 

[PeterPawn]

Du kannst es doch überschreiben, hast du doch selber gesagt. Du musst dann nur die Checksumme anpassen, damit die modifizierte Sicherung zurückgespielt werden kann.

Das funktioniert meiner Meinung nach so nicht ...

Nach meinen Tests würde ich eher folgenden Mechanismus für den Ex- und Import der Einstellungen annehmen (sind nur deduktive Schlüsse mangels Quelltext):

1. Die Box verschlüsselt die Einstellungen ja auch bei interner Speicherung mit einem "boxspezifischen" Kennwort. Ich habe einen (mehr oder weniger bestätigten) Verdacht, woraus dieses Kennwort besteht und suche Freiwillige (bitte per PM melden) mit einer unbenutzten Box zum Testen, um diese Annahme zu verifizieren.

2. Die Box verschlüsselt grundsätzlich unter Einbeziehung eines zufälligen "Salt", d.h. die wiederholte Speicherung desselben Klartextes führt nicht zu einem identischen Chiffrat. Es gab mal Ausnahmen, wo ein statisches Salt verwendet wurde an einigen wenigen Stellen ... dieser Fehler ist offenbar aber beseitigt. Ich kenne im Moment keine Einstellung, die ein reproduzierbares Chiffrat liefert.

Da die umts.cfg bei den wenigsten benutzt werden dürfte, eignet sie sich gut für diesen Test:

# grep "PIN" /var/flash/umts.cfg
<PIN></PIN>
# ctlmgr_ctl w gsm settings/PIN 1234
# grep "PIN" /var/flash/umts.cfg
<PIN>$$$$HVQVBEOZCPZXB4FRMVTDQAS5VULPONHXAX42E6KLRTJSBQ5KRN6YAXNZG5JIFXWIEGNSIIXMDDPBS65O</PIN>
# ctlmgr_ctl w gsm settings/PIN 1234
# grep "PIN" /var/flash/umts.cfg
<PIN>$$$$61CSOHC6TV5EOOMPCW6L324OVEWOW6SUK6JCVOEVGUJOGJMFLXEICSDZCZ6TXI1F3IR4AN56WVPCW65O</PIN>
#

3. Da auch in einer Export-Datei die Daten nur einmal verschlüsselt werden können und es aber - bei der Vergabe eines Kennworts im GUI - zwei mögliche Kennwörter zur "Entschlüsselung" gibt (1x boxspezifisches Passwort, 1x user-specified), muß da also ein anderer Mechanismus angewandt werden, um die einzelnen Einstellungen zu verschlüsseln (bis zur 06.03, danach wurde offenbar auch dort geändert).

Eine Lösung wäre hier z.B., die Einstellungen mit einem zufälligen Kennwort zu verschlüsseln und dieses zufällige Kennwort dann an den Beginn der Export-Datei zu schreiben ... einmal mit dem boxspezifischen Kennwort verschlüsselt und einmal mit dem benutzerdefinierten Kennwort (Password/Password2).

Wenn die Annahme unter 3. stimmt, ist es nicht möglich, einfach das Chiffrat aus einer Datei in eine andere zu kopieren, unabhängig vom Anpassen der Prüfsumme oder "NoChecks=yes" (was demnächst auch im Release wohl ohnehin nicht mehr funktionieren wird).

Wie das nun wieder in den neuen Versionen gelöst wird, konnte ich noch nicht richtig testen. Offenbar gibt es nur noch eine einzelne "Password"-Zeile am Beginn der Export-Datei. Sollte auch da das Einspielen einer Sicherung mit Kennwort in dieselbe Box wieder mit und(!) ohne Kennwort möglich sein, müßte irgendwie in die "Password="-Zeile am Beginn ja sowohl das benutzerdefinierte Kennwort als auch eine Kennzeichnung, von welcher Box diese Export-Datei stammt, einfließen.

 

[informerex]

alles wegen einer Konfig?
die Frage wurde bisher nicht beantwortet:

Was spricht gegen Recover und händische Neuinstallation?

 

[i2r]

[...]

Sieh's mal so:
nach Recover ist das Kennwort weg und das möchte er gern wissen, weil es jemand anders wieder rein schreiben wird.

 

[informerex]

@i2r
und wenn so wäre, sollte man keine Anleitung liefern
PS: fullquote war überflüssig

 

[koyaanisqatsi]

@PeterPawn: Kannst du mal versuchen, dein Passwort aus der ar7.cfg in die umts.cfg einfach per Copy'n'Paste einzutragen und so, wie in deinen Beitrag gezeigt, zu entschlüsseln?

EDIT: Mist, entschlüsseln ist nicht. Kommen nur **** bei raus.

EDIT2: Könnte man Monty's ar7.cfg in die ar7.cfg einer anderen Box cat'en und dann
mit allcfgconv -c entschlüsseln? (bevor die Box abstürzt)
Beziehungsweise: Könnte Monty selber versuchen (Sicherungsdatei).

 

[koyaanisqatsi]

Ja, das mit denn * war: ctlmgr_ctl r gsm settings/PIN
Und die Idee mit der Sicherungsdatei auf ar7.cfg kürzen und nach /var/flash zu cat'en,
ok, das war eher eine Schnapsidee. Was sich jetzt sowieso erledigt hat, denn die Lösung
hast du gerade geschrieben. Gute Idee.

 

[KunterBunter]

Das funktioniert meiner Meinung nach so nicht ...

Das habe ich auch nicht behauptet, dass man auf diese Weise ein bekanntes Passwort aus einer anderen Konfig übertragen kann, sondern nur, dass die modifizierte Sicherung mit einem überschriebenen Passwort zurückgespielt werden kann, nachdem die Checksumme angepasst wurde. Das Passwort ist dann aber ein anderes als das vorherige.

 

[i2r]

Fragestellung "Wie komme ich an das alte Kennwort ?"

Wie wär's damit:

Du hast die export bzw. ar7.cfg?
- Vertausch per Editor den Login-User-Kennwort-String mit einem beliebigen bekannten Kennwortstring z.B. eines Voip-Accounts.
- Zieh die neue Datei über "Wiederherstellen" drauf.
- Log dich dort mit dem Kennwort vom ehemals Voip über telnet ein und
- lies das unbekannte Login Kennwort aus dem Voip-Account mit allcfgconv -C voip -c -o - | egrep 'username|passwd' aus.

Ob das geht?

 

[PeterPawn]

Zieh die neue Datei über "Wiederherstellen" drauf.

Wie geht das ohne Einloggen ins GUI ?

 

[i2r]

[Edit Novize: Überflüssiges Fullquote gelöscht - siehe die abgenickten Forumsregeln!]

Als berechtigter Nutzer hat doch er doch wohl Backups. Dann kann er wie vom TE in #1 beschrieben vorgehen.
Zumindest war das mal ein in einem IP-Fachforum beschriebener Umweg, wenn man nicht den FBEditor ans Laufen bringen konnte.

Das Einsetzen des Strings mit dem Login-PW kann man sich natürlich sparen, indem man gleich was im Klartext zwischen die "" schreibt.

Vielleicht geht dieser Weg mit den neueren FWs nicht mehr. Weiß ich nicht.

 

[informerex]

wir machen uns hier einen Kopf und der TS hat immer noch nicht auf die mehrfach gestellte Frage geantwortet.

@PeterPawn dein Einsatz in allen Ehren, auf der einen Seite stellst AVM an den Pranger wenn das PW einfach auszulesen wäre, auf der anderen Seite div. User die evtl. eine Variante der Nutzung der Konfig. aufzeigen.
auch hier ist bisher nicht klar was der TS eigentlich detailiert braucht bzw. für was, denn bspw. die User-Hinweise würde eine Nutzung der Alt-Daten möglich machen.
alles andere kann doch sehr gefährlich werden, denn sodann könnte man gefälschte Daten in jede Box implizieren, ohne dass der Inhaber* der Box dies merken würde. (sprich wenn altes PW funktioniert)
*denn der reale Zugriff auf die Hardware, heißt doch noch lange nicht, dass eine Autorisierung zur Konfig.-Änderung vorliegt.

 

[i2r]

Haltet den Dieb! oder was ?

wir machen uns hier einen Kopf und der TS hat immer noch nicht auf die mehrfach gestellte Frage geantwortet.
... denn der reale Zugriff auf die Hardware, heißt doch noch lange nicht, dass eine Autorisierung zur Konfig.-Änderung vorliegt.

Einfach jemandem kriminelles Handeln zu unterstellen oder zumindest unterschwellig sehr deutlich herausstellen,
weil ihm widerfahren ist, was uns selbst schon häufiger passiert ist bei den 50 monatlichen Kennwortänderungen (oder 500?),
zu denen uns regelmäßig die selbsterfundenen Profi-Ecksperten aufrufen,
halte ich nicht für gerechtfertigt.

War vielleicht nicht deine Absicht. Kam mir aber so rüber.

Er hat doch Backups! Da wird er schon irgendwie ran gekommen sein. In der Regel machen sorgfältige berechtigte Nutzer Backups.
Oder machen das üblicherweise Verdächtige Malware-Injizierer?

Solche Vorverurteilungen werfen nicht gerade ein gutes Licht auf den Charakter und Gedankengänge dessen, der sie ausspricht.

 

[informerex]

ich bin diesbzgl. absolut vorbehaltlos und wollte niemand was unterstellen.
aber man sollte abwägen und somit beide Seiten betrachten, dh. "kann jedem passieren" und "ich will knacken".

eine einfache Erklärung/Beantwortung der og. Frage würde doch ausreichen und die helfenden User müssten nicht spekulieren