[Gelöst] FritzBox 7330 SL (freetz-trunk) kein Zugriff mehr...

[eisbaerin]

Reden wir eigentlich über Freetz oder über aufgepimpte AVM-Firmware?

Nein, kein Freetz. Nur ein paar Binarys (dropbear, sftp-server, busybox) und ein paar einfache Scripte.

Das tritt auch nur aller Jubeljahre auf und stört mich auch nicht im geringsten.
Deshalb lasse ich es sogar so stehen. Wann macht man den bei einer produktiven FB7170 noch ein Recovery?
Die läuft und läuft einfach. Man muß nur daran denken, falls man doch mal recovern will.

Das "böse" daran ist ja, daß die Box sich ganz normal verhält. Es geht alles. Man merkt es überhaupt nicht.
Nach einem Werksreset hat sie auch die 192.168.178.1.
Nur Recovern geht nicht und natürlich der FTP login zu EVA/ADAM geht dann auch nur zu der IP aus dem Urlader-Environment.

Man sollte diese mögliche Ursache aber mit erwähnen, wenn es mal wieder heißt:
"Ich kann meine Box nicht recovern."
Hatte ich bisher noch nicht als mögliche Fehlerquelle gelesen.

EDIT: Da wir nun schon so ausführlich darüber reden, will ich auch noch für Mitleser die Kommandos anfügen, mit denen man es kontrollieren und berichtigen kann:

Kontrollieren mit:

cat /proc/sys/urlader/environment | grep my_ipaddress

Wenn da nicht 192.168.178.1 erscheint, dann berichtigen mit:

echo my_ipaddress 192.168.178.1 >> /proc/sys/urlader/environment

und natürlich noch mal mit dem oberen Kommando kontrollieren.

 

[PeterPawn]

Aber wegen der Angreifer: Du meinst solche, die bereits physischen Zugriff auf Dein Netzwerk haben, oder? Schließlich wird der APIPA-Bereich ja nicht geroutet.

Eigentlich nicht, ich rede hier mehr von CSRF über einen Browser oder einen anderen verwundbaren Client im LAN.

Zum Beispiel so:
Ob und wann das FRITZ!Box-GUI in der aktuellen Version tatsächlich noch CORS verwendet bzw. zum Browser signalisiert, weiß ich nicht ... sollte es das tun, braucht es in der Theorie nur das Spoofen der IP-Adresse eines beliebigen Servers unter *.avm.de (das meint eigentlich eher DNS-Cache-Poisoning/DNS-Spoofing, nicht das tatsächliche Umleiten einer IP-Adresse über falsche ARP-Antworten), um da weitgehend per JS auf das FRITZ!Box-GUI zugreifen zu dürfen, jedenfalls im Rahmen dessen, was der Browser bei CORS zuläßt.

In der ar7.cfg steht i.d.R.:

        cors_allow_origins = "*.avm.de";
        cors_allow_headers = "SOAPACTION", "Content-Type", "Origin";
        cors_allow_methods = "GET", "POST", "OPTIONS";
        cors_max_age = 1d;

Damit müßte der fragliche Server, von dem Ressourcen nachgeladen werden, die dann erweiterte Rechte haben, nicht einmal tatsächlich existieren ... einzige Hürde wäre, auf eine DNS-Abfrage nach "catchmeifyoucan.avm.de" die passende Antwort zu liefern, auf einem Windows-PC würde da schon ein Eintrag in der "hosts"-Datei ausreichend sein und die Zahl der Malware, die versucht dort zuzugreifen, ist ja Legion. Da ist auch nichts mit HTTPS o.ä. und einer nachträglichen Erkennung von Fakes über das Zertifikat vorgesehen. Daß ein Virenscanner das wohl in der Tat verhindern würde, setzt immer noch die Existenz eines solchen beim Aufrufer voraus und wir wissen alle, daß es immer noch genug andere Fälle gibt. Es ist auch nur ein Beispiel ...

Oder auch anders:
Die "webcm"-Lücke Anfang 2014 ließ sich ja über den Aufruf einer URL (schon über eine eingebettete Werbung) ausnutzen, es wurde einfach das auszuführende Kommando in der URL mit angegeben. Dieser Angriff ging eben dann ins Leere, wenn die URL "http://192.168.178.1/..." lautete und der Anwender seine Box auf eine andere Adresse konfiguriert hatte. Die Adresse 169.254.1.1 als permanent gültiges Ziel für einen Zugriff auf eine FRITZ!Box läßt sich allerdings noch schlechter abstellen, als der Zugriff über "fritz.box", den sie auch immer für sinnvoll erachtet, wenn man ihren DNS-Server befragt.

Aber die DNS-Einstellungen eines Clients (mit dem Browser) kann man eben in aller Regel auch noch beeinflussen ... dann nimmt man eben einen anderen DNS-Server als die FRITZ!Box. Bei der APIPA-Adresse nutzt das alles nicht, die FRITZ!Box antwortet auf ARP und man kann eigentlich nur noch dagegen angehen, wenn der Client für das Segment 169.254.0.0/16 keine ARP-Abfragen macht.

Ansonsten hilft bei vorhandenem ARP-Eintrag auch bei vielen Stacks keine "unpassende" IP-Adresse auf dem Interface mehr etwas, weil meist das Ethernet-Paket direkt mit der Layer2-Adresse auf die Reise geht und die ganzen Layer3-Mechanismen gar nicht mehr unbedingt greifen.

Fakt ist mal, es ist wesentlich einfacher, ein Ziel mit einer bekannten IP-Adresse oder einem bekannten Namen über "prediction" anzugreifen, als ein etwas "unschärferes". Da ich nicht unbedingt genau erkennen kann, was Du mit "physischem" Zugriff meinst, bin ich für ein klares "ja" oder "nein" zu unentschlossen. Der Zugriff über ein Relay (ich komme immer wieder auf die bekanntermaßen verwundbare und nicht mehr zum Fixen vorgesehene WebView-Komponente im Android, weil das die derzeit wohl bekannteste Lücke ist und diese Komponente nun mal genau für die Anzeige von Inhalten aus dem Internet, mithin von "untrusted sources", gedacht ist und benutzt wird) ist für mich noch kein physischer Zugang zum Netz, das ist nur der Zugriff (das muß noch nicht mal wirkliche "Kontrolle" sein auf dem Relay) über ein dort befindliches Gerät. Ich kenne aber auch Leute, für die das - wegen der physischen Präsenz des Relays im LAN der Box - tatsächlich ein physischer Zugriff ist.

Die Kritikpunkte an solchen "Fixpunkten" im LAN stehen im Groben ja auch noch mal in dem von mir verlinkten heise.de-Artikel ...

Auch wenn das nichts mit der Notfall-IP auf "dev lan" zu tun hat ... ich würde nicht einmal die Hand dafür ins Feuer legen wollen, daß die FRITZ!Box tatsächlich keine 169.254.0.0/16 routen würde, wenn das externe Interface entsprechend konfiguriert ist. Ob die Box es tatsächlich ablehnen würde, von einem DHCP-Server auf dem WAN-Interface mit einer Adresse aus dem APIPA-Segment konfiguriert zu werden, bezweifle ich ehrlich gesagt. Mit privaten IP-Adressen nach RFC1918 hat sie jedenfalls keine Probleme, die sollten ja auch "nicht routbar" sein ... macht in bestimmten Szenarien aber auch Sinn. Von der speziellen Bedeutung des Segments 100.64.0.0/10 nach RFC6598 hat sie ja auch eher keine Ahnung ...

 

[the.gangster]

@PeterPawn:
Mit physischem Zugang hatte ich gemeint, dass man bereits einen Client im Netz haben oder übernommen haben muss, dessen NIC man in den APIPA-Adressbereich hinein konfiguriert haben muss. Sei es durch Umkonfigurieren der vorhandenen oder Hinzufügen einer zusätzlichen IP.
Mir war nicht bekannt (oder über die Jahre vielleicht auch nur wieder entfallen), dass es Stacks gibt, die unter den von Dir genannten Voraussetzungen den für ein Ziel "falschen" Layer 3 quasi ignorieren und auf Layer 2 einfach weiter machen, es also auf gut-deutsch möglich ist, über eine mit IP 192.168.178.x/24 konfigurierte NIC eine 169.254.1.1 zu erreichen, nur weil sie einen passenden ARP-cache Eintrag dazu hat.
Und was das Routen der "nicht routbaren Netze" anbetrifft, muss ich Dir wohl bezüglich Deiner Zweifel auch zustimmen. Zwar hab ich es nie selbst getestet aber ich meine mich zu erinnern, dass Anfangs die Webseiten eines Kabelnetzbetreibers nicht von Kundenanschlüssen mit dahinter betriebenen Fritzboxen erreichbar waren, bis genau dieses Routing (oder soll ich schreiben "dieses Nicht-Routing") gelockert wurde. Muss sich zwar nicht auf alle Betriebsarten übertragen lassen, aber da war zumindest was.
Danke für die wie so oft umfangreiche Aufklärung.

gruss
the.gangster

 

[PeterPawn]

dass es Stacks gibt, die unter den von Dir genannten Voraussetzungen den für ein Ziel "falschen" Layer 3 quasi ignorieren und auf Layer 2 einfach weiter machen, es also auf gut-deutsch möglich ist, über eine mit IP 192.168.178.x/24 konfigurierte NIC eine 169.254.1.1 zu erreichen, nur weil sie einen passenden ARP-cache Eintrag dazu hat.

Vielleicht habe ich mich zu unglücklich ausgedrückt ... wobei das Setzen eines (falschen) ARP-Eintrags ja genau das ist, was beim Spoofen von IP-Adressen benutzt wird. Wenn das nicht funktioniert, geht ja theoretisch das ganze Spoofen nicht mehr.

Wenn da tatsächlich immer erneut auf Layer3 aufgelöst würde, müßte man ständig den Eintrag erneuern - mit der Gefahr von "Kollisionen" mit der Antwort des "richtigen Hosts", wenn der mal so einen Broadcast dann schneller beantwortet.

Meines Wissens - ich müßte es aber tatsächlich auch erst probieren, gerade bei aktuellen Linux-Kernels ist das "Caching" von Layer2-Adressen etwas komplizierter und beschränkt sich nicht auf den ARP-Cache, da gibt es noch andere Quellen wie den "Neighborhood Cache" - "vergiftet" ein aktiver (und immer wieder verlängerter) Eintrag für die Zuordnung einer IP- zu einer Ethernet-Adresse den Stack nachhaltig.

Ansonsten braucht man für einen Angriff auf 169.254.1.1 meines Erachtens auch keine Netzwerk-Interfaces umzuprogrammieren, ganz im Gegenteil. Wenn auf dem Relay nicht selbst eine Route zu einem APIPA-Segment existiert, dann geht der Traffic für 169.254.1.1 ja an das Standard-Gateway, das in aller Regel (darüber schwadroniere ich hier ja nur) die FRITZ!Box sein dürfte. Damit braucht es nicht einmal eine APIPA-Adresse auf dem Interface des Relays ... das nimmt einfach die Default-Adresse des Interfaces.