WPA2 protocol gekraakt - Lijst met vendor updates

[daxy]

Bron: https://arstechnica.com/i...ic-open-to-eavesdropping/
Een mooi duidelijk Nederlands artikel staat overigens op iCulture: https://www.iculture.nl/n...etsbaar-wpa2-beveiliging/

De Belgische onderzoekers Mathy Vanhoef van KU Leuven en Frank Piessens van imec-DistriNet ontdekten tien kwetsbaarheden in het WPA2 protocol. De details zijn bekend gemaakt in een paper: https://papers.mathyvanhoef.com/ccs2017.pdf. Deze kwetsbaarheden zijn al weken bekend en bedrijven zijn al bezig hun software te updaten.

De kwetsbaarheden zijn bekend onder: 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.

---

Voor zover bekend zijn deze firmwares al gefixed (client fixes in bold):

• Aerohive:
  • HiveOS versie 8.1r2a zal vandaag beschikbaar zijn.
  • HiveOS versie 6.5r9 en 6.7r4 zullen uiterlijk 20 oktober beschikbaar komen.
  • De AP121, AP141, AP170, BR200, AP130*, AP230*, AP320, AP340, AP330, AP350, AP370, AP390 en AP1130 moeten upgraden naar HiveOS 6.5r9 zodra deze beschikbaar komt.
  • De AP122, AP130*, AP150W, AP230*, AP245X, AP250, AP550 en AP1130* moeten upgraden naar HiveOS 8.1r2a.
  * Voor de AP130, AP230 en AP1130 kan je kiezen tussen HiveOS 6.5r9 en HiveOS 8.1r2a
• Apple - iOS, tvOS, watchOS en macOS laatste Beta's
• Aruba - ArubaOS:
  • 6.3.1.25
  • 6.4.4.16
  • 6.5.1.9
  • 6.5.3.3
  • 6.5.4.2
  • 8.1.0.4
• Aruba - InstantOS:
  • 4.2.4.9
  • 4.3.1.6
  • 6.5.3.3
  • 6.5.4.2
• Cisco:
  • Meraki: 24.11 and 25.7
  • Full details on all Cisco products: https://tools.cisco.com/s...ory/cisco-sa-20171016-wpa
• DD-WRT: toegevoegd in SVC Changeset 33525 (16 Oct). Komt in nieuwe daily builds
• Debian: wpa_supplicant versie:
  • jessy - 2.3-1+deb8u5
  • stretch - 2:2.4-1+deb9u1
  • buster - 2:2.4-1.1
  • sid - 2:2.4-1.1
• Fedora - Zelf installeren via https://koji.fedoraproject.org/koji/buildinfo?buildID=984995
• Fortinet - FortiAP v5.6.1
• Intel / Windows - Multiple fixes for Intel's Windows drivers: https://security-center.i...SA-00101&languageid=en-fr
• Juniper Networks - MSS 9.2.1, 9.6.5, and all subsequent releases.
• LineageOS - Any nougat (cm-14.1) build that was sync'd as of 17:45 UTC on 2017-10-16 will be patched.
• LEDE: 17.1.4 (when released)
• Mikrotik - RouterOS:
  • v6.39.3
  • v6.40.4
  • v6.41rc
• Netgear:
  • Advisory: https://kb.netgear.com/00...V-2017-2836-PSV-2017-2837
  • WN604,WNDAP620, WAC720/WAC730, WNAP210v2, WNDAP660, WND930, WAC505 / WAC510, WAC120, WNAP320, WNDAP350
• OpenBSD:
  • -current
  • 6.0 patch: https://ftp.openbsd.org/p...on/018_net80211.patch.sig
  • 5.9 patch: https://ftp.openbsd.org/p...on/035_net80211.patch.sig
• Ubiquity - 3.9.3
• Windows - October 2017 Update

Wellicht kunnen we hier bijhouden welke versies wel gefixed zijn (en wie wil er helpen bij te houden)?

Nog iemand die een lijstje bijhoudt: https://www.bleepingcompu...krack-wpa2-vulnerability/

[ Voor 82% gewijzigd door daxy op 17-10-2017 11:25 ]

[ISaFeeliN]

Ik wacht met smart op de update van Asus RT-N66U (merlin), op het forum ervan geregistreerd zodat ik dat in de gaten kan houden.

[RobinF]

Is er een manier waarom we dit zelf kunnen testen?

[ISaFeeliN]

RobinF schreef op maandag 16 oktober 2017 @ 10:07:
Is er een manier waarom we dit zelf kunnen testen?

Ga er maar vanuit dat alle wifi apparatuur vulnerable is (uitgezonderd het lijstje hierboven die al gepatchet is)

[daxy]

RobinF schreef op maandag 16 oktober 2017 @ 10:07:
Is er een manier waarom we dit zelf kunnen testen?

Op dit moment nog niet, aangezien de details nog niet bekend zijn gemaakt.
"Ze" gaan er van uit dat vanmiddag informatie beschikbaar komt op https://www.krackattacks.com/.
Ga er van uit dat alle software kwetsbaar is, tenzij het specifiek opgelost is.

[ISaFeeliN]

" The basic idea seems to be that there's a way of forcing certain parts of the cryptographic process to reuse what should be one-time values, and this results in leaking enough information so as to reveal authentication keys and therefore mean anything not secured by means other than the WiFi encryption becomes accessible.

... as for whether mitigations are available or not, I suspect it's going to depend on:

- Whether the code that implements the affected parts of the WPA2 protocol can be updated on the affected equipment (read only in silicon? firmware? read only but can be overridden in software, but a performance hit?)
- Whether the chipset manufacturers release an update
- Whether the manufacturers release that update"

ajajaj..

[hcQd]

Zo te zien is wpa_supplicant gepatcht, nu nog even wachten tot deze nieuwe versie opgenomen wordt in de verschillende firmwares. Hopelijk komt Eric snel met een update voor Merlin.

[daxy]

De paper staat nu online: https://papers.mathyvanhoef.com/ccs2017.pdf

[Nakebod]

Aruba Instant firmware van 10/10/2017 zit nu op 6.5.4.2. Deze heeft de fix NIET schijnbaar wel.
Zie vtsalf in "WPA2 protocol gekraakt - Lijst met"

[ Voor 42% gewijzigd door Nakebod op 16-10-2017 13:39 ]

[DennusB]

Ubiquiti Unifi firmware 3.9.3 fixt het probleem ook! (Is nog wel in beta)

[hjs]

DennusB schreef op maandag 16 oktober 2017 @ 11:50:
Ubiquiti Unifi firmware 3.9.3 fixt het probleem ook! (Is nog wel in beta)

Staat toch al in de openingspost

[DennusB]

hjs schreef op maandag 16 oktober 2017 @ 12:09:
[...]


Staat toch al in de openingspost

Je hebt gelijk. Had ik even gemist. Liever dubbel posten dan niet posten in dit geval denk ik

[Raven]

Hoe zit het als je een pc met pfSense, IPFire of wat anders hebt, bij wie moet dan de fix wegkomen? De makers van de wifi drivers, hostapd, het OS of ergens anders?

[Shinji]

Geldt dit ook voor als je dot1X gebruikt op wireless? Is mij nog niet helemaal duidelijk momenteel.

Volgens een reactie op nieuws: Belgische onderzoekers vinden ernstig lek in wifibeveiliging wpa2 zou je niet kwetsbaar zijn indien je WPA2 enterprise icm met dot1X gebruikt. Echter zie ik dit nog nergens bevestigd.

[gertvdijk]

Shinji schreef op maandag 16 oktober 2017 @ 12:31:
Geldt dit ook voor als je dot1X gebruikt op wireless? Is mij nog niet helemaal duidelijk momenteel.

Volgens een reactie op nieuws: Belgische onderzoekers vinden ernstig lek in wifibeveiliging wpa2 zou je niet kwetsbaar zijn indien je WPA2 enterprise icm met dot1X gebruikt. Echter zie ik dit nog nergens bevestigd.

Zoals ik "WPA2 enterprise" ken is dat 802.1x. En quote van de website:

quote: https://www.krackattacks.com/

The attack works against both WPA1 and WPA2, against personal and enterprise networks

[vtsalf]

Nakebod schreef op maandag 16 oktober 2017 @ 11:42:
Aruba Instant firmware van 10/10/2017 zit nu op 6.5.4.2. Deze heeft de fix NIET.
Grote kans dat de fix in 6.5.4.3 of 6.5.5 komt, afhankelijk hoe ze hun versienummering doen.

Dit is onjuiste informatie. Volgens de security advisory van Aruba is deze versie juist WEL gepatched.

Q: Which versions of ArubaOS software contain the fixes?
A: The vulnerabilities have been fixed in the following ArubaOS patch releases, which are all available for download immediately:
• 6.3.1.25
• 6.4.4.16
• 6.5.1.9
• 6.5.3.3
• 6.5.4.2
• 8.1.0.4

Bron: http://www.arubanetworks....SA-2017-007_FAQ_Rev-1.pdf

[doc]

Ubiquiti 3.9.3 nu ook beschikbaar als non-beta user

https://community.ubnt.co...een-released/ba-p/2099365

[daxy]

vtsalf schreef op maandag 16 oktober 2017 @ 12:43:
[...]
Dit is onjuiste informatie. Volgens de security advisory van Aruba is deze versie juist WEL gepatched.
[...]

Bron: http://www.arubanetworks....SA-2017-007_FAQ_Rev-1.pdf

Thanks, toegevoegd aan de start-post!

[daxy]

Nu weet ik weer waarom ik fan van Debian ben, zojuist de security update binnen gekregen (start-post aangepast), Android schijnt pas vanaf 6 november een update te krijgen! Cisco / Meraki heeft al een fix.

[ Voor 33% gewijzigd door daxy op 16-10-2017 13:27 ]

[Nakebod]

vtsalf schreef op maandag 16 oktober 2017 @ 12:43:
[...]
Dit is onjuiste informatie. Volgens de security advisory van Aruba is deze versie juist WEL gepatched.
[...]
Bron: http://www.arubanetworks....SA-2017-007_FAQ_Rev-1.pdf

Ok, dan hebben ze daar in de release notes niets over (mogen?) vermelden. Vandaar dat ik dacht dat dit er nog niet inzat.
BTW: ArubaOS is niet hetzelfde als InstantOS waar ik het over had. Al komen de versienummers wel erg overeen voor de duidelijkheid

Dus voor de volledigheid:

Q: Which versions of ArubaOS software contain the fixes?
A: The vulnerabilities have been fixed in the following ArubaOS patch releases, which are all available for
download immediately:
• 6.3.1.25
• 6.4.4.16
• 6.5.1.9
• 6.5.3.3
• 6.5.4.2
• 8.1.0.4


Q: Which versions of InstantOS software contain the fixes?
A: The vulnerabilities have been fixed in the following InstantOS patch releases, which are all available for
download immediately:
• 4.2.4.9
• 4.3.1.6
• 6.5.3.3
• 6.5.4.2

[daxy]

Ouch, ik hoop dat er niemand wacht op een Zyxel fix, die komen ergens tussen November en Februari! http://www.zyxel.com/supp...wpa2_key_management.shtml

[Groentjuh]

LEDE Project is ook hard aan het werk om een nieuwe versie zonder deze kwetsbaarheid te maken.

Er zijn 2 commits (master en 17.01) gepushed, dus 17.01.4 zal niet kwetsbaar zijn. Het is echter nog even wachten op deze versie.

[gertvdijk]

daxy schreef op maandag 16 oktober 2017 @ 13:57:
Ouch, ik hoop dat er niemand wacht op een Zyxel fix, die komen ergens tussen November en Februari! http://www.zyxel.com/supp...wpa2_key_management.shtml

De fixes zijn vooral voor wireless clients. Logisch om dan apparaten die bedoeld zijn als AP ook geen prio te geven nu. Ubiquiti Unifi apparatuur vanaf Gen2 heeft echt ondersteuning om in STA mode te draaien (als bridge dus) en die krijgen dan ook de fix.

Met andere woorden; focus op al die client devices die je nu hebt. Je foon, je tablet, je pc, je smart home apparaten etc.

[Blommie01]

Goed om te zien dat diverse fabrikanten direct reageren en de boel fixen. Ik ga mijn Ubiquiti AP's ook maar direct updaten.

Ik ben wel erg benieuwd hoe ISP's en de alles-in-een boeren zoals Asus, Draytek, Zyxel, Netgear enz. gaan reageren. Actief of als struisvogels.

Ze kunnen nu het verschil maken...

[Nakebod]

Volgens AVM/Fritzbox is er "niets aan de hand" want er zijn geen inbraken gemeld. En dan moet je ook nog in de buurt zijn. En je hebt toch nog HTTPS
Verwacht dus geen updates binnen redelijke termijn.

quote: https://en.avm.de/service/current-security-notifications/

Krack breach in WPA2
Several media have reported about a leak in the WPA2 protocol of wireless networks today. WPA is relevant for all wireless LAN products from smartphone to router all the way to IP cameras. So far there have been no attacks reported, which could only occur in a direct wireless environment. More details are needed to fully assess the situation. Besides Krack, Internet connections via HTTPS pages (online banking, Google, Facebook, etc.) are secureley encrypted.
If necessary, AVM will provide an update as always. Please find the statement from the Wi-Fi Alliance > here.

[dion_b]

Blommie01 schreef op maandag 16 oktober 2017 @ 14:47:
Goed om te zien dat diverse fabrikanten direct reageren en de boel fixen. Ik ga mijn Ubiquiti AP's ook maar direct updaten.

Ik ben wel erg benieuwd hoe ISP's en de alles-in-een boeren zoals Asus, Draytek, Zyxel, Netgear enz. gaan reageren. Actief of als struisvogels.

Ze kunnen nu het verschil maken...

Ik wil niet afhankelijk zijn van het wel of niet gepatched zijn van het AP waar ik toevallig mee verbind. Het echte verschil zit aan clientzijde. Dat is ook wat ik op dit moment vooral mis, hoe het daar zit.

Laptops:
- Windows, geen idee
- MacOS, geen idee

Mobile:
- iOS, geen idee
- Android - pas in november update in de source tree - en dan de vraag of de device vendors het overnemen en hoe lang dat duurt.

[Brahiewahiewa]

dion_b schreef op maandag 16 oktober 2017 @ 14:55:
[...]

Ik wil niet afhankelijk zijn van het wel of niet gepatched zijn van het AP waar ik toevallig mee verbind. Het echte verschil zit aan clientzijde. Dat is ook wat ik op dit moment vooral mis, hoe het daar zit.

Laptops:
- Windows, geen idee
- MacOS, geen idee

Mobile:
- iOS, geen idee
- Android - pas in november update in de source tree - en dan de vraag of de device vendors het overnemen en hoe lang dat duurt.

Naar verluid zijn windows, osx en ios niet kwetsbaar

[Blommie01]

dion_b schreef op maandag 16 oktober 2017 @ 14:55:
[...]

Ik wil niet afhankelijk zijn van het wel of niet gepatched zijn van het AP waar ik toevallig mee verbind. Het echte verschil zit aan clientzijde. Dat is ook wat ik op dit moment vooral mis, hoe het daar zit.

Laptops:
- Windows, geen idee
- MacOS, geen idee

Mobile:
- iOS, geen idee
- Android - pas in november update in de source tree - en dan de vraag of de device vendors het overnemen en hoe lang dat duurt.

Ik verbind al jaren niet meer met vreemde netwerken. Alleen maar thuis en op kantoor vertrouw ik de netwerken. Beide inmiddels gepatched

De rest gaat via tethering.

[ Voor 3% gewijzigd door Blommie01 op 16-10-2017 15:07 ]

[dion_b]

Brahiewahiewa schreef op maandag 16 oktober 2017 @ 15:01:
[...]

Naar verluid zijn windows, osx en ios niet kwetsbaar

Is dat zo? Linux (incl Android >6.0) is bijzonder kwetsbaar door een stricte interpretatie van een onhandig geformuleerde 802.11 spec in WPA-supplicant 2.4, doordat je dan de PTK kunt overschrijven met allemaal nullen en vanaf dat moment ongestoord alle verkeer kunt afluisteren - maar dat wil niet zeggen dat andere platforms helemaal niet kwetsbaar zijn. Om krackattacks.com te citeren:

During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks.

[...]

With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper.

Tenzij ze dus specifiek sindsdien gepatched zijn zijn ze nog steeds kwetsbaar.

Bij Windows 7, Windows 10 en iOS betreft het alleen de GTK, niet de PTK, dus de scope is kleiner, maar nonzero.

[ Voor 4% gewijzigd door dion_b op 16-10-2017 15:13 ]

[begintmeta]

OpenBSD had volgens Vanhoef toch ook al een stille pre-embargopatch in juli gekregen, toch?

[SmokingSig]

Benieuwd wanneer Cisco met nieuws komt.

[daxy]

begintmeta schreef op maandag 16 oktober 2017 @ 15:16:
OpenBSD had volgens Vanhoef toch ook al een stille pre-embargopatch in juli gekregen, toch?

Klopt, toegevoegd aan de start-post.

SmokingSig schreef op maandag 16 oktober 2017 @ 15:17:
Benieuwd wanneer Cisco met nieuws komt.

Staat al in de start-post: Cisco - Meraki: 24.11 and 25.7
Of zocht je een andere?

[Brahiewahiewa]

dion_b schreef op maandag 16 oktober 2017 @ 15:08:
[...]
\
Tenzij ze dus specifiek sindsdien gepatched zijn zijn ze nog steeds kwetsbaar....

Denk je dat in juli alleen de routerfabrikanten zijn ingelicht, en Microsoft en Apple niet?

[plizz]

Overzicht van Cisco system:
https://tools.cisco.com/s...ory/cisco-sa-20171016-wpa

[daxy]

Intel (Windows drivers) en Netgear info heb ik toegevoegd.
Cisco link heb ik toegevoegd, thanks @plizz

[vDorst]

Fedora F26 nog in goedkeur fase. Het is wel handmatig te installeren.
https://koji.fedoraproject.org/koji/buildinfo?buildID=984995

[Nijl]

Weet iemand hoe ik kan zien of de experia v10 die bug ook heeft?

[daxy]

vDorst schreef op maandag 16 oktober 2017 @ 16:37:
Fedora F26 nog in goedkeur fase. Het is wel handmatig te installeren.
https://koji.fedoraproject.org/koji/buildinfo?buildID=984995

Thanks, added!

Nijl schreef op maandag 16 oktober 2017 @ 16:37:
Weet iemand hoe ik kan zien of de experia v10 die bug ook heeft?

Ja, alles wat WiFi heeft is kwetsbaar tenzij het specifiek gefixed is. Dus de KPN Experia boxen en Ziggo modems ook. Die moeten gefixed worden, maar ook de clients. Alle Android, iOS, Windows drivers etc moeten geupdate gaan worden.

[Nijl]

daxy schreef op maandag 16 oktober 2017 @ 16:41:
[...]

Thanks, added!


[...]

Ja, alles wat WiFi heeft is kwetsbaar tenzij het specifiek gefixed is. Dus de KPN Experia boxen en Ziggo modems ook. Die moeten gefixed worden, maar ook de clients. Alle Android, iOS, Windows drivers etc moeten geupdate gaan worden.

Ik lees net dat voor de experia vx (telfort/kpn) nog geen fix voorhanden is.

Draadje bij telfort: https://forum.telfort.nl/...-wifi-protocol-wpa2-71824

Draadje bij KPN https://overons.kpn/nl/ni...baarheid-in-wifi-protocol

[ Voor 20% gewijzigd door Nijl op 16-10-2017 16:43 ]

[Raven]

Heeft Samsung (of welke smartphone-/tabletfabrikant dan ook) al gereageerd over hoe om te gaan met toestellen die buiten de 2 jaar updateondersteuning zijn en dus volgens het updatebeleid niks krijgen?
( * Raven heeft een S4)

[ Voor 7% gewijzigd door Raven op 16-10-2017 17:42 ]

[dion_b]

Brahiewahiewa schreef op maandag 16 oktober 2017 @ 15:31:
[...]

Denk je dat in juli alleen de routerfabrikanten zijn ingelicht, en Microsoft en Apple niet?

Dat zijn ze zeker, maar vertelt me nog niet wat ze ermee gedaan hebben. Wat ik wil weten is bevestiging of ze de boel al gepatched hebben, zo ja vanaf welke patch/buildversie en zo nee vanaf welke versie het verwacht is.

Oh, en wat ze wel of niet gaan doen met EOL dingen als WinXP/Vista, waar eerder bij uitzondering wel nog patches op security issues gekomen zijn.

[Lrrr]

Draadje bij T-Mobile Thuis. Lijkt goed opgepakt te worden.

[justmike]

Is er bekend of AVM ( fritzbox) aan een update werkt? Had al eens hun twiter gecheckt maar het duits daar had net zo goed chinees kunnen zijn voor mij.

[apNia]

Ziggo thread

[hcQd]

@justmike
Van hun site:

Falls notwendig wird AVM wie gewohnt ein Update bereitstellen.

(Mocht het noodzakelijk zijn zal AVM, zoals gewoonlijk, een update beschikbaar stellen.)

Een beetje teleurstellende reactie.

[vanaalten]

daxy schreef op maandag 16 oktober 2017 @ 16:32:
Intel (Windows drivers) en Netgear info heb ik toegevoegd.

Misschien wel goed om de lijst alfabetisch te houden en Intel dus op z'n plek te zetten.

Daarnaast vind ik de website van Intel waar je naar linkt iets verwarrend, in eerste instantie dacht ik dat ik de 'mitigated' versie moest hebben - maar je moet volgens mij op de 'wifi driver' in de 'updated source' kolom klikken. Dan kom ik in elk geval op wifi-driver 20.0.2 uit (terwijl de gewone download-site van Intel nog 19.70.0 heeft).

[Zaffo]

Voor de compleetheid, een link naar het draadje op het Mikrotik forum.

[Thralas]

daxy schreef op maandag 16 oktober 2017 @ 16:41:
Ja, alles wat WiFi heeft is kwetsbaar tenzij het specifiek gefixed is. Dus de KPN Experia boxen en Ziggo modems ook. Die moeten gefixed worden, maar ook de clients. Alle Android, iOS, Windows drivers etc moeten geupdate gaan worden.

Je hebt niet goed gelezen.

What if there are no security updates for my router?

Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients.

[...]

For ordinary home users, your priority should be updating clients such as laptops and smartphones.

Alle ISP-routers vallen dus per definitie buiten de boot.

En verder doet iedereen weer alsof de wereld half vergaat. De aanval is ontzettend elegant gezien het aantoont dat de security proofs voor de WPA handshake dus blijkbaar niet voldoen, maar praktisch valt het allemaal wel mee.

Je kunt verkeer ontsleutelen, maar moet daarvoor wel voor een gedeelte van het verkeer kunnen raden wat de inhoud is. En dan moet je een soort Lingo gaan spelen om er ook maar een zinnige reeks van karakters uit te krijgen. Ontzettend onpraktisch.

De bug in wpa_supplicant (en dus Android 6.0+) die ze along the way vonden is een stuk zorgelijker. Die gebruiken ze dan ook (wijselijk) in de demo. Eigenlijk een beetje flauw, want dat is niet representatief voor de meest wijdverbreide bug waar alles en iedereen het over heeft (de protocolkwetsbaarheid).

EDIT: Wat nuance

En ja, dat zijn nog veel Androiddevices (en wat je nog meer kunt bedenken met een recente wpa_supplicant), maar die hadden bijna allemaal ook nog een hoop BT/WiFi-firmwareupdates tegoed. Dan is deze bug ook niet meer je grootste probleem..

[ Voor 12% gewijzigd door Thralas op 16-10-2017 20:32 ]

[AlterEgo]

LineageOS:
Patched: Any nougat (cm-14.1) build that was sync'd as of 17:45 UTC on 2017-10-16 will be patched.
Our marshmallow (cm-13.0) branch is currently unpatched.

[dion_b]

MS heeft blijkbaar de boel afgelopen dinsdag al gepatched voor alles vanaf Windows 7 / Server 2008 en ze hebben bevestigd dat het alleen om de group key (GTK) gaat:

https://portal.msrc.micro...88-e711-80e2-000d3a32fc99

ADV170016 was deprecated in lieu of CVE-2017-13080.

http://seclists.org/microsoft/2017/q4/6

Thralas schreef op maandag 16 oktober 2017 @ 20:11:
[...]

Alle ISP-routers vallen dus per definitie buiten de boot.

Nou...

Twee dingen die nog niet breed opgepikt zijn maar gewoon in het artikel staan:
1) als TKIP encryption gebruikt wordt (WPA1) ipv CCMP-AES, kun je niet alleen pakketten decrypten en replayen maar ook forgen.
2) als 802.11r actief is kun je naast verkeer van STA naar AP ook andersom van AP naar STA vangen.

Beide zaken die je op de AP kunt/moet aanpakken. Quick&dirty schakel je TKIP en 802.11r uit, duurzamer los je de mogelijkheid voor key reinstallation op.

Zat werk aan de winkel voor de AP vendors dus.

Je kunt verkeer ontsleutelen, maar moet daarvoor wel voor een gedeelte van het verkeer kunnen raden wat de inhoud is. En dan moet je een soort Lingo gaan spelen om er ook maar een zinnige reeks van karakters uit te krijgen. Ontzettend onpraktisch.

De bug in wpa_supplicant (en dus Android 6.0+) die ze along the way vonden is een stuk zorgelijker. Die gebruiken ze dan ook (wijselijk) in de demo. Eigenlijk een beetje flauw, want dat is niet representatief voor de meest wijdverbreide bug waar alles en iedereen het over heeft (de protocolkwetsbaarheid).

44% van Android toestellen wordt geacht vulnerable te zijn. Dat is 44% van een erg groot getal. Zat om je zorgen over te maken. Ben blij dat ik Lineage 14.1 draai

[ Voor 65% gewijzigd door dion_b op 16-10-2017 20:32 ]

[daxy]

Thralas schreef op maandag 16 oktober 2017 @ 20:11:
[...]


Je hebt niet goed gelezen.


[...]


Alle ISP-routers vallen dus per definitie buiten de boot.

En verder doet iedereen weer alsof de wereld half vergaat. De aanval is ontzettend elegant gezien het aantoont dat de security proofs voor de WPA handshake dus blijkbaar niet voldoen, maar praktisch valt het allemaal wel mee.

Je kunt verkeer ontsleutelen, maar moet daarvoor wel voor een gedeelte van het verkeer kunnen raden wat de inhoud is. En dan moet je een soort Lingo gaan spelen om er ook maar een zinnige reeks van karakters uit te krijgen. Ontzettend onpraktisch.

De bug in wpa_supplicant (en dus Android 6.0+) die ze along the way vonden is een stuk zorgelijker. Die gebruiken ze dan ook (wijselijk) in de demo. Eigenlijk een beetje flauw, want dat is niet representatief voor de meest wijdverbreide bug waar alles en iedereen het over heeft (de protocolkwetsbaarheid).

toon volledige bericht

Voor zover ik het begrepen heb, kan je het probleem oplossen door of al je clients te fixen, of ervoor te zorgen dat je AP's goed reageren. Met andere woorden, als je je eigen huis op orde wil hebben, zou ik beginnen met je eigen AP te fixen. Er zijn netwerken (bedrijf, openbare ruimtes, studentenhuizen) waar wel kwaadwillende rondlopen. Fix dat, daar gaat deze post over en daarom zit iedere vendor er bovenop. Ja, je moet ook nog steeds je clients fixen, dat is ook van toepassing natuurlijk, vandaar dat Intel/Windows en Debian/Fedora ook tussen het lijstje staan.

Ga niet alleen uit van je eigen vertrouwde veilige thuis netwerkje, er ligt veel meer gevaar op de loer.

[dion_b]

Deze link zou in TS mogen:
https://www.bleepingcompu...krack-wpa2-vulnerability/

We zijn niet de enige die een lijst bijhouden

[Ramon]

Heeft het zin om mac-address filtering aan te zetten op mijn Experia Box v8 totdat de boel gepatched is?

[Thralas]

dion_b schreef op maandag 16 oktober 2017 @ 20:26:
2) als 802.11r actief is kun je naast verkeer van STA naar AP ook andersom van AP naar STA vangen.

Beide zaken die je op de AP kunt/moet aanpakken. Quick&dirty schakel je TKIP en 802.11r uit, duurzamer los je de mogelijkheid voor key reinstallation op.

Oké, in enterprisesituaties heb je en punt, maar in de thuissituatie zouden we willen dat we 802.11r konden doen, toch?

Dan blijft het een hele complexe, inefficiente aanval (bonus: je moet APs wormholen).

En al lekt er (zeer beperkt) plaintext uit, als het zo belangrijk was dan zou ik me vooral afvragen waarom je niet iets van SSL gebruikte op de transportlaag. Werkt ook nog eens over vaste netwerken en het internet.

44% van Android toestellen wordt geacht vulnerable te zijn. Dat is 44% van een erg groot getal. Zat om je zorgen over te maken. Ben blij dat ik Lineage 14.1 draai

Niet in het licht van al die open SSIDs die in iedere telefoon staan. En de WiFi/BT-kwetsbaarheden van de afgelopen maanden (die leveren code-executie op).

De enige lering die ik er persoonlijk uit kan trekken is dat gebruikers nóg maar eens na moeten gaan waarom hun telefoon eigenlijk geen updates krijgt..

daxy schreef op maandag 16 oktober 2017 @ 20:29:
Voor zover ik het begrepen heb, kan je het probleem oplossen door of al je clients te fixen, of ervoor te zorgen dat je AP's goed reageren.

Nee, met uitzondering van 802.11r kun je daar weinig aan doen. Het retransmitten is inherent aan WiFi, het is de client die een hoop counters reset terwijl dat niet zou moeten..

Ja, ik erger me inderdaad aan het feit dat men nooit echt goed nagaat in hoeverre dit soort (prachtige) academische kunstjes naar een praktijkrisico vertalen. Vrijwel nooit is het je grootste probleem...

[ Voor 20% gewijzigd door Thralas op 16-10-2017 21:14 . Reden: Lezen is moeilijk ]

[daxy]

Ik heb de laatste suggesties er weer tussen gezet, inclusief de link naar het andere lijstje (maar deze hier is completer

Apple heeft deze issues opgelost in de laatste beta's. Dus qua clients zitten Windows, Debian, Fedora en OpenBSD goed, Apple bijna goed en Android... die beginnen volgende maand te kijken

Iemand interesse om te helpen met het bijhouden van dit lijstje?

[ Voor 33% gewijzigd door daxy op 16-10-2017 21:08 ]

[dion_b]

Ramon schreef op maandag 16 oktober 2017 @ 20:52:
Heeft het zin om mac-address filtering aan te zetten op mijn Experia Box v8 totdat de boel gepatched is?

Nope. Hele idee van deze attack is dat je je voordoet als de reeds geassocieerde client, dus je spooft sowieso z'n MAC-adres. MAC-filtering is hoegenaamd hooguit een admin-hulpmiddel, het heeft geen enkele toegevoegde waarde qua security.

[Ultra]

Ik denk dat MS het voor Windows alleen opgelost heeft voor de ingebouwde drivers? Anders zou bijv. Intel geen nieuwe drivers voor wireless adapters uitbrengen.

[dion_b]

Ultra schreef op maandag 16 oktober 2017 @ 21:39:
Ik denk dat MS het voor Windows alleen opgelost heeft voor de ingebouwde drivers? Anders zou bijv. Intel geen nieuwe drivers voor wireless adapters uitbrengen.

Het gaat om de WPA supplicant in kwestie. Out-of-the-box gebruikt Windows z'n eigen supplicant. Die is nu gepatched. Maar bij Windows is er een lange traditie van vendor drivers die een eigen vendor-specifieke supplicant gebruiken. In dat geval zal de fix van MS geen invloed daarop hebben en zal de vendor met eigen supplicant die ook moeten patchen. Ik vermoed dat dat is wat Intel gedaan heeft.

Waar ik me meer zorgen om maak:
MS zegt CVE-2017-13080 en CVE-2017-13081 gepatched te hebben, maar dat een evt fix voor CVE-2017-13087 en CVE-2017-13088 ((I)GTK reinstallatie vanuit slaapstand) vanuit de driver vendors zou moeten komen. Als ik dan kijk naar de Intel patches worden enkel CVE-2017-13080 en CVE-2017-13081 genoemd en niet de twee slaapstandgevallen. Dus het ziet ernaar uit dat Intel nog niet de door MS genoemde fix voor slaapstand vulnerabilities aangeleverd heeft.

[SmokingSig]

We got lucky. 2700 reeks staat er niet tussen bij Cisco

De pagina (https://tools.cisco.com/s...ory/cisco-sa-20171016-wpa) is echt onoverzichtelijk.

De 2700 reeks staat niet in de lijst. Maar als je doorklikt op de bug bij bijvoorbeeld de 2600 reeks zeggen ze:

Further Problem Description:
Cisco wireless APs models 1570, 1700, 2700 and 3700 are NOT vulnerable for 5Ghz connections, but are vulnerable on 2.4Ghz connections.


Ik zie door de bomen het bos niet.

Verder zeggen ze dat versie 8.3.130.0 available is van 16-Oct-2017. Maar bij downloads staat deze al van in september...

[ Voor 83% gewijzigd door SmokingSig op 17-10-2017 07:33 ]

[DJSmiley]

Aerohive:

Aerohive zal op zeer korte termijn nieuwe HiveOS versies uitbrengen om het probleem op te lossen. Wanneer u access points beheert die als cliënt of als mesh functioneren, update dan zo snel mogelijk.

• HiveOS versie 8.1r2a zal vandaag beschikbaar zijn.
• HiveOS versie 6.5r9 en 6.7r4 zullen uiterlijk 20 oktober beschikbaar komen.
• De AP121, AP141, AP170, BR200, AP130*, AP230*, AP320, AP340, AP330, AP350, AP370, AP390 en AP1130 moeten upgraden naar HiveOS 6.5r9 zodra deze beschikbaar komt.
• De AP122, AP130*, AP150W, AP230*, AP245X, AP250, AP550 en AP1130* moeten upgraden naar HiveOS 8.1r2a.
* Voor de AP130, AP230 en AP1130 kan je kiezen tussen HiveOS 6.5r9 en HiveOS 8.1r2a

Overigens is het updaten van je AP geen oplossing, tenzij je specifieke functies als mesh, roaming of clients gebruikt. Het issue zit in de client. In een normale AP-mode is het AP dus geen partij in dit probleem.

[ Voor 12% gewijzigd door DJSmiley op 17-10-2017 11:13 ]

[Raven]

IPFire

by Michael Tremer, 18 hours ago

Hello Community,

a team of researchers has discovered a number of vulnerabilities in WPA2 which are essentially exploitable on any device that has WiFi. All the details are over here. Congratulations! Excellent work!

I have patched the relevant packages in IPFire already with the patches provided by their developers, but it takes a while to compile everything together.

So packages are available for the x86_64 architecture right now, i586 will be available today and ARM architectures will receive updated packages no later than tomorrow. I will update this information right here when ever something changes.

En een topic hierover: http://forum.ipfire.org/viewtopic.php?f=50&t=19628

[ Voor 4% gewijzigd door Raven op 17-10-2017 11:34 ]

[DennusB]

Is er eigenlijk al iets bekend over wanneer Apple met patches voor MacOS komt?

[Nielson]

Ruckus:

https://ruckus-www.s3.ama...visory-id-101617-v1.0.pdf

https://theruckusroom.ruc...pproach-uncommon-problem/

[Bierkameel]

Ubiquiti heeft naast de Unifi range ook Amplifi:

Here are the release notes for AmpliFi firmware:

v2.4.3

WiFi security improvements (fixed several WPA key management vulnerabilities)

[dion_b]

DJSmiley schreef op dinsdag 17 oktober 2017 @ 11:11:
Aerohive:

[...]


Overigens is het updaten van je AP geen oplossing, tenzij je specifieke functies als mesh, roaming of clients gebruikt. Het issue zit in de client. In een normale AP-mode is het AP dus geen partij in dit probleem.

Roaming - specifieker Fast BSS transition, "FT", oftewel 802.11r - is wel per default ingeschakeld op de Aerohove AP's, en de attack op de FT handshake (CVE-2017-13082) is juist op de AP gericht. Als dat lukt kan alle verkeer van AP naar client gelezen of verkeer van de client naar AP gereplayed worden, en als je ook nog TKIP aan hebt staan is het mogelijk verkeer te forgen. TKIP verergert bovendien al de client attacks.

Toch aardig de moeite waard om te updaten dus. Tot die tijd vooral zorgen dat je geen TKIP gebruikt en 802.11r uitschakelt als workaround.

Edit:
Ik zie dat Ruckus exact dat aanraadt achter de link hierboven:

Until client vendors provide updates, disabling 802.11r can help mitigate the attack by eliminating one source of vulnerability (Fast BSS Transitions, otherwise known as 802.11r roaming).

[ Voor 14% gewijzigd door dion_b op 17-10-2017 12:28 ]

[doc]

Bierkameel schreef op dinsdag 17 oktober 2017 @ 12:17:
Ubiquiti heeft naast de Unifi range ook Amplifi:

Here are the release notes for AmpliFi firmware:

v2.4.3

WiFi security improvements (fixed several WPA key management vulnerabilities)

Daarnaast nog de AirMax:

All airMAX AC and M series products have fixes for the majority of WPA2 rekeying issues since v8.4.0 (AC series) and v6.0.7 (M series). Additional improvements will fully resolve the issue with v8.4.2/v6.1.2. Furthermore, our proprietary airMAX protocol makes simple attacks more difficult.

[Wijnands]

Probeer via Twitter AVM en XS4ALL te porren. Merk daar niet echt een "Sense of urgency". Mijn Ubuntu systeem kreeg vanochtend heel vroeg al een patch. Maak me momenteel vooral zorgen om de android devices in huis, Motorola/Lenovo is niet zo sterk in patchen van dingen ouder dan een jaar.

[iTeV]

Ubuntu is zoals hierboven al vermeld is, ook gepatcht

[SmokingSig]

Release update voor Cisco 5508 controllers zijn gepland deze week (19 en 20 oktober).

edit: Deze update verhelpt niet al de problemen. Het past "hetzelfde" toe als het uitschakelen van 802.11r

[ Voor 39% gewijzigd door SmokingSig op 17-10-2017 16:14 ]

[PatrickPR]

dion_b schreef op maandag 16 oktober 2017 @ 21:25:
[...]

Nope. Hele idee van deze attack is dat je je voordoet als de reeds geassocieerde client, dus je spooft sowieso z'n MAC-adres. MAC-filtering is hoegenaamd hooguit een admin-hulpmiddel, het heeft geen enkele toegevoegde waarde qua security.

Even hierop inhakend, aangezien ik zelf ook MAC-filtering thuis heb, en ook bij anderen adviseer als extra beveiliging bovenop een ingewikkeld wifi-wachtwoord.

Bedoel je dit in het licht van deze WPA2 attack? Ik heb altijd begrepen dat MAC-filtering juist wel een extra barrière is tegen het inbreken op netwerken via wifi. Het zal ongetwijfeld niet de heilige graal zijn, maar het voegt toch wel iets van beveiliging toe?

[DennusB]

PatrickPR schreef op dinsdag 17 oktober 2017 @ 14:56:
[...]

Even hierop inhakend, aangezien ik zelf ook MAC-filtering thuis heb, en ook bij anderen adviseer als extra beveiliging bovenop een ingewikkeld wifi-wachtwoord.

Bedoel je dit in het licht van deze WPA2 attack? Ik heb altijd begrepen dat MAC-filtering juist wel een extra barrière is tegen het inbreken op netwerken via wifi. Het zal ongetwijfeld niet de heilige graal zijn, maar het voegt toch wel iets van beveiliging toe?

Mac filters kan je zooooo makkelijk omzeilen door een MAC adres te spoofen. Die kan je net zo goed uitzetten...

[SmokingSig]

PatrickPR schreef op dinsdag 17 oktober 2017 @ 14:56:
[...]

Even hierop inhakend, aangezien ik zelf ook MAC-filtering thuis heb, en ook bij anderen adviseer als extra beveiliging bovenop een ingewikkeld wifi-wachtwoord.

Bedoel je dit in het licht van deze WPA2 attack? Ik heb altijd begrepen dat MAC-filtering juist wel een extra barrière is tegen het inbreken op netwerken via wifi. Het zal ongetwijfeld niet de heilige graal zijn, maar het voegt toch wel iets van beveiliging toe?

.
Het voegt sowieso iets toe. Maar er iemand mee weren die slechte intenties heeft zal niet lukken. Een mac adres spoofen (een toegelaten mac nabootsen) is gefixt in twee klikken.

[TP-Link]

Ook het hoofdkantoor van TP-Link is druk bezig te controleren welke apparaten in aanmerking komen voor een update naar aanleiding van deze WPA2 Hack.

Zodra hier meer over bekend is zal ik dit met jullie mededelen

Mvg Carmen van TP-Link

[Brooky]

Synology SRM is ook gepatched:

https://www.synology.com/...eNote/RT1900ac#ver_6542-3

[gekkie]

TP-Link schreef op dinsdag 17 oktober 2017 @ 16:20:
Ook het hoofdkantoor van TP-Link is druk bezig te controleren welke apparaten in aanmerking komen voor een update naar aanleiding van deze WPA2 Hack.

Zodra hier meer over bekend is zal ik dit met jullie mededelen

Mvg Carmen van TP-Link

Je zou zeggen alles van TP-link wat WPA(2) ondersteund (heeft) ?

[dion_b]

gekkie schreef op dinsdag 17 oktober 2017 @ 16:28:
[...]

Je zou zeggen alles van TP-link wat WPA(2) ondersteund (heeft) ?

De vendors lijken de conclusie te trekken dat het probleem aan clientzijde opgelost moet worden, dus dat alleen devices die als client kunnen optreden kwetsbaar zijn. Een router of AP in reguliere modus is dat dus niet. Enkel als je het als repeater danwel wireless bridge inzet zou dat nodig zijn.

Uitzondering is als de AP 802.11r doet, maar dat zal voor meeste consumer-grade spullen niet het geval zijn.


Wat IMHO wel relevant is: de impact van de vulnerability is veel groter als je WPA(1)-TKIP draait ipv WPA2-AES. Overal waar je default WPA/WPA2 en TKIP/AES hebt dat wijzigen in WPA2-AES only zou flink kunnen schelen *als* je client de lul is.

[gekkie]

dion_b schreef op dinsdag 17 oktober 2017 @ 16:55:
[...]

De vendors lijken de conclusie te trekken dat het probleem aan clientzijde opgelost moet worden, dus dat alleen devices die als client kunnen optreden kwetsbaar zijn. Een router of AP in reguliere modus is dat dus niet. Enkel als je het als repeater danwel wireless bridge inzet zou dat nodig zijn.

Uitzondering is als de AP 802.11r doet, maar dat zal voor meeste consumer-grade spullen niet het geval zijn.


Wat IMHO wel relevant is: de impact van de vulnerability is veel groter als je WPA(1)-TKIP draait ipv WPA2-AES. Overal waar je default WPA/WPA2 en TKIP/AES hebt dat wijzigen in WPA2-AES only zou flink kunnen schelen *als* je client de lul is.

Hmm ik meende ergens te hebben gelezen dat ook een gepatchte AP zou kunnen helpen (vermoedelijke als mitigation omdat je MITM dan niet meer wil slagen ofzo).

[Kortfragje]

Ubuntu heeft ook fixes uitgebracht :
https://usn.ubuntu.com/usn/usn-3455-1/

Update instructions

The problem can be corrected by updating your system to the following package version:

Ubuntu 17.04:
hostapd 2.4-0ubuntu9.1
wpasupplicant 2.4-0ubuntu9.1

Ubuntu 16.04 LTS:
hostapd 2.4-0ubuntu6.2
wpasupplicant 2.4-0ubuntu6.2

Ubuntu 14.04 LTS:
hostapd 2.1-0ubuntu1.5
wpasupplicant 2.1-0ubuntu1.5

[MerijnB]

Ik kreeg een mailtje van Kommago waar ik een jaar geleden een Draytek router had besteld (goed bezig Kommago!). Hier staat een statement van Draytek in: https://data.kommago.nl/i...2_KRACK_vulnerability.pdf

Dit is misschien ook nog interessant:
https://www.wifishop.nl/k...oor-wpa2-beveiligingslek/

[dion_b]

gekkie schreef op dinsdag 17 oktober 2017 @ 16:57:
[...]

Hmm ik meende ergens te hebben gelezen dat ook een gepatchte AP zou kunnen helpen (vermoedelijke als mitigation omdat je MITM dan niet meer wil slagen ofzo).

Eens, dat leek mij ook na doorlezen van de paper. Maar als ik kijk naar wat de vendors schrijven lijkt dat anders opgevat te worden. Zie bijv:

https://kb.netgear.com/00...V-2017-2836-PSV-2017-2837

Routers and gateways are only affected when in bridge mode (which is not enabled by default and not used by most customers). A WPA-2 handshake is initiated by a router in bridge mode only when connecting or reconnecting to a router.

Ze hebben het hier niet over AP-mode (wat technisch gezien natuurlijk een bridge is), maar als client bridge, dus als de router als client optreedt.

https://www.draytek.com/e...wpa2-krack-vulnerability/

When DrayTek wireless products, such as wireless routers and access points, are used as wireless base stations, they are not affected by the KRACK (Key Reinstallation AttaCK) vulnerability; therefore patches or updates are not required.

[...]

When DrayTek products are used as wireless clients and access into Internet with universal repeater or wireless WAN modes, the wireless traffic is susceptible to interception as the router or access point is acting as a wireless client.

Weet nog niet helemaal wat ik hiervan moet denken, maar consequent lijkt het wel.

[hp-got]

Zoals hier eerder gesignaleerd werd worden er op meer plaatsen lijstjes bijgehouden.
Ik kwam net deze tegen op GitHub die er behoorlijk compleet uit ziet.
Misschien iets om in de TS post als referentie op te nemen?

https://github.com/kristate/krackinfo

[hp-got]

Op het SNB forum zag ik een interessante post van RMerlin (van de Merlin ASUS firmware).
Hij heeft kennelijk contact gehad met ASUS en daar zegt men dat routers met de Broadcom chipset alleen kwetsbaar zijn in STA / repeater mode, niet in AP mode.
Daarnaast is er een patch van Broadcom onderweg, waarna er nieuwe firmware van ASUS verschijnt.

De bron is hier te vinden:
https://www.snbforums.com...-patch.41688/#post-352870

edit:
link aangepast

[ Voor 3% gewijzigd door hp-got op 17-10-2017 19:08 ]

[gekkie]

dion_b schreef op dinsdag 17 oktober 2017 @ 18:20:
[...]
Eens, dat leek mij ook na doorlezen van de paper. Maar als ik kijk naar wat de vendors schrijven lijkt dat anders opgevat te worden. Zie bijv:

Wellicht dat het verschil er in zit dat de AP vendors vooral (willen) kijken naar de vulnerability (vooral device) zelf en niet naar de mogelijkheden van mitigation via het AP. Immers als ze het naar zich toe zouden trekken betekend het en een hoop werk en er wellicht deels op aangekeken worden (door de massa).

Ah en er zitten wellicht ook wat downsides aan het patchen aan de AP kan, uit een LEDE commit::

Unfortunately this can cause interoperability issues and reduced
robustness of key negotiation, so disable the workaround by default, and
add an option to allow the user to enable it if he deems necessary.

Achja hier afwachten op Lede .. vanavond of morgen lineage maar eens updaten. Laptops zijn middels Debian al braaf gepatched. Hou ik een semi-ongebruikte elcheapo chinese android tablet over. Achja als ik me erg druk maak dan moet ik er maar braaf aan denken om altijd openvpn er op te gebruiken, maar goed de hack-o-kiddy die het geduld heeft om er op te wachten tot ik dat ding eens onder het stof vandaan haal die zou bijna wel beloond mogen worden.

[ Voor 13% gewijzigd door gekkie op 17-10-2017 19:48 ]

[dion_b]

hp-got schreef op dinsdag 17 oktober 2017 @ 19:04:
Op het SNB forum zag ik een interessante post van RMerlin (van de Merlin ASUS firmware).
Hij heeft kennelijk contact gehad met ASUS en daar zegt men dat routers met de Broadcom chipset alleen kwetsbaar zijn in STA / repeater mode, niet in AP mode.

Dat is zelfde boodschap die Netgear en Draytek verspreiden. Je zou bijna denken dat Broadcom een advisory rondgestuurd heeft

Dat de AP zelf niet vatbaar is voor de PTK, GTK, STK en TPK reinstall attacks is evident, maar voorwaarde hiervoor is dat niets met Broadcom chips 802.11r en FT ondersteunt. Dat lijkt me geen goede reclame.

Plus ik blijf erbij: WPA1-TKIP uitschakelen is als mitigation van de impact in het geval van compromitteren van een kwetsbare apparaat iets wat je wel op ieder AP kunt doen. Dus ook AP's van Asus en Draytek, en andere AP's met willekeurig welke chipset, inclusief die van Broadcom

[begintmeta]

Bij heise houden ze ook een overzichtje bij, waar ze weer naar de CMU-CERTlijst met getroffen producten linken.

[ Voor 36% gewijzigd door begintmeta op 17-10-2017 21:35 ]

[dion_b]

Hmm, over Broadcom enzo - AP's op basis van hun chipsets mogen dan niet zelf kwetsbaar zijn, maar als ik de paper herlees zijn ze wel medeplichtig te maken in de aanval:

This attack technique requires us to wait until a rekey of the
session key occurs. Several APs do this every hour [66], some examples
being [24, 26]. In practice, clients can also request a rekey by
sending an EAPOL frame to the AP with the Request and Pairwise
bits set. Coincidently, Broadcom routers do not verify the authenticity
(MIC) of this frame, meaning an adversary can force Broadcom
APs into starting a rekey handshake.

En dan zeggen dat er niets te patchen valt...

[Bl@ckbird]

Wat is er gebeurd?
Op 16 Oktober 2017 heeft een onderzoeker van de Universiteit Leuven een onderzoek gepubliceerd met daarin een aantal kwetsbaarheden in de WiFi Protected Access en WiFi Protected Access 2 protocollen. Dit zijn kwetsbaarheden in de protocollen die alle fabrikanten treffen, zowel van infrastructuur als van clients. Deze kwetsbaarheden zijn ook bekend onder de naam Key Reinstallation AttaCK (KRACK).

Welke Cisco producten zijn kwetsbaar?
Het Cisco Product Security Incident Response Team (PSIRT) heeft een Advisory uitgebracht met alle kwetsbare producten.

Wat is de impact?
Er zijn in totaal 10 kwetsbaarheden gevonden:

• 9 kwetsbaarheden zijn van toepassing op draadloze clients
• 1 kwetsbaarheid is van toepassing op infrastructuur (APs)

Om geheel veilig te zijn, moeten de kwetsbaarheden zowel in de infrastructuur, als in de clients geadresseerd worden, alleen de infrastructuur aanpassen is NIET voldoende.

De enige kwetsbaarheid van toepassing op de infrastructuur is CVE-2017-13082, en heeft betrekking op de mogelijkheid om bij gebruik van 802.11r Fast BSS Transition het AP een eerder gebruikte sleutel te laten hergebruiken.

De overige kwetsbaarheden laten een man-in-the-middle aanvaller verschillende sleutels in de client manipuleren.

NB: Geen van de aanvallen is in staat om WiFi wachtwoorden te achterhalen.

Wat kan/moet ik doen in de Cisco Infrastructuur?
De infrastructuur is alleen kwetsbaar als 802.11r Fast Transition of Adaptive Fast Transition (De adaptive r feature in samenwerking met Apple) aan staat. Wat er moet gebeuren in de infrastructuur is afhankelijk van het gebruik van die features, en het model AP.

Voor APs vóór de x800 series AC Wave 2 APs:

• 11r / Adaptive FT niet aan / niet gewenst: Geen software update nodig
• 11r / Adaptive FT aan, maar niet gewenst: Zet deze feature uit
• 11r / Adaptive FT nodig: Update software naar 8.3.130.0

Voor x800 seriesAC Wave 2 APs:

• 11r / Adaptive FT niet aan / niet gewenst: Geen software update nodig
• 11r / Adaptive FT aan, maar niet gewenst: Zet deze feature uit
• 11r / Adaptive FT nodig: Open TAC case, er wordt gewerkt aan een interim release

Voor Meraki APs:

• 11r / Adaptive FT niet aan / niet gewenst: Geen software update nodig
• 11r / Adaptive FT nodig: Update naar 24.11 of 25.7 via dashboard.

Aanvallen op clients kunnen voor een groot deel gezien worden door de infrastructuur, omdat er een AP nagedaan moet worden met hetzelfde SSID en MAC adres, op een ander kanaal. Dit is makkelijk uit te voeren, maar wordt meteen gezien door de rogue detectie van de infrastructuur. Raadpleeg voor het configureren van Rogue detectie het Rogue Management and Detection best practice document.

toon volledige bericht

Origineel bericht met meer linkjes:
https://ciscotechblog.nl/wpa-wpa-2-protocol-kwetsbaarheden/

[freedzed6]

snapt men wel dat het updaten van je eigen router (AP) NIET datgene wat hier als oplossing wordt geoppert
en eigenlijk aan de hand is? Ik zie dat men zit te wachten op updates van de provider / AP update maar juist dit is niet het probleem.

De aanval is erop gericht om het dataverkeer dat jouw telefoon / pc / tablet VERSTUURD te onderscheppen door een MITMA. Deze decrypt het verkeer en stuurt het daarna door naar je AP.
Wat normaal gesproken niet hoort te gebeuren omdat het WPA2 encrypted is. ) PLAIN TEXT verkeer zoals http, telnet en websites met geen encrypt zijn zo dus te ondervangen.

Indien je WPA2 nog niet is geupdate kan men dus onversleuteld verkeer dat via WPA2 gaat opvangen en uitlezen. Zaak is nu dus om vooral SSL(HTTPS) / VPN tunnel te gebruiken VANAF je eigen device.
maar zoals men dus ook zegt is dit ook niet 100% veilig. Door NSA tools (die de Shadow Brokers hadden uitgebracht) blijkt ook SSL niet helemaal veilig.
SSL is dus niet veilig als de website weer last heeft van een niet veilige SSL verbinding ( deze WPA2 hack laat dus beide zien zodat ook HTTPS niet altijd 100% veilig is). Hoe het zit met VPN verbinding is met nog niet helemaal duidelijk maar dit blijkt wel het beste te zijn.

Zaak is dus om de WPA2 protocol te updaten op vooral Android devices ( Linux ). Ik vraag me af hoe ze dit KIP-EI verhaal gaan oplossen met oude toestellen zonder updates.

ps: TKIP blijft minder veilig dan AES.

[TP-Link]

gekkie schreef op dinsdag 17 oktober 2017 @ 16:28:
[...]

Je zou zeggen alles van TP-link wat WPA(2) ondersteund (heeft) ?

Het hoofdkantoor heeft vannacht een FAQ uitgebracht waarin de benodigde informatie staat.

http://www.tp-link.com/en/faq-1970.html

Als je de FAQ goed doorleest dan heeft deze HACK niet op alle apparaten een invloed

Het hoofdkantoor is druk bezig een update uit te brengen op de apparaten waar dit wel een invloed op heeft.

Mvg Carmen van TP-Link

[dion_b]

TP-Link schreef op woensdag 18 oktober 2017 @ 09:47:
[...]


Het hoofdkantoor heeft vannacht een FAQ uitgebracht waarin de benodigde informatie staat.

http://www.tp-link.com/en/faq-1970.html

Als je de FAQ goed doorleest dan heeft deze HACK niet op alle apparaten een invloed

Het hoofdkantoor is druk bezig een update uit te brengen op de apparaten waar dit wel een invloed op heeft.

Mvg Carmen van TP-Link

Jammer dat met geen woord gerept wordt over de zwaardere gevolgen van de attack voor je client als op de AP WPA-TKIP ingesteld staat.

Gelukkig worden recente TP-Link apparaten per default met WPA2-AES only geleverd, maar er zijn mensen met oudere apparaten met andere defaults, en mensen die zelf de instelling aangepast hebben. Het zou daarom raadzaam zijn om een verwijzing daarnaar in zo'n statement op te nemen.

[copywizard]

ik zie net dat Synology voor hun RT1900/2600ac routers een update met fixes voor alle CVE versies heeft.

https://www.synology.com/nl-nl/releaseNote/RT1900ac

Version: 1.1.5-6542-3

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).

[ Voor 59% gewijzigd door copywizard op 18-10-2017 11:04 ]

[Raven]

ESP8266 / ESP32: Espressif Releases Patches for WiFi Vulnerabilities (CERT VU#228519)
- release/v2.1 (ESP-IDF) branch, since commit b6c91ce088ef64bd5b96a5af04885040b42b1816; it will appear in the forthcoming V2.1.1 release.
- master branch (ESP-IDF), since commit 904d6c8f2b01de52597b9e16dad19c78ade9e586; it will appear in the forthcoming V3.0 release.
- ESP8266 RTOS (ESP8266) master branch, since commit 2fab9e23d779cdd6e5900b8ba2b588e30d9b08c4.
- ESP8266 NON-OS (ESP8266) master branch, since commit b762ea222ee94b9ffc5e040f4bf78dd8ba4db596.

Additionally, Arduino ESP32 has been updated accordingly and the relevant link can be found here. Therefore, all Espressif chipset users are strongly encouraged to upgrade their systems as soon as possible.

[ Voor 19% gewijzigd door Raven op 18-10-2017 16:38 ]

[T.Kreeftmeijer]

Ik vraag mij af of fabrikanten als Devolo nog updates uitbrengen. Ik hoop het wel.

Ik heb hier twee van hun wifi powerline adapters in gebruik, maar nog geen informatie over een update kunnen vinden...

En een Apple Airport Extreme: geen updates tot nu.

En met de box van KPN (EB V10) zal het ook niet zo vaart lopen. Ik weet niet of daar al iets mee gebeurt is, want dat gaat toch automatisch.

Voor zover ik weet gebruiken we WPA2 EAS.

Ik lees zo dat het eigenlijk alleen clients interessant zijn en de AP's niet veel uitmaken.

[ Voor 14% gewijzigd door T.Kreeftmeijer op 18-10-2017 15:54 ]

[dion_b]

T.Kreeftmeijer schreef op woensdag 18 oktober 2017 @ 15:47:
Ik vraag mij af of fabrikanten als Devolo nog updates uitbrengen. Ik hoop het wel.

Ik heb hier twee van hun wifi powerline adapters in gebruik, maar nog geen informatie over een update kunnen vinden...

En een Apple Airport Extreme: geen updates tot nu.

En met de box van KPN (EB V10) zal het ook niet zo vaart lopen. Ik weet niet of daar al iets mee gebeurt is, want dat gaat toch automatisch.

Zie hierboven. Volgens uitspraken van Broadcom (die iig chipsets levert voor zowel de Airport Extreme als de Experiabox 10, en mogelijk ook de Devolo WiFi powerline adapters) zijn AP's zelf niet kwetsbaar en moet het probleem op clientzijde opgelost worden.

Van deze drie apparaten kunnen de PLC-adapters en de Experiabox enkel als AP fungeren en hoeft er dus (volgens Broadcom) geen update voor te komen. De Airport Extreme kan als client bridge ingesteld worden en is in die situatie kwetsbaar als client - maar zo gebruik jij hem waarschijnlijk niet. Er is in Apple-wereld aardig discussie over het ontbreken van berichten over updates voor de Airport-lijn. Apple lijkt alle support ervoor stilletjes stopgezet te hebben...

[PatrickPR]

Ik gebruik zelf Tomato Shibby op mijn Asus router.

Weet iemand of de ontwikkelaar(s) achter Tomato Shibby al een statement hebben gedaan over nieuwe firmware? Of zijn ze al bezig met een nieuwe versie? Ik kan me voorstellen dat dit even gaat duren gezien de lange lijst van ondersteunde devices waar Tomato Shibby op kan.

[dion_b]

PatrickPR schreef op woensdag 18 oktober 2017 @ 16:02:
Ik gebruik zelf Tomato Shibby op mijn Asus router.

Weet iemand of de ontwikkelaar(s) achter Tomato Shibby al een statement hebben gedaan over nieuwe firmware? Of zijn ze al bezig met een nieuwe versie? Ik kan me voorstellen dat dit even gaat duren gezien de lange lijst van ondersteunde devices waar Tomato Shibby op kan.

Statement is voor bepalen vulnerability niet nodig.

Kwetsbaar zijn:
- WiFi clients
- WiFi APs die 802.11r draaien

Als je je device met Tomato niet als client bridge draait, en geen 802.11r doet, dan is het zelf niet kwetsbaar. De kwetsbaarheid in client mode is betrekkelijk triviaal te verhelpen, dus als Tomato actief ontwikkeld wordt zou dat snel genoeg gefixed kunnen worden.

Enige losse eindje wmb is het punt dat Broadcom AP chipsets blijkbaar sommige aanvallen onnodig makkelijk maken. Als je device Broadcom-based is, dan kan het daardoor impacted zijn. Een update om dat te verhelpen zou mooi zijn, maar dat zou eerst een update van Broadcom vereisen en die lijken daar nog geen noodzaak toe te zien...

[gekkie]

En daar is de Lede release.

[djwice]

Iemand een tip hoe ik alle devices in m'n netwerk scan voor deze kwetsbaarheid? Dan kan ik direct fabrikanten / leveranciers vragen om een patch. En hen ook een manier bieden om te testen of de patch werkt.

[WeaZuL]

djwice schreef op donderdag 19 oktober 2017 @ 14:43:
Iemand een tip hoe ik alle devices in m'n netwerk scan voor deze kwetsbaarheid? Dan kan ik direct fabrikanten / leveranciers vragen om een patch. En hen ook een manier bieden om te testen of de patch werkt.

Op crackattacks.com staat hierover het volgende:

Tools

We have made scripts to detect whether an implementation of the 4-way handshake, group key handshake, or Fast BSS Transition (FT) handshake is vulnerable to key reinstallation attacks. These scripts will be released once we have had the time to clean up their usage instructions.

We also made a proof-of-concept script that exploits the all-zero key (re)installation present in certain Android and Linux devices. This script is the one that we used in the demonstration video. It will be released once everyone has had a reasonable chance to update their devices (and we have had a chance to prepare the code repository for release). We remark that the reliability of our proof-of-concept script may depend on how close the victim is to the real network. If the victim is very close to the real network, the script may fail because the victim will always directly communicate with the real network, even if the victim is (forced) onto a different Wi-Fi channel than this network.

Ik heb nog geen tools gezien in het wild die dergelijke vulnerabilities zouden kunnen detecteren. Ik las ergens dat het advies is dat enterprise omgevingen dergelijke scans uitvoeren om hun security posture te testen.

edit:
Op Kali.org echter staat hierover het volgende (waarmee lijkt dat de informatie op krackattacks.com niet helemaal correct is / achterloopt ) :

With your Kali system updated, there are also some steps you can take to test for this vulnerability on your access points. Mathy Vanhoef recently released a script that can be run from Kali Linux to test whether or not your access point (AP) is affected by CVE-2017-13082 or specifically the Key Reinstall in FT Handshake vulnerability found in 802.11r devices. The script requires that you authenticate to the access point, but bear in mind that it may incorrectly flag an AP as vulnerable due to “benign retransmissions of data frames”.

en KISMET die het volgende mogelijk maakt:

“introducing alerts to attempt to detect a Krack-style attack”

[ Voor 25% gewijzigd door WeaZuL op 19-10-2017 23:48 ]

[SvenVD]

Iemand een idee of ip cameras vulnerable zijn, van vendors zoals foscam? Het is verdacht stil in die hoek.