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.