RouterOS (v6.39.3, v6.40.4, v6.41rc) NOT affected by WPA2 vulnerabilities

Announcements
1

On October 16. CERT/CC/ICASI released a public announcement about discovered vulnerabilities in WPA2 handshake protocols that affect most WiFi users and all vendors world wide.
RouterOS v6.39.3, v6.40.4, v6.41rc are not affected!
It is important to note that the vulnerability is discovered in the protocol itself, so even a correct implementation is affected.
These organizations did contact us earlier, so we have already released fixed versions that address the outlined issues. Not all of the discovered vulnerabilities directly impact RouterOS users, or even apply to RouterOS, but we did follow all recommendations and improved the key exchange process according to the guidelines we received from the organizations who discovered the issue.
We released fixed versions last week, so if you upgrade your devices routinely, no further action is required.
CWE-323
CVE-2017-13077
CVE-2017-13078
CVE-2017-13079
CVE-2017-13080
CVE-2017-13081
CVE-2017-13082
CVE-2017-13084
CVE-2017-13086
CVE-2017-13087
CVE-2017-13088

The following applies to RouterOS software prior to updates related to the issue.

nv2
nv2 is not affected in any way. This applies to both - nv2 AP and client. There is no nonce reset in key exchange possible and key re-installation is not possible, because nv2 key exchange does not directly follow 802.11 key exchange specification.

802.11 nonce reuse
RouterOS is not affected in any way, RouterOS generates cryptographically strong random initial nonce on boot and never reuses the same nonce during uptime.

802.11 key reinstallation
The device operating as client in key exchange is affected by this issue. This means that RouterOS in station modes and APs that establish WDS links with other APs are affected. RouterOS APs (both - standalone and CAPsMAN controlled), that do not establish WDS links with other APs, are not affected. Key reinstallation by resending key exchange frame allows attacker to reset encrypted frame packet counter. This allows attacker to replay frames that where previously sent by AP to client. Please note that RouterOS DOES NOT reset key to some known value that would allow attacker to inject/decrypt any frames to/from client.

Suggested course of action
It is always recommended to upgrade to latest RouterOS version, but depending on wireless protocol and mode the suggested course of action is as follows:

  • nv2: no action necessary
  • 802.11/nstreme AP without WDS: no action necessary
  • CAPsMAN: no action necessary
  • 802.11/nstreme client (all station modes) or AP with WDS: upgrade to fixed version ASAP.

For AP devices:
Mode****Course of actionnv2No upgrade necessarynstremeNo upgrade necessaryWiFiNo upgrade necessaryCAPsMAN WiFiNo upgrade necessaryWDS WiFi/nstremeUpgrade requiredFor CPE devices (MikroTik Station mode):
Mode****Course of actionnv2No upgrade necessaryWiFiUpgrade requirednstremeUpgrade required*Please contact your vendor for any 3rd party devices in the network.

2

Well done on the quick response.

3

Agreed. I just found out about this, headed to the forums to see what (if any) mitigation options were available, and discovered that my APs were already sorted. Thank you :slight_smile:.

Noting the details about this vulnerability are currently scarce - is it sufficient that the APs be patched to address the issue, or might older (non-mikrotik) clients still be vulnerable to this problem, even when the AP is running a non-vulnerable implementation?

4

Basically, is it OK to understand Routerboard with AP function as target?
If you are using the CAPsMAN function with Rotuerboard without AP function, is this Routerboard also applicable?

5

Hello, thank you for rapid response with the patch.

But I’m not seeing 6.39.3 as available update for my router.
It just shows v6.39.2 (stable) as current version, and no packages are available at auto-upgrade section. Is there a reason?

6

Hi,
6.39.3 is on bugfix channel.

Osman Kazdal

7

Thanks! Updated my router manually from bugfix channel (via Packages tab, not Auto-Upgrade)! But will have to find out why update-upgrade is not working as I’d have expected.

8

What sort of response do you expect when you haven’t said what model your router is???
Duh.

9

Since the Bugfix channel was updated last, it could be possible your local network still has the previous release info cached. Should be available soon.

10

Actually it is station mode device that is primary target and needs to be fixed. RouterOS APs in AP mode (either standalone or controlled by CAPsMAN) are not affected by this - improvements are in station mode code.

11

Hi :slight_smile:

First, congratulations (and a big thank you!) on the quick response. One more reason to stick to Mikrotik.

Now, a suggestion. RouterOS has been affected by the WPA2 vulnerability but you have released a fix. I would certainly rephrase that
announcement. I guess some people will just read the subject and say “phew, I’m secure!”

12

In the statement, we included a line, maybe it was not clearly phrased. One of the biggest issues that was mentioned, never applied to RouterOS at all (“nonce reuse”). We did include other general suggestions from CERT for key exchange improvement. So part of that stuff never affected RouterOS. Other part was addressed.

13

Oh alright, then I misunderstood. Sorry!

I assumed that this problem affected all the implementations.

In that case, double kudos apply.

14

All routers updated, only my Caps-man forgot what certs to use so it decided to turn off.
Without wifi, it must be a lot safer :wink:

Setting the certs to the right values and everything was working like a charm again :wink:

15

So what does this mean exactly in general? Can the password be stolen? How has Mikrotik fixed it, if it is the protocol itself who is vulnerable?

16

All details just published here: https://www.krackattacks.com

17

It’s important to note that this is a client vulnerability - patching your router / AP does not prevent the attack from working on connected devices. You need to update almost every device that has WPA2 support.

18

Vendor Information for VU#228519
Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated to induce nonce and session key reuse
VendorStatusDate NotifiedDate Updated
Aruba NetworksAffected28 Aug 201709 Oct 2017
CiscoAffected28 Aug 201710 Oct 2017
Espressif SystemsAffected22 Sep 201713 Oct 2017
Fortinet, Inc.Affected28 Aug 201716 Oct 2017
FreeBSD ProjectAffected28 Aug 201712 Oct 2017
HostAPAffected30 Aug 201716 Oct 2017
Intel CorporationAffected28 Aug 201710 Oct 2017
Juniper NetworksAffected28 Aug 201728 Aug 2017
Microchip TechnologyAffected28 Aug 201716 Oct 2017
Red Hat, Inc.Affected28 Aug 201704 Oct 2017
Samsung MobileAffected28 Aug 201712 Oct 2017
Toshiba Commerce SolutionsAffected15 Sep 201713 Oct 2017
Toshiba Electronic Devices & Storage CorporationAffected28 Aug 201716 Oct 2017
Toshiba Memory CorporationAffected28 Aug 201716 Oct 2017
Ubiquiti NetworksAffected28 Aug 201716 Oct 2017
ZyXELAffected28 Aug 201713 Oct 2017
Arista Networks, Inc.Not Affected28 Aug 201709 Oct 2017
Lenovo Not Affected28 Aug 201711 Oct 2017
MikroTik Not Affected28 Sep 201716 Oct 2017
VMware Not Affected28 Aug 201716 Oct 2017

19

Nice!

20

It’s funny that Mikrotik already had this patched in the most recent bugfix and stable release trains, while Ubiquiti’s response on AirMax is that it’s “not as easy” on AirMax shots, and that a patched beta will be released later this week.