AVM-Sicherheitslücke "manuell!fixen??

[df8oe]

Hallo an alle,

ich betreibe eine FB mit Freetz. Die Firmware wird beim Start von eine angeschlossenen USB-Festplatte geladen - die auf der Box befindliche Firmware wird nur benötigt, um das "eigentliche OS" nachzuladen. Es handelt sich um ein stark modifiziertes System - ein "Neubauen" auf Basis der neuesten AVM-Firmware wäre sehr aufwändig. Da stellt sich mir die Frage, ob es nicht möglich ist, die Sicherheitslücke "manuell" zu patchen. Schliesslich liegt das System ja auf einer HDD und kann ohne neubauen z.B. mit dem mc verändert werden (wenn es "nur" eine config oder geänderte Rechte sind) oder durch überschreiben evtl. betroffener Binaries....


Weiss jemand, ob das geht???

Gruß
df8oe

 

[HabNeFritzbox]

Klar, die Angreifer wissen es oder AVM.

Wenn es nicht selbst herausfindest, bleibt nur Update oder Bequemlichkeit mit Risiko in Kauf nehmen.

 

[princenewton007]

Der Hanno hat die genauen Details.

 

[olistudent]

Du kannst versuchen einen Diff zwischen deinen Binaries und den Binaries der neuen Firmware zu machen und alle unterschiedlichen Dateien auszutauschen...

Ob man die Lücke mit einer Änderung der Konfiguration schließen kann ist bis jetzt nicht bekannt. Würde ich aber, nachdem was ich bis jetzt gelesen habe, bezweifeln.

Gruß
Oliver

 

[df8oe]

Es sieht wohl in der Tat so aus, als wenn ich das Binary, das die Auswertung der Inputs auf Port 443 auswertet, finden muss und ggf. nur dieses eine Binary tauschen muss. Leider ist es kein "Apache", da hätte ich jetzt einfach eine htaccess angelegt und gut ist...

Gruß
df8oe

 

[koyaanisqatsi]

Moin, die einfachste Art das Loch zu stopfen ist: mount -o bind EinLeeresVerzeichnis /var/ /usr/www
Mit freetz sehr simpel durchzuführen, und auch wieder rückgängig zu machen mit: umount /var/ /usr/www
Falls es keinen einfacheren Weg gibt den Webserver zu stoppen.

 

[df8oe]

Das Verzeichnis /var/www gibt es auf der 7360SL nicht. Zur Info für alle Mitleser:

/var/html (ist das Webserververzaichnis)
/var/html.myfritz
/var/html.nas
die beiden letzteren erklären sich von selbst - denke ich...

In all diesen Verzeichnissen (sind übrigens Symlinks) liegen haufenweise cgis und luas. Irgendwo dort schlummern die Nachlässigkeiten seitens AVM.

Wie kann man etwas, was von Aussen offen ist, schludrig parsen?? Hier muss ALLES abgefangen werden, was nicht zur gewünschten Funktion gehört. Egal, ob es schädlich ist / sein könnte / oder auch nicht. Grob fahrlässig, würde ich sagen...

Gruß
df8oe

 

[df8oe]

Nachtrag:


Wenn ich nach Aussen keine Ports offen habe, kann ein Angriff ja nur aus dem LAN kommen. Wenn ich jetzt dafür Sorge, dass die URL http://fritz.box (oder fritz.nas oder myfritz) nicht auf die IP-Adresse der Box zeigen, sondern z.B. auf einen Honeypot - dann müsste ich doch bei geschickter Echtzeitauswertung des Honeypots sofort sehen, wenn beim Aufruf einer Webseite dort irgendwas "reingefallen" ist - oder nicht? Zusätzlich wären Angriffe auf diese Weise auch nicht mehr durchführbar...

Gruß
df8oe

 

[RalfFriedl]

Es sollte oben wohl /usr/www heißen. Dann ist das komplette Web-Interface nicht mehr ansprechbar.

Das Umleiten von fritz.box usw. sollte helfen, schließlich kennt keiner die IP Deiner Box, wenn sie nicht 192.168.178.1 ist.

 

[koyaanisqatsi]

Danke, für den Hinweis: /usr/www
Hab nämlich den Fernzugriff abgeschaltet und konnte grad nicht sicher nachgucken, verbessert.

 

[SF1975]

Hallo,

... wenn sie nicht 192.168.178.1 ist.

Was wäre mit der "Notfall-IP"? Ist die nicht überall bekannt und kann nicht geändert werden?

 

[koyaanisqatsi]

Die Notfall IP ist lan:0 und kann mit ifconfig lan:0 down abgeschaltet werden.
Nur wenn der multid das mitkriegt, startet der Lan:0 mit der NotfallIP neu.
Müsste also per Pingtestskript geprüft werden und gegebenenfalls dann wieder entfernt werden.
Geändert werden kann die schon: ifconfig lan:0 down ; ifconfig lan:0 192.168.22.22 up
Die Route wird dabei auch entfernt und auf die Neue gesetzt.

192.168.22.0    *               255.255.255.0   U     0      0        0 lan

 

[edward]

Ja schon, aber der Rechner muß sich auch in 169.254.1.0/24 - Range befinden, sonst kein Zugriff.

Die Idee mit der hosts hatte ich auch, aber funktioniert nicht. Die habe beide Dateien /tmp/hosts als auch /etc/hosts angepasst, ein nslookup auf der Box liefert das gewünschte Ergebniss, aber die Fritzbox liefert den W-/Lan-Clients immernoch die richtige IP.

 

[koyaanisqatsi]

Ein äußerst wichtiger Schutz wäre es, den Domänennamen der Fritz!Box (fritz.box) frei wählen zu können.
Den die Hacks nutzen diesen, da jede Fritz!Box in dieser Domäne ist.
Kennt da Jemand einen Ausweg aus diesen Dilemma?

 

[KunterBunter]

Ja schon, aber der Rechner muß sich auch in 169.254.1.0/24 - Range befinden, sonst kein Zugriff.

Das trifft, zumindest bei meinem einen Rechner, nicht zu. Der Rechner hat die IP-Adresse 192.168.178.53 und man kann mit der Adresse 169.254.1.1 direkt auf eine Fritzbox mit der IP-Adresse 192.168.178.9 zugreifen.

 

[RalfFriedl]

Genau, weil die Box als Default Router im PC eingetragen ist, was notwendig ist, um Zugriff aufs Internet zu haben. Das bedeutet, der PC sendet das Paket wie alle anderen auch an die Box, und die Box kennt die Adresse.

 

[edward]

Also bei mir ist die Notfall-IP nur dann erreichbar wenn ich meinen Rechner eine IP aus dem Range 169.254.1.0/24 vergebe, sonst erhalte ich die Meldung "PING: Fehler bei der Übertragung. Allgemeiner Fehler."

 

[koyaanisqatsi]

Richtig lustig wirds mit 3 Fritz!Boxen im LAN. :mrgreen:
Je nachdem von wo ich 169.254.1.1 aufrufe, krieg ich ne andere Box:
Aus dem LAN: ...meistens den Router (7360SL), selten die 7113.
Über WLAN: ...fast immer meine 7113 (WDS, WLAN-AP), manchmal die 7360SL.
Meine 7270v2 erwisch ich so gut wie nie, eher zufällig.
Also recht sinnfrei, diese IP mit 3 Boxen.

 

[KunterBunter]

@edward: Dann liegt bei dir offenbar ein allgemeiner Fehler vor.

 

[edward]

Den Fehler konnte ich eingrenzen. Ich nutze den Shrew VPN Client und wenn dieser läuft ist die Notfall-Ip nicht erreichbar, obwohl nur Traffic zur VPN-Gegenstelle durch den Tunnel geht. Shrew VPN hat auch Probleme wenn mehr als 2 IP an der Netzwerkkarte konfiguriert sind, dann sind die VPN-Gegenstellen nicht erreichbar.

Dann ist die beste Lösung die Webui auf einen anderen Port zu verbannen. Genau wie die Fernwartung, die war bei mir von Anfang an, nicht auf dem default Port.