OpenWrt Forum Archive

Topic: KRACK Attack against WPA2

The content of this topic has been archived between 30 Mar 2018 and 3 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Hello,

"Severe flaw in WPA2 protocol leaves Wi-Fi traffic open to eavesdropping" is today's headline for the new KRACK (Key Reinstallation AttaCK) against WPA2.
Is someone already familiar with the details and working on a fix/workaround for this attack?

See

(Last edited by Lorphos on 16 Oct 2017, 09:29)

Over at LEDE it's being worked on but from what i have read it is worse for wifi clients not the APs!

You got a link to where they say it's being worked on? All I could find is this:
forum.lede-project.org/t/critical-wifi-vulnerability-found/7450 (I'm new here, not allowed to post proper links)

The advice seems to be - disable WiFi.

twistedLucidity wrote:

You got a link to where they say it's being worked on?

As far as I understand, it has been fixed in LEDE master with this commit:
https://git.lede-project.org/?p=source. … ec2e82a9a5

(and now also LEDE 17.01 stable branch has a fix)

(Last edited by hnyman on 16 Oct 2017, 11:38)

tapper wrote:

Over at LEDE it's being worked on but from what i have read it is worse for wifi clients not the APs!

This is indeed a problem on the clientside and not on the AP side, never the less the WPA2 implementation is broken so does it really matter?

Also there's a problem with wpa_supplicant 2.4 and up (EAPOL-Key, so many reports can't find the one), it has a nasty bug which allows the attacker to force all 0's for the cipher meaning easy decryption.

(Last edited by telefunken on 16 Oct 2017, 12:15)

A fix will be out in LEDE 17.1.4 as soon as testing is complete!

The paper has now been released, it's at https://papers.mathyvanhoef.com/ccs2017.pdf

The most important part (I guess):

6.5  Countermeasures
Key reinstallation attacks can be mitigated at two layers. First, the
entity implementing the data-confidentiality protocol should check
whether an already-in-use key is being installed. If so, it should
not reset associated nonces and replay counters. This prevents our
attacks, at least if an adversary cannot temporarily trick an imple-
mentation into installing a different (old) key before reinstalling
the current one. In particular, when using this countermeasure it is
essential that the replay counter of received group key handshake
messages only increases. Otherwise, an adversary can use an old
group message 1 to make a victim temporarily install an old (differ-
ent) key, to subsequently reinstall the current group key using a
more recent group message 1.

A second solution is to assure that a particular key is only in-
stalled once into the entity implementing the data-confidentiality
protocol during a handshake execution. For example, the generated
session key in a 4-way handshake should only be installed once.
When the client receives a retransmitted message 3, it should reply,
but not reinstall the session key.

If I'm using Chaos Calmer 15.05.1, what I supposed to do?

expend wrote:

If I'm using Chaos Calmer 15.05.1, what I supposed to do?

Switch to LEDE 17.1.4.

hnyman wrote:
twistedLucidity wrote:

You got a link to where they say it's being worked on?

As far as I understand, it has been fixed in LEDE master with this commit:
git.lede-project.org/?p=source.git;a=commit;h=bbda81ce3077dfade2a43a39f772cfec2e82a9a5

Brilliant! I'll keep an eye on Lede then. I just hope it has all the features I'm used to.

So is this going to be the end of the line for OpenWRT? I understood the two projects were making friends again.

(Last edited by twistedLucidity on 16 Oct 2017, 15:44)

What about the majority of cheap routers that only have 4Mbit of FLASH and 32MB RAM?
Those routers won't be able to run LEDE, but only OpenWRT, which in turn needs an urgent security patch.
I hope it'll be implemented soon.

twistedLucidity wrote:

So is this going to be the end of the line for OpenWRT? I understood the two projects were making friends again.

It has been the end for the old Openwrt since some time ago.
The merge, if that happens, will overwrite the stale Openwrt codebase with LEDE codebase.

For all practical purposes, LEDE 17.01 is the up-to-date stable branch, and LEDE master is the development branch.
Only the Openwrt name is missing, and the "merge" is pretty much about renaming the current LEDE to Openwrt.

hnyman wrote:
twistedLucidity wrote:

You got a link to where they say it's being worked on?

As far as I understand, it has been fixed in LEDE master with this commit:
https://git.lede-project.org/?p=source. … ec2e82a9a5

(and now also LEDE 17.01 stable branch has a fix)

@hnyman - the first mention that we're working on this was at 11:56 today. I thought that we're over the days of cross-posting agenda - and please check what exactly we voted on.

Anyway, to sum up:

OpenWrt/CC: https://github.com/openwrt/openwrt/pull/555
(source-only for now, but there might be a dnsmasq/hostapd binary fix for CC.1.)

OpenWrt/trunk: https://github.com/openwrt/openwrt/comm … a45e495a12
(buildbots will go through the binaries for each target.)

Hope this helps.

Regards,
-w-

Is there a way to patch an older version of OpenWrt? I have an old 12.09 router around that still does its job.

Please, let us know.

wigyori wrote:

please check what exactly we voted on.

Sure:
https://www.mail-archive.com/openwrt-de … 41078.html

*) git trees
- rebrand the lede tree to openwrt
- work out what has happened inside the openwrt tree since the reboot and pick up the useful bits (zoltan has done some prior work on this already)

I interpret that to mean that the current LEDE tree is to be seen as the continuing "Openwrt" tree, and the possible interesting bits from the old Openwrt tree will get incorporated. But from a non-core developer's / activist's perspective the current LEDE tree is the interesting one, as pretty much all active development happens there (and has happened there since the split 1.5 years ago).

I was not trying to start any flame war or so, but just thought to mention that the thing was already fixed in the active development tree. Hopefully the merge goes through as soon as possible, so that we get over this two separate git trees thing.

Great that you also backported the fix to the old 15.05 branch, for those who still compile that branch.

Is there a way to patch an older version of OpenWrt? I have an old 12.09 router around that still does its job.
Please, let us know.

That seems a hard thing to crack. You would need to update hostapd to at least 2.6, along with updating the wireless drivers, and then put the KRACK-fixes on top. You might be better off with upgrading to CC or LEDE if your router is able to.

What router is it?

Regards,
-w-

wigyori wrote:

Is there a way to patch an older version of OpenWrt? I have an old 12.09 router around that still does its job.
Please, let us know.

That seems a hard thing to crack. You would need to update hostapd to at least 2.6, along with updating the wireless drivers, and then put the KRACK-fixes on top. You might be better off with upgrading to CC or LEDE if your router is able to.

What router is it?

Regards,
-w-

Thanks for replying it.

The router in question is:

TP-Link TL-WR2543N/ND v1

OpenWrt Attitude Adjustment 12.09 / LuCI 0.11.1 Release (0.11.1)

Kernel Version    3.3.8

(Last edited by HbbS on 16 Oct 2017, 16:49)

Hi, I use this firmware for my router: viewtopic.php?id=68809 . If I use the build script mentioned in the post ( gist. github. com/amq/f3895b208850ab0 7c5e2e855fa5fcab9 ), will I have the most recent patch from LEDE to fix KRACK? It seems to me that that's the case, but I'm not quite sure?

Dear MODERATORS can we please have this thread sticky? It is really a security issue rendering the Wireless security useless on both OpenWRT and LEDE.

On my original question, will OpenWRT CC (last version) get a security patch? LEDE, while interesting and actual, doesn't fit in the 4MB flash / 32 MB RAM 20-30USD/EUR routers that are still mainly sold or received from the provider.
There are some unofficial LEDE compilations for these routers, but they are not really stable and trustworthy (security). ATM you cannot really force the acquisition of exotic/expensive routers while the market dictates differently.

This WPA2 security issue, while fresh and still "academic" will promptly turn into hacking tools available everywhere, kids will start to take over all the APs around pretty soon.
Either patch OpenWRT or squeeze LEDE (build a light version) while preserving basic functionality to fit the 4MB flash / 32MB RAM devices.

Thanks!

(Last edited by justme123 on 16 Oct 2017, 21:51)

HbbS wrote:

The router in question is:
TP-Link TL-WR2543N/ND v1
OpenWrt Attitude Adjustment 12.09 / LuCI 0.11.1 Release (0.11.1)

HbbS that router has 8 MB flash and 64 MB RAM, otherwise being a bog standard ar71xx device, you really shouldn't be running 12.09 (which hasn't seen any kind of security support since at least 2014 - and yes, there are worse things to worry about with that release (e.g. kernel, dnsmasq, dropbear, pppd, ...) than just KRACK.

The TL-WR2543ND should run OpenWrt 15.05.1/ trunk and/ or LEDE 17.01.x/ snapshots comfortably:
LEDE 17.01.3 (17.01.4 should be released shortly, probably within the next 2-3 days; wpad-mini is already upgradable to fixed version using opkg):
lede-17.01.3-ar71xx-generic-tl-wr2543-v1-squashfs-sysupgrade.bin
OpenWrt 15.05.1 (afaik dnsmasq and wpad-mini upgrades should be available, but other security issues (e.g. in the kernel) will remain unfixed):
openwrt-15.05.1-ar71xx-generic-tl-wr2543-v1-squashfs-sysupgrade.bin

As mentioned previously in this thread, upgrading to LEDE 17.01.3 (and then to 17.01.4, once it becomes avaiable) is probably the best course of action. Either way, sticking to 12.09 or 14.07 does not make any sense for devices that can run the current releases comfortably.

(Last edited by slh on 16 Oct 2017, 23:16)

Hello. I have an older build of OpenWRT, which I couldnt upgrade anymore, because of the LEDE switch. It is a custom build of OpenWrt Designated Driver r49296. The only upgrades I did since then were:

libopenssl to 1.0.2j-1
libpolarssl to 1.3.17-1
dropbear to 2017.75-1

All other packages are still from r49296 (around Q1 2016 I think).

Is it enough if I do an opkg upgrade wpad-mini hostapd-common? It is version 2016-01-15-2 right now. Will this even work, or is there a (high) chance it will break anything? Is wpad-mini 100% standalone or does it relay on other updated things too, like the kernel? hostapd-common is 2016-01-15-2. Kernel is 4.1.23-1. Dnsmasq is 2.75-7. The router just has SSH port open to the WAN, so I didnt see any reasons to upgrade to LEDE yet.

wpad-mini is btw still this old version on the trunk tree for ar71xx: wpad-mini_2016-06-15-1_ar71xx (build date 16-Oct-2017 09:08)

(Last edited by makedir on 17 Oct 2017, 01:13)

Wpad-mini is a simple package, one executable file and two symlinks that make aliases for it.  The main binary, wpad, will serve as either hostapd or wpa_supplicant depending on how it is called.

Pull the wpad binary out of a new version then replace your /usr/sbin/wpad with it, keeping the old one in a safe place of course.  If that breaks the wireless, copy back the old version.

I just did an 'opkg upgrade wpad-mini hostapd-common' and a reboot and wifi is still working fine it seems. I am now on hostapd-common    2016-06-15-1 and wpad-mini    2016-06-15-1, so are these patched? Why are they though called 2016-xx-xx? So would I need to wait for a 2016-06-15-2, but it's not up yet it seems? Or is the xx-1 the new patched one already?

(Last edited by makedir on 17 Oct 2017, 01:30)

No those are probably not patched. LEDE has been based on version 2016-12-19, with -4 being the the last release and a just released -5 includes the anti-KRACK patches.

No, look at the link above by wigyori, it seems to be patched (based on 2016-06-15), but I cant link links... I cant even link pictures here. It says for the last two changes for hostapd for OpenWRT:

1.
CC: hostapd: update to version 2016-06-15
nbd168 committed with wigyori on Jun 15, 2016
@wigyori

2.
CC: hostapd: fix WPA packet number reuse with replayed messages and k…
wigyori committed 12 hours ago

CC: upgrade hostapd to 2016-06-15, include KRACK fix

So I guess the 2016-06-15-1 file is patched, no? Or would it be a -2?

(Last edited by makedir on 17 Oct 2017, 01:34)

Sorry, posts 26 to 25 are missing from our archive.