Looks like the state tracking is fixed during rekey to mark when the new PTK is installed.
Thanks. Do you know the behavior when the new PTK installation is detected? Does it basically reset and forcibly regenerate a new PTK?
And, what happens if there is not a new PTK installation? (somehow I got the impression that the point of this KRACK is the same secret and be used over and over and over again even for new client/AP handshake -- but honestly I do not fully understand it).
Without getting into too much detail, this code implements the recommendations made in the research paper.
The primary change to note is that the code now keeps track of the TK being installed so that duplicate "message 3" (3/4 of the handshake) do not result in multiple installations of the same key, which is how the replay counter was being reset. Instead, the code simply skips the duplicate key installation and responds back with message 4, as the 802.11i spec requires.
I'm not very familiar with the hostap code. Is this actually fixing it for client-mode or is this actually implementing the AP side mitigation for KRACK as well?
I'm not very familiar with the hostap code. Is this actually fixing it for client-mode or is this actually implementing the AP side mitigation for KRACK as well?
Good question - I'd like to know too. From xpxp2002's explanation I'd assume the handshake fix is on the AP-side (no way DD-WRT can reliably tell the client what to do based on states it tracks, right?).
In other words, does this mean a AP-side fix is sufficient (i.e. no client side patch needed) to mitigate all of these listed CVEs?
From what I can tell, ‘hostapd’ is not used by the dd-wrt firmware (at least for the BCM SOCs) but rather the proprietary ‘nas’ utility for access point functionality.
I'm not very familiar with the hostap code. Is this actually fixing it for client-mode or is this actually implementing the AP side mitigation for KRACK as well?
Good question - I'd like to know too. From xpxp2002's explanation I'd assume the handshake fix is on the AP-side (no way DD-WRT can reliably tell the client what to do based on states it tracks, right?).
In other words, does this mean a AP-side fix is sufficient (i.e. no client side patch needed) to mitigate all of these listed CVEs?
The more I read about it, I'm not sure what a router can actually do. Yuck. This kinda sucks because I have an ancient WRT-HP-54G running some 14xxx or 15xxx build acting as a wireless bridge.
I'm not very familiar with the hostap code. Is this actually fixing it for client-mode or is this actually implementing the AP side mitigation for KRACK as well?
Good question - I'd like to know too. From xpxp2002's explanation I'd assume the handshake fix is on the AP-side (no way DD-WRT can reliably tell the client what to do based on states it tracks, right?).
In other words, does this mean a AP-side fix is sufficient (i.e. no client side patch needed) to mitigate all of these listed CVEs?
Q&A wrote:
Do we now need WPA3?
No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point, and vice versa. In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available.
_________________ 2 times APU2 Opnsense 21.1 with Sensei
2 times RT-AC56U running DD-WRT 45493 (one as Gateway, the other as AP, both bridged with LAN cable)
3 times Asus RT-N16 shelved
E4200 V1 running freshtomato 2020.8 (bridged with LAN cable)
3 times Linksys WRT610N V2 converted to E3000 and 1 original E3000 running freshtomato 2020.8 (bridged with LAN cable)
No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point, and vice versa. In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available.
The krackattacks Q&A also has this:
Quote:
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. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details. In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.
I'm not entirely clear what it means to "patch" the access point unless you're talking about an access point as a client.
Do we now need WPA3?
[...] In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. [...]
The krackattacks Q&A also has this:
Quote:
What if there are no security updates for my router?
[...] you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.
I'm not entirely clear what it means to "patch" the access point unless you're talking about an access point as a client.
They are using layman's terms for client->user and access point->router. But from the above, it sounds like only router modes for Repeater and Client are vulnerable to the 3rd step in the handshake exchange. _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
They are using layman's terms for client->user and access point->router. But from the above, it sounds like only router modes for Repeater and Client are vulnerable to the 3rd step in the handshake exchange.
That's my read on it too, but I've also seen comments elsewhere that it should be possible to detect the vulnerable clients and the key reinstallation attempts but I wasn't clear if the patches brainslayer pulled in attempts to do that. my quick read of it seems that it doesn't but I'm not even remotely close to familiar with hostapd's code.
Its great news that the bug is being patched, but unfortunately it will take some time before the update is available as installable firmware (im on asus rt-n13u (first version).
Well, it'll be in the next build, which I'd suspect will be soon (in the next week), so keep an eye on ftp://ftp.dd-wrt.com/betas/2017/
to grab it from the /asus-rtn13u/ directory.
Of course as you know, monitor the appropriate New Build thread to make sure there isn't an issue first.
What about devices who can't flash a build because the file size is too big?
Yes, I'm using the WNDR4000 so will the patch include future K2 builds? I've been using a K2 build since 2013 and have no desire to jump to K3 if it's not necessary.
Forgive my ignorance on the issue, as I'm rather behind the times.
EDIT: I simply need to upgrade to the Broadcom K26 build (I.e. dd-wrt.v24-33492_NEWD-2_K2.6_mega-nv64k.bin) in order to avoid any K3 size nightmares, correct?
From what I can tell, ‘hostapd’ is not used by the dd-wrt firmware (at least for the BCM SOCs) but rather the proprietary ‘nas’ utility for access point functionality.
Anyone in the know can comment on this?
Hi all,
May I know if there's any knowledge on whether BCM SoCs are covered by BS's patch? I myself own R7000 and R6300v2 -- but I believe answer to this would be of interest to the general audience in this (Broadcom) forum.
BS's newer commit #33526 ( http://svn.dd-wrt.com/changeset/33526 ) also updated hostapd to newer version -- but it seems from this diff alone only atheros (i.e. ATH10K) are using the newer, patched 2016-09-05 version, while the rest still falls back to 2014-06-03 or 2014-10-25.
quarkysg, that's a good question. Maybe BS or Kong will comment here.
dragonC wrote:
May I know if there's any knowledge on whether BCM SoCs are covered by BS's patch? [...]
BS's newer commit #33526 ( http://svn.dd-wrt.com/changeset/33526 ) also updated hostapd to newer version -- but it seems from this diff alone only atheros (i.e. ATH10K) are using the newer, patched 2016-09-05 version, while the rest still falls back to 2014-06-03 or 2014-10-25.
So it appears that ath10k has the newer patched hostapd from 33526, while everything else uses the older patched hostapd from 33525. But they are both patched for krack. _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
Posted: Mon Oct 23, 2017 17:06 Post subject: nas vs hostapd
quarkysg wrote:
From what I can tell, ‘hostapd’ is not used by the dd-wrt firmware (at least for the BCM SOCs) but rather the proprietary ‘nas’ utility for access point functionality.
nas is not used for the real supplicant work. the authentication is within the driver itself. and for devices with a own on chipset firmware like the newer dhd drivers, we need complete new firmware blobs
Fixes are in:
Changeset [33574] by brainslayer: update for older broadcom devices
Changeset [33573] by brainslayer: fix for krackattack
Changeset [33572] by brainslayer: fix for broadcom supplicant to handle krackattack