[Info] fritzbox boxusr in etc/passwd mit dropbear ssh shell [evtl] sicherheitsrisiko

die fritzbox 7390 (ua.) bringen von haus aus in der passwd neben root ein paar boxusr mit,
theoretisch könnten doch dann mit dem fritzmod.net voschlägen menschen als boxusr11 oder so einloggen?

Die sind von Haus aus angelegt und nicht trivial (hashwerte gegengecheckt) - die sind doch dann wohl AVM dem Hersteller (und vielleicht anderen bekannt) ...
ich mein wenn die Passwörter rauskommen dann ist doch ende im schacht, vielleicht kann mir ja jemnd meehr zu den boxusr erzählen, wozu sind die da, woher kommt deren passwort und warum sind die nicht einfach nur auf die box begrenzt.


EDIT zur Lösung
also folgende lösung(Vorschlag), AVM s Verwendung von allen boxusern in der etc/passwd ist ... naja ...
unter anderem benutzt dropbear diese Datei um Benutzerzugriffe zu regeln

wer dropbear auf einer Fritzbox ausführt sollte überlegen dies mit der option -0 (Null) tun,
wer z.B. den anweisungen von fritzmod.net gefolgt ist dürfte dann in der debug.cfg in der entsprechenden Zeile stehen haben
$TEMP/dropbear -p 22 -r $TEMP/dropbear_rsa_host_key -d $TEMP/dropbear_dss_host_key -0 -S $TEMP/sftp-server
man sollte eventuell bedenken den Port 22 zu ändern (obwohl standard nicht empfohlen)

sehr seltsam,
jetzt war ich doch zu neugierig ..also folgendes

ssh login als root
vi etc/passwd
folgende Zeile hinzugefügt (user test1 mit passwd test1)
test1:$1$TsYaRY94$Gt18ZTMnKa/9IuOZrutzy1:1111:0:box user:/:/bin/sh
ausgelogt, mit ssh -l test1 fritz.box erfolgreich eingeloggt
und dies bekommen
$ id
uid=1111(test1) gid=0(root) groups=0(root)

daraus folgt das die auch in der etc/passwd stehenden boxusr (allesamt der gruppe root zugehörig) auch gehen, auch wenn ich das Passwort nicht habe und niemand kennt.
mag sein das man das als geringes risiko einstuft , aber alle fritzboxen wären dann empfänglich mit dem gleichen passwort

geprüft mit fritz os 6.03 auf einer 7390
mit Dropbear server v2013.62 BusyBox v1.20.2

also was tun, seltsam erstmal das dies bei dir nicht geht

liebe grüße
Jens

also in der passwd sind bei mir standardmässsig
der user root ist mit dem x als passwd nicht zum login gemacht, wird wohl wie geplant von dropbear überschrieben mit den shadow ... test1 mit test1 (entspricht dem hash hier) ist angelegt worden um zu testen ob diese benutzer auch einen login machen können, die anderen waren von der fritzbox schon da .. und die haben ein salted/hash .. heisst wer das passwort weis kann sich als ebendieser boxusr der gruppe root einloggen.
sollten die hashwerte auf allen fritzboxen gleich sein könnte man so - wenn jemand seine box mit ssh aufmacht, quasi mit nem standardlogin einloggen ...
und das ist tatsächlich ein problem (find ich) - auch wenn man erstmal aus dem hash wieder ein passwort rückzaubern müsste.

@koyaanisqatsi
wie auf fritzod.net vorgeschlagen steht in der debug.cfg :
$TEMP/busybox sed -e "/root:/s#^root:[^:]*:#root:$PASSWD:#" -i $TEMP/shadow
wobei $TEMP=var/tmp
und $PASSSWD=netterkleinerhash

in der shadow steht dann eben nur ein root mit entprechendem hash
aber es gibt eben auch noch die etc/passwd die scheinbar auch mit eingelesen wird.

- wie ich die deaktiviert bekomme, oder eben als nicht "loginfähig" weis ich - könnte z,b. deren hashes alle auf x setzen oder einige der obigen vorschläge (ob ein nonexistent verzeichnis da reicht weis ich nicht - wenn dem so ist dann ists Thema ja auch schon erledigt)

mich interessiert ob andere das so bestätigen können,
1. ein angelegter user in /etc/passwd kann sich einloggen
2. die etc/passwd enthält valide boxuser

EDIT:
gerade überprüft, ein nicht existierendes Verzeichnis führt zu einem abbruch der ssh verbindung, damit sind die boxusr doch "safe" - aber nur weil nicht standardmässig ein anderes Verzeichnis genommen wird - wenn das gewünschte nicht existiert.

@RalfFriedl
danke für den Hinweis, hatte das mit den boxusr bisher nicht näher erklärt gefunden ...
ausser das man den brauch um den apache zum laufen zu bringen

nach einigen Tests weis ich nun,
die angelegten fritzbox benutzer (übers webinterface > System > benutzer )
werden in die etc/passwd eingetragen ... bzw vielmehr von irgendwoher kopiert, denn evtl eigene Einträge (mein test1 account) sind nach einem neuanlegen eines benutzers auf der weboberfläche weg.

bei der 7390 sind das dann als erstes boxusr10 etc pp .. einfach nach oben weitergezählt.

die box legt immer 2 benutzer an, boxusr10 und boxusr10int mit unterschiedlichen hashes..

ein ssh login ist dann möglich nicht mit den in der fritzbox vergebenen namen, sondern eben mit boxusr13 (in meinem fall)
- und weil die alle auf ein nichtexistentes verzeichnis verweisen wird die verbindung NACH einem erfolgreichen login getrennt:
Ausgabe bei richtigem PW
Ausgabe bei falschem PW

blöd das die sicherheit damit von dem verwendetem program abhängt (das bricht in dem moment die verb ab wenn das verzeichnis nicht stimmt, könnte aber irgendwann mal anders gemacht werden)
ob das eine Sicherheitslücke ist? keine Ahnung, wahrscheinlich kann man damit aber ziemlich schnell mal passwörter gegenchecken auf einer box (bruteforce/wordlist attacks) - wohl schneller als über die weboberfläche und man müsste nichtmal den original benutzernamen kennen.
sehr schmaler/unwahrscheinlicher Angriffsvektor ...

----
some more strange behaviour
der login mit dem angelegten test1 (auf der weboberfläche) - der im grunde garnix darf (laut weboberfläche) - bzw boxusr13 in der etc/passwd gibt bei einer ssh verbindung garnichts aus, friert quasi das terminal ein
im gegensatz zu einem der anderen standard benutzer wo einfach nur die verbindung geschlossen wird.
Dies scheint bei allen int logins auch der Fall zu sein. (boxusr10 geht -> connection closed, boxuser10int ->freeze bei richtigem PW)
dropbear mit der option -E (Terminal output) ausgeführt ergibt dann bei einem solchen login
kontrolle übers 2. terminal verrät erst wenn ich das terminal schliesse wird der user auch disconnected, man hängt also ohne shell auf der fritzbox
(child ssh verbindung öffnen, paar sekunden später login, nach ner minute von mir terminal von hand gekillt)
in diesem ZUSTAND funktionieren die SSH escape keys ( ~. ) und man kann zum beispiel port forwarding betreiben.

die fritzbox hat normal keine ssh zugänge .. von daher wird avm sagen - so what

wenn man aber welche einrichtet - dann scheint man die angelegten benutzer mit "einzukaufen" ..
ich weis auch nicht ob das nicht eher ein Problem von dropbear ist, welche ja den ssh zugang ermöglicht - weil eben dieses auch in passwd schaut. (oder ob man das zumindest dort nicht optional abstellen können sollte , sowas wie dropbear blabla -passwd)

nochmal zum verdeutlichen des "problems"

würde ich also eine fritzbox hacken wollen, und ginge davon aus das das root passwort stark wäre - dann näme ich den boxusr10 und würde den bruteforcen mit intelligenten regeln ...
da die Ausgabe bei erfolgreichen login spezifisch ist, hätte ich dann zwar keine shell aber ein Passwort zu einem benutzer.
Ich könnte an dieser Stelle ssh escape codes (port forwarding) nutzen oder mit dem gefundenen passwort über die weboberfläche den nutzernaen "bruteforcen" - Nutzernamen sind meist sehr spezifisch 4-12 Buchstaben lowercase .. manchmal der erste groß, manchmal nen punkt oder nen strich dazwischen - aber eben sehr eingeschränkt zufällig.
Damit hätte ich eine valide boxusrXY web-interface-username passwort kombination.
käme ich auf die weboberfläche (mir war als hätte ich dazu mal was gesehen) könnte ich evtl den Inhalt der passwd dahingehend ändern das die benutzer NICHT mehr in nichtvorhandene verzeichnisse zeigen, sondern ins stammverzeichnis / ... damit bin ich dann im prinzip schon bei einem root ssh shell zugang (der vorher nicht ging weil gehackte benutzer ja ins leere zeigen in der passwd)
man könnte einwenden Bruteforce ginge ja immer ... was hier "neu" wäre ist das man die evtl sehr schwach geschützten User / Passwort Kobinationen für diesen Hack benutzen kann. Ich werde das nicht weiter prüfen, aber das müsste auch gehen wenn die Benutzer im Grunde keine Rechte über weboberfläche haben - aber in die passwd müssten sie schreiben dürfen)

wenn man auch anders auf die Usernamen von dem boxuser aus schliessen kann ginge der hack bedeutend effizienter

edit 13.06.2014 11:00h
die benutzer können allesamt über den Quelltext der Adresse fritz.box/login.lua inklusive der zugehörigen email und anderen spannenden Dingen ausgelesen werden: bspw.

strace müsst ich dann auch erstmal über ein box-debian installieren und das laufen lassen - ist mir im moment zuviel arbeit.

sicher sollten alle sichere passwörter haben, nur bietet die Fritzbox eben ja an user zu generieren ("die keinen Access von aussen" haben sollten)
dann aber in der passwd stehen - alles gut bis ich einen ssh server zum laufen bringe der sich dann der etc/passwd bedient.

ich selber hab meine lösung gefunden, denke aber das das eine offene leichte hintertüre ist über die man - nicht unendlich einfach - in eine fritzbox hinein kann.

schwacher trost für die verwendung von standartbenutzernamen und die einladung mit-wenig-rechten-ausgestattete benutzer (und evtl schwachen passwörtern) zu generieren - abgesehn davon das selbiges mehr noch für telnet gilt

öhm, telnet is aus ... was soll das jetzt bringen? mir nicht ganz klar..
soweit ich mich erinnere, konnte ich mich mit Telnet mit allen Usern die in der etc/passwd eingetragen sind anmelden. boxusrxyz hab ich nicht ausprobiert ..

gibt es einen schönen Überlick wie die vm benutzerverwaltung funktioniert? (also wer schreibt wo welchen user hin und wer prüft dann was wann wo nach)
btw: was mich mehr interessieren würde - wenn ich einen neuen benutzer anlege, wird die alte passwd überschrieben, aber wie generiert die fritzbox die, ich mein wo steht deren vorlage mit all den anderen usern und passwörtern.

und von weiter oben etwas untergegangen @RalfFriedl : " Weiterhin kann man den dropbear so starten, dass er nur Anmeldungen als root zulässt."
ich hab in den man pages von dropbear nur optionen gefunden um root access abzuschalten, aber keine um den EXPLIZIT als einzigen zu nutzen .. kannst du das näher beschreiben?