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 action
nv2	No upgrade necessary
nstreme	No upgrade necessary
WiFi	No upgrade necessary
CAPsMAN WiFi	No upgrade necessary
WDS WiFi/nstreme	Upgrade required

For CPE devices (MikroTik Station mode):

Mode	Course of action
nv2	No upgrade necessary
WiFi	Upgrade required
nstreme	Upgrade required

*Please contact your vendor for any 3rd party devices in the network.

Well done on the quick response.

Well done on the quick response.

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 .

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?

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?

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?

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?

Hi,
6.39.3 is on bugfix channel.

Osman Kazdal

6.39.3 is on bugfix channel.

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.

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?

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

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.

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?

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.

Hi

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!"

Hi

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!"

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.

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.

Oh alright, then I misunderstood. Sorry!

I assumed that this problem affected all the implementations.

In that case, double kudos apply.

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

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

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?

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?

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

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.

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

Nice!

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.

Great work guys

Thanks for publishing and informing.

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.

Which means every device ( I guess every one secures wireless connection on WPA2)
If I understood it correctly, if you patch the AP you will practically secure the third handshake of WPA2 which AP sends if client drops. But is the client still listening for a resend? I am curious about the method Mikrotik used to fix this vulnerability of the protocol itself, although as far as we know Mikrotik was not affected even in previous versions of ROS.

From the link:

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.

Good job on the fast announcement and staying on top of the vulnerabilities.

Specially thanks for the additional per-protocol information and the clarification that was added after the initial post!
(for people coming in later - the bottom half of MikroTiks post was added after official information became available at 14:00 CET)

Thanks for fast and clear information.

Hi

when I read about the vulnerability this morning I immediatly checked the forum and was very happy to read this announcement. I updated all my access points and was quite relieved this should not concern me anymore. Now that there is more information and as it was already quoted:

From the link:

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 am asking myself if my networks really are secure just because I upgraded my access points. To me it reads more like this was a client issue and may not be resolved by patching an access point?

May someone come up with a more detailed explanation how the update to my AP will solve this issue?

BR
Alex

Hi

when I read about the vulnerability this morning I immediatly checked the forum and was very happy to read this announcement. I updated all my access points and was quite relieved this should not concern me anymore. Now that there is more information and as it was already quoted:

From the link:

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 am asking myself if my networks really are secure just because I upgraded my access points. To me it reads more like this was a client issue and may not be resolved by patching an access point?

May someone come up with a more detailed explanation how the update to my AP will solve this issue?

BR
Alex

Some routers also have Client/Station mode (instead of being an AP) and are therefore vulnerable in those modes.

Than this announcement was terribly misleading and is causing a false sense of safety. This is fucking dangerous and must not happen!!!!

It must be explicitly stated in which cases the update will help and even more importantly in which cases it will not, especially if it will not mitigate the vulnerability in the majority of cases.

@Mikrotik:
please update your initial post to clarify exactly what the update will prevent and what it will not!

BR
Alex

Thanks for info, im always keep up to date for my mikrotik.

Thank you for the details and the quick publication. update in progress ^_^

802.11/nstreme client (all station modes)

So all client that use nstreme in station-bridge mode need to be upgraded too??
Thanks

802.11/nstreme client (all station modes)

So all client that use nstreme in station-bridge mode need to be upgraded too??
Thanks

Sorry, but "all station modes" mean "all station modes"

802.11/nstreme client (all station modes)

So all client that use nstreme in station-bridge mode need to be upgraded too??
Thanks

Sorry, but "all station modes" mean "all station modes"

Yes I Know but I wanted to be sure to have understood well!
Thanks a lot

Hi

when I read about the vulnerability this morning I immediatly checked the forum and was very happy to read this announcement. I updated all my access points and was quite relieved this should not concern me anymore. Now that there is more information and as it was already quoted:

From the link:

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 am asking myself if my networks really are secure just because I upgraded my access points. To me it reads more like this was a client issue and may not be resolved by patching an access point?

May someone come up with a more detailed explanation how the update to my AP will solve this issue?

BR
Alex

Hi Alex

You can fix the 4-way handshake issue either at the client side or at the Access Point side. That is where your confusion comes from. Seeing you do not have every AP under your administrative control, updating the client is the best approach for home users. However, not all clients (looking at Android phones here!) will receive a patch. So it's good practice to also fix it at the AP side:-). Consult the manufacturer for more information whether this fix also works when the client is still vulnerable.

If your AP acts as a client, called station mode (or bridge mode), then fixing the AP that is in station mode is a must unless the AP it is connecting to already has the fix.

You can fix the 4-way handshake issue either at the client side or at the Access Point side. ... So it's good practice to also fix it at the AP side:-).

Wrong!!! KRACK is a pure client-side attack. Patching AP will give you nothing.

You can fix the 4-way handshake issue either at the client side or at the Access Point side. ... So it's good practice to also fix it at the AP side:-).

Wrong!!! KRACK is a pure client-side attack. Patching AP will give you nothing.

Worse!!! Patching AP will just give some people false sense of security when in fact every client on the WiFi network is vulnerable, Android the most but also every other client WPA implementation regardless, and that could allow an attacker to make a havoc in your network ... so look for client patches, APs are irrelevant!!!

You can fix the 4-way handshake issue either at the client side or at the Access Point side. ... So it's good practice to also fix it at the AP side:-).

Wrong!!! KRACK is a pure client-side attack. Patching AP will give you nothing.

It's not wrong, however, I understand your interpretation. You cannot prevent the attack (on the clients) by patching the AP. If you can get an unpatched client to connect to the attackers rogue AP, the attack remains possible. However, can fix the handshake vulnerability at the AP even if the client is not patched. It's good pratice to do that. So a vulnerable client will not make a vulnerable handshake if an AP is patched. I hope this clarification makes sense.

I notice that the NV2 is not affected. My questions is if the tower is NV2 but WDS is turned on and client is using WDS are they affected?

If you can get an unpatched client to connect to the attackers rogue AP, the attack remains possible. However, can fix the handshake vulnerability at the AP even if the client is not patched. It's good pratice to do that. So a vulnerable client will not make a vulnerable handshake if an AP is patched.

You don't appear to understand how these attacks work; and you comments are misleading at best. Please stop that!

Hello guys!

Just want to have approval - is the SXTsq Lite5 model firmware secure against the latest WPA2 vulnerability?

Regards

Hello guys!

Just want to have approval - is the SXTsq Lite5 model firmware secure against the latest WPA2 vulnerability?

Regards

Hi,
just ensure your RouterOS version is at least equal or above 6.39.3 in bugfix channel, 6.40.4 in current channel or 6.41rc if you use the release candidate channel.
Check it through System->Packages and upgrade as necessary.

Thanks for the answers - I will check tose RouterOS versions and update them accordingly!

Thanks for fast fix and clear informations, well done!

MikroTik Team, short question:
If I have a wireless link on 802.11 protocol using Management Protection - can it be vulnerable to the attacks (before the upgrade)? Or does Management Protection already solve the problem (by not allowing the client, if Management Protection is "required", to connect to a "fake" AP not using it)?

Or does Management Protection already solve the problem (by not allowing the client, if Management Protection is "required", to connect to a "fake" AP not using it)?

According to the documentation, the management frame protection has nothing to do with the initial 4-way handshake, and thus does not protect you from the aforementioned attacks. Also please note that this attacks do not require wireless clients to connect to a "fake" AP- this "fake" AP just listens and sends you some additional packets while you are still connected to the "real" AP.

Hi Andriys

Please be constructive instead of just shouting at me. Not looking for an online fight.
What do you mean by your last post?

Also please note that this attacks do not require wireless clients to connect to a "fake" AP- this "fake" AP just listens and sends you some additional packets while you are still connected to the "real" AP

The demo from the researcher clearly indicates a man-in-the-middle attack. It is shown in the video on his website around 1:54 https://youtu.be/Oh4WURZoR98
Hence, the client does connect to the malicious AP. You seem to claim the client does not need to connect to the fake AP?

You can fix the 4-way handshake issue either at the client side or at the Access Point side. ... So it's good practice to also fix it at the AP side:-).

Wrong!!! KRACK is a pure client-side attack. Patching AP will give you nothing.

Worse!!! Patching AP will just give some people false sense of security when in fact every client on the WiFi network is vulnerable, Android the most but also every other client WPA implementation regardless, and that could allow an attacker to make a havoc in your network ... so look for client patches, APs are irrelevant!!!

Patching ap is viable if ap is used as a client (station mode) and has some or all software errors that where reported. But in all sence you are right ALL CLIENTS SHOULD UPGRADE and AP that is used as a CLIENT may or may not be needing updates as well. Microsoft and Apple in their latest updates all ready patched. But Linux and Android where following rfc to the point and where therefore hit hard this time. And we all know how well fragmented the android market is.... Many perhaps will not even get an update.... Game over in that case.

You can fix the 4-way handshake issue either at the client side or at the Access Point side. ... So it's good practice to also fix it at the AP side:-).

Wrong!!! KRACK is a pure client-side attack. Patching AP will give you nothing.

Worse!!! Patching AP will just give some people false sense of security when in fact every client on the WiFi network is vulnerable, Android the most but also every other client WPA implementation regardless, and that could allow an attacker to make a havoc in your network ... so look for client patches, APs are irrelevant!!!

Patching ap is viable if ap is used as a client (station mode) and has some or all software errors that where reported. But in all sence you are right ALL CLIENTS SHOULD UPGRADE and AP that is used as a CLIENT may or may not be needing updates as well. Microsoft and Apple in their latest updates all ready patched. But Linux and Android where following rfc to the point and where therefore hit hard this time. And we all know how well fragmented the android market is.... Many perhaps will not even get an update.... Game over in that case.

Well I did say CLIENT implementation is vulnerable ...
Although APs implementing 802.11r are also affected by CVE-2017-13082 and should be patched ... but Mikrotik does not support it as far as I know ...

The demo from the researcher clearly indicates a man-in-the-middle attack. It is shown in the video on his website around 1:54 https://youtu.be/Oh4WURZoR98
Hence, the client does connect to the malicious AP. You seem to claim the client does not need to connect to the fake AP?

You should have also read the detailed description of the attack, and not just watch the demonstration video. Now to your points. Yes, it is an MiTM type of attack (researchers called it channel-based MiTM attack). No, the victim does not connect to the rogue AP (and no attempt is made to trick it to connect to the rogue AP at the beginning). Instead, it is tricked to switch to the rogue AP once the connection with the real AP is established. And no, there's nothing the real AP can do to prevent this.

The demo from the researcher clearly indicates a man-in-the-middle attack. It is shown in the video on his website around 1:54 https://youtu.be/Oh4WURZoR98
Hence, the client does connect to the malicious AP. You seem to claim the client does not need to connect to the fake AP?

You should have also read the detailed description of the attack, and not just watch the demonstration video. Now to your points. Yes, it is an MiTM type of attack (researchers called it channel-based MiTM attack). No, the victim does not connect to the rogue AP (and no attempt is made to trick it to connect to the rogue AP at the beginning). Instead, it is tricked to switch to the rogue AP once the connection with the real AP is established. And no, there's nothing the real AP can do to prevent this.

Apparently AP can mitigate this by "bending" the standard 4-way handshake and instead of re-transmitting message 3 de-authorize the client so the handshake starts all over again ... that would break standard behavior designed to happen on bad and unreliable connections but will effectively make the attack unsuccessful ... better way would be of course to patch the clients not to reinstall keys ...

Apparently AP can mitigate this by "bending" the standard 4-way handshake and instead of re-transmitting message 3...

It does not re-transmit anything during attack. It's an attacker who replays the message 3 that was originally transmitted by the real AP.

Apparently AP can mitigate this by "bending" the standard 4-way handshake and instead of re-transmitting message 3...

It does not re-transmit anything during attack. It's an attacker who replays the message 3 that was originally transmitted by the real AP.

It does actually ... the attacker is replaying retransmissions of message 3 of the 4-way handshake ... so without this re-transmissions to replay the attack would not be possible ... and if you are criticizing the others you should also familiarize yourself with how the attack actually works ...

It does actually ... the attacker is replaying retransmissions of message 3 of the 4-way handshake ... so without this re-transmissions to replay the attack would not be possible ...

Ok, got it. You're absolutely right here.

Still none of the (even patched) APs now do what you suggested to mitigate the attack (and is unlikely to ever do, as that will be a pure violation of the existing standards, whereas, as I understand, what the industry now aims at is to make wording in the standards stricter, but still fully preserve backwards compatibility). So getting back to the original post of Jeroen1000, and the following replies or mine and yours it is vital to understand that patching only AP gives you absolutely nothing in terms of KRACK attack mitigation.

To summarize, the client does connect to the fake AP. That's why the researcher enabled ip forwarding on his linux box.

Actually there are AP's that will do this (mitigate the 4-way handshake problem). I'm not sure it will break anything with compatibility but we administer a ton of AP's and they are running this firmware right now (I work at an ISP). We have not verified this as of yet but it's planned.

To summarize, the client does connect to the fake AP. That's why the researcher enabled ip forwarding on his linux box.

Actually there are AP's that will do this (mitigate the 4-way handshake problem). I'm not sure it will break anything with compatibility but we administer a ton of AP's and they are running this firmware right now (I work at an ISP). We have not verified this as of yet but it's planned.

There may be some APs with an already upgraded firmware to mitigate KRACK attack but I am unaware of any so maybe you could share what APs are you using.
The main problem can be that under low quality links clients would have to be reauthorized too often and if under attack clients would not be able to connect at all, but I am certain that most people would be OK with this ...
Also just to be clear on MikroTik APs mitigation is not yet available and the only option is to patch the clients and that maybe impossible especially with Android devices that probably will never receive a patch, so maybe a suggestion for MikroTik to develop something like this and make it available as an option when working as an AP ...

Also just to be clear on MikroTik APs mitigation is not yet available and the only option is to patch the clients and that maybe impossible especially with Android devices that probably will never receive a patch, so maybe a suggestion for MikroTik to develop something like this and make it available as an option when working as an AP ...

Also if anyone is interested here is a link for hostapd implementation of mitigation at AP side ...
https://w1.fi/cgit/hostap/commit/?id=6f ... 45ed8e52d3

Hello friends

Looks like MTU of OVPN server was changed after update. Symptoms:

@ router (mikrotik) to router (mikrotik) VPN tunnel.

1. Ping host behind vpn works on small packet about 1300
2. Ping x.x.x.x. -l2000 dosen't work (windows)
After change MTU from 1400 to 1500 (only server side) everything works great (ofcourse you have to change network mask).

One small note. There I don't have issues on MTU 1400 or 1500 using OVPN connect on Android to router (mikrotik)

Have nice week.
Maciej

Hi guys, is it possible to do AP-side mitigation with this version?