eisbaerin schrieb:
Wieso geht das nicht auch für FTP, SIP und anderes?
Das frage ich mich auch ... bei mir rennt man damit offene Türen ein.
Schon die Behandlung der Logins (die SIP-Accounts benutzen ja zumindest getrennte Credentials, wo man mangels Notwendigkeit der permanenten Eingabe problemlos auch starke Kennwörter "erzwingen" könnte, ohne daß der Bedienkomfort für den Benutzer wirklich leidet) ist höchst unterschiedlich.
Selbst bei der aktuellen Labor-Version für die 7490 (33566) kann man noch problemlos ein Konto für ein IP-Telefon mit dem Kennwort "test1" einrichten und für den Zugriff aus dem Internet freigeben. Ob da dann auch noch eine Anmeldung möglich ist oder nicht (weil die "Verbesserung" vielleicht erst bei der Benutzung so eines SIP-Accounts greifen sollte), habe ich nicht weiter getestet.
Solange die Maßnahmen nicht abgestimmt sind, führt das ja nur zu mehr Konfusionen beim Kunden und wenn der ein IP-Telefon mit Kennwort "test1" anlegen und extern freigeben kann, dann bleibt mir einfach nur die Spucke weg. Hier sähe ich AVM sogar in der Pflicht, einfach beim Anlegen ein Kennwort vorzugeben und das muß der Kunde dann eben in sein Endgerät übernehmen.
Das macht er in der Regel genau ein einziges Mal ... und hier geht m.E. Sicherheit vor Bequemlichkeit und das heißt, so ein Kennwort hat mind. 16 Stellen (alphanumerisch, am besten Base64-Zeichensatz, dann gibt es auch wenige Probleme mit ASCII > 128 oder anderen Zeichensätzen) und das ist auch schon ein Kompromiß aus Sicherheit und Bequemlichkeit für den Kunden (beim WLAN-Kennwort sind es ja inzwischen auch 20 Ziffern, die AVM erst einmal vorgibt). Wenn das einem Kunden nicht passen sollte und er unbedingt eigene Kennwörter vergeben will (und sei es dreist, weil ihm persönlich 16 Zeichen zu wenig sind), dann muß er eben zu einem Editor greifen (oder AVM erlaubt beim "Editieren" dann doch wieder die Vergabe eines eigenen, aber eben nicht beim Anlegen, was 90% schon davon abhält, da mit "test1" einzusteigen). Bei 16 Zeichen könnten wirklich nur noch ausgesprochen paranoide Zeitgenossen von einem per se unsicheren Kennwort reden.
-Zum zweiten ... leider wird auch nie so richtig kommuniziert von AVM, was sich bei dieser ganzen Protokollierung nun wann ändert (bzw. ändern soll) - oder ich kann das nur nie finden, weil ich mich zu blöd anstelle.
Die Protokollierung beim FTP-Server ist (nach den veröffentlichten Quellen) ja tatsächlich vorgesehen (wenn auch in einer Routine, die (vermutlich) nicht explizit/exklusiv für den FTP-Server geschaffen wurde, dazu komme ich später) ... sie funktioniert nur leider nicht im Ansatz (die Nachricht 460 dürfte eine Ausnahme bilden, die kommt auch aus dem ftpd selbst) und vermutlich hat das schon sehr lange niemand mehr wirklich getestet bei AVM - ganz im Gegenteil.
Da wurde zwar zur 06.20 hin die Art des Aufrufs von "eventadd" entschärft und von "system()" auf "execl()" umgestellt, damit da keine "command injection" mehr möglich ist. Vorher (bei der 7490 bis zur 06.05) gab es da einen Aufruf:
Code:
static void Event(unsigned id, const char *display_name)
{
char buf[256];
snprintf(buf, sizeof(buf)-1, "/sbin/eventadd %u %s", id, display_name);
buf[sizeof(buf)-1] = '\0';
system(buf);
}
und man kann sich ja leicht ausmalen, was man mit einem in "display_name" eingeschmuggelten Shell-String da bewirken könnte (da spielte es auch keine Rolle, ob das "eventadd" erfolgreich gewesen wäre oder nicht, da hilft es also auch nicht, daß die ganze Protokollierung ohnehin nicht klappt).
Das hat man - wie gesagt - geändert, an den anderen Stellen bzgl. der Protokollierung mit den Event-IDs 7xx kann man (bzw. ich) da nichts sehen ... daher die Feststellung "ganz im Gegenteil", die sich natürlich auf das Testen der Änderung beim Ersetzen von "system()" bezog - dabei hätte die fehlende Protokollierung ja auffallen müssen.
Wenn ich es richtig in Erinnerung habe, war aber zumindest beim FTP-Server das (externe) Einschmuggeln von Shell-Code in den Benutzernamen beim (vergeblichen) Protokollieren nicht ganz so einfach, weil bereits vorher nach dem Benutzernamen gesucht wurde (beim Mapping vom AVM-Namen auf den Linux-Benutzer) und es deshalb nie bis zur Protokollierung kam.
Aber der gesamte Code in logincontrol.c könnte (und da geht die Spekulation dann auch schon los) natürlich genauso bei den Versionen vor 06.20 noch an anderen Stellen in der Firmware benutzt werden und wenn man sich ansieht, daß es in der Firmware eine libavmacl2.so gibt, dann kann man auch annehmen, daß andere Komponenten sie benutzen:
Code:
# grep -r libavmacl2
Binary file sbin/ftpd matches
Binary file sbin/smbd matches
Binary file lib/libwebusb.so.0.0.0 matches
Binary file lib/libavmacl2.so.0.0.0 matches
Binary file usr/www/cgi-bin/nasupload_notimeout matches
Binary file usr/share/ctlmgr/libctlusb.so matches
(das ist die 06.05 der 7490). Hier führte dann aber jeder Versuch, die folgende Routine:
Code:
void LoginControlWrongPassword(const char *display_name, int from_internet)
{
if (!display_name || !IsOEM_tcom()) return;
struct record *r = LockRecordWithCreate(display_name);
if (!r) {
return;
}
if (r->blocked && !IsStillBlocked(r->blocked)) {
// reset
r->blocked = 0;
r->failed_logins_local = 0;
r->failed_logins_extern = 0;
}
if (from_internet) r->failed_logins_extern++;
else r->failed_logins_local++;
if (r->failed_logins_local > 5 || r->failed_logins_extern > 5) {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
r->blocked = ts.tv_sec + BLOCK_TIME; // login blocked for some time
Event(from_internet ? 718 : 717, display_name);
}
WriteAndUnlockRecord(r);
}
mit einem vielleicht doch nur unzureichend geprüften "display_name" aufzurufen, beim sechsten falschen Login-Versuch zur Ausführung von zusätzlichem Shell-Code im "display_name" ... nicht vergessen, ist in aktueller Firmware Geschichte und damit nicht mehr akut - nur ältere Versionen sind eventuell(!) betroffen.
Jetzt könnte man mit sehr viel Geduld zwar noch im smbd nachsehen, ob da alles korrekt ist ... bei den anderen drei Vorkommen (die vierte Datei ist ja die Lib selbst) beißt man aber (zumindest in Quelltext-Form) ohnehin auf Granit und damit lohnt sich auch der Blick in den smbd nicht.
Zwar müssen die auch nicht unbedingt eine der "LoginControl..."-Funktionen mit Protokollierung von Ereignissen aufrufen, dafür ist es nicht auszuschließen, daß AVM-Komponenten ähnlichen Code auch direkt benutzen. Die oben zu sehenden Binärdateien für die beiden ausführbaren Dateien (ftpd und smbd) sind ja auch diejenigen, die von AVM als Source-Code veröffentlicht werden müssen und wo die Verwendung einer gesonderten Library anstelle der Interprozess-Kommunikation mit dem ctlmgr wohl auch darauf zurückzuführen ist, daß AVM ansonsten diesen IPC-Mechanismus (hinter dem "msgsend") hätte offenlegen müssen. Da braucht es allerdings dann auch keinen Aufruf von "eventadd" als externes Kommando, weil man da gleich die passenden AVM-Libraries linken kann. Trotzdem sind solche Spekulationen m.E. durchaus erlaubt ... sichtbare Fehler an der einen Stelle sind eben in sehr vielen Fällen auch darauf zurückzuführen, daß da jemand vorhandenen Code falsch angepaßt hat nach dem Kopieren.
Daher bitte auch diese - wirklich nur theoretische - Schwachstelle nicht damit verwechseln, daß ich irgendwie behaupten will, man könne sie konkret ausnutzen (und schon gar nicht von außen). Solange immer alle, die an solchem Code mitarbeiten oder den von jemand anderem benutzen, die entsprechenden Vorsichtsmaßnahmen auch einhalten, sind selbst solche Stellen im Code noch kein echtes Problem ... erst beim ersten Programmierer, der dann seinerseits eben den Benutzernamen nicht bereits vorher einer Validierung unterzogen hätte, würde das zum Problem ... und genau deshalb vermeidet man solche unsicheren Konstrukte besser von Beginn an, dann kann kein anderer später an solchen Stellen in die Falle laufen.
Man kann nur konstatieren (und sei es auch nur aus reiner Vorsicht), daß man eben bei den Modellen, wo AVM keine Updates mehr ausliefert, selbst Hand anlegen kann/soll/muß ... meine 7270v3 ist eben so ein Kandidat.
Für die 06.06 gibt es kein OpenSource-Paket bei AVM und damit muß man erst einmal unterstellen, daß sich da nichts geändert hat und ein Blick in die Firmware zeigt das auch:
Code:
# strings lib/libavmacl2.so | grep eventadd
/sbin/eventadd %u %s
Das ist die 06.06 und da bleibt einem dann nichts weiter als Gottvertrauen (oder AVM-Vertrauen, wobei ich das nicht unbedingt gleichsetzen würde), daß da niemals ein Aufruf von "LoginControlWrongPassword()" mit einem unzureichend geprüften Benutzernamen erfolgt (da reicht auch keine vorherige Prüfung in irgendeinem HTML-Formular per Javascript).
Oder man geht eben selbst hin und ändert die libavmacl2.so aus reiner Vorsicht selbst (für die gibt es tatsächlich die Quellen), daß da auch nichts mehr passieren kann in den älteren Versionen.
Das war jetzt ein Beispiel für eine potentielle Lücke, für die kein Stillschweigen vereinbart war ... AVM hat eben viele (fast alle) der unsicheren Aufrufe von Shell-Kommandos aus den eigenen Komponenten heraus so überarbeitet, daß da auch bei unzureichender Prüfung der Eingaben nicht mehr direkt ein Ausführen von Kommandos möglich ist. Es gibt fast keine Aufrufe von "system()" mehr, wo dann eben die Shell automatisch aufgerufen wurde und auch die exec()-Aufrufe für /bin/sh (die natürlich ähnliche Probleme erzeugen können, wenn da Parameter nicht richtig geprüft werden) sind deutlich weniger geworden (noch nicht vollkommen verschwunden, aber auch nicht jeder dieser Aufrufe hat noch eine Zeichenketten-Ersetzung in der Parameterliste).
Der FTP-Server wäre jetzt per se auch der einzige Service gewesen, der von extern zugänglich sein könnte ... alle anderen Funktionen (event. mit Ausnahme von nasupload, das müßte ich glatt noch einmal prüfen) sind normalerweise nur von intern zugänglich und damit könnte man auch nur von innen den Streßtest für die Validierung der übergebenen Benutzernamen machen.
Das lohnt sich aber nicht mehr wirklich ... es ist wesentlich einfacher, einfach generell auf FRITZ!Boxen mit Firmware < 06.20 zu verzichten (und auch meine 7270v3 dient eigentlich nur noch zum (erweiterten) Testen und als Notnagel, falls das DSL mal nicht will - hier geht ohnehin kein eingehender Verkehr von extern wegen des Mobilfunks).
Aber für den Angriff von innen (sprich, für das Erlangen eines Shell-Zugriffs auf eine 6360) konnte das eben auch verwendet werden ... wenn man in einer so alten Firmware einen passenden Benutzernamen eingetragen hatte (z.B. "ftpuser$(/var/media/ftp/<usb_stick>/my_command.sh)", über den FBEditor kein großes Kunststück und auch auf anderen Wegen möglich, die S44-hostname-Lücke war ja ähnlich zu initiieren) dann konnte man den selbstverständlich auch beim Login in den FTP-Server verwenden (das geht selbst bei aktuellen Versionen noch, kann jeder selbst austesten) und sich sogar erfolgreich anmelden. Damit kam dann irgendwann der Versuch, das erfolgreiche Login auch zu protokollieren (selbst wenn das nie funktionierte, erhält man doch eine Vorstellung, wie gefährlich solche Relikte dann sein können).
Die Quellen dazu gab es irgendwann auch mal von AVM, ich weiß nicht mehr genau, ob ich dazu erst anfragen mußte oder ob die generell verfügbar waren, heute sind sie es wohl nicht mehr - jedenfalls finde ich die Datei nicht bei AVM auf dem FTP-Server.
Aber das ist tatsächlich derselbe Code wie bei den DSL-Modellen und damit kann man auch dort sehen, daß da bei erfolgreichem Login (je nach extern oder intern) die Nachricht mit der Event-ID 713 oder 715 ausgegeben werden soll und das führt dann wieder zur Ausführung der (Skript-)Datei unter "/var/media/ftp/<usb_stick>/my_command.sh", die man natürlich vor dem Login passend auf einem USB-Stick bereitstellen muß (Linux-Dateisystem und die passenden Rechte sind Pflicht).
Code:
void LoginControlPasswordOk(const char *display_name, int from_internet)
{
if (!display_name || !IsOEM_tcom()) return;
if (from_internet) Event(701, display_name); // EVENT_ID_TCOM_FW102
[COLOR="#FF0000"] Event(from_internet ? 715 : 713, display_name);[/COLOR]
struct record *r = LockRecordIfExists(display_name);
if (!r) return;
short modified = 0;
if (!from_internet && r->failed_logins_local) { modified = 1; r->failed_logins_local = 0; }
if (from_internet && r->failed_logins_extern) { modified = 1; r->failed_logins_extern = 0; }
if (r->blocked) {
r->blocked = 0;
modified = 1;
}
if (modified) WriteAndUnlockRecord(r);
else UnlockRecord(r);
}
Aber diese alten Versionen sind ja nun wenigstens bei den KNB ebenfalls Geschichte ... damit kann man das auch mal zeigen, wie so ein Relikt an ziemlich unerwarteter Stelle einen Angriff (hier eben zum Rooten des DOCSIS-Gerätes) ermöglichen konnte.
Da ich selbst auch keine 6360 mehr habe, ist diese "Story" nur aus dem Gedächtnis und ich würde die Hand nicht ins Feuer legen, daß es 1:1 so funktionierte. Das ist fast drei Jahre her und ich habe seitdem so viele Tests an anderen Stellen gemacht, da wirft man dann auch mal versehentlich die Modelle und/oder Versionen durcheinander. Wenn sich jemand mit einer 6360 mit einer ausreichend alten Firmware-Version findet, kann er ja mal ausprobieren, ob das skizzierte Vorgehen bei seiner Version noch funktioniert. Mein Firmware-Archiv geht nur bis zur 06.05 und selbst das kann ich nicht wirklich testen, seit mir die Box dazu fehlt.
-Zurück zur Protokollierung ... selbst die Nachricht 460 aus dem FTP-Server heraus ist eher witzlos für den normalen Benutzer. Sie enthält zwar die Angabe, daß ein erfolgreiches(!) Login für FTP aus dem Internet erfolgte, aber dann auch nur, von welcher IP-Adresse aus dieser Zugriff erfolgt(e). Die wesentlich wichtigere Information wäre aber (meine Meinung) der verwendete Benutzername. Wer kennt schon beim mobilen Internet-Zugang seine eigene IP-Adresse und kann damit einschätzen, ob er das selbst war (oder eine App auf seinem Smartphone im Hintergrund, die das durchaus darf) oder ob es doch ein fremder Zugriff auf ein unzureichend gesichertes anderes Konto war.
-Die fehlende Benachrichtigung für fehlgeschlagene NAS-Logins (bzw. die nicht funktionierende ... warum das so ist, kann man sich in den Quellen von AVM (avmacllib2/logincontrol.c) ansehen) zieht sich inzwischen endlos durch die Historie (mindestens seit 06.05, eigentlich schon seit der 05.59 bei der 7490 nachweisbar) ... im Rahmen eines anderen Problems habe ich die gerade noch einmal an AVM gemeldet (bzw. bei dieser anderen Meldung erneut erwähnt).
Manchmal geht so etwas als (anonymes) Feedback zu Labor-Versionen ja auch unter ... wobei das bei vielen anderen kleinen Problemen ja (früher zumindest) auch so war - die Verbesserungen bei den AVM-Bemühungen konnte man zwischenzeitlich konstatieren, im Moment habe ich wieder die Befürchtung, es geht in die Gegenrichtung beim offeneren Umgang mit Problemen der Firmware.
Meiner Meinung nach sind da aber auch die Kunden nicht ganz unschuldig ... wenn sich aus der Veröffentlichung beseitigter Lücken für 7 Jahre alte Router (meinetwegen auch 5 Jahre, falls die 7270v-irgendwas länger vertrieben wurde) beim Kunden dann die Frage ergibt: "Und was ist mit meinem Router, muß ich etwa nach nur fünf Jahren jetzt schon den nächsten anschaffen?", dann stimmt für mich (auch wieder nur meine Meinung) etwas mit der Erwartungshaltung der Kunden nicht.
Die Geräte haben 5 Jahre Herstellergarantie, mir fällt beim besten Willen kein Grund ein, wieso ein Hersteller bei diesen (vergleichsweise auch noch preiswerten) Geräten noch Firmware über diesen Zeitraum hinaus aktualisieren sollte. Das macht auch kein anderer Hersteller, da ist (mit sehr viel Glück) vielleicht noch in den ersten zwei Jahren ein Security-Update drin ... wenn ich dann ab und an lese, daß man wegen genau dieses (unausgesprochenen) Update-Versprechens zu einem AVM-Gerät gegriffen hätte, dann frage ich mich da schon, ob die anderen Preise wirklich so niedrig sind, daß man die Rechnung "eine AVM-Box in 5 Jahren ist immer noch teurer als 2,5 andere Router in diesen 5 Jahren" aufmachen könnte oder sollte (vom Funktionsumfang will ich nicht schreiben, da sind die Bedürfnisse des einzelnen Kunden ohnehin entscheidend und nicht zu verallgemeinern).
Auf das (bei sehr vielen) auch regelmäßig aktualisierte Smartphone habe ich oft genug Bezug genommen ... warum geht das bei einem (preiswerter zu habenden) Router nicht ebenfalls? Wenn dann ein Shitstorm losbricht, wie AVM es wagen kann, nach 5 Jahren keine weiteren Updates mehr zu liefern, dann muß man sich auch nicht wundern, wenn das Management bei AVM wieder das Visier fallen läßt.
Am Ende schaden solche Rufe (auch wieder nur mein Standpunkt) dann den Kunden, die neuere Boxen besitzen und dank einer "Verschwiegenheit" in Bezug auf vorhandene Probleme nur raten können, ob ihr Internet-Zugang nun sicher ist oder nicht.
Dieser Fall hier (also die AVM-Warnung, auf der dieser Thread basiert) ist nahezu ein klassischer Fall der selbsterfüllenden Prophezeiung, daß so etwas immer negativ für das Image ausgehen muß. Dank nur sehr schwammiger Fakten (also einer eher halbherzigen Warnung) in der Meldung rätselt die ganze Welt herum, wo diese neue Lücke nun wieder liegen möge (für die dürftige Faktenlage ist allerding ganz klar AVM verantwortlich), aber die Alternativen wären (m.E.) nur zwei gewesen: Hinsetzen, ducken und die Klappe halten (wird schon nicht so schlimm werden) oder tatsächlich die Versionen zu benennen, die angreifbar sind (ohne genaue Details zur Lücke).
Aber dann wären eben sofort wieder die Fragen gekommen, was denn nun die Besitzer der ganzen alten Boxen (die hoffentlich in absehbarer Zeit den elektronischen Tod erleiden, hier ist Langlebigkeit ein echter Fluch) machen sollen ... auf die Idee, sich dann einfach eine neuere FRITZ!Box zuzulegen, kommen wahrscheinlich die wenigsten.
Nun will ich auch diejenigen nicht aus den Augen verlieren, die sich keinen neueren Router leisten
können ... denen wäre dann trotzdem mit einer besseren Risikoabschätzung (und möglichen Gegenmaßnahmen) eher geholfen und diejenigen, die sich keinen neuen Router zulegen
wollen, für die kann ich persönlich tatsächlich kein Mitleid aufbringen. So ein Router ist kein wirkliches "Haushaltsgerät", was man einmal anschafft und das dann auch mal 10 Jahre und länger seinen Dienst tun sollte, wenn es eine entsprechende Qualität hat ... schon die technische Entwicklung dürfte das in vielen Fällen verhindern.
-Zurück zum Support ... ich habe seit der Umstellung der Feedback-Funktion für die Labore zugegebenermaßen dieses Formular eigentlich nicht mehr benutzt - kann denn jemand tatsächlich positive Erfahrungen berichten, wenn er dort ein Problem (keinen Verbesserungsvorschlag) meldet?
In Anbetracht vieler eher negativer Feststellungen hier im Forum - vor allem bei "langfristigen Problemen" - habe ich da zugegebenermaßen meine Vorbehalte, ob sich der zu investierende Aufwand für eine solche Meldung tatsächlich rentiert - mit einer "danke für Ihr Feedback, wir melden uns bei Nachfragen"-Mail, einer ausbleibenden Nachfrage und trotzdem regelmäßig weiterhin neu erscheinenden, "problembelasteten" Labor-Versionen ist es ja eher unwahrscheinlich, daß da jemand bei AVM diese Meldungen auch wirklich liest (ja, das ist unzulässig verallgemeinert - absichtlich ... eine öffentlich einsehbare Liste von akzeptierten, registrierten und zu behebenden Problemen (das muß ja nicht immer sicherheitsrelevant sein) würde hier wahre Wunder bewirken). Da hat dann so ein länglicher Beitrag im IPPF vermutlich mehr Leser ... leider.
Mein Fazit (sorry, ist wieder mal überlang geworden): Der Einsatz von älterer Firmware ist - genau wie AVM es (wenn auch nur sehr allgemein) anmerkt - risikobehaftet. Es wurden viel mehr (potentielle) Lücken geschlossen, als in irgendeinem Changelog zu finden sind ... insofern ist die (leider auch hier noch anzutreffende) Haltung, auch mal mit älterer Firmware ins Internet zu gehen, nicht so auf die leichte Schulter zu nehmen.
