[Info] Neue Sicherheitshinweise von AVM

Mir bereiten Versionen über 6.30 WLAN Probleme, daher nutzt mir die 6.80 nicht. Da nutzt mit "das vermeintliche Wissen".
 
Was nützt Dir da das vermeintliche Wissen, das Update auf 6.50 wäre nicht kritisch
Verstehe gar nichts :confused:

Ich mache kein Update nur um des Updaten willens.
Schon gar nicht bei AVM. Denn die Features an den die Softwareschmiede die letzten 2 Jahre rumgebastelt hat brauch ich keines Falls.
Noch dazu machen diese Features wieder neue Lücken/Fehler auf.

Schreibt jetzt AVM alles hin was behoben ist oder verschweigt AVM was und wenn ja warum ?
Immer noch Dreck am Stecken. Würde mich nicht wundern.

Und nochmal, wo ist er dicke Hund begraben, der AVM berühmt machte.
AVM schreibt nichts darüber
 
Zumindest verschweigt AVM noch, was in 6.80 behoben ist. Das kann kritisch sein oder auch nicht. Und Sicherheitslücken sind meist länger bestehend, keine erst mit der letzten Version (hier 6.50) hinzugekommenen Regressions.
 
16.10.2017 Krack-Lücke bei WPA2
Seit heute wird über eine Lücke im WPA2-Protokoll von WLAN berichtet. WPA ist relevant für alle WLAN-Produkte vom Smartphone über Router bis zur IP-Kamera. Angriffe sind nicht bekannt und könnten auch nur im direkten WLAN-Umfeld erfolgen. Für eine genauere Einschätzung müssen noch weitere Details bekannt werden. Unabhängig von Krack findet bei der Internetverbindung über HTTPS-Seiten (Onlinebanking, Google, Facebook etc.) eine sichere Verschlüsselung statt.

Falls notwendig wird AVM wie gewohnt ein Update bereitstellen. Die Wifi Alliance fasst die Situation > hier zusammen.
http://web.archive.org/web/20171016110714/https://avm.de/service/aktuelle-sicherheitshinweise/
https://avm.de/service/aktuelle-sicherheitshinweise/
 
Genau, AVM ist auf der sicheren Seite, die Klienten nicht.
Was mich zu der Frage führt: Wie sieht es aus, wenn die Fritz!Box ein IP-Klient (W-LAN Repeater) ist ?
...davon hab ich 3 Stück.
 
AVM hat von Krack am 16. Oktober Kenntnis erlangt. Das für solche Fälle vorgesehene Responsive-Disclosure-Verfahren wurde von den Entdeckern der Lücke leider nicht angewandt.
Habe ich da irgendetwas verpaßt und hat AVM jetzt tatsächlich eine eigene Policy für "security incidents" veröffentlicht? Wo wäre die genau zu finden?

Ansonsten wurde das Problem ja tatsächlich als "responsible disclosure" behandelt (das ist sicherlich auch bei AVM im Text gemeint, auch wenn "responsive disclosure" eine mögliche Vorgehensweise beim UI-Design ist und damit sogar noch in den "IT-Bereich" fallen könnte) ... nur war AVM halt kein Mitglied der Gruppe von Herstellern, die darüber benachrichtigt wurden (siehe www.krackattacks.com):
When did you first notify vendors about the vulnerability?
We sent out notifications to vendors whose products we tested ourselves around 14 July 2017. After communicating with these vendors, we realized how widespread the weaknesses we discovered are (only then did I truly convince myself it was indeed a protocol weaknesses and not a set of implementation bugs). At that point, we decided to let CERT/CC help with the disclosure of the vulnerabilities. In turn, CERT/CC sent out a broad notification to vendors on 28 August 2017.
Erstens hätte man das bei AVM auch selbst feststellen können, wenn man die Webseite bis zum Ende gelesen hätte (hat man das tatsächlich getan und "beschwert" sich trotzdem, wird das ja nur um so witziger) und zweitens muß man sich wohl kaum wundern, wenn die anderen Kinder einen nicht mehr zum Spielen einladen, nur weil man ohnehin immer den eigenen Kopf durchsetzen will und das alles anders macht als die halbe Branche. Wenn sich AVM irgendwann mal an die "Bräuche" hält (bzw. an die veränderten Bedingungen und Gegebenheiten der heutigen Zeit anpaßt), sieht das ggf. auch wieder anders aus.

Allerdings ist AVM eben so klein und außerhalb von D (bzw. dem deutschsprachigen Raum und einigen wenigen "Inseln" in der Welt) auch so "unbedeutend", daß man es nicht mal auf die Liste der betroffenen Hersteller beim CERT/CC schafft: https://www.kb.cert.org/vuls/id/228519 - auch nicht in der "ausführlicheren" Variante hier: https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4 ... da kann man dann (in der Spalte "Date Notified") auch gleich sehen, daß eben eine ganze Reihe von Herstellern tatsächlich schon länger benachrichtigt waren und damit die "Vorwürfe" von AVM in weiten Teilen der Grundlage entbehren.
 
  • Like
Reaktionen: uhus50 und weißnix_
Dann drück mal F5 oder nimm einen anderen Browser. ;)
 
Komisch ... ich hatte einen IE11 (in einer Windows7-VM und auch noch mit der Einstellung "Do not save encrypted pages to disk") verwendet und auch die Browser-Instanz neu gestartet (weil das ohnehin aus einem VMware-Snapshot heraus erfolgte, auf den ich immer wieder zurücksetzen lasse beim Beenden der VM) - mir fehlt gerade die Phantasie, wo da ein Cache irgendwelche älteren Dateien ausliefern könnte.

Aber Du hast recht ... wenn ich das mit einem FF in einem anderen System öffne, ist es tatsächlich geändert. Anhand der Uhrzeit (14:02 Uhr laut Meta-Daten der Typo3-Seite) war das dann aber bereits "in Arbeit", als ich den Beitrag oben schrieb ... der ging ja dann erst zwei Minuten später "online".
 
In den Firefox Seiteninformationen steht
Modifiziert: 17. Oktober 2017 um 14:54:28 GMT+2
 
Gut ... die Frage, welches Datum jetzt für welche Aktion genau steht, kann ich auch nicht beantworten. In den Meta-Daten der Seite steht halt:
Code:
<meta name="date" content="2017-10-17T12:02:00+02:00"/>
und wenn das keine Änderung "in Etappen" war, sollte auch zu diesem Zeitpunkt ja irgendetwas in der Seite passiert sein. Die erste Version, auf der #70 basiert, war garantiert schon älter als zwei Minuten, als ich auf "Antwort erstellen" gedrückt habe (ca. 4-5 Minuten habe ich bestimmt zum Schreiben gebraucht - erst recht für Beiträge mit Links zu anderen Quellen; auch wenn ich das i.d.R. nicht "mitstoppe").
 
Ich habe AVM bisher halt nicht als übermäßig "responsive" wahrgenommen, auch wenn man beim Melden von Problemen "responsible" vorging.
Bist du dir da jetzt ganz sicher, daß du die 2 Worte nicht verwechselt hast?

Also wenn ich die austausche, dann ergibt es für mich einen Sinn.
 
Nein, bin ich natürlich nicht ... aber wenn ich "responsible" mit "verantwortungsvoll/verantwortungsbewußt" übersetze und "responsive" mit "reagieren(d)", dann paßt dieser Satz deutlich zu meinen eigenen Erfahrungen. Bis man von AVM eine Reaktion erhält, vergeht deutlich mehr Zeit als (z.B. vom BSI) empfohlen und zwar gerade dann, wenn man selbst sich zuerst nur vertraulich an AVM gewandt hat und nicht gleich damit "an die Öffentlichkeit" gegangen ist.

Man bezeichnet "responsible disclosure" ja auch als "coordinated disclosure" ... aber wie soll man etwas koordinieren, wenn der eine "Kommunikationspartner" eher "unresponsive" ist? Das ist genau das Problem, auf welches ich hier hinauswollte.

Wenn das also nichts mit (von mir nicht verstandener) Ironie zu tun hatte, dann verstehe ich nicht, warum für Dich der Tausch einen Sinn ergibt.
 
Dieses ganze gerede von wegen HTTPS finde ich an dieser Stelle für falsch
Zumal das ja gerade mal gar nichts daran ändert, daß auch ein WLAN-Client (also eine STA) angegriffen werden könnte (und zwar durchaus von einem Angreifer im WLAN, der seinerseits das WPA2-Kennwort selbst - berechtigterweise - kennt) und da von dort zum FRITZ!Box-GUI dann eben keine HTTPS-Verbindung erzwungen wird, wäre eine FRITZ!Box spätestens auf dem Umweg über das "Abgreifen" von Admin-Credentials ebenfalls wieder gefährdet.

Es ist also sehr nett, wenn AVM da betont, daß eigentlich alle wichtigen Vorgänge heutzutage auch eine Ende-zu-Ende-Verschlüsselung verwenden ... das AVM-GUI der FRITZ!Box macht das genau nicht (auch wenn es möglich ist, sofern der Benutzer sich selbst darum kümmert).
 
Es ist also sehr nett, wenn AVM da betont, daß eigentlich alle wichtigen Vorgänge heutzutage auch eine Ende-zu-Ende-Verschlüsselung verwenden ... das AVM-GUI der FRITZ!Box macht das genau nicht (auch wenn es möglich ist, sofern der Benutzer sich selbst darum kümmert)
Und ich füge hinzu...
Den sicheren lokalen HTTPS Zugang verhindert, wenn man ihn für den lokalen Zugriff auf Port 443 setzt und sie ihn dann, bei Benutzung ihrer "MyFRITZ!App 2" bei Aktivierung der Heimnetzverbindung für den Zugriff aus den Internet (Fernzugriff) auf eine beliebige, nicht zu erratende hohe Portnummer unüberlegt "scharfschalten", obwohl der Benutzer überhaupt keinen "Fernzugriff" benötigt, da er ja stattdessen VPN (die Heimnetzverbindung) nutzen möchte.
 
Den sicheren lokalen HTTPS Zugang verhindert, wenn man ihn für den lokalen Zugriff auf Port 443 setzt und sie ihn dann, bei Benutzung ihrer "MyFRITZ!App 2" bei Aktivierung der Heimnetzverbindung für den Zugriff aus den Internet (Fernzugriff) auf einen beliebige, nicht zu erratende hohe Portnummer unüberlegt "scharfschalten", obwohl der Benutzer überhaupt keinen "Fernzugriff" benötigt, da er ja stattdessen VPN (die Heimnetzverbindung) nutzen möchte.
Hä? Irgendwie komme ich bei diesem Schachtelsatz nicht mit. Kannst Du das mal bitte etwas ausführlicher erläutern, am besten in mehreren Sätzen? Danke.
 
  • Like
Reaktionen: AdamSapfel
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.