[Info] Neue Sicherheitshinweise von AVM

Erst einmal meine ganz tiefe Verbeugung vor den Bemühungen der Security-Leute bei AVM.

Die neue Seite

https://avm.de/service/sicherheitshinweise/

ist eine echte Errungenschaft - ein Zeichen für die Kunden, daß es bei AVM auch aktive Bemühungen um die Sicherheit der Produkte und einen ständigen Prozess der Verbesserungen an dieser Stelle gibt - und ich würde viel Geld einsetzen bei einer Wette, daß es bis zur "Genehmigung" einer solchen Seite ein steiniger Weg war, bei dem viele Widerstände im Unternehmen zu überwinden waren.

Auf der anderen Seite bekräftigt es die von mir ab und an hier vorgetragene Meinung, daß es eben keine so richtig gute Idee ist, sich Updates generell zu verweigern, weil einem ein neues Feature nicht zusagt oder ein liebgewonnenes nicht mehr vorhanden ist.

Für den ersten Punkt fällt mir auch keine Lösung ein, außer ein solches Feature dann eben nicht zu benutzen. Daß dieses nicht immer geht, ist mir auch bewußt ... aber auch bei anderen Produkten ist der technische Fortschritt und daraus resultierende Änderungen in so gut wie jeder Dokumentation ausdrücklich vorbehalten und - neben einer (sachlichen) Abgabe der eigenen Meinung zu solchen Änderungen beim Hersteller, die auch schon einmal entsprechende Auswirkungen haben kann, wenn es denn andere auch betrifft und eine kritische Masse überschritten wird (s. z.B. Samba bei der internationalen Firmware 06.0x der 7390) - muß man dann eben Vor- und Nachteile eines Updates abwägen und gerade dabei kann eine Seite wie die oben verlinkte eine wichtige Hilfe sein.

Für den zweiten Punkt (auch wenn ich persönlich nach wie vor bestimmte Streichungen (nmbd bei der 7390/7360SL) eher für einen Unfall als für ein absichtliches Vorgehen (zumindest aus technischer Sicht) halte) gibt es immer noch die Möglichkeit, sich die Firmware wieder so "hinzubiegen", daß sie den eigenen Vorstellungen entspricht. Da das auch für den Kunden mit einem entsprechenden Aufwand verbunden ist (wenn er nicht ohnehin schon weitere Änderungen vornehmen will), ist auch das sicherlich bei vielen eine "Einzelfall-Entscheidung" und auch dabei kann so eine Information wie oben ein entscheidender Punkt für oder gegen ein Update sein.

Aber zumindest kann nun hinterher auch kein "Update-Verweigerer" mehr sagen, er habe es ja nicht wissen können, wenn doch mit einer älteren Firmware bei ihm irgendein Sicherheitsproblem aufkommt, was AVM in neueren Versionen bereits gefixt hat.

Daß die Beschreibungen ein wenig schwammig sind, ist zwar nicht so richtig schön (falls jemand Security-Mailing-Listen abonniert hat, weiß er sicherlich, was ich meine), aber man muß auch Kompromisse eingehen können (und es war vermutlich nicht leicht, überhaupt so weit zu kommen) und auf der anderen Seite gibt es zu viele ältere Modelle "in freier Wildbahn", die weiterhin ein Problem haben. Das ist vollkommen normal und EOS ist EOS, das macht jeder Hersteller so ... wenn die Geräte jemandem zu lange halten, kann er ja beim Hersteller für eine "geplante Obsoleszenz" votieren.

Also mein (persönliches) Fazit: Chapeau - ein wichtiger Schritt hin zu mehr Transparenz und zu mehr Vertrauen beim (verständigen) Kunden, denn daß eine Software auch mal ein Sicherheitsproblem haben kann (was man dann eben behebt), ist in der heutigen Zeit eher Normalität (die Behebung beim A-400 rettet Leben, leider kosten dort Fehler auch welche - aber es zeigt eben auch, wo überall solche Fehler auftauchen können trotz sicherlich mehrfacher Kontrollen) und wenn ein Hersteller niemals Fehler in seinen Produkten hat (außer jeweils dem ganz großen Knall) bzw. dort keine zu behebenden Probleme auftauchen (die Publikation nach der Behebung ist ja vollkommen ausreichend), ist das - für mich jedenfalls - ein schlechtes Zeichen ... weil es eher heißen würde, daß dort niemand mit diesem Thema befaßt ist.

qwertz.asdfgh schrieb:

Das war mir gestern schon aufgefallen und hatte mich schon gewundert warum du dazu noch kein Thema eröffnet hattest...

Zum Vergrößern anklicken....

Beschäftigt und erst heute registriert ... dafür wird es heute wohl das neue modfs mit 06.35-Unterstützung noch geben - wenn nichts Unvorhergesehenes dazwischen kommen sollte.

@koy:
Was verunsichert Dich denn jetzt daran?

Da steht doch deutlich:

Bei manuellem Einspielen einer präparierten Firmware-Datei kann die Signaturprüfung nicht mehr umgangen werden. Das Einspielen einer Firmware-Datei erfordert die Kenntnis des Gerätekennworts .

Zum Vergrößern anklicken....

Wo ist da der Zusammenhang zur debug.cfg, Telnet und der Möglichkeit, über die "calllog"-Datei Kommandos auszuführen?

Und ja ... bei Deiner Version kann man mit einem präparierten Update-Image die Fehlermeldung "Firmware nicht von AVM" umgehen und Dir damit praktisch einen auf Dich zugeschnittenen Angriff unterjubeln, von dem Du nichts mitbekommen würdest. Es reicht vollkommen aus, Deinen Request für ein solches Image zum Updaten der Box abzufangen und Dir anstelle des AVM-Servers zu antworten. Das zweite Problem ist doch auch deutlich ... bei dieser Version ist es (mit bestimmten Vorbereitungen, die Du garantiert nicht in der Öffentlichkeit besprochen sehen willst) möglich, ein Update auch dann auszulösen, wenn man kein Admin-Kennwort für das Gerät hat. Was man aus der Kombination dieser beiden Sachen machen könnte, kannst Du Dir selbst ausrechnen. Was soll AVM denn nun machen? Wenn es für Dein Modell kein Update gibt, ist es eben EOS ... damit mußte man ja dann auch einmal rechnen. Nun weißt Du wenigstens, daß da ein potentielles Problem besteht und kannst Dir die Entscheidung, ob Du ein neues Gerät brauchst oder lieber mit diesen Problemen weiterlebst, gut überlegen -> der entscheidende Punkt ist doch, daß Du jetzt diese Entscheidung überhaupt treffen kannst.

EDIT: Und noch eine ernsthafte Bitte meinerseits ... wenn schon von den Leuten, die es eigentlich besser wissen sollten (und lesen können), solche Bemerkungen wie

Diese Sicherheitshinweise verunsichern mich...

Zum Vergrößern anklicken....

kommen, dann bestätigt das (meine Meinung) nur Vorbehalte/Gegenargumente in Bezug auf solche "security advisories". Das ist aber ein vollkommen normales Verhalten eines Software-Herstellers (daß AVM Hard- und Software macht, ändert daran nichts) und die Alternative dazu ist es nur, den Kunden "dumm sterben zu lassen". Ich hoffe inständig, daß das nicht Deine Ansicht ist und so bitte ich wirklich alle, die nur etwas Verständnis für diese Materie haben oder aufbringen können, sich - zumindest vorerst, bis die Akzeptanz bei AVM verbürgt/verbrieft/"was auch immer" ist - solche Bemerkungen gut zu überlegen bzw. vorher richtig zu lesen.

@koy:
Ich weiß natürlich nicht, mit welcher Firmware Du die 7360SL (von 1&1 ?) erhalten hast ... daher bezieht sich die Argumentation nur auf die Annahme, daß Du Deinerseits das Branding geändert hast und die internationale Firmware verwendest:

1. Es gibt die Möglichkeit, die 06.30 von AVM für die 7360SL zu verwenden (auch wenn die verlinkte Info-Datei auf dem AVM-Server noch eine alte ist), diese Version steht zur Verfügung. Ohne den Sicherheitshinweis würdest Du nicht einmal eine Ahnung haben (zumindest keine konkrete), daß Du dort angreifbar bist und Dir eine passende Reaktion überlegen mußt.

2. Was meinst Du bitte mit

koyaanisqatsi schrieb:

Mit anderen Worten: Was da nicht erwähnt wird, ist nicht der Rede wert.
Und obwohl meine 7360SL nicht EoS/EoL ist, ist sie es, weil ich eine Firmware benutze, ohne Info wie unsicher die ist.
Weil es AVM nicht wert ist, das irgendwo zu erwähnen.

Zum Vergrößern anklicken....

?

Willst Du da eine konkrete Anleitung sehen, wie es funktioniert? Die würdest dann sicherlich nicht nur Du lesen können (auch wenn ich es ja auch als "schwammig" empfinde) und das wäre dann tatsächlich eine Anleitung für einen (von einem Angreifer zu nutzenden) Exploit.

Ansonsten verstehe ich die Argumentation im o.a. Zitat nicht ... eigentlich nicht einmal, was Du da gerne wie anders sehen würdest. Vielleicht kannst Du das ja mal etwas konkreter fassen? "Was da nicht erwähnt wird, ist nicht der Rede wert." kann entweder eine (zufriedene) Feststellung sein, daß keine weiteren Sicherheitslücken bekannt sind oder ein Zweifel, ob es nicht noch viele weitere gibt. Letzteres ist nicht unwahrscheinlich, aber eine Veröffentlichung setzt nun mal als allererstes auch voraus, daß man selbst davon Kenntnis hat ... und natürlich auch, daß man einen Workaround oder sogar einen Fix hat. Aber das ist eigentlich genau das, was AVM auf der neuen Seite auch schreibt, insofern verstehe ich diese Reaktion absolut nicht.

Selbst wenn Du eine "originale internationale Version der 7360SL" besitzen solltest, hat sich doch für Dich die Situation nur marginal verändert (wenn Du nicht auf das deutsche Update gehen willst) ... Du weißt jetzt, daß die 06.03 ein Problem hat, was man vorher nur vermuten konnte. So blauäugig kannst Du nicht sein, daß Du vermutet hast, alle Versionen nach der 06.03 (die ist vom 11.02.2014) hätten nur "Kosmetik" betrieben und nicht auch andere Probleme gefixt. So dumm ist auch kein Angreifer ... und wenn Du jetzt etwas weniger gut schläfst, weil Du die Gewißheit hast, daß Dein Router angreifbar ist, dann ist das vielleicht Deiner Gesundheit abträglich, aber eine wirklich neue Situation bei der Bedrohung ist damit nicht verbunden. Wenn die 7360SL mit internationaler Firmware nicht EOS/EOM/EOL ist, wird es ja vermutlich auch noch ein reguläres Update geben (die internationalen hinken nun mal hinterher) und dann ist diese "Unsicherheit" auch bei Dir beseitigt.

koyaanisqatsi schrieb:

Und was soll ich schreiben? Der Versuch dieses Gefühl zu vermitteln endete (unbefangen) in einer Art: PANIC
...dann kann es schon mal vorkommen, dass ich so einen Blödsinn von mir gebe.

Zum Vergrößern anklicken....

Warum denn diese "panische Reaktion"? Das ist es ja, was ich nicht verstehe ... wenn da "PANIC" entsteht anstelle von "OK, THERE'S SOMETHING TO DO NOW", dann mag das bei einem "durchschnittlichen Kunden" noch verständlich sein (und sichert dem FRITZ!Box-Versteher das Leben bzw. andere "Vergütungen" - vielleicht geht da ja was bei der hübschen Nachbarin, mit einen Essen selbstverständlich nur), aber auch das ist dann eher das Ergebnis sehr selektiven Lesens seitens dieses Kunden -> es steht eigentlich alles deutlich (und für mich ehrlich gesagt auch unmißverständlich) da, was man wissen muß.

Was fehlt, ist die konkrete Beschreibung, die muß auch nicht sein bzw. sollte es (bei einer auch durch Dritte zu nutzenden Lücke und das kann der Angreifer im LAN auf dem Relay sein) auch nicht sein. Das ist allerdings tatsächlich immer ein schmaler Grat, wieviel man da veröffentlicht und wie konkret man das beschreibt ... das wird sicherlich auch von Fall zu Fall bei einer solchen Beschreibung entschieden. Besser als das "weitere Sicherheitsverbesserungen" in der info.txt ist es allemal.

Dann möchte ich mich auch dafür entschuldigen.
...und überleg mir das Ganze nochmal.

Zum Vergrößern anklicken....

Ich will ja nur vermeiden, daß "eine Sau durch's Dorf getrieben wird". Ich kann mir bei Dir die "PANIC" auch nur so erklären, daß Du das "behoben ab" nicht richtig interpretiert hast und das eigentlich umgekehrt als Liste der angreifbaren Versionen lesen würdest wollen? So eine Art "Nachschlagewerk", ob und für welche Probleme Deine 06.03 noch anfällig ist? Die Liste von eisbaerin mit den Änderungen seitens AVM könnte man vielleicht um solche Informationen ergänzen, wobei ich den Sinn nicht so richtig sehe ... es gilt (wie woanders eben auch) eigentlich immer der Hinweis, die neueste veröffentlichte Firmware zu verwenden.

Zu den "Kröten" der "entfernten Funktionen" habe ich schon in #1 etwas geschrieben ... wenn Du als "Bewältigungsstrategie" für den fehlenden nmbd bei der 7360SL die internationale Firmware verwendest, gibt es andere (u.U. auch wirklich bessere) Lösungen. Wenn die Verwendung der internationalen Firmware andere Gründe hat, mußt Du die eben gegen die potentielle Angreifbarkeit abwägen und für Dich selbst entscheiden, welches die beste Variante ist.

Zumindest ist die Annahme "alles ist Wölkchen" bei Deiner 06.03 damit vom Tisch und wenn für AVM die "7360SL-int" tatsächlich noch ein zu supportendes (gibt es so etwas überhaupt?) Gerät ist, sollte eine Anfrage an den Support (mit Gerätenummer, die aber natürlich dann auch Auskunft über die "ursprüngliche Konfiguration" gibt) eine passende Antwort erbringen. Ich habe gar keine Liste mit EOS-Terminen für internationale Modelle auf Anhieb gefunden, damit kann ich da nur spekulieren.

Ist zwar OT, aber ich bin TE und führe das einfach mal fort:
Verstehe ich das richtig und Du verwendest die gerade deshalb, weil sie kein Windows-Netzwerk unterstützt?

Über die Möglichkeit des "customizings", bei dem Du das dann eben selbst entfernst (wenn nicht schon das Setzen von CONFIG-Variablen ausreicht), brauchen wir sicherlich nicht reden.

Ich kann auch nur das lesen, was AVM da geschrieben hat ... weiß aber u.a. um eine bestimmte Sicherheitslücke (vor Sept. 2014), wo besonders vollkommen neue (unkonfigurierte / "resettete (tettettette) ") Boxen bereits vor dem Setzen eines Kennworts bei der Ersteinrichtung angegriffen werden konnten.

Wenn ich mich nicht "vertestet" habe (die Rückmeldungen zu behobenen Schwachstellen vor Mitte/Ende Mai 2015 sind nicht nur mäßig, sie sind praktisch nicht vorhanden - so nach dem Motto (sinngemäße Aussage): Teste doch einfach, dann merkst Du schon, ob die behoben sind oder nicht.), dann ist das u.a. so behoben worden, daß nicht nur keine unsignierten Updates mehr eingespielt werden können, solange kein Kennwort gesetzt ist (das war schon länger so, aber bei einer "frischen Box" ist das auch nur bedingt hilfreich, wenn der Angreifer eben einfach eines setzt, das Update macht und die Box dann wieder auf Werkseinstellungen setzt), sondern jetzt nimmt die Firmware keine Updates (und hoffentlich auch keine Einstellungen per Restore? Müßte ich glatt noch einmal testen ...) mehr an, solange kein Kennwort gesetzt wurde.

Wie gesagt, auch nur eine kleine Hürde ... aber immerhin eine, die "alte Angriffe" zumindest bis zu einem Update des Exploits unterbindet. Das betrifft in diesem konkreten Falle ja aber ohnehin nur Angriffe, bei denen der Angreifer schon im LAN ist, denn ohne Konfiguration hat die Box logischerweise keinen Internet-Zugriff (solange wir über DSL/PPPoE reden, bei DHCP ist das schon wieder etwas anders, aber das ist ja nicht der "Auslieferungsmodus" einer Box mit Werkseinstellungen - wie es bei der 4020 aussieht, weiß ich nicht) und damit auch das Internet keinen Box-Zugriff.

Der "richtige Schutz" vor solchen LAN-seitigen Angriffen kann es eben nicht nur sein, irgendwelche "softwaregestützten" Hürden aufzubauen, eine physische Aktion seitens des Benutzers/Besitzers bei der Ersteinrichtung (eben z.B. das Drücken von Tasten, damit die Box überhaupt in den Modus "Erst-/Neukonfiguration" geht) wäre eine weit bessere Lösung, die auch das "Fernkonfigurieren" über TR-069 ohne Kenntnis oder sogar gegen den Willen des Benutzers verhindern könnte (zumindest als optionales Feature). Wie weit die Provider als OEM-Kunden dabei mitspielen, weiß man natürlich nicht ... und die meisten Kunden sind ja ohnehin froh, wenn das "einfach nur funktioniert". Wenn die könnten, wie sie wollen, würden sie auch noch die "surveillance station" automatisch mit entsprechendem Internetzugriff einrichten lassen, weil es "so schön bequem" ist.

PS: Das neue Feature "Gerätekennwort" hilft natürlich (begrenzt oder richtig, je nach Umsetzung) auch ... ich habe noch keine Box mit einem solchen Kennwort in der Hand gehabt. Wenn das tatsächlich nur hinten aufgedruckt ist und nicht auch im Urlader-Environment landet (eine vermutlich passende Variable dafür gibt es dort schon länger, den Namen müßte ich jetzt auch erst wieder nachsehen), ist das natürlich auch eine Methode anstelle der "Buttons" ... wobei das TR-069 sicherlich nicht interessieren wird, ob der ACS das "Gerätekennwort" (wenn es so genannt werden sollte, da ist vielleicht die Wortwahl von AVM in der Sicherheitsseite etwas unglücklich/zweideutig?) kennt. Wenn dieses Kennwort dann auch beim Zugriff über EVA ("QUOTE GETENV" bzw. "get env") nicht gelesen werden kann, wäre das ja ein passabler Schutz ... ohne passende Box eben schwer einzuschätzen. Läßt sich das über EVA auslesen (wie die anderen Angaben auch, damit wird ja das TFFS "präpariert" beim Recovern), ist das zwar eine weitere Hürde, aber eben noch nicht wirklich sicher.

Daniel Lücking schrieb:

Da wurde mir dann auch das Kennwort der Box-Oberfläche mit ausgegeben.

Zum Vergrößern anklicken....

Na ja, dann ist das wahrscheinlich genau die Variable, die ich in Erinnerung hatte. Wenn Du das Kennwort mit dem ruKernelTool auslesen kannst, kann das ein Angreifer beim Start der Box natürlich im Hintergrund genauso machen ... das kostet max. 10 Sekunden zusätzliche Startzeit bei der Box und würde im ungünstigsten Fall von Dir gar nicht bemerkt. Dann habe ich mit meiner Skepsis in Bezug auf die (absolute) Wirksamkeit dieses zusätzlichen Schutzes ja nicht so sehr daneben gelegen ... schade.

Ich weiß zwar nicht genau, wie die neue Einrichtung jetzt ablaufen soll (sehe auch bei der Beschreibung in #19 nicht richtig durch), aber von einer VPN-Verbindung in diesem Zusammenhang höre ich das erste Mal ... das wäre in der Tat eine spannende Neuerung, aber ich kann mir das noch nicht so richtig vorstellen. TR-069 läßt sich ja auch über TLS sichern und auch bei einer VPN-Verbindung zum ACS des Providers bleibt ja das Problem der "remote identity", das wieder nur über Zertifikate gelöst werden kann.

Auch das mit dem Auslesen des "Box-Benutzer-Passworts" über FTP kann ich im Moment nicht so richtig einordnen ... wenn hier EVA gemeint ist, sind da nur sehr wenige Ausgaben möglich und eigentlich kein Zugriff auf Einstellungen innerhalb der Box (abgesehen vom Urlader-Environment), denn neuere Loader lassen m.W. auch das Auslesen von MTD3/MTD4 nicht mehr zu - dort ist nur Schreiben implementiert.

Aber - wie gesagt - ich weiß auch nicht genau, was die "Neuerungen rund um die Provider-Einrichtung" sind und wie sich diese auswirken ... dafür fehlt einfach die Zeit, das alles auch noch auszutesten. Mein letzter Test einer "Grundausbildung" neuer FRITZ!Boxen diente noch der Feststellung, daß der WLAN-Assistent zwar das Umbenennen des eigenen Netzes empfahl, wenn er jemals zum Zuge kam ... aber das leider bei der Einrichtung mit 1&1-Startcode nie der Fall war, weil da immer schon vor dem (siebten, wenn die Erinnerung nicht trügt) Schritt zur Individualisierung der SSID ein Neustart erfolgte, nach dem der Assistent nicht automatisch neu anlief.