That is one smoking fast update release. Demo works in perfect environment, but I wonder if there are some settings on AP that help to prevent successful exploitation of this vulnerability before(if ever) firmware updates are released by device manufacturers. Such as setting re-keying delay to one minute (it is usually 3600sec or 7200sec), so attacker will be forced to perform successful exploitation every minute. Or disabling SSID broadcasting and setting channel to fixed value on AP and client, so this should prevent rogueAP from tricking client to connect to it. Also setting power of AP transmitter to the maximum should prevent situation where client will talk to rogueAP or make it significantly harder, because rogueAP have to be closer to client. I'm waiting for PoC scripts release to test it all out.
On 16.10.2017 20:57, tv.deb...@googlemail.com wrote: > On 16/10/2017 21:12, Curt wrote: >> https://www.krackattacks.com/ >> >> 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. >> >> Uh-oh. >> >> > It was addressed in Debian by DSA-3999-1 I think, but will probably > linger for a long time on routers, phones, appliances and IoT all over > the world. After Bluetooth a few weeks ago, now wpa2 wifi, most of the > wireless consumer electronic have it's base covered and ripe for > cracking... > -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄⠀⠀⠀⠀
