kristate / krackinfo Goto Github PK

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080

cert.org posted with the vulnerability notes a list with known vulnerable Vendors:
https://www.kb.cert.org/vuls/id/228519

There is annual Digital Ocean + GitHub event for supporting open source development of any kind.
This repo is opensource documentation project.
Adding Hacktoberfest label to project and using this label in issues allows commiters to win prizes from Digital Ocean. More info at https://hacktoberfest.digitalocean.com/#details and https://hacktoberfest.digitalocean.com/#resources

4f08971 seems to have clobbered fdbb78b

WPA2 flaw – FRITZ!Box on broadband connections are secure
LINK
AVM will provide updates for its wireless repeaters.

CZ.NIC Turris team is testing a fix (backported from hostapd upstream):
https://gitlab.labs.nic.cz/turris/openwrt/commit/a60970f33f65bfb1d531ce822bfd28ee049a702f
via
https://forum.turris.cz/t/major-wpa2-vulnerability-to-be-disclosed/5363/8

Homepage: https://www.turris.cz/en/

• Mikrotik
• Ubiquiti

KRACK is mostly client based, which is why I think the entries should be separated into two tables: Client OS and AP vendor. Not going to submit a PR for this since it would merge conflict with all the current PRs, just a suggestion.

Patched: LINK
Packages released: LINK

The Linux distro Debian (and by extension, Ubuntu) have updated wpasupplicant to address these vulnerabilities;

wpa (2.3-1+deb8u5) jessie-security; urgency=high

  * Non-maintainer upload by the Security Team.
  * Add patches to fix WPA protocol vulnerabilities (CVE-2017-13077,
    CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081,
    CVE-2017-13082, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088):
    - hostapd: Avoid key reinstallation in FT handshake
    - Prevent reinstallation of an already in-use group key
    - Extend protection of GTK/IGTK reinstallation of WNM-Sleep Mode cases
    - Fix PTK rekeying to generate a new ANonce
    - TDLS: Reject TPK-TK reconfiguration
    - WNM: Ignore WNM-Sleep Mode Response if WNM-Sleep Mode has not been used
    - WNM: Ignore WNM-Sleep Mode Response without pending request
    - FT: Do not allow multiple Reassociation Response frames
    - TDLS: Ignore incoming TDLS Setup Response retries

 -- Yves-Alexis Perez <[email protected]>  Sat, 14 Oct 2017 14:11:26 +0200

wpa (2:2.4-1+deb9u1) stretch-security has also been observed.

Allegedly it has also been updated for Arch Linux.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa

But there's this reddit comment: https://www.reddit.com/r/KRaCK/comments/76pjf8/krack_megathread_check_back_often_for_updated/dofszli/

The information added in commit 4bfa25b seems unsubstantiated and out-of-place to me.

I personally think it would be best to keep it simple - let other websites and resources explain the implications, or the information could be merged into sections "Attacks that ...".

FEDORA-2017-f45e844a85

As of writing:
Status: Fixed
Release: Pending*

*= Manual installation possible

Please add vendors of AVR equipment (Denon/Marantz, Onkyo, Pioneer, ...)
As I own a Marantz receiver with WiFi, I Tweeted @MarantzEurope

According to Jolla Forum, patch is included in upcoming 2.1.3 release of Sailfish OS

https://together.jolla.com/question/170073/krack-attacks-wpa2-is-not-secure-anymore/

Patched in the upcoming Sailfish OS 2.1.3:

https://git.merproject.org/mer-core/wpa_supplicant/commits/upgrade-2.1.3
https://git.merproject.org/mer-core/wpa_supplicant/merge_requests/6

Sonos has stated here: https://en.community.sonos.com/ask-a-question-228987/is-sonos-vulnerable-to-the-krack-attack-6792188

Ryan S, Community Manage said:

Hi everyone,

We're aware of the issues with WPA2 and our team is working to determine any ramifications this may have for Sonos players.

We appreciate your concern and thanks for reaching out.

Status: Testing LINK

OnePlus is not on the list

Xirrus is not in the vendor list

Would it make sense to add Comcast/Xfinity to the list, since they have a ton of gateway/APs that only they can patch? Or are their devices listed under another manufacturer?

Thanks so much for this list/your work!

I foresee that Android is going to be a huge problem, mainly due to the severity of the issue and also the continued lack of support for devices from OEMs. We are already seeing some poor choices such as Tesco deciding not to patch Hudl.

I am going to start an Android specific page of information regarding each of the devices.

What is the latest from team Android?

Thanks again to everyone for their support!

Not an issue, just a curiosity. Why are two of the headings paraphrased in Japanese? A friend and I couldn't figure out the motivation but we're darned curious.

I have notified Pakedge about this issue today.
http://pakedge.com/

They have acknowledged they have received my enquiry but don’t have any info about the state of this vulnerability in their products.

Also, why are some of the dates in the future? E.g., 2017-10-21 (Last Checked)

Probably should add:
Nest Labs - Doesn't seem to be taking things seriously "No known attacks can be carried out against our hardware" was the reply I was told vai support.
Ring - Per support "They promise to update public shortly, actively working with developers."
Yi (Xiaoyi) - Waiting on a reply.

https://ruckus-www.s3.amazonaws.com/pdf/security/faq-security-advisory-id-101617-v1.0.pdf

Fixed in Debian but not yet included in Raspbian repository.

http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007.txt

No official response.
No response found in any way.

Update:
I have a screen-dump of the response from iRobot.

As far as I know they didn’t make an official statement. It’s a very popular product and since most of the users typically use the devices wirelessly, it would be very welcome to have them on this list.

The KRACK author states that Android 6.0 devices and others using more recent versions of wpa_supplicant are vulnerable to an easier, more powerful attack. However, although the attack against those devices sounds scarier, the real-life implications of that attack are actually less worrisome than against other devices. The KRACK author did not look at the big picture.

The attack specific to those versions of wpa_supplicant which zero out the PTK works by taking over the connection from those devices to the access point. However, it does not allow the attacker to interact in any way with the original access point. Although the attacker now has full control over the connection to the device, they cannot forward it to the real AP and man-in-the-middle the resulting traffic (unless they have credentials to the AP, but then there are many other ways to attack it). This is unlike the original KRACK attack which does allow the attacker to decrypt and possibly modify data while the client remains connected to the original AP.

Crucially, we can already do similar things without relying on KRACK, intrinsic to the way WiFi works. If I want to take over your network connection, all I have to do is show up with a rogue access point with the SSID of a public WiFi that your device is likely to have stored, and then forcibly inject a deauth to kick it off its current network. Chances are it will join my rogue network of its own accord. Anyone who has ever connected to a public WiFi on their phone is vulnerable to this, and the impact is all but identical to what you can do with the specific form of KRACK we're talking about. This is a much simpler attack (you don't even need custom attack tools, just a aircrack to inject deauths and a standard AP) and works on every device.

Other than that, the worst you can do with this variant of KRACK relevant to the original AP's network is to sniff whatever traffic the client attempts to send to the original AP. However, since you can't reply appropriately (unless it's new connections to Internet hosts you can forward to), this is most likely of rather limited use.

Therefore, I would suggest changing the language around this to better reflect the reality of the situation. In my opinion, Android 6.0 and later devices are actually affected by KRACK in a less severe way, in practical situations, all things considered.

For further reading, the wpa_supplicant advisory has a more accurate description of the problem that gauges the impact on older versions as being more severe:

For the station/Supplicant side GTK/IGTK reinstallation and TK configuration:

All wpa_supplicant versions. The impact on older versions can be more severe due to earlier changes in this area: v2.3 and older can also reinstall the pairwise key and as such have similar impact as the AP FT case (CVE-2017-13077); v2.4 and v2.5 end up configuring an all-zero TK which breaks the normal data path, but could allow an attacker to decrypt all following frames from the station and to inject arbitrary frames to the station. In addition, a different message sequence involving 4-way handshake can result in configuration of an all-zero TK in v2.6 and the current snapshot of the development repository as of the publication of this advisory.

Response on UK website is here:

http://www.draytek.co.uk/information/our-technology/wpa2-krack-vulnerability

DrayTek are investigating solutions for this and plan to issue appropriate updates (firmware) as soon as possible. We will update this page in due course.

Hi Kris,

Mojo Networks would like to be included on your Vendor Patch Matrix for the WPA2. Not only have we already upgraded our cloud server with the fix, we have an upgrade available for all Mojo APs. Further, Mojo is the only vendor with built-in MAC spoofing and Man-in-the-Middle protection that helps users mitigate the majority of the client side vulnerabilities until software updates are available for those clients. (other vendors may cover those features, but only to customers who purchase an extra license/product add on).

You can find info at the following URLs. If you have any questions, please feel free to contact me directly at [email protected]

WPA Vulnerability Announcement (https://www.mojonetworks.com/wpa2-vulnerability)

Blog: WPA2 Key Reinstallation Vulnerabilities (KRACK) Explained (http://blog.mojonetworks.com/wpa2-vulnerability)

Mitigation Plan on Mojo Support Portal
https://support.mojonetworks.com/support/solutions/articles/9000134420-wpa2-wpa-key-reinstall-vulnerabilities

Thanks!
Cherie

Ruckus Wireless is not in the vendor list.

see https://twitter.com/LineageAndroid/status/920143977256382464 and the changelog with patches at https://download.lineageos.org 💕

Sophos also confirmed the vulnerability and is working on a fix:
https://community.sophos.com/kb/en-us/127658

Not sure I believe them, but I have contacted ecobee support and they claim that ecobees are not vulnerable

Their full response as of 10:21am on 10-17:

Hello,

Thank you for contacting ecobee technical support today.

ecobee is aware of the industry-wide vulnerability in WPA2 referred to as KRACK. The security of our customers is very important to us, and we have confirmed that ecobee device security is not impacted by this issue.

Regards

http://docs.fortinet.com/uploaded/files/3961/fortiap-v5.6.1-release-notes.pdf

FortiAP 5.6.1 is no longer vulnerable to the following CVE Reference:
...
CVE-2017-13077
CVE-2017-13078
CVE-2017-13079
CVE-2017-13080
CVE-2017-13081
CVE-2017-13082

I spoke with Samsung customer support and they said a fix is in the works, no ETA available.

OmniROM builds updated with KRACK fixes
all official OmniROM N builds have the fix included.
LINK

TP-Link have stated they will be updating this page with details when they have verified specific products as vulnerable.

Beveiligingsonderzoekers vinden kwetsbaarheid in wifi-protocol

Status: No fix

Do we have any information if the WiFi library on Arduino is affected?

All official 14.1 builds built after this tweet have been patched for KRACK.
LINK

After doing some research I found that webOS uses connman. See git LINK
WebOS forum shows no activity concerning KRACK LINK
Connman has not released any information or updates yet. LINK
Other distro's using connman might also be affected.

https://www.sonicwall.com/en-us/support/product-notification/wpa2-krack-exploit-a-sonicwall-alert

https://kb.netgear.com/000049498/Security-Advisory-for-WPA-2-Vulnerabilities-PSV-2017-2826-PSV-2017-2836-PSV-2017-2837