KRACK-Attacke auf WPA2

[peterhart]

Hallo,
gibt es bereits Hinweise wie mit der Problematik KRACK-Attacke auf das WPA2 Protokoll bezügliche der pfsense umgegangen werden sollte?

Gruß
Peter

[JeGr]

pfSense nutzt FreeBSD. FreeBSD wiederum nutzt wpa_supplicant, soweit mir bekannt ist hauptsächlich als Port von Upstream. Von "pfSense" Seite aus kann ich mir somit wenig vorstellen, was da getan werden soll, da das Problem nicht in irgendwelchen spezifischen pfSense (oder sogar FreeBSD) Quellen sitzt, sondern Protokoll- und toolabhängig ist.

Upstream von wpa_supplicant hat wohl bereits mit commits begonnen zu patchen und soweit ich sehe sind die Patches auch bei FreeBSD schon angekommen bzw. werden analysiert:
https://docs.freebsd.org/mail/current/freebsd-current.html

Auf der Mailingliste gibt es dazu wie üblich bei sowas die entsprechenden Detailinfos. Man wird also in entsprechender Zukunft mit Patches für den wpa_supplicant und hostapd Teil rechnen können. Interessant auch die Aussage, dass man davon ausgeht, dass viele Hersteller von commodity-Routern wohl wahrscheinlich nichts tun werden, da ihre Versionen (wenn genutzt) von den Tools zu alt sind und der Aufwand zu patchen zu hoch - es wird spannend sein zu sehen, welche SOHO Hersteller da was tun und welche nicht. Und in wieweit auch Enterprise Hersteller was tun.

Generell ist aber zumindest mein Empfinden so, dass die meisten größeren pfSense Installationen kein WiFi einsetzen, die Richtung das getrennt von der Firewall zu halten wurde ja schon länger vorgegeben und der offizielle Verkauf von WLAN HW mit pfSense/Netgate Produkten zu Gunsten externer Lösungen ja ebenfalls.

Gruß

Edit: Zusätzlich: https://forum.pfsense.org/index.php?topic=138176.0
Edit2: pfSense Bugtracker dazu: https://redmine.pfsense.org/issues/7951

[un1que]

Bitte korrigiert mich, wenn ich falsch liege, aber ich habe schon an mehreren Stellen gelesen, dass in erster Linie ein Client-seitiges Update kommen muss, weil der Angriff über die Clients stattfinden würde. Wenn ich mir nun überlege, wie viele Android Smartphones/Tablets nun ohne dieses Sicherheitsupdate werden leben müssen…

[JeGr]

Um es zu zitieren:

Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!

Es müssen beide Seiten gefixt werden um das sinnvoll umzusetzen. Zusätzlich sind flexiblere APs als 08/15 Home/SOHO Router ja auch in der Lage, nicht nur AP zu spielen, sondern auch selbst Client o.ä., somit ist es auch für Linux/BSD/Distros etc. wichtig, hier zu patchen. Ubuntu, Fedora und Co. haben hier schon vorgelegt und angefangen zu patchen. AVM soll angeblich in einem Statement gesagt haben, dass sie es auf den FritzBoxen NICHT patchen, weil sie die "Schuld" auf dem Client sehen. Wird also ein ziemliches Chaos sowohl auf Client als auch AP Seite - zumal ein betroffener Client (bspw. Android) immer noch hergehen kann und macht einfach schlupp nen VPN auf für die Kommunikation und prompt ist ihm WPA ziemlich schnuppe. Bei nem Router/AP geht das nicht mal so eben.

[Exordium]

@un1que:

Bitte korrigiert mich, wenn ich falsch liege, aber ich habe schon an mehreren Stellen gelesen, dass in erster Linie ein Client-seitiges Update kommen muss, weil der Angriff über die Clients stattfinden würde. Wenn ich mir nun überlege, wie viele Android Smartphones/Tablets nun ohne dieses Sicherheitsupdate werden leben müssen…

Bei dem meisten Androids mit altem Stand bis 4.2.x ist das doch egal. Die Dinger sind meist schon so verseucht, da kommt es den weiteren Bug eh nimmer an. Bei 5+6 sieht es aber auch nicht rosig aus.
Oftmals hilft hier nur noch ein "community-rom update" weil von den Herstellern nichts offizielles kommt.