[Info] Neue Sicherheitshinweise von AVM

Klaro, mit Nummerierung sogar....
1. Ohne den Fernzugriff zu aktivieren den HTTPS Port auf 443 setzen
2. Mit MyFRITZ!App 2 auf dem Mobile die Heimnetzverbindung (VPN) aktivieren
3. Ergebnis: HTTPS Fernzugang wird mit random Port aktiviert
4. Obwohl der Benutzer für VPN den Fernzugriff gar nicht benötigt
5. Ist so der lokale sichere HTTPS Zugang vereitelt
 
Zuletzt bearbeitet:
Die MyFRITZ!App2 aktiviert halt bei der Einrichting einer VPN-Verbindung zur FRITZ!Box automatisch über TR-064 auch den Fernzugriff auf das GUI und verwendet dafür einen eher zufälligen Port.

Da AVM leider intern und extern denselben Port verwenden will (was sicherlich auch damit zu tun hat, daß dann URLs für den Fernzugriff "stabil" bleiben von "innen" und von "außen", auch wenn NAT-Hairpinning an die Stelle der externen Adresse einfach die interne setzt) und ansonsten auch keine Vorkehrungen für eine Weiterleitung von Port 80 oder Port 443 (aus dem LAN) auf den tatsächlich verwendeten Port (mit TLS-Protokollnamen, also mit "https://...") trifft, funktioniert in so einem Falle auch der interne HTTPS-Zugriff auf die FRITZ!Box-Oberfläche nicht mehr, solange man nicht in der URL auch noch selbst den verwendeten Port (den man nicht unbedingt kennen muß und erst mal zu "erkuinden" hat, denn er ist ja zufällig gewählt bei der Aktivierung) mit angibt.

Da "predige" ich ja auch schon lange genug ... schon eine simple Einstellung (wenn AVM das nicht permanent aktiviert haben will, damit unbedarfte User sich nicht am "self-signed certificate" stören können), daß nur noch sichere Verbindungen im LAN zugelassen werden sollen und eine daraus resultierende, automatische Weiterleitung auf die richtige HTTPS-URL, wenn man nur "fritz.box" versucht zu kontaktieren, könnte die gesamte "FRITZ!Box-Administration" nur noch über HTTPS laufen lassen ... man muß es eben nur wollen und bisher kam an solchen Stellen immer die Versicherung, daß ja die Verbindungen zu WLAN-Clients absolut sicher verschlüsselt wären und man diese (weil sie ja direkt zur Box erfolgen) auch nicht so einfach abfangen und "umleiten" könne.

Wie einfach das aber am Ende geht (erst recht bei reinen Kabelverbindungen, wo es eben keine Verschlüsselung gibt), kann praktisch jeder selbst an einem freien Nachmittag mal probieren, z.B. mit dem "ettercap"-Paket. Jetzt kommt eben auch beim WLAN noch die Möglichkeit hinzu, den verwendeten Client zur Benutzung eines "null keys" bei der Verschlüsselung zu überreden (vorzugsweise, wenn das ein Android-Gerät ist) und was man bereits mit einer abgefangenen SID auf einer FRITZ!Box alles anstellen kann, ist ja ebenfalls bekannt. Man muß nur noch die IP-Adresse passend spoofen, wenn man nicht ohnehin gemeinsam mit dem angegriffenen Client über eine Routerkaskade und damit mit derselben IP-Adresse (dank NAT im kaskadierten Router) auf die zu übernehmende FRITZ!Box zugreift.

Das klingt zunächst nach einem sehr exotischen Szenario ... aber selbst ohne Kaskade ist das Spoofen einer IP- und MAC-Adresse (mal unterstellt, das "richtige Gerät" hätte z.B. das Haus verlassen, ohne die FRITZ!OS-Sitzung zu "invalidieren", was der Normalfall sein dürfte) mehr eine Fingerübung und ein "Angreifer" muß nicht automatisch nur der böse Nachbar vor der Tür sein, das kann genauso gut auch der minderjährige Filius sein, der mit "erzieherischen Maßnahmen" nicht einverstanden ist und für den natürlich die (berechtigte) Benutzung des WLAN dank Kenntnis des WPA2-PSK auch kein Problem darstellt. Wenn er das nicht gleich übers Kabel macht, denn m.W. prüft AVM nicht, ob plötzlich ein WLAN-Client über eine Kabelverbindung kommt oder nicht (zumindest bisher war das m.E. so), was ja auch im "richtigen Leben" mal passieren kann, wenn man mehrere APs hat.

Auch ist der überwiegende Teil der Prüfungen auf "Betrugsversuche" meines Wissens (auch wieder "bisher" und nicht aktuell getestet) darauf ausgerichtet, daß/ob ein Client sich den Internetzugriff erschleichen will durch Spoofen von IP- oder MAC-Adressen (und dann greift das erst, wenn der "usermand" befragt wird) ... ich bin nicht einmal sicher, ob man nicht einfach mit der passenden IP-Adresse so eine SID problemlos "nachnutzen" könnte, solange das andere Gerät nicht ebenfalls in Reichweite ist und damit doppelte IPs auftreten.
 
  • Like
Reaktionen: AdamSapfel
@opto: Das Synonym, dass AVM für VPN in ihrer App benutzt: Heimnetzverbindung
Das Synonym, dass AVM für HTTPS benutzt: Fernzugriff

Habs in Klammern (nachträglich) hinzugefügt, zum Verständnis.

@PeterPawn: Danke, du hast es verstanden und wahscheinlich auch vorher schon gewusst
 
Zuletzt bearbeitet:
Macht sie auch nicht ... sie richtet halt nur beide Zugänge automatisch ein, weil die Verwendung der VPN-Verbindung nur optional ist. Man kriegt aber auch nicht alle Dienste - z.B. SIP-Telefonie - über den Fernzugang - andersherum würde da sicherlich eher ein Schuh draus, aber einige Gemeinsamkeiten (z.B. die Notwendigkeit der Einrichtung eines DynDNS- oder MyFRITZ!-Kontos für das Auffinden bei dynamischen IP-Adressen) haben diese beiden Zugriffe eben schon und ich weiß nicht, ob auf dem TR-064-Interface tatsächlich getrennte Funktionen existieren, mit denen einerseits die Anmeldungen bei einem DynDNS-Service freigeschaltet werden können und parallel dazu aber der "Fernzugriff" nicht aktiviert wird.

Da das früher "alles ein Aufwasch" war (iirc), könnte ich mir auch vorstellen, daß die Aktivierung des Fernzugriffs auf das GUI nur ein "Nebenprodukt" der anderen Aktionen ist (die aber notwendig sind, damit eine VPN-Verbindung funktionieren kann).

Andererseits darf man auch nicht vergessen, daß die TR-064-Funktionen von AVM "nach außen" auch nur über den HTTPS-Zugang bereitgestellt werden (über "tr064cgi") .. insofern bedingt schon die Aktivierung des TR-064-Zugriffs von der WAN-Seite auch parallel die Aktivierung des HTTPS-Zugangs. Da bei einigen AVM-Apps auch TR-064-Funktionen gebraucht werden (z.B. bei der FRITZ!App Fon zum Einrichten und zum Auslesen von Telefonbuch und Anrufliste), aktivieren die gerne mal dieses Interface automatisch und zwar auch für die WAN-Seite. "Überstimmen" kann man das nur mit der passenden Checkbox ... dann verliert man aber parallel auch die eingerichteten Funktionen.
 
So sieht's bei Synology aus mit dem WPA 2 Bug:

Version: 6.1.3-15152-8
(2017-10-18)
Important Note

  1. The update is expected to be available for all regions within the next few days, although the time of release in each region may vary slightly.
  2. This update will restart your Synology NAS.
Fixed Issues

  1. Fixed multiple security vulnerabilities regarding WPA/WPA2 protocols for wireless connections (CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088).
Da könnte AVM sich mal ein Beispiel dran nehmen!
 
AVM sagt, die *Router* sind nicht betroffen, wogegen die *Repeater* betroffen sein könnten und AVM das prüft. Sollten die Repeater dieses ausnutzbare Verhalten zeigen, wird auch AVM Updates herausgeben.
Die Frage wäre dann höchstens, für welche Repeater noch Updates herauskommen. Ich habe hier noch einen mit FM-Radiosender ...

Was noch unklar ist: Verhalten sich die AVM-Boxen "nur" im Accesspoint-Modus sicher, d.h. sind im Repeatermodus von dem Problem betroffen, oder sind die Router generell sicher, egal welche Betriebsart?
 
Was noch unklar ist: Verhalten sich die AVM-Boxen "nur" im Accesspoint-Modus sicher, d.h. sind im Repeatermodus von dem Problem betroffen, oder sind die Router generell sicher, egal welche Betriebsart?

Nach meinem Verständnis haben die Kisten die gleichen fehlerhaften Routinen für den Client-Modus in der Firmware, wie auch andere Clients.
 
Ja - auch die Boxen haben das Problem, wenn die als Repeater betrieben werden.

Deswegen hat AVM das auch so formuliert:
"Eine FRITZ!Box am Breitbandanschluss ist nach aktuellem Stand nicht von der "Krack" genannten WLAN-Sicherheitslücke betroffen, da sie als Access Point die betroffene Norm 802.11r nicht verwendet."
 
Bisher verwende ich das Fritz-VPN um z.B. aus öffentlichen WLANs mit meinm Android Smartphone eine sichere Verbindung aufzubauen.

Nun mit Kracks frage ich mich, ob man das auch im eigenen WLAN nutzen kann. Dabei sollte doch alles durch den Tunnel laufen, oder?
 
Wer wissen will, welche Version von "wpa_supplicant" (und "hostapd") in seiner Firmware verwurstet ist, braucht nur mal einen Blick in die Firmware zu werfen. Da diese Software unter BSD-Lizenz steht, packt AVM zwar keine Quellen ins OpenSource-Paket, aber man kann ja auch problemlos in das Programm "hineinsehen":
Code:
# strings sbin/wpa_supplicant | grep "wpa_supplicant "
wpa_supplicant v2.0-devel
  wpa_supplicant [-BddhKLqqstuvW] [-P<pid file>] [-g<global ctrl>] \
Dann noch einen zweiten Blick in die Support-Daten riskiert und in die dort zu findende "wlan_dynamic.cfg" (das ist die aktuell von der Box verwendete WLAN-Konfiguration) ... und wenn man dort dann eine "Rolle" (role) findet, wo bei "station_type" etwas von "STA" steht, dann ist das eine, in der die fragliche FRITZ!Box ihrerseits als "Client" auftritt.

Was galt gleich noch für andere Geräte, die "wpa_supplicant" als Client verwendeten? Ich weiß es nicht mehr ... vielleicht hilft ja das Nachlesen auf der Seite www.krackattacks.com mir auf die Sprünge.

Hier wird AVM vermutlich wirklich mal wieder dadurch vor einem ernsthaften Problem verschont, daß man uralte Software verwendet, welche die fehlerhaften Stellen noch gar nicht enthält (dafür ggf. andere, bisher unveröffentlichte Schwachstellen hat, die niemals den Weg in ein Advisory gefunden haben). Das ging AVM schon bei der Samba-Lücke im Frühjahr so, daß man - wie durch ein Wunder oder eben durch uralte Software - verschont wurde, während rundherum über diese Schwachstellen die "WannyCry"-Infektionen stattfanden.

Nach www.krackattacks.com sind jedenfalls erst Versionen von "wpa_supplicant" jenseits der 2.4 so richtig schwer von dem Problem betroffen, weil sie dann einen Key installieren, der gar keiner ist:
Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key.
Jetzt kann man sich eigentlich nur noch beruhigt zurücklehnen und sich - je nach Naturell - darüber freuen oder wundern, wie es AVM mit einer Version von 2012 (es ist die 2.0-devel, das dürfte der Vorläufer der 2.0 vom 12.01.2013 sein) weiterhin gelingt, die WLAN-Interoperabilität mit allen anderen Herstellern so hervorragend aufrechtzuerhalten.

Was sind diese ganzen anderen Hersteller/Anbieter doch für Schwachköpfe, wenn die auf aktuelle Versionen der Software setzen. Wenn die ganzen Linux-Distributionen nicht immer so update-geil wären und einfach auch weiterhin auf die Versionen vor 2.4 (15.03.2015) gesetzt hätten, bräuchten die heute auch keine Updates.

Manchmal zahlt es sich eben doch aus, wenn man nur lahmarschig genug ist ... irgendwann ist die Software dann so alt, daß die ohnehin kein Mensch mehr auf Schwachstellen untersucht, weil ja keiner davon ausgeht, daß die irgendwo noch in Benutzung sein könnte. Mein MS-DOS 6.22 habe ich auch schon lange nicht mehr aus diesem Blickwinkel betrachtet ... es wird wohl Zeit für eine "Rückbesinnung" - die 80er erleben ihr Revival (oder es waren doch die frühen 90er? - egal, auf alle Fälle war da alles viel besser, sagen manche).

PS: Nein, man kann aus dem eigenen WLAN heraus das AVM-VPN nicht benutzen ... beide Adressen (die aus dem WLAN und die vom VPN) würden in demselben Netzwerk liegen.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: uhus50 und Marcoblue
VPN
Klappt aber prima aus dem Gastzugang ( Lan4 oder W-Lan Gastzugang ) heraus.
Entsprechende Filter/Netzwerkanwendung vorausgesetzt.

Inwieweit dass sinnvoll wäre sei mal dahingestellt.

@PeterPawn: Ich hab hier noch einen Olivetti von 1986 :)
...da gabs noch kein W-LAN oder was ähnliches.
...mit 10 MB Festplatte die pro MB 1kg wiegt.
:D
 
Zuletzt bearbeitet:
Für den 1260E gibt es bereits ein 6.92 Firmware Release, das den WPA2 Bug beheben soll
 
  • Like
Reaktionen: rainernoa
Für den Fritz Repeater 1750 gibt es bereits ein 6.92 Firmware Release, das den WPA2 Bug beheben soll.

Im Moment liegt er nur auf dem FTP Server von AVM
 
@penum

gerade über die FB7580 für 1750 eingetroffen.
 
Nabend.
Muss den nun eine 7490 mit 6.90 die per Mesh als Ip Client (mit Kabel) an einer weiteren 7490 mit 6.90 angemeldet ist auch ein wpa2 Update erhalten?
Mein 1750e bekamm das update ja schon..Benutzte den 1750 nur selten > wenn ich zu Opas Haus rüber muss wird er eingesteckt.
Ist die 7490 als Ip Client nicht dann eine Ap?
Wo ist bitte der unterschied wenn ich per Kabel eine 7490(Ip Client) oder per Kabel den 1750E betreibe?

Danke und schönes Wochenende...
 
Nabend.
Muss den nun eine 7490 mit 6.90 die per Mesh als Ip Client (mit Kabel) an einer weiteren 7490 mit 6.90 angemeldet ist auch ein wpa2 Update erhalten?
Nein! Der IP-Client 7490 meldet sich ja nicht über WLAN beim Router an, sondern per (LAN)-Kabel. Er stellt seinerseits einen WLAN-AP zur Verfügung, an dem sich andere Clients anmelden können, wobei diese Clients dann wieder von der Sicherheitslücke betroffen sind.
 
Danke Dir Pom-Fritz.
Das Update für die 1750e ist also nur wichtig wenn dieser per WLAN zur 7490 verbunden ist und nicht per Kabel?
 
In dem Update 1750E 6.92 sind neben drei Bugfixes auch diverse neue Features enthalten.
Lohnt sich also schon ...
 
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.