• Last Updated:
  • Nov 11th, 2017 8:05 pm
Tags:
None
Deal Fanatic
User avatar
Oct 25, 2003
9019 posts
195 upvotes
tkyoshi wrote:
Oct 18th, 2017 11:25 am
As long as one side is patched you should be ok, it's a fault in the WiFi protocol. As long as one side is patched it will no longer allow that command/bypass to happen since there won't be a handshake on both ends. Client patch is important because you can't reliably assume all APs will be patched.
Thanks for this. Patched my Unifi APs last night. Now to wait for the Android devices and iPads.
it's me ramin.
Deal Fanatic
Mar 6, 2005
5323 posts
574 upvotes
B0000rt wrote:
Oct 18th, 2017 12:03 pm
Thanks for this. Patched my Unifi APs last night. Now to wait for the Android devices and iPads.
Excellent, since Android/Apple doesn't have a real patch out, this will protect those devices on your home network :)
Member
Dec 7, 2015
414 posts
78 upvotes
Ottawa, ON
Further to that:

If you patch your client device, that device is safe as far as this bug goes. If you patch your AP, then all devices connecting to that AP are protected. The former is important if you use your device in many locations (that may not be patched) while the latter is important for all those devices that you can't get patched. If you can't get a device patched, don't use it anywhere but at a location where you know with certainty that the AP you connect to has been patched.

If neither your device nor AP can be patched, get out your credit card.
Deal Addict
User avatar
Sep 10, 2005
3107 posts
493 upvotes
GTA
Faith24 wrote:
Oct 18th, 2017 9:59 am
They are taking the same line that many router manufacturers have taken, that this is primarily a client-side problem. Unfortunately that ignores that fact that the vast majority of clients running Android and embedded Linux cannot be patched on the client side.
tkyoshi wrote:
Oct 18th, 2017 11:25 am
As long as one side is patched you should be ok, it's a fault in the WiFi protocol. As long as one side is patched it will no longer allow that command/bypass to happen since there won't be a handshake on both ends. Client patch is important because you can't reliably assume all APs will be patched.
B0000rt wrote:
Oct 18th, 2017 12:03 pm
Thanks for this. Patched my Unifi APs last night. Now to wait for the Android devices and iPads.
This keeps getting repeated but to my understanding, this is wrong.

Patching only one side, specifically the AP side, does not fix this. The attack is based on how the client deals with part of the handshake that is relayed. Patching the AP does not address this.

Any patches that are released for APs and routers are fixes for circumstances in which they act as clients themselves.

The only way to fix this completely is to patch everything. But 99% of the problem is on the client side. You have to patch the clients. Period.
Deal Addict
Feb 29, 2012
2662 posts
1394 upvotes
Richmond
Dave98 wrote:
Oct 18th, 2017 12:57 pm
Patching only one side, specifically the AP side, does not fix this. The attack is based on how the client deals with part of the handshake that is relayed. Patching the AP does not address this.
But it's a flawed handshake, so patching either side to avoid the flaw should prevent it. Therefore shouldn't the router be patched too, to deal with clients that can't be patched?

See http://blog.mojonetworks.com/wpa2-vulnerability

They clarify that the flaw in WPA2 actually creates 2 vulnerabilities, one that affects the client side where the attacker acts as a man-in-the-middle, and the other vulnerability in Fast Transition (FT) Handover that affects APs.
"The AP side implementation flaw in FT handover creates a vulnerability for decryption attack on unicast frames transmitted by the AP to the client and replay attack on unicast frames transmitted by the client to the AP. "
Deal Fanatic
Mar 6, 2005
5323 posts
574 upvotes
Faith24 wrote:
Oct 18th, 2017 1:59 pm
But it's a flawed handshake, so patching either side to avoid the flaw should prevent it. Therefore shouldn't the router be patched too, to deal with clients that can't be patched?

See http://blog.mojonetworks.com/wpa2-vulnerability

They clarify that the flaw in WPA2 actually creates 2 vulnerabilities, one that affects the client side where the attacker acts as a man-in-the-middle, and the other vulnerability in Fast Transition (FT) Handover that affects APs.
"The AP side implementation flaw in FT handover creates a vulnerability for decryption attack on unicast frames transmitted by the AP to the client and replay attack on unicast frames transmitted by the client to the AP. "
Correct! Ideally you would want both sides, in reality you can't control patching of other APs so client patch is important.

For home 100% patch both if possible.
Deal Addict
User avatar
Sep 10, 2005
3107 posts
493 upvotes
GTA
Faith24 wrote:
Oct 18th, 2017 1:59 pm
But it's a flawed handshake, so patching either side to avoid the flaw should prevent it. Therefore shouldn't the router be patched too, to deal with clients that can't be patched?

See http://blog.mojonetworks.com/wpa2-vulnerability

They clarify that the flaw in WPA2 actually creates 2 vulnerabilities, one that affects the client side where the attacker acts as a man-in-the-middle, and the other vulnerability in Fast Transition (FT) Handover that affects APs.
"The AP side implementation flaw in FT handover creates a vulnerability for decryption attack on unicast frames transmitted by the AP to the client and replay attack on unicast frames transmitted by the client to the AP. "
Sorry, if I wasn't clear. I meant that simply patching only the access point does not protect the clients, not that you don't have to patch the AP at all.

But the handshake in of itself is not flawed. The main flaw is in the client accepting message 3 more than once and then being MiTMed. The real AP/router in this case isn't doing wrong as it is re-sending the message as it is supposed to. I'm not sure how a patch on the AP can fix it when it's the client that needs to be told, "don't install this key more than once".

The FT Handover vulnerability is more applicable to environments with multiple APs and roaming between them.

But this is just my understanding of the flaw and I could be completely wrong. But thanks for the link and I'll give it a watch later.
This means a patched client can still communicate with an unpatched access point (AP), 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. 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!
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.
Deal Fanatic
Mar 6, 2005
5323 posts
574 upvotes
Dave98 wrote:
Oct 18th, 2017 6:38 pm
Sorry, if I wasn't clear. I meant that simply patching only the access point does not protect the clients, not that you don't have to patch the AP at all.

But the handshake in of itself is not flawed. The main flaw is in the client accepting message 3 more than once and then being MiTMed. The real AP/router in this case isn't doing wrong as it is re-sending the message as it is supposed to. I'm not sure how a patch on the AP can fix it when it's the client that needs to be told, "don't install this key more than once".

The FT Handover vulnerability is more applicable to environments with multiple APs and roaming between them.

But this is just my understanding of the flaw and I could be completely wrong. But thanks for the link and I'll give it a watch later.
You're pretty much on the right track and yeah fast Transition/roaming is 802.11r which you are unlikely to have in your home.

It is also off by default in most implementations, with it turned off clients can still roam just it's up to the client device to decide to hop to another AP or to hang on to the current one.

Most rapid firmware fixes so far for AP's are to fix the 802.11r flaw, however if it's not turned on you are not vulnerable for that one.
Banned
User avatar
Oct 18, 2017
1 posts
United States
Techcrunch and Wired have written a great piece on this issue.
Deal Addict
User avatar
Mar 15, 2004
3671 posts
183 upvotes
With this vulnerability, does it mean a hacker can manipulate your network traffic without even establishing a connection to your WiFi network? The articles just say a hacker needs to be in range of your WiFi network, but it doesn't really say whether they need to be successfully connected to your WiFi network.
Jr. Member
Nov 6, 2006
150 posts
39 upvotes
Coquitlam
awestruck wrote:
Oct 19th, 2017 3:31 pm
With this vulnerability, does it mean a hacker can manipulate your network traffic without even establishing a connection to your WiFi network? The articles just say a hacker needs to be in range of your WiFi network, but it doesn't really say whether they need to be successfully connected to your WiFi network.
With this vulnerability, it means that hackers within range of your wifi network can successfully connect to your network. WPA2, which is the encryption designed to keep your network secure and keep others out of your network, has been proven vulnerable. So if someone is in-range and your AP and devices aren't patched up, they can read the traffic and potentially gain complete access to your wifi network.
Deal Guru
User avatar
Mar 25, 2003
11122 posts
1431 upvotes
Markham
EugW wrote:
Oct 16th, 2017 4:53 pm
Already fixed in the iOS and macOS betas.
I guess Apple will not give update to fix old devices like ipad 2 , iPhone 4 and 5
80TB Mediasonic H82-SU3S2 / 60TB Raid 50 on Mediasonic H8R2-SU3S2
40TB Node 304 / i5-3570 / Server 2016 Essentials
11TB HP Mediasmart EX 495 (E8400, 3.0GHZ, 4GB Mushkin), with Server 2012 Essentials
16TB Qnap TS-459 Pro / 6TB HP Mediasmart EX 485
Sr. Member
Dec 28, 2004
764 posts
169 upvotes
nope apple shafted us on ios 9.3.5 for ipod touch 5 and ipad 2 and android and kitkat or higher fuggetaboutit other than nouget so far or a google device for android if that for older google hardware :)

has rogers put out fixes for the internet modems if anyone has checked - maybe I should put i a case with rogerhelps or on their twitter feeds :)
Deal Fanatic
Mar 6, 2005
5323 posts
574 upvotes
smoraes wrote:
Oct 19th, 2017 5:02 pm
nope apple shafted us on ios 9.3.5 for ipod touch 5 and ipad 2 and android and kitkat or higher fuggetaboutit other than nouget so far or a google device for android if that for older google hardware :)

has rogers put out fixes for the internet modems if anyone has checked - maybe I should put i a case with rogerhelps or on their twitter feeds :)
You sure you trust them? Took them forever to get the modem firmware to be stable to begin with Grinning Face With Smiling Eyes

Top