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

meisterlei

Neuer User
Mitglied seit
8 Jun 2014
Beiträge
24
Punkte für Reaktionen
0
Punkte
0
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)
 
Zuletzt bearbeitet:
Hallo meisterlei,

diesen Beitrag habe ich auch gleich entdeckt ;)

das stimmt so nicht, denn dropbear benutzt ja nicht die /etc/passwd sondern /var/tmp/shadow ;) und da ist meiner Beschreibung nach nur der root drin. Ich habe es gerade eben verrifiziert: man kann sich mit anderen nicht einloggen :)

trotzdem danke für den Hinweis

Gruß
R@d
 
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
 
Du hast also einen Benutzer test1 mit Passwort test1 angelegt und konntest Dich danach damit anmelden. Das sollte man so auch erwarten.

Was könnte denn Deiner Meinung nach mit den boxusr Benutzern passieren, und passiert dies tatsächlich? Wie sieht denn die Zeile der boxusr aus?
 
also in der passwd sind bei mir standardmässsig
Code:
root:x:0:0:root:/:/bin/sh
boxusr12:$1$wXXXXXXXXXXXXXXXXXX:1012:0:box user:/home-not-used:/bin/sh
test1:$1$TsYaRY94$Gt18ZTMnKa/9IuOZrutzy1:1111:0:box user:/:/bin/sh
boxusr12int:$1$sXXXXXXXXXXXXXXXXXX:2012:0:box user:/home-not-used:/bin/sh
boxusr11:$1$gyyXXXXXXXXXXXXXXXXXX:1011:0:box user:/home-not-used:/bin/sh
boxusr11int:$1$ijXXXXXXXXXXXXXXXXXX:2011:0:box user:/home-not-used:/bin/sh
boxusr10:$1$sioobXXXXXXXXXXXXXXXXXX:1010:0:box user:/home-not-used:/bin/sh
boxusr10int:$1$azXXXXXXXXXXXXXXXXXX:2010:0:box user:/home-not-used:/bin/sh
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.
 
Abend

Wenn dich das nervös macht, und du sowieso als root alles darfst, ändere doch mal alle...
Code:
/home-not-used:/bin/sh
..in..
Code:
/nonexistent:/bin/false

Apropos root: Welches Kommando hast du denn abgesetzt um sein Passwort zu erstellen?
 
@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.
 
Zuletzt bearbeitet:
@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
Code:
[email protected]'s password: 
Connection to fritz.box closed.
Ausgabe bei falschem PW
Code:
[email protected]'s password: 
Permission denied, please try again.

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
Code:
[14071] Jun 13 02:09:44 Exit (boxusr11int): Error changing directory
[14071] Jun 13 02:09:44 chown /dev/pts/1 0 0 failed: Operation not permitted
kontrolle übers 2. terminal verrät
Code:
[14070] Jun 13 02:09:44 Password auth succeeded for 'boxusr11int' from 192.168.0.22:58920
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)
Code:
[14145] Jun 13 02:17:59 Child connection from 192.168.0.22:58947
[14145] Jun 13 02:18:04 Password auth succeeded for 'boxusr13' from 192.168.0.22:58947
[14145] Jun 13 02:19:07 Exit (boxusr13): Disconnect received
in diesem ZUSTAND funktionieren die SSH escape keys ( ~. ) und man kann zum beispiel port forwarding betreiben.
 
Zuletzt bearbeitet:
Welcher Benutzergruppe sind die boxusr denn zugeordnet? <- Die Frage hat sich erledigt, habe die Gruppe vorhin in der oberen passwd überlesen.
Und was sagt AVM dazu?

/edit: Ich habe mal gesucht und folgendes gefunden: http://www.wehavemorefun.de/fritzbox/Passwd_(etc)
 
Zuletzt bearbeitet:
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.
Code:
["boxusers:settings/user/list(UID,id,enabled,name,email,password,is_tr069_remote_access_user)"] = {
    [1] = {
      ["UID"] = "boxuser10", 
      ["_node"] = "user0", 
      ["email"] = "", 
      ["enabled"] = "1", 
      ["id"] = "10", 
      ["is_tr069_remote_access_user"] = "0", 
      ["name"] = "ftpuser", 
      ["password"] = "****"
    }, 
    [2] = {
      ["UID"] = "boxuser12", 
      ["_node"] = "user1", 
      ["email"] = "[email protected]", 
      ["enabled"] = "1", 
      ["id"] = "12", 
      ["is_tr069_remote_access_user"] = "0", 
      ["name"] = "nettername", 
      ["password"] = "****"
    }, 
    [3] = {
      ["UID"] = "boxuser11", 
      ["_node"] = "user2", 
      ["email"] = "[email protected]", 
      ["enabled"] = "1", 
      ["id"] = "11", 
      ["is_tr069_remote_access_user"] = "0", 
      ["name"] = "nettername", 
      ["password"] = "****"
    }, 
    [4] = {
      ["UID"] = "boxuser13", 
      ["_node"] = "user3", 
      ["email"] = "", 
      ["enabled"] = "1", 
      ["id"] = "13", 
      ["is_tr069_remote_access_user"] = "0", 
      ["name"] = "test1", 
      ["password"] = "****"
    }
 
Zuletzt bearbeitet:
Die Datei passwd wird immer neu angelegt, nur der Eintrag für root wird dabei aus der vorhandenen Datei übernommen.

Das unterschiedliche Verhalten für boxusr und boxusrint ist seltsam, schließlich sind die Einträge in der passwd gleich bis auf den Namen und die Nummer. Du kannst versuchen, mit strace herauszufinden, was da auf dem Server passiert.
Weiterhin kann man den dropbear so starten, dass er nur Anmeldungen als root zulässt.

Ein Ausprobieren aller Passwörter wird schwierig, zumindest die älteren Boxen neigen zu einem Reboot, wenn zu viele SSH Verbindungen aufgebaut werden. Das ist mit ein Grund, warum es sinnvoll ist, Dropbear nicht auf Port 22 laufen zu lassen.

Ansonsten sollte man auf einem System, das von extern zugänglich ist, nicht nur für root sondern auch für die anderen Benutzer sichere Kennwörter verwenden.
 
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.
 
Moin

Das Programm passwd, aufgepasst, denn ohne -a md5 als Parameter wird schwache Verschlüsselung genommen.
Code:
sL0kFoNs/nG1o
...mit -a md5...
Code:
$1$2q5LfRet$cCCWBSYNqIbHPgnWSpcqF/
 
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.

Wie Du oben schon richtig geschrieben hast, kann AVM nichts dafür, dass Du einen SSH Server auf die Box bringst.
 
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
 
Jetzt kommen wir langsam zum Kern der "AVM-Benutzerverwaltung". :)
Wenn AVMs telnetd -l /sbin/ar7login gestartet ist, und im Webinterface eingestellt ist:
Anmeldung mit Benutzername und Passwort
Welcher Benutzer bist du dann, nach erfolgreichen Login mit PuTTY/telnet?
 
ö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?
 
Zuletzt bearbeitet:
Tippe er bitte: nvi /var/flash/ar7.cfg
Dann leitest du eine Suche ein mit: /
Jetzt: boxusers [RETURN/ENTER/EINGABE]
Beenden ohne Änderung: [Esc] :q! [RETURN/ENTER/EINGABE]
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.