Sehr viel Aufwand, der durchaus leichter zu erreichen ist ... hat man erst einmal einen Telnet-Zugang, kriegt man den Benutzer ohnehin nicht wieder aus der Box - es sei denn, er sperrt sich selbst aus (2x Update mit einer Version ohne eingebautes Telnet und ohne bekanntgewordene Lücke) oder man ändert den Update-Vorgang.
Wenn AVM nach dem Ändern der "linux_fs_start"-Variablen (dann ist die Umschaltung ja durch und der "normale Benutzer" kommt ohnehin nicht mehr auf die Vorgängerversion zurück) einfach noch das Dateisystem der alten Systeme überschreiben würde (da reicht schon der Superblock und der liegt ohnehin im Speicher und wird nicht jedesmal neu gelesen), dann führt auch kein Weg mehr über die Änderung von "linux_fs_start" zurück bei einer Box, die ohne ein angepaßtes System online aktualisiert wurde.
Deshalb sollte man ja vor dem Update überprüfen, was so ein install-Skript eigentlich genau macht. Wobei man als Hersteller vermutlich noch mehr "Moddern" in die Suppe spuckt, wenn man so etwas nicht sofort ausführt, sondern erst nach ca. 4 Wochen nach der Veröffentlichung - dann haben garantiert genug Kunden die (originale) Firmware installiert und halten sich nur noch die ältere "für den Telnet-Zugang" (wofür eigentlich?), daß so eine Aktion dann mit einem Schlag bestimmt 95% der Telnet-Boxen auch wieder aus dem Rennen nimmt. Und niemand möge mir erklären, daß AVM dazu nicht in der Lage oder nicht berechtigt wäre ... die DOCSIS-Spezifikation ist da nun mal eindeutig und und selbst wenn die ANGA das nur als "informative" referenziert, ist eben bei der AVM-Firmware (inzwischen gibt es ja so viele Telnet-Zugänge in freier Wildbahn, daß auch das unvermeidbar bekannt ist) mit einem Shell-Zugang auch die OFI-Seite des CMCI zugänglich.
Sich ein eigenes Image mit einem Telnet-Zugang zu bauen, ist ja hingegen nun wieder Kinderkram (auch irgendwo beschrieben und @fesc hat da für eine 06.50 was bei bitbucket.org eingerichtet, das läßt sich sicherlich auf eine Retail-Version anpassen) - man muß halt nur lesen und verstehen anstatt nur abzutippen.
Wer das nicht kann, sollte ohnehin die Finger davon lassen (und das ist wieder keine Überheblichkeit, es ist tatsächlich nur allzu leicht, sich bei seinem Router selbst ins Knie zu schießen und dann geht das Gejaule erst richtig los - Sicherheit heißt zwar auch, daß man Hersteller und KNB irgendwie auf die Finger schauen kann und das Gerät keine reine Blackbox ist, aber am Ende ist das Wühlen in den Eingeweiden des Routers (das meint nicht einmal dann APP-Teil, wenn das richtig getrennt ist) genauso abzulehnen - wenn derjenige nicht wirklich weiß, was er tut - wie das Wühlen in den Eingeweiden anderer Familienmitglieder, weil gerade kein Chirurg zur Hand ist oder das "Umprogrammieren" des Airbag-Steuergerätes und des ABS, weil man scharf auf die Lebensversicherung ist.
Das Problem bei der AVM-Firmware ist es ja nicht, daß eine laufende Firmware irgendwie kryptographisch gesichert wäre, nur das Einbringen einer neuen Image-Datei (egal ob CVC-, Online- oder Datei-Update) wird entsprechend geprüft und wenn man mit einem Shell-Zugang bereits die erste Hürde genommen hat, kann man die Firmware ja erst "hinter" der Prüfung installieren.
Auch das ist alles kein wirkliches Geheimnis oder auch nur neu ... deshalb ist ja der Dammbruch beim ersten Shell-Zugang so unangenehm für Hersteller und KNB. Solange dann die neue Firmware auch noch beim Download "abgefangen" werden kann (das ist ja momentan nicht einmal notwendig, man muß ja nur die URL ermitteln), kann man jederzeit auch die aktuelle Firmware wieder mit einem Shell-Zugang versehen.
Die entscheidende Frage bleibt es halt, was der "normale Benutzer" damit will. Bei Intel gibt es ja eine (mehr oder weniger deutliche) Aufgabenteilung zwischen den Systemen ... der ARM-Core nennt sich "NP" (ich tippe auf "network processor") und der x86-Core dann "APP" (naheliegend, wie ich das "übersetzen" würde). Wenn es also am Ende darauf hinauslaufen würde, daß tatsächlich der eCM- und der eRouter-Teil (bei AVM glaube ich nicht daran, daß sich der "dsld" auf den "APP"-Core verlagern läßt) auf dem "NP" laufen, dann wäre der Shell-Zugriff auf den x86-Core wieder kein Problem im Hinblick auf Chapter 9.2 - mal sehen, ob so ein Schritt überhaupt kommt bzw. wann er vollzogen wird. Problematisch ist es im Moment halt, daß der Zugriff auf den einen Core auch automatisch den auf dem anderen Core nach sich zieht - angesichts von "rpc" bin ich eher geneigt, an eine "richtige Trennung" nicht zu glauben.
Wer nur den Telnet-Zugang "pflegen" will, damit er ihn eben hat, handelt m.E. leichtsinnig. Es mag triftige Gründe geben ... aber wer sich heute der Illusion hingibt, er hätte sein Netz schon im Griff und außer ihm würde niemand einen Telnet-Zugang nutzen können, der irrt in den allermeisten Fällen oder lebt als Eremit mit einem DOS-Rechner in der Vergangenheit.
Wenigstens ein SSH-Zugang sollte es dann schon sein, wenn man so etwas dauerhaft einrichtet (auch SIAB mit TLS ist eine Alternative) ... schon die Annahme, ein per Telefon-Code ausgeschalteter Telnet-Zugang wäre das auf ewig, ist einfach naiv. Wer z.B. parallel dazu noch irgendein FRITZ!Fax-Programm benutzt und deshalb die "Remote CAPI" auf der Box aktiviert, der ermöglicht auch das Wählen einer Nummer (für die Box sieht das wie ein ISDN-Telefon aus) ohne jede Anmeldung - zumindest war es einmal so. Ob das immer noch so ist, verrät sicherlich "Phoner" ... kann man mit diesem Programm über CAPI den Telnet-Daemon an- und ausschalten (lange nicht mehr getestet), nutzt auch das Abschalten von Telnet durch den Benutzer per Telefon-Code nichts.
Wie leicht es in einem LAN möglich ist, die Daten anderer Geräte abzufangen (solange der Traffic nicht verschlüsselt ist), kann jeder zuhause mit "ettercap" selbst probieren ... das Tool bietet auch die gängigsten Mechanismen an, wie sich ein Angreifer in so eine unverschlüsselte Verbindung einklinken würde - einfach mal die Doku lesen, damit man eine Vorstellung erhält, warum ein LAN mit unverschlüsseltem Verkehr zur FRITZ!Box einfach nicht wirklich sicher sein kann, wenn da irgendwelche Clients in diesem LAN aktiv sind, die Internet-Zugriff haben.
Nicht einmal einen Brute-Force-Angriff auf einen Admin-Account über Telnet (oder FTP) würde man als Besitzer so einer Box bemerken, weil solche Zugriffe gar nicht protokolliert werden. Für FTP wird AVM das wohl noch nachrüsten oder zumindest etwas ändern in der nächsten Version, aber für Telnet wohl kaum - den gibt es ja "offiziell" gar nicht und das "ar7login" wird m.W. nirgendwo anders mehr genutzt.
Seitdem es eine "maximale Wartezeit" nach einem falschen Login gibt (die Wartezeit bei einem Fehlversuch liegt max. um die 22 Sekunden), ist es auch für einen dauerhaft laufenden LAN-Client (nehmen wir mal ein Synology-NAS, das über eine Lücke infiziert wurde oder ein "ranziges" Smart-TV-Gerät, einen HDMI-Stick, usw.) problemlos möglich, an einem einzigen Tag ca. 3750 Kennwörter (alle 23 Sekunden eines) einfach aus einem Wörterbuch zu probieren und das ohne jede Anzeige, daß da etwas faul ist.
Nicht einmal ein GUI-Login würde dadurch entscheidend verzögert - nur andere Aufrufe von ar7login würden ggf. diese ~ 20 Sekunden Verzögerung nach der Kennworteingabe bemerken (wenn der Benutzer wirklich aufmerksam ist und das nicht auf Überlastung der Box o.ä. schiebt). Ein solcher offener Telnet-Zugang ist also (auf der LAN-Seite ist es ziemlich simpel, die denkbaren Benutzernamen zu ermitteln, da reicht schon das Auslesen des Login-Formulars) nicht wirklich ein Spaß ... es gab schon gute Gründe, warum der (auch bei den DSL-Modellen) "abgeschafft" wurde.
Wer tatsächlich nur Kennwörter verwendet, die mit keinem der gängigen Passwort-Knacker per Wörterbuch-Attacke (inkl. Permutationen in "l33t" und ähnlichem) in akzeptabler Zeit ermittelt werden können, der mag das wieder "in den Skat drücken" ... aber wer sich auf die Standardeinstellung des FRITZ!OS (ein Kennwort für den Zugang, kein Benutzername) verläßt, wird auch bei mehr als einem angelegten Benutzer von deren Anzahl kaum als Multiplikator für den Aufwand einer solchen Attacke profitieren. Leider lehrt die Erfahrung, daß die meisten der Ansicht sind, in ihr LAN käme schon niemand hinein und "drowssap" ist ein gutes Kennwort, weil es in keinem Wörterbuch auftaucht.
Es gibt für einen Angreifer auch noch genug Möglichkeiten abseits eines Telnet-Zugangs - IP-Spoofing und "SID theft" sind auch nicht so schwer, wobei AVM hier mit der Verkürzung des Intervalls für Auto-Logout (bzw. den Verfall der SID) auf 1200 Sekunden (vorher waren es 3600) schon wieder einen Schritt in eine richtige Richtung gemacht hat (nach meiner Ansicht), das schränkt den "Wert" einer erbeuteten SID etwas ein, weil man sich beeilen muß. Da muß man nicht unbedingt noch einen weiteren (permanenten) Angriffspunkt in so einem Router bereitstellen ... liest sich vielleicht komisch aus meinen Fingern, ist aber so und auch die Argumentation ist ja nicht so neu.
