Critical WiFi Vulnerability Found - KRACK

[anon80727944]

Thanks.

Are there more updates still forthcoming for the kernel mac80211 code? Or is that a different vulnerability?

[slh]

A kernel (mac80211) patch has already been merged (for HEAD and 17.01.4), but the major issue is in hostapd/ wpa_supplicant (wpad).

[slh]

Keep in mind that the main attack vector are wireless clients, those (Windows, MacOS, Linux, Android, iOS, Windows Mobile, esp8266 and other embedded devices) must be updated as well, actually even more urgently than your router. Even if your router (LEDE) is fixed, your clients remain vulnerable until they get fixed as well.

[anon80727944]

Understood.

In my case, I'm already running iOS 11.1b3 and macOS 10.13.1b3, which contains the patches. Most of my other devices which use some form of authentication are wired and/or use TLS/SSL

The only other devices I am concerned about are my wireless cameras and Amazon Echo, all of which use some form a Linux.

[moretocome]

@RangerZ

So for the dumb Windows user, can I just download and OPKG Install the packages currently installed for my version and be done with KRACK on LEDE?

From what I understand this will only prevent an attacker from sniffing the router traffic (which is only possible if the router is acting like at wifi repeater/bridge). You will still have to patch every device that connects through wifi to LEDE to make sure an attacker can't sniff the traffic from that particular device.

[silentcreek]

Guys, the latest update (package release 6) of the hostapd/wpad packages in LEDE 17.01 is quite a big deal. They include a new feature that will allow to mitigate the attack from the router/access point side even if your clients are not patched! [1][2]

The new configuration option is wpa_disable_eapol_key_retries which is by default disabled, because it might cause compatibility issues with clients. I'd assume that issues are more likely in crowded wireless areas where you see package losses often. But I am testing this new feature now, and so far my clients haven't had any issues.

Suffice it to say, if you can patch all your cliets, you don't need this new option.

[1] https://git.lede-project.org/?p=source.git;a=commit;h=d501786ff25684208d22b7c93ce60c194327c771
[2] https://git.lede-project.org/?p=source.git;a=commit;h=b6c3931ad6554357a108127797c8d7097a93f18f

[angelos]

Speaking of clients...

does anyone know if our WIFI adapters (PCI, PCI Express or USB doesn't matter) are vulnerable and the OEMs should release new drivers for windows and new/patched modules/firmwares for linux?

Or the "OS part" is responsible for the communication with the AP and if it's patched there is no problem with the device drivers even if they are old?

[PlqnK]

@RangerZ

As I said, dumb Windows user. Please elaborate on how someone would breach my home network. Is he just sitting in front of my house (starbucks) and waiting for me to connect my phone to my WLAN and then inserts his WLAN between my client and WLAN?

Like I said, the attacker will not connect to your network. He will make your clients devices connect to a fake version of your network which he has total control on.
He needs to be in range of your clients and your real Wi-Fi network in order to perform the attack.

@RangerZ

Unfortunately ya buried me in geek speak.

I'm sorry, I should've use more layman terms in the first place ^^

@RangerZ

So the exposure for the light bulb is someone turning it on and off at will? For the washing machine, its running a cycle with no clothes in the tub (which I can probably fix by leaving the door open - a good idea to prevent mold anyhow).
The door lock may be more of an issue if they can open it.

That's correct.

@RangerZ

But again, not clear they gain device control as much as can monitor the traffic it produces?

They can monitor the traffic. Then there are two possibilities :

• The traffic is correctly and fully encrypted (the device uses properly implemented standards) : The attacker can't do much. All he will se is some giberish which he can't decipher.
• The traffic is not encrypted at all or not correctly and securely encrypted : The attacker can do a lot of things. He can see what the device is sending to the server, he can act as the server, issuing commands to the device for example.

The problem is not only on IoT and "smart" devices, your smartphone and your PC are also vulnerable (if not patched). For example if you visit a website with a non-secured connection (using plain HTTP instead of HTTPS) then everything you send to the website including your credentials can be retrieved by the attacker.

Also if the server you are visiting is not correctly configured then the attacker can performs an SSL Striping attack : It's simple really, you search your website on Google, you click on the link that says https://website.com and because the website is not correctly configured, the attacker will disable HTTPS for this website. Your browser will tell you that the connection is not secured (no padlock in the address bar) but if you don't pay attention it can be dangerous.

That's a non exhaustive list of what an attacker can do. Because he has direct access to your device is the master of the network your device is connected to he could do so much bad things I can't list them all.

@moretocome

From what I understand this will only prevent an attacker from sniffing the router traffic (which is only possible if the router is acting like at wifi repeater/bridge). You will still have to patch every device that connects through wifi to LEDE to make sure an attacker can't sniff the traffic from that particular device.

That's correct, except as silentcreek said there is a new option on the AP side to mitigate the risks:

@silentcreek

Guys, the latest update (package release 6) of the hostapd/wpad packages in LEDE 17.01 is quite a big deal. They include a new feature that will allow to mitigate the attack from the router/access point side even if your clients are not patched! [1][2]

The new configuration option is wpa_disable_eapol_key_retries which is by default disabled, because it might cause compatibility issues with clients. I'd assume that issues are more likely in crowded wireless areas where you see package losses often. But I am testing this new feature now, and so far my clients haven't had any issues.

Suffice it to say, if you can patch all your cliets, you don't need this new option.

[1] https://git.lede-project.org/?p=source.git;a=commit;h=d501786ff25684208d22b7c93ce60c194327c771
[2] https://git.lede-project.org/?p=source.git;a=commit;h=b6c3931ad6554357a108127797c8d7097a93f18f

[anon80727944]

@silentcreek

The new configuration option is wpa_disable_eapol_key_retries which is by default disabled, because it might cause compatibility issues with clients. I’d assume that issues are more likely in crowded wireless areas where you see package losses often. But I am testing this new feature now, and so far my clients haven’t had any issues.

Thanks. I have a number of embedded devices which patches are still pending.

Added option wpa_disable_eapol_key_retries '1' after every config wifi-iface entry in /etc/config/wireless and confirmed the option appears in every /var/run/hostapd-phy{n}.conf after restart.

So far no issues, but only time will tell.

[cHrish1980]

@PlqnK

They can monitor the traffic. Then there are two possibilities :

• The traffic is correctly and fully encrypted (the device uses properly implemented standards) : The attacker can’t do much. All he will se is some giberish which he can’t decipher.
• The traffic is not encrypted at all or not correctly and securely encrypted : The attacker can do a lot of things. He can see what the device is sending to the server, he can act as the server, issuing commands to the device for example.

@PlqnK There's a third option:

• He doesn't forward your traffic anywhere effectively taking your wifi device offline (similar to a DoS attack).

[bluewavenet]

@Mushoz and everyone else:

It is probably more sensible to put this into proper perspective rather than go with the wild hype today's "Press" love to whip up.
WiFi security should only be viewed as a method of preventing unauthorised access to the network and not as a means of encrypting your data.
Does your bank rely on whatever WiFi you are using for the first few meters from your device to the data centre and no security after that?
I don't think so.
Come on guys, get real and don't whip up the silly hype.
Sure it needs fixing - oh it has been already. My router has not been patched and my android neither? So what ?
Ok, do I use an ethernet connection to log in to an unencrypted connection to my online banking? Or my business email? I think not. When did I last use unencrypted email? So long ago I cannot remember.

Just do everything as if you are using an open WiFi. Wifi encryption should just be cream on the top.

Yes lets patch, reflash etc., whatever we need to do, but recommending people not to use WiFi is just a bit over the top. Remember public wifi hotspots are usually open anyway.

As for IoT... if you have designed a security critical device that does not use its own encryption, then well, what can I say.

[fantom-x]

I do not this new option wpa_disable_eapol_key_retries in LEDE anywhere. Do I need to install some new packages? I have already updated all installed ones.

[mrroute]

I am currently running LEDE Reboot 17.01.2 r3435-65eec8bd5f. I was going to wait till 17.04 is released but since it appears the fixes are just separate packages, can someone tell me exactly what to download and how to install these separate packages? I'm only familiar with upgrading the entire firmware as a whole. Thanks.

[silentcreek]

You won't see this new option in the webinterface, so you have to do this change manually, e.g. over a ssh connection. When you are logged in type:
uci set wireless.@wifi-iface[0].wpa_disable_eapol_key_retries='1'
and, if you have a second interface (usually one for 2.4GHz wifi and one for 5GHZ), also type:
uci set wireless.@wifi-iface[1].wpa_disable_eapol_key_retries='1'
Then save your changes and apply them by rebooting your device:
uci commit
reboot

In order for this to work, you need the latest wpad or hostapd packages. If your interfaces have different names or you have more interfaces, change the "uci set" lines accordingly. (If you don't knwo how you'Re interfaces are named you can use "uci show wireless" to get your current configuration.)

[anon80727944]

@fantom-x

I do not this new option wpa_disable_eapol_key_retries in LEDE anywhere. Do I need to install some new packages? I have already updated all installed ones.

See my post above how to manually add. There is no LUCI GUI option I saw. Hopefully this will be added to 17.01.4

[Mushoz]

@bluewavenet

Ok, do I use an ethernet connection to log in to an unencrypted connection to my online banking? Or my business email? I think not. When did I last use unencrypted email? So long ago I cannot remember.

Just do everything as if you are using an open WiFi. Wifi encryption should just be cream on the top.

I couldn't disagree more. Yes, all important access should be done through HTTPs. But as the demonstration movie already showed, many sites have HTTPs configured inproperly, which allows for HTTPs stripping. It's a separate issue of course, but the combination of both is especially harmful.

Furthermore, many sites (such as news sites) don't use HTTPs at all. This would allow an attacker to inject a virus into the pages that you're visiting. Of course, the browser / OS needs to be susceptible to such an attack, but it's definitely possible.

So I still stand by my statement that you should not use wifi with a device that is affected by this bug before it is patched.

Edit: Or sidestep the issue by using an encrypted VPN connection.

[silentcreek]

The easiest way is probably to just upgrade all packages that have updates available. Log in to your LEDE device over ssh and type in this (each line followed by ENTER):
opkg update
new_pkgs=$(opkg list-upgradable | awk 'BEGIN{ORS=" "}{print $1}')
[ -n "$new_pkgs" ] && okpg upgrade $new_pkgs
This will download the latest package lists (or feeds) from the LEDE repository, check for upgradable packages and if there are any, upgrade them.

Edit: And you might wanna reboot your device after that by typing:
reboot

[Mushoz]

Piping is also a possible way to do this, and is more readable I think. But both solutions will work fine of course

opkg update
opkg list-upgradable | awk -F ' - ' '{print $1}' | xargs opkg upgrade

edit: Not sure on this one myself: Is a reboot needed after updating the packages?

[fantom-x]

Thank you! Do I need to install full versions of hostapd/wpad?

[phuque99]

@anon80727944

See my post above how to manually add. There is no LUCI GUI option I saw. Hopefully this will be added to 17.01.4

The 17.01.4 release has been tagged on the source codes. I don't build mine with Luci. But if you have the means to compile your own firmware from source, you can check it out.