fritz 7270 nach ssh Modifikation kein web login

[jh24]

Hallo,

ich habe auf meine 7270 das letzte OS bei dem die debug.cfg noch funktioniert aufgespielt.
Dann die Modifikation nach https://www.antary.de/2012/12/28/dropbear-ssh-server-auf-fritzbox-7270/
gemacht.
Also dropbear auf usb stick usw...
Hat alles super funktioniert, kann mich jetzt sowohl auf lan als auch auf wan interface über ssh einloggen.
Dann merkte ich, dass das web login nicht mehr funktioniert, falsches Passwort.
Hatte das gleiche Passwort für Zugang via Internet als auch via LAN (via LAN kein user name, nur Passwort).
Also beide gehen nicht.
D. h. natürlich gehen ftp und telnet auch nicht.

OK, ich versuchte über ssh das Passwort zu verändern:

# passwd boxusr10

(altes) web Passwort 2x eingegeben.
Hat er genommen, aber sich beschwert, dass für den user in /etc/shadow kein Eintrag existiert.

Hat aber nichts geholfen, web login immer noch gescheitert.
Allerdings geht jetzt ssh Zugang nur noch über LAN nicht mehr über Internet (falsches root Passwort).

Meine /etc/passwd sieht so aus:
root:x:0:0:root:/:/bin/sh
boxusr11:$1$ummwntd$xVQmV50.TEiJmbzK6Y7hD1:1011:0:box user:/home-not-used:/bin/sh
boxusr11int:$1$syhlfsu$BxfjpxW8jHQ06C10ok.gy/:2011:0:box user:/home-not-used:/bin/sh
boxusr10:$1$bxqfrxh$ejlrN5dUanQN6cTokWF2k/:1010:0:box user:/home-not-used:/bin/sh
boxusr10int:$1$cacoaab$4MyHdgrTYr6aBYkuJzRtn.:2010:0:box user:/home-not-used:/bin/sh
boxusr100:$1$ndjzics$P/gHu7H7FDcuL.4.rg0UM.:1100:0:box user:/home-not-used:/bin/sh
boxusr100int:$1$cxwnnst$B1eAz2LlveLAquzx2PQoZ.:2100:0:box user:/home-not-used:/bin/sh

Keine Sorge, vom hash auf das Passwort zu kommen lohnt sich nicht ;-)

Eigentlich hatte ich nur einen user.
Weiss jemand welcher user für was ist?
Was könnte bei der Modifikation schiefgelaufen sein, so dass das web Passwort nicht angenommen wird?

Danke !

 

[NDiIPP]

Ich würde jetzt auf Werkseinstellung gehen und dann ein neues Passwort vergeben.

 

[frank_m24]

Ich kann mich an die Urzeiten der Fritzbox-Mods erinnern, wo man die SSL Bibliotheken mit Modifikationen durcheinander bringen konnte. Die Symptome waren vielfältig, von Abstürzen bis hin zu Passwort-Problemen. Die Hash/Digest Algorithmen werden ja auch davon beeinflusst.

 

[koyaanisqatsi]

Aus der Erinnerung an meine freetz Zeiten...
Die busybox ihr passwd machte standardmässig einen schwachen Algo ( des - Nur 8 Zeichen als Passwort, Rest wird einfach ignoriert ) zum Standard.

busybox passwd --help
BusyBox v1.30.0 (2018-12-30 22:25:27 CET) multi-call binary.

Usage: passwd [OPTIONS] [USER]

Change USER's password (default: current user)

    -a ALG    des,md5,sha256/512 (default des)
    -d    Set password to ''
    -l    Lock (disable) account
    -u    Unlock (enable) account

...das konnte/kann aber mit dem Parameter -a md5 wieder eingerenkt werden.
Kann aber auch noch auf meiner unmodifizierten 7270 nachgucken.
Hab da für dropbear und etc. sämtliche Startscripte im /data* Verzeichnis.


* Normalerweise für den Anrufbeantworter - Rebootfester 1MB Speicher

 

[PeterPawn]

Das mit den "alten Zeiten" mag ja alles richtig sein ... aber seitdem es bei AVM eine eigene Benutzerverwaltung gibt, werden auch die Kennwörter für diese Konten in der ar7.cfg verwaltet und das hat ÜBERHAUPT NICHTS mit den üblichen Linux-Mechanismen zu tun. Wenn es dennoch auch in der /etc/passwd Einträge für Konten boxusrXX gibt, dann dienen die höchstens noch zum Login in den (AVM-)FTP-Server - und die Zuordnung zwischen den boxusrXX-Konten und denen in der ar7.cfg erfolgt anhand der Benutzer-ID (nicht mit der Linux-UserID zu verwechseln). Wer Shell-Zugriff hat, kann sich das "Mapping" auch in der Datei /var/tmp/users.map ansehen.

Will man also ein Kennwort für eines der von AVM verwalteten Benutzerkonten setzen, muß das schon über die AVM-Mechanismen erfolgen ... und das ist garantiert kein passwd oder ein ähnliches Kommando. Man kann vielleicht aus "historischen Gründen" noch in Ansätzen nachvollziehen, warum Freetz irgendwann mal eine zweite Benutzerverwaltung eingeführt hat - spätestens als die von AVM dann dazu gelernt hatte und auch feiner granulierte Zugriffsrechte im Dateisystem erlaubte, hatte sich das eigentlich überlebt und hätte vermutlich auch geändert werden sollen - ist halt nicht passiert.

Jedenfalls haben die Accounts, mit denen man sich am AVM-Webinterface anmelden kann, ABSOLUT GAR NICHTS mit denen zu tun, die in der /etc/passwd zu finden sind - der Versuch, da mit einem passwd boxusr10 IRGENDETWAS bewirken zu wollen, war also schon nicht besonders schlau (spätestens die Frage, wer oder was denn eigentlich nun dieser boxusr10 GENAU ist, hätte einen da ja stutzen lassen sollen).

Wenn tatsächlich noch ein so uraltes System verwendet werden soll (schon bei der Bemerkung:

das letzte OS bei dem die debug.cfg noch funktioniert

sollten sich einem die Fußnägel aufrollen - glücklicherweise liegt aber auch diese Version (die offenbar ungenannt bleiben will) vermutlich noch nach der "webcm"-Lücke), dann sollte man auch wissen, daß bei dem beschriebenen Modus der Anmeldung immer ein (verstecktes) Benutzerkonto @CompatMode mit der User-ID 100 verwendet wurde ... und siehe da, auch nach der /etc/passwd gibt es ja einen Benutzer boxusr100 - nur wird eben auch nicht dessen Kennwort-Hash in der /etc/passwd zum Vergleich herangezogen (und NIEMAND hier wäre so blöd, auf:

Keine Sorge, vom hash auf das Passwort zu kommen lohnt sich nicht

irgendwelche Zeit zu verschwenden ... auch wenn solche Aussagen für Hash-Werte mit MD5 schon REICHLICH kühn sind, denn MD5 ist nun alles mögliche, nur nicht mehr "sicher" - aber das steht auf einem ganz anderen Blatt) beim Login am AVM-GUI, sondern der in der ar7.cfg gespeicherte Wert (der steht da sogar im Klartext und nicht "nur als Hash", auch wenn der Eintrag natürlich - wie üblich - mit der AVM-Verschlüsselung für die Konfigurationsdateien behandelt wurde) wird zur eigenen Berechnung des Hash-Wertes aus "challenge" und dem korrekten Kennwort verwendet.

Will man jedenfalls das Kennwort für eines der Konten in der AVM-Benutzerverwaltung von der Shell aus ändern, muß man sich schon mit dem Lua-Interface (z.B. set.lua - Beschreibung hier irgendwo im Board) befassen oder man nimmt gleich ctlmgr_ctl (UI-Module boxusers) und setzt damit die password-Property für den passenden User. Dann sollte auch wieder ein GUI-Login mit dem neu gesetzten Kennwort möglich sein - wobei sich die Frage stellt, wie das "durcheinander gekommen" sein kann und die wirklich schlauen FRITZ!Box-Besitzer dann auch den Anmeldemodus auf "Benutzername und Kennwort" ändern, weil ihnen dann auch noch Chancen für ein erfolgreiches Login mit einem anderen Konto verbleiben, wenn sie mal wieder das Konto @CompatMode oder einen anderen Benutzer-Account kaputt gespielt haben.

Der Telnet-Service, der vom AVM-Daemon telefon gestartet wird, verwendet dann auch ein anderes Binary für das Login - nämlich /sbin/ar7login ... und wie der Name schon VERMUTEN läßt, arbeitet auch dieses dann nicht mit den "Linux-Konten", sondern mit denen aus der ar7.cfg. Und es ist sogar NOCH VERRÜCKTER ... auch für die Anmeldung am FTP-Server verwendet man bei AVM die Benutzernamen aus der ar7.cfg und um das Mapping auf die entsprechenden Einträge in der /etc/passwd (jeweils einer für den internen und einer für den "Internet"-Zugriff - letzterer dann mit dem Zusatz "int" als Suffix des Benutzernamens, das steht also NICHT für "int"ern) kümmern sich dann wieder andere.

---

Also besser nicht einfach - ohne genauere Kenntnisse - auf die Einträge in den "üblichen" Linux-Dateien losgehen ... erst einmal kundig machen und dann an der RICHTIGEN Stelle ändern. Wenn man nicht selbst etwas durcheinander bringt, funktioniert auch die "zweigeteilte" Benutzerverwaltung eigentlich ziemlich reibungslos - man muß halt nur VERSTEHEN, was da in Wahrheit passiert und solange ein SSH-Zugang nicht auch mit den Konten in der ar7.cfg arbeitet (was er problemlos auch machen könnte - beim dropbear könnte man sogar entsprechende Exit-Routinen programmieren), sind das IMMER zwei verschiedene Paar Schuhe.

---

EDIT:
Und vielleicht sollte man auch noch erwähnen, daß es tatsächlich einen sehr zuverlässigen Weg gibt, alle im FRITZ!OS in verschlüsselter Form gespeicherten Daten auf einen Schlag zu invalidieren - was auch "gerne genommen" wird von Anfängern in dem Bestreben, die "Einstellungen" ihrer FRITZ!Box an ihre Vorstellungen anzupassen. Wer auf die (überhaupt nicht kluge) Idee kommt, das WLAN-Password im Urlader-Environment doch lieber durch einen eigenen "Standardwert" zu überschreiben, der beraubt das FRITZ!OS damit auch jeder Möglichkeit, bereits vorhandene und verschlüsselt gespeicherte Daten wieder auszulesen - das gilt dann sowohl für Benutzernamen als auch für Kennwörter in der ar7.cfg (und auch ALLE anderen Einstellungen, die mit vier Dollarzeichen beginnend in den AVM-Dateien gespeichert sind). Gleiches gilt auch für die anderen Komponenten, aus denen das "boxinterne Kennwort" für die Verschlüsselung der Daten gebildet wird.

Warum erwähne ich das noch einmal extra? Weil es wenige (plausible) Gründe gibt, wieso die Daten aus der ar7.cfg plötzlich nicht mehr lesbar sein könnten (und die Benutzernamen werden ja normalerweise als Liste in der SELECT-Box angezeigt - da KANN man eigentlich gar nicht auf die Idee kommen, einer davon könnte jetzt boxusr10 lauten und deshalb würde eine Änderung des Kennworts für DIESEN Benutzer nun irgendeinen Vorteil versprechen) ... und eine solche Änderung an den "Grunddaten" einer Box ist eine dieser Ursachen, die ich auch schon oft genug "live" bei anderen beobachten konnte, die sich dabei gar nichts weiter dachten. Solange man danach tatsächlich einen Werksreset macht, funktioniert das auch (weil neu gespeicherte Einstellungen dann auch die geänderten Eigenschaften zum Verschlüsseln nutzen) ... aber eben auch nur dann.

 

[jh24]

Hallo zusammen,

danke euch allen für die schnelle und ausführliche Hilfestellung.
Die Verbindung zu ar7.cfg war mir nicht klar.
Denke am besten ich setze zum WE alles neu auf.

 

[PeterPawn]

Ich würde mir auch DAS noch einmal gut überlegen ... die dropbear-Version dort ist tatsächlich (ich habe extra noch einmal nachgesehen) von 2013 - seitdem gab es 13 (in Worten: dreizehn) Probleme im dropbear, die es zu einer CVE-Nummer gebracht haben: https://www.cvedetails.com/vulnerability-list/vendor_id-15806/Dropbear-Ssh-Project.html

Auch ohne mir jetzt jede einzelne von denen anzusehen und zu bewerten, ob die in dem hier besprochenen Szenario nun wirklich gefährlich ist oder nicht - ich KANN mir einfach nicht vorstellen, daß jemand, der auf diese vorkompilierten Binaries ANGEWIESEN ist (das war ja sicherlich auch als "Angebot" und "Prinziplösung" gedacht und nicht dafür, daß da nach fast 10 Jahren noch jemand die Binär-Dateien weiterhin benutzt), das selbst auch nur ANNÄHERND beurteilen kann.

Und es ist ja auch nicht so, daß dieser SSH-Server dann nur in der kleinen Enklave des eigenen LAN benutzt werden soll (was sträflich genug wäre) ... nein, der hängt dann auch gleich noch "im Internet".

Wer so etwas tatsächlich noch auf einer FRITZ!Box (mit FRITZ!OS) machen will, der geht nun mal Risiken ein ... und auch hier habe ich wieder meine Zweifel, ob jemand, der das nicht "von Grund auf" selbst zusammenstellen kann (oder will), überhaupt in der Lage ist, diese einigermaßen präzise einzuschätzen und damit dann auch "im Einsatz" zu vermeiden.

Es ist ja NICHT NUR der uralte dropbear, der hier potentiell Probleme bereitet (denen könnte man mit einem eigenen Kompilat einer neueren Version ja noch begegnen) ... das FRITZ!OS der 7270 (egal, welches Modell, von v1 bis v3) ist sooo alt, daß darin verwundbare SSL-Bibliotheken und mind. zwei mittlerweile erkannte WLAN-Lücken fröhliche Urständ feiern und in trauter Gemeinschaft aus dem OS einen Schweizer Käse im Hinblick auf die Sicherheit des Gerätes machen.

Selbst die "modernste" Version der Firmware für eine 7270v3 (das ist die 06.06 aus dem Herbst 2015) enthält noch die OpenSSL-Version 0.9.8zg ... die ging auch zum 01.01.2016 "out of service". Das heißt dann wieder, daß danach gefundene Probleme in SSL-Implementierungen gar nicht mehr daraufhin untersucht wurden, ob Version 0.9.8z<irgendwas> davon noch betroffen sein könnte - was die Einschätzung, ob ein entdecktes Problem auch die alten Versionen betreffen würde, durch einen Laien noch viel schwerer macht (https://www.openssl.org/news/vulnerabilities.html).

Aber auch das OpenSSL ist ja nur EINE weitere Baustelle ... es gibt viele weitere Stellen in der Firmware, wo Security-Probleme behoben wurden in den letzten 6,5 bis 7 Jahren - seitdem diese letzte Version der Firmware für die 7270v3 erschien.

Wer diese Geräte wirklich NICHT entsorgen will, der kann sie ja mit anderer Firmware nutzen - üblicherweise mit Abstrichen beim Funktionsumfang. Wer ein solches Gerät mit der alten AVM-Firmware nutzen will, sollte das - schon in seinem eigenen Interesse - per se schon mal OHNE WLAN machen (FragAttack (Mai 2021), KRACK (Okt. 2017, wenn ich mich richtig erinnere)) und am Ende dann auch noch ohne Internet-Zugang. Ja, sogar als SIP-Endpoint könnte so eine Box ein Problem sein - ich kann mich auch noch an eine "traffic amplification attack" auf die Box erinnern, wo der SIP-Stack von AVM unbedingt den Absender einer falschen SIP-Message noch über seinen Mißmut unterrichten wollte ... und das dann auch noch mit mehreren Wiederholungen, wenn der so Gescholtene darauf nicht reagieren mochte (und das alles noch mit UDP, wo der Absender eines Pakets (auch heute noch) problemlos gefälscht werden kann).

Bei letzterer weiß ich zwar nicht mehr genau, in welcher OS-Version das dann behoben wurde - aber ich glaube nicht, daß das schon in der 06.0x-Reihe der Fall war und derartige Fixes haben sicherlich auch spätere "Neufassungen" des OS nicht erhalten - die 06.06 kam eigentlich (iirc) nur mit einer (letztmaligen) Aktualisierung des SSL-Stacks, weil die damaligen Browser irgendwann ALLE die einzige Option, die vom FRITZ!OS zuvor angeboten wurde (das war dann "Arcfour" oder auch "RC4"), wegen "unsicher" (wir erinnern uns an E. Snowden und den NSA-Skandal?) ablehnten und man damit gar nicht mehr auf das GUI dieser Boxen zugreifen konnte, wenn man einen halbwegs aktuellen (hinsichtlich der SSL-Sicherheit) Browser verwenden wollte.

Und so könnte man das noch eine Weile fortsetzen ... am Ende bleibt eigentlich nur das Fazit, daß man entweder eine andere Firmware verwenden sollte (z.B. OpenWRT, wobei ich nicht exakt weiß, wie gut der UR8 der 7270 da bei aktuellen Versionen noch unterstützt wird und auch der Flash-Speicher ist schon stark limitiert bei diesen Modellen) oder die Box MIT NICHTS anderem verbinden sollte - was ihre "Nützlichkeit" dann eher auf ein paar blinkende LED und entsprechenden Energieverbrauch reduziert. Aber selbst als "Heizung" mit elektrischer Energie, falls das Gas knapp werden sollte, taugt die nicht wirklich - der Wirkungsgrad ist recht gering.

Da bietet sich selbst für "Spielereien" eher ein passender "Bastelrechner" (z.B. Einplatinen-Computer wie die "Himbeere" -> Raspberry Pi) an, wo man auch nicht sofort Kopf und Kragen riskieren MUSS (wenn man's richtig macht), sobald man das Gerät "zugänglich" macht.

 

[B612]

wobei ich nicht exakt weiß, wie gut der UR8 der 7270 da bei aktuellen Versionen noch unterstützt wird

mMn wurde die 7270 noch nie von OpenWRT unterstützt.

 

[PeterPawn]

Auch möglich ... wobei die Kernel-Patches eigentlich vorlägen und eine Weile war die UR8-Plattform ja auch einigermaßen aktuell - aber vielleicht gab es andere Probleme oder irgendwelche "AVM-Spezialitäten" (auch jenseits des Bootloaders) verhinderten, daß sich jemand damit befaßte. Es gibt da ja schon einige Kuriositäten ... am besten ist mir das "port sharing" für die serielle Schnittstelle in Erinnerung geblieben, wo bei der 7412 dann die Daten, die eigentlich zum Xilinx-FPGA gehen sollen, auch noch auf der seriellen Konsole landen und im Extremfall ein dort auch noch angeschlossener RS232-Adapter dafür sorgen kann, daß das Laden der FPGA-Firmware fehlschlägt und die Box gleich wieder einen Reboot hinlegt.

Wenn das WLAN der 7270 auch unter OpenWRT nicht verfügbar war, DAS würde mich aber tatsächlich nicht wundern - das gehört zu den "Einschränkungen", die man dann eben hinnehmen müßte (und nicht nur DECT und Telefonie allgemein) - wie ich oben schon erwähnte.