[Info] Wie realistisch sind LAN-seitige Angriffe auf einen Router?

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,138
Punkte für Reaktionen
1,703
Punkte
113
Nur mal als "Literaturhinweis" ... es ist eben nicht alles nur graue Theorie.

http://heise.de/-2665387

Die Router rücken immer mehr in den Fokus der Angreifer und eine der vordringlichsten Aufgaben der Hersteller muß es für die nähere Zukunft sein, einen Router nach innen genauso gut abzusichern, wie der Kunde es zu Recht auf der WAN-Seite erwartet.

EDIT: Um das etwas zu relativieren und entsprechenden Fragen vorzubeugen ... die originale Webseite http://malware.dontneedcoffee.com/2015/05/an-exploit-kit-dedicated-to-csrf.html enthält zwar oben ein Bild, auf dem auch eine FRITZ!Box zu sehen ist (das sieht aus wie eine 72xx oder auch eine 6360), aber FRITZ!Boxen stehen derzeit nicht im Fokus dieses Exploit-Kits.

Aber was nicht ist, kann ja noch werden ... bisher rettet uns FRITZ!Box-Besitzer immer noch der Umstand, daß die internationale Verbreitung dieser Geräte recht überschaubar ist. Das dürfte aber auch schon der entscheidende Punkt sein ... spätestens wenn es ein Exploit-Kit gibt, was sich z.B. auf dem NAS (oder dem Webradio oder dem Smartphone oder der neuen Smartwatch oder oder oder) einnistet und von dort aus den Router (oder das LAN generell) attackiert, ist es mit der relativen Ruhe auch schnell vorbei.

Spätestens jetzt ist das Verwenden einer FRITZ!Box mit "Keine Anmeldung im Heimnetz erforderlich" das absolute "no go" ... wer das immer noch benutzen sollte, spielt mit dem Feuer und stellt die eigene Bequemlichkeit ganz klar über die Sicherheit. Man kann sicherlich nicht oft genug davor warnen ... eigentlich müßte man ganz dringend an AVM appellieren, diese Möglichkeit umgehend abzuschaffen. Wenn wirklich jemand genau weiß, was er da macht, dann kann man dem auch > 10 Klicks für die Deaktivierung einer Anmeldung zumuten, wenn man mit den vorhergehenden 10 Aktionen "weniger technikaffine Nutzer" davon abhalten kann, einfach aus Bequemlichkeit die Anmeldung zu deaktivieren. Leider wird das meines Wissens immer noch im ersten Dialog nach dem Start einer "frischen" Box direkt angeboten (wenn auch "nicht empfohlen", aber das schert solche Leute in der Regel auch nicht, wenn sie es überhaupt lesen).
 
Zuletzt bearbeitet:
Moins

XSS Attacken?

Fritz!Box geht ja noch.
Viel erschreckender sind die Zugriffsmöglichkeiten auf SmartTVs und Mediacenter.
...nur mal so. (von Smartfon/Tablet Apps hört man ja auch nix Gutes)
 
Und das ist genau der Grund, warum bei mir zu Hause der allergrößte Teil vom schönen neuen Internet der Dinge von jeglichem WAN-Verkehr ausgeschlossen ist (Fernseher, BR-Player,Raspis usw.)
Nochmal kurz zum konkreten Eingangsthema: Stelle ich mir die Sache zu einfach vor, wenn in den Logs der FB (die AVM-eigenen und/oder diejenigen des syslogds) massiv gescheiterte Authentifizierungsversuche nebst zugehöriger Usprungs-LAN-IP auftauchen und ich diesen dann nachgehen kann ?
 
Denke schon.

Bei XSS gehts meist darum dem (unbekannten) Opfer was unterzujubeln.
...unbemerkt, vielleicht über Bilder die gar keine sind.
Gern auch kodiert, zum Beispiel: base64

Also, was im LAN dein SmartTV erreichen kann und bei einer gespeicherten EMail einen XSS Link lokal ausführt, ist nicht sicher.

Die Autostartfunktion für Wechseldatenträger an einem PC ist übrigen auch hilfreich bei sowas.
...also keinen ungeschützten USB Austausch zulassen. ;)
 
Zuletzt bearbeitet:
@JohnDoe42:
Solange der Angreifer nicht erfolgreich war, schon ... bin ich erst einmal in so einer FRITZ!Box drin, ist auch das selektive Löschen einzelner Nachrichten (so daß Du davon keine Spur mehr findest) aber kein wirkliches Problem. Solange das Protokoll nicht außerhalb der Box persistent gespeichert wird, ist das zwar ein gewisser Schutz, aber der ist tatsächlich noch weit jenseits von "optimal". Im Zeitalter von NAS für den Heimgebrauch, wo auch problemlos ein Syslog-Server mitlaufen kann, sollte eigentlich ein konfigurierbarer Syslog-Service (spätestens in den Experteneinstellungen) zum guten Ton gehören ... auch im Consumer-Bereich.

Und derzeit nutzt bei einem Syslog-Daemon am Ende auch nur die "-R"-Option für das externe Protokollieren ... wobei ein Syslog-Daemon auf einer FRITZ!Box ja nicht der Normalfall ist, da könnte ein Angreifer das Löschen des Syslogs tatsächlich "vergessen". Das Problem dabei ist nur, daß die AVM-Komponenten (eigentlich nur der ctlmgr und ar7login, wenn es um Anmeldeversuche geht, event. noch der ftpd, das müßte ich noch mal ansehen) gar nicht ins Syslog schreiben wollen ... da findest Du also höchstens Einträge von /bin/login oder einem SSH-Daemon.

Wobei ein Angreifer außerhalb des Browsers (ggf. aber auch innerhalb eines Browsers) schön blöd wäre, wenn er tatsächlich das Login über das GUI versucht. Viel schlauer ist es doch, dafür den FTP-Server zu verwenden (das klappt ggf. auch mit XmlHttpRequest vom Browser aus, hängt davon ab, welchen man benutzt) oder auch das Telnet-Login, da werden die Fehlversuche nicht protokolliert und der Account ist trotzdem derselbe. Was noch ziemlich gut funktioniert (allerdings auch wieder fast als DoS-Einfallstor benutzt werden kann), ist die steigende Verzögerung für weitere Anmeldeversuche nach einem Fehlversuch.

Dafür bieten diese zusätzlichen Dienste dann wieder keinen effektiven Schutz gegen das Abschnorcheln von Credentials (dafür reicht ein browser-basierter Angriff normalerweise aber ohnehin nicht, solange da keine Flash- oder Java-Lücke auch noch zum Einsatz kommt), denn gerade bei diesen beiden ist die im GUI verwendete Challenge-Response-Methode ja nicht vorhanden und die Daten sind im Netzwerk im Klartext zu lesen.

Irgendwo hatte ich mal eine Liste, wie die unterschiedlichen Logins mit Fehlversuchen umgehen ... aber die ist sicherlich nicht mehr aktuell. Früher war es mal möglich (wenn ich das nicht mit den AVM-basierten Speedports durcheinander bringe, diese "Sperre" war wohl anfangs ein Feature für die Telekom, es gibt noch entsprechende Rudimente in den Lua-Files), die Wartezeit bis in den Bereich von 8 Stunden zu treiben.

Also ... AVM macht schon einiges, aber beileibe noch nicht alles richtig. Spätestens nach dem dritten fehlgeschlagenen Login hätte ich zum Beispiel gerne eine E-Mail, egal welchen Dienst das betraf.
 
Ich denke auch, dass SmartTV´s auch eher dran glauben dürfen, und man den User noch teils sehen und hören kann, wenn noch Cam und so im TV ist. Android Handys sind ja auch recht anfällig oft, darüber könnte man wohl auch Attacken starten.

Auch so senden manche Geräte ja schon Daten zum Hersteller als Verhalten und so.

Die FB sehe ich nicht so kritisch, die war oft nicht betroffen.

Wie Peter schon anmerkt, sollte AVM besser mal ein Zwangspasswort durchsetzen, ist bei anderen auch üblich.

Selbst beim aktuellen Speedport ist kein Standard PW, sondern auf Rückseite klebt das Standard PW vom Router sowie WLAN Schlüssel. Also mit 0000 oder password, ist da nichts mehr.

Schadware kommt oft ja über Spam, Werbung oder manipulierte Seiten.
 
Moins

Um mal auf den Router zurückzukommen, im speziellen die Fritz!Boxen ab F!OS 6.20?
Kennt ihr das hier schon: [Info] F!OS 6.20 - Fritz!Box Domainname fritz.box lässt sich ändern
Damit wäre die Domain fritz.box und alle Verwandschaften Geschichte.
Momentan besonders geeignet für Diejenigen, die das NAS und MYFRITZ (lokal) WebIf nicht nutzen.
Um es komplett Konstantensicher hinzukriegen muss natürlich Standard F!B IP und NotfallIP individualisiert werden.
...oder ist das ein alter Hut?

Ich mein, wenn eine XSS Attacke durchkommt, und die nutzen dieses mal diese undokumentierte(?) Funktion,
wäre das doch auch mal eine prima Möglichkeit den Besitzer der Fritz!Box auszusperren.

Wäre übrigens toll wenn das mal ein analysefreundlicher Mitleser analysieren würde. :D
 
Zuletzt bearbeitet:
...oder ist das ein alter Hut?
Das kommt ein wenig darauf an, was Du damit eigentlich meinst ...

Die Variable an sich ist tatsächlich ein "alter Hut", bei der 7490 steht in 06.05 z.B. der Name "fritz.fonwlan.box" darin, wenn ich mich richtig erinnere.

Als Hostname wird der dort hinterlegte Wert eigentlich auch nur wirksam, wenn in der ar7.cfg kein Name gesetzt ist (also nichts in "hostname=" steht oder das dort stehende "(none)" ist).

Nach welchem Schema jetzt dieser Wert auch noch für die Bildung der lokalen Domain herangezogen wird, weiß wohl nur der "multid", der diese meines Wissens verwaltet. Das könnte tatsächlich neu sein, wenn diese Umgebungsvariable da jetzt Einfluß hat, andererseits war der frühere Wert (s.o.) auch schon immer als alternativer Hostname verwendbar (wenn man den DNS-Server der Box nutzte). Das müßtest Du also noch einmal richtig abklären, dabei könnten Dir die Supportdaten (insb. die DNS-Daten dort) helfen. Vielleicht ist es ja auch nur so, daß alle lokalen Geräte grundsätzlich auch als "gerätename.fritzboxname" aufgelöst werden? So genau habe ich mich mit dem multid-DNS nie beschäftigt, mir reichte es immer, wenn ich den übertölpeln konnte für DNS-Spoofing und ihm einen anderen Resolver unterjubeln konnte. Das interne Zeugs war außerhalb des Fokus ...
 
Hab mal IP auf 192.168.55.1 und Domain auf divino.net geändert...
Code:
login as: root
root@deepbase's password:
overwrite feature CONFIG_HOSTNAME=divino.net
overwrite feature PATH=/tmp:/tmp/bin:/bin:/sbin:/usr/bin:/usr/sbin:/var/media/ft                                                                                              p/SanDisk-Cruzer-01/mips:/var/media/ftp/SanDisk-Cruzer-01/scripts
ermittle die aktuelle TTY
tty is "/dev/pts/2"
weitere telnet Verbindung aufgebaut
disable start/stop characters and flowcontrol
/var/tmp # arp
viento.divino.net (192.168.55.5) at X [ether]  on lan
? (192.168.55.22) at * PERM PUP on lan
/var/tmp # arp
viento.divino.net (192.168.55.5) at X [ether]  on lan
? (192.168.55.6) at <incomplete>  on lan
GT-S5380.divino.net (192.168.55.7) X [ether]  on lan
? (192.168.55.22) at * PERM PUP on lan
/var/tmp # nslookup fritz.box fritz.fonwlan.box
nslookup: bad address 'fritz.fonwlan.box'
/var/tmp # nslookup fritz.fonwlan.box
nslookup: can't resolve '(null)'

nslookup: can't resolve 'fritz.fonwlan.box'
/var/tmp # nslookup fritz.box
nslookup: can't resolve '(null)'

nslookup: can't resolve 'fritz.box'
/var/tmp # nslookup myfritz.box
nslookup: can't resolve '(null)'

nslookup: can't resolve 'myfritz.box'
/var/tmp # nslookup deepbase
nslookup: can't resolve '(null)'

Name:      deepbase
Address 1: fd00::9ec7:ffff:ffff:ffff divino.net
Address 2: 192.168.55.1 divino.net

/var/tmp # nslookup viento divino.net
Server:    192.168.55.1
Address 1: 192.168.55.1 divino.net

Name:      viento
Address 1: 2003:45:4838:ffff:ffff:ffff:ffff:ffff viento.divino.net
Address 2: 192.168.55.5 viento.divino.net
 
Na ja, das sieht ja so aus, als ob meine Annahme mit "geraet.fritzboxname" stimmen könnte ... spannend wäre dann eben "box.fritz.box". Wenn dann "viento" am Ende "viento.box.fritz.box" heißt, dürfte das eine Bestätigung sein.

Wobei wirklich die Support-Daten (notfalls auch nur der DNS-Teil von Hand) da eine gute Quelle sind, da stehen praktisch alle DNS-Records drin und man braucht kein nslookup/dig (wo man den Namen ja kennen sollte, damit die Anfrage klappt), um einen Gesamtüberblick zu bekommen.
 
Ich hoffe du meinst jetzt das hier...
Code:
##### BEGIN SECTION dns_server DNS configuration
dns-server:
-----------
servers:
 * 217.237.151.51:53 dns
 + 217.237.149.205:53 dns
allowedv4:
 192.168.55.0 255.255.255.0 (55.168.192.in-addr.arpa)
 10.10.0.0 255.255.0.0 (10.10.in-addr.arpa)
 192.168.179.0 255.255.255.0 (179.168.192.in-addr.arpa)
allowedv6:
 fd00::/64 (0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa)
 2003:45:4838:dd01::/64 (1.0.d.d.8.3.8.4.5.4.0.0.3.0.0.2.ip6.arpa)
 2003:45:4838:dd00::/64 (0.0.d.d.8.3.8.4.5.4.0.0.3.0.0.2.ip6.arpa)
localinfo:
 divino.net (none):
     SOA
     NS=divino.net
     192.168.55.1
 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa (none):
     NS=divino.net
     SOA
 dns.divino.net (none):
     217.237.151.51
     217.237.149.205
 55.168.192.in-addr.arpa (none):
     NS=divino.net
     SOA
 10.10.in-addr.arpa (none):
     NS=divino.net
     SOA
 179.168.192.in-addr.arpa (none):
     NS=divino.net
     SOA
 deepbase.divino.net (none):
     192.168.55.1
 localhost (none):
     127.0.0.1
 viento.divino.net (llmnr):
     192.168.55.5
 1.0.d.d.8.3.8.4.5.4.0.0.3.0.0.2.ip6.arpa (none):
     NS=divino.net
     SOA
 0.0.d.d.8.3.8.4.5.4.0.0.3.0.0.2.ip6.arpa (none):
     NS=divino.net
     SOA
 GT-S5380.divino.net (none):
     192.168.55.7
##### END SECTION dns_server
...ein paar IPv6 rausgelöscht. Die 10.10.0.0 deutet auf NotfallIP.
 
Exakt das meinte ich mit dem Verweis auf die Support-Daten ... da steht es eben, ohne daß man wissen muß, wonach man "dig"gen soll (was man mit nslookup fragen soll).
 
Soll ich mal ändern auf box.fritz.box oder reicht das?
 
Ad libitum ... es würde zumindest die Frage klären, ob AVM da irgendwelche Grenzen (ähnlich ndots in der /etc/resolv.conf) eingezogen hat oder tatsächlich auch "a.b.c.d.e" akzeptieren (und verwenden) würde.

Spannend ist ja auch noch die Frage, was bei Dir eigentlich im Hostnamen in der ar7.cfg steht ... ich tippe mal auf "deepbase"? Wenn das tatsächlich so ist, könnte man "CONFIG_HOSTNAME" als eine Art "lokale Domäne" benutzen, wobei das Überschreiben mit der featovl.cfg auch so seine Seiteneffekte hat. Zum Beispiel die "system_status"-Seite wird damit auch "verstümmelt", das wieder verwirrt dann den FBEditor ... die featovl.cfg sollte also möglichst eine temporäre Angelegenheit sein, sonst sucht man sich u.U. an anderen Stellen einen Wolf, weil AVM die rc.conf (da wird die featovl.cfg gelesen und verarbeitet) auch an diversen anderen Stellen "sourced" (z.B. in /etc/version). Das disqualifiziert diese Möglichkeit in meinen Augen als "reguläre" Basis für die Änderung der lokalen Domain, da müßte man dann bei "Imagebau" gleich an die rc.conf gehen.
 
Nagut...
Gleich zu Anfang der Supportdaten steht übrigens schon...
Code:
##### TITLE Version overwrite feature CONFIG_HOSTNAME=box.fritz.box
overwrite feature PATH=/tmp:/tmp/bin:/bin:/sbin:/usr/bin:/usr/sbin:/var/media/ftp/SanDisk-Cruzer-01/mips:/var/media/ftp/SanDisk-Cruzer-01/scripts
109.06.20
##### TITLE SubVersion overwrite feature CONFIG_HOSTNAME=box.fritz.box
overwrite feature PATH=/tmp:/tmp/bin:/bin:/sbin:/usr/bin:/usr/sbin:/var/media/ftp/SanDisk-Cruzer-01/mips:/var/media/ftp/SanDisk-Cruzer-01/scripts

Der DNS Teil...
Code:
##### BEGIN SECTION dns_server DNS configuration
dns-server:
-----------
servers:
 * 217.237.151.51:53 dns
 + 217.237.149.205:53 dns
 + [2003:180:2::53]:53 dns
 + [2003:180:2:6000::53]:53 dns
allowedv4:
 192.168.55.0 255.255.255.0 (55.168.192.in-addr.arpa)
 10.10.0.0 255.255.0.0 (10.10.in-addr.arpa)
 192.168.179.0 255.255.255.0 (179.168.192.in-addr.arpa)
allowedv6:
 fd00::/64 (0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa)
 2003:45:484a:e001::/64 (1.0.0.e.a.4.8.4.5.4.0.0.3.0.0.2.ip6.arpa)
 2003:45:484a:e000::/64 (0.0.0.e.a.4.8.4.5.4.0.0.3.0.0.2.ip6.arpa)
localinfo:
 fritz.box (none):
     SOA
     NS=fritz.box
     192.168.55.1
 0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa (none):
     NS=fritz.box
     SOA
 dns.fritz.box (none):
     217.237.151.51
     217.237.149.205
 55.168.192.in-addr.arpa (none):
     NS=fritz.box
     SOA
 10.10.in-addr.arpa (none):
     NS=fritz.box
     SOA
 179.168.192.in-addr.arpa (none):
     NS=fritz.box
     SOA
 box.fritz.box (none):
     192.168.55.1
  www.fritz.box (none):
     192.168.55.1
 myfritz.box (none):
     192.168.55.1
     fd00::9ec7:a6ff:fe56:3e7f
     2003:45:484a:e000:9ec7:a6ff:fe56:3e7f
 www.myfritz.box (none):
     192.168.55.1
     fd00::9ec7:a6ff:fe56:3e7f
     2003:45:484a:e000:9ec7:a6ff:fe56:3e7f
 deepbase.fritz.box (none):
     192.168.55.1
     fd00::9ec7:a6ff:fe56:3e7f
     2003:45:484a:e000:9ec7:a6ff:fe56:3e7f
 fritz.nas (none):
     192.168.55.1
     fd00::9ec7:a6ff:fe56:3e7f
     2003:45:484a:e000:9ec7:a6ff:fe56:3e7f
 www.fritz.nas (none):
     192.168.55.1
  GT-S5380.fritz.box (none):
     192.168.55.7
 viento.fritz.box (llmnr):
     192.168.55.5
 localhost (none):
     127.0.0.1
 1.0.0.e.a.4.8.4.5.4.0.0.3.0.0.2.ip6.arpa (none):
     NS=fritz.box
     SOA
 0.0.0.e.a.4.8.4.5.4.0.0.3.0.0.2.ip6.arpa (none):
     NS=fritz.box
     SOA
##### END SECTION dns_server
...wie schade, trotzdem geht "http://box.fritz.box" zum Login, "http://fritz.box" allerdings auch.
 
Zuletzt bearbeitet:
Tja, da "zählt" AVM wohl die Dots und mag nur einen zweistufigen "Domain-Namen" akzeptieren ... das ist dann tatsächlich im Großen und Ganzen das althergebrachte Verhalten.
 
Ok, wenn dieser Angriff also über JavaScript das Internetgateway rauskriegt...
...ist natürlich blöd/klug, wie auch immer. Muss JavaScript aus. :confused:
...und wie basteln die den Server? node.js ?

Also, dem Artikel zufolge ist aktiver telnetd (Port 23 ?) die Router Angriffsfläche.
...trifft also bei Fritz!Boxen die wenigsten. ;)
 
Zuletzt bearbeitet:
Für Javascript und so kann man doch RequestPolicy oder Noscript ect verwenden als Addon für Firefox z.B., um Scripte von externen Servern zu blocken.

Damit bleibt teils auch schon was Werbung weg. Habe sogar Flash deaktiviert, und fast nie vermisst bzw. benötigt.

Man kann also auf einige Sachen verzichten, jedoch ist sowas eher nicht Standard, und damit leider teils Angriffe möglich.

Evt. gibt es für FB Nutzer ja nen Popup und die Bitte #96*7* anzurufen, für tolle Gewinne, oder die Sicherheit des Netzes zu prüfen. ;)

bzw. könnte die Schadware ja während man eingeloggt ist in der FB die Nummer über Wahlhilfe wählen lassen, oder wenn kein Passwort vorhanden ist einloggen.
 
Zuletzt bearbeitet von einem Moderator:
:lach:
Evt. gibt es für FB Nutzer ja nen Popup und die Bitte #96*7* anzurufen, für tolle Gewinne, oder die Sicherheit des Netzes zu prüfen.

Auwaia, das ist natürlich ein Argument.
:rolleyes:
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.