Tech Solvency / The Story So Far / KRACK Attack

Executive summary

• Flaw with the protocol itself - so *anything* speaking Wi-Fi will need to be patched (both client *and* server), including the long tail of legacy, EOL, and cheap IoT gear that will likely never be patched - so replacing hardware will be the only option.
• Unless you are already familiar with the security posture of the specific Wi-Fi networks that you're riding, assume all Wi-Fi networks are observable (core mitigation: use a VPN, tether instead of Wi-Fi). You should already be doing this.
• Android and Linux are the most vulnerable. Much harder to exploit on Windows or iOS.
• Once exploitable, threat actors can:
  • decrypt arbitrary packets (all platforms?)
  • decrypt and inject arbitrary packets (TKIP or GCMP)
  • replay broadcast/multicast (all platforms?)
  • inject an "all-zeroes" encryption key ("all traffic is trivially decrypted when attacking Linux and Android 6.0+ clients.").
  • "Can be easily leveraged to dump TCP SYN traffic and hijack connections."
  Based on our understanding of the vulnerabilities, threat actors cannot:
  • Threat actors cannot: directly recover WPA passphrases (but they could already force a handshake, intercept the hash, and crack it offline if it's weak).
  • Inject packets (if using AES-CCMP)
• The authors are releasing a proof-of-concept exploit on November 1st, 2017
• As was true prior to this issue, once someone can see your Wi-Fi traffic, sites using HTTPS can be sslstripped. Strongly recommend ramping up to deploying HSTS as a countermeasure (if not for this issue, then to be ready for the next one). You should be doing HSTS anyway.
• The Wi-Fi standard is closed and behind a paywall. If it was an open standard, it might have taken less than 13 years for someone to discover this flaw.
• Long term, assume more attacks like this are possible. Recommend regularly studying Wi-Fi traffic for protocols that are not encrypted, and moving to upgrade/fix those data flows. Also recommend requiring in RFPs for any gear (not just wireless) to ensure updates for X period of time.
• Long term, start moving to a zero-trust model like BeyondCorp, in which all users and devices are authenticated, regardless of location or topology. This is the model that all organizations will eventually have to move to, but it takes time. Start now. You'll thank me.

Core announcements

• Main announcement: https://www.krackattacks.com/
• GitHub for the site itself: https://github.com/vanhoefm/krackattacks
• Paper with background: https://papers.mathyvanhoef.com/ccs2017.pdf
• CERT info: http://www.kb.cert.org/vuls/id/228519

Rolling summaries and key commentary

• https://github.com/kristate/krackinfo - very active, watch this
• Rob Graham - very good commentary: http://blog.erratasec.com/2017/10/some-notes-on-krack-attack.html
• Aruba FAQ: http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007_FAQ_Rev-1.pdf
• Beaumont: https://doublepulsar.com/regarding-krack-attacks-wpa2-flaw-bf1caa7ec7a0
• Matthew Green - root causes: https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/
• Talos - https://blogs.cisco.com/security/wpa-vulns

Analysis

• From CERT: Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated to induce nonce and session key reuse, resulting in key reinstallation by a wireless access point (AP) or client. An attacker within range of an affected AP and client may leverage these vulnerabilities to conduct attacks that are dependent on the data confidentiality protocols being used. Attacks may include arbitrary packet decryption and injection, TCP connection hijacking, HTTP content injection, or the replay of unicast and group-addressed frames.
• Matthew Green - overview and root causes: https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/
  (I read this as "decryption without faking the AP"):
  The key vulnerability in KRACK (no pun intended) is that message #3 can be blocked by adversarial nasty people. When this happens, the AP re-transmits this message, which causes (the same) key to be reinstalled into the client (note: see update below). This doesn’t seem so bad. But as a side effect of installing the key, the packet number counters all get reset to zero. (And on some implementations like Android 6, the key gets set to zero — but that’s another discussion.)
  
  The implication is that by forcing the AP to replay this message, an adversary can cause a connection to reset nonces and thus cause keystream re-use in the stream cipher. With a little cleverness, this can lead to full decryption of traffic streams. And that can lead to TCP hijacking attacks. (There are also direct traffic forgery attacks on GCM and TKIP, but this as far as we go for now.)
• Rob Graham - very good commentary: http://blog.erratasec.com/2017/10/some-notes-on-krack-attack.html

Absract and conclusion from paper

Abstract: - We introduce the key reinstallation attack. This attack abuses design or implementation flaws in cryptographic protocols to reinstall an already-in-use key. This resets the key’s associated parameters such as transmit nonces and receive replay counters. Several types of cryptographic Wi-Fi handshakes are affected by the attack.
- All protected Wi-Fi networks use the 4-way handshake to generate a fresh session key. So far, this 14-year-old handshake has remained free from attacks, and is even proven secure. However, we show that the 4-way handshake is vulnerable to a key reinstallation attack. Here, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying handshake messages. When reinstalling the key, associated parameters such as the incremental transmit packet number (nonce) and receive packet number (replay counter) are reset to their initial value. Our key reinstallation attack also breaks the PeerKey, group key, and Fast BSS Transition (FT) handshake. The impact depends on the handshake being attacked, and the data-confidentiality protocol in use. Simplified, against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPATKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged. Because GCMP uses the same authentication key in both communication directions, it is especially affected.
- Finally, we confirmed our findings in practice, and found that every Wi-Fi device is vulnerable to some variant of our attacks. Notably, our attack is exceptionally devastating against Android 6.0: it forces the client into using a predictable all-zero encryption key.

Conclusion - Despite the security proof of both the 4-way and group key handshake, we showed that they are vulnerable to key reinstallation attacks. These attacks do not violate the security properties of the formal proofs, but highlight limitations of the models employed by them. In particular, the models do not specify when a key should be installed for usage by the data-confidentiality protocol. Additionally, we showed that the PeerKey and fast BSS transition handshake are vulnerable to key reinstallation attacks.
- All Wi-Fi clients we tested were vulnerable to our attack against the group key handshake. This enables an adversary to replay broadcast and multicast frames. When the 4-way or fast BSS transition handshake is attacked, the precise impact depends on the data-confidentiality protocol being used. In all cases though, it is possible to decrypt frames and thus hijack TCP connections. This enables the injection of data into unencrypted HTTP connections. Moreover, against Android 6.0 our attack triggered the installation of an all-zero key, completely voiding any security guarantees.
- Rather worryingly, our key reinstallation attack even occurs spontaneously if certain handshake messages are lost due to background noise. This means that under certain conditions, implementations are reusing nonces without an adversary being present.
- An interesting future research direction is to determine whether other protocol implementations are also vulnerable to key reinstallation attacks. Protocols that appear particularly vulnerable are those that must take into account that messages may be lost. After all, these protocols are explicitly designed to process retransmitted frames, and are possibly reinstalling keys while doing so.

Remediation and mitigation

• Patch clients and servers as noted.
• Use AES-CCMP (not AES-TKIP, already known to be weak)
• Use VPN, Citrix, or other intercept-resistant encryption.
• Use tethering instead of Wi-Fi.
• Disable 802.11r.
• Use browser plugins like HTTPS Everywhere (to minimize use of HTTP), and Ugly HTTP (to be more aware when you are using HTTP).

Products

Product summaries:

• CERT: https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4
• https://github.com/kristate/krackinfo - very active, watch this
• Reddit: https://www.reddit.com/r/KRaCK/comments/76pjf8/krack_megathread_check_back_often_for_updated/
• https://char.gd/blog/2017/wifi-has-been-broken-heres-the-companies-that-have-already-fixed-it

Android:
    Patched in November 6th patch level, per https://threatpost.com/google-patches-krack-vulnerability-in-android/128818/

Apple:
    Was initially only unofficial, only in betas:
        http://appleinsider.com/articles/17/10/16/apple-confirms-krack-wi-fi-wpa-2-attack-vector-patched-in-ios-tvos-watchos-macos-betas
    Now available in iOS 11.1
        https://www.macrumors.com/2017/10/31/apple-releases-ios-11-1-with-new-emoji/

Arduino:
    https://github.com/esp8266/Arduino/releases/tag/2.4.0-rc2

Aruba:
    (Aruba patch info also has WIPS updates to detect and alert on attempts to exploit)
    http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007.txt
    http://community.arubanetworks.com/t5/Wireless-Access/Core-level-protocol-flaw-in-WPA2/td-p/310038
    http://community.arubanetworks.com/t5/Technology-Blog/WPA2-Key-Reinstallation-Attacks/ba-p/310045
    http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007_FAQ_Rev-1.pdf
    http://www.arubanetworks.com/support-services/security-bulletins/

Asus (nothing at this writing but should appear here:
    https://www.asus.com/Static_WebPage/ASUS-Product-Security-Advisory/

Cisco / Meraki:
    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa
    (Note: Meraki fix only addresses 802.11r vuln, not the client-level ones):
    https://documentation.meraki.com/zGeneral_Administration/Support/802.11r_Vulnerability_(CVE%3A_2017-13082)_FAQ

DD-WRT - patched, but patched version not yet released
    https://www.dd-wrt.com/phpBB2/viewtopic.php?t=311679

Debian:
    http://seclists.org/bugtraq/2017/Oct/25
        Jessie: fixed in version 2.3-1+deb8u5.
        Stretch: fixed in version 2:2.4-1+deb9u1.
    https://www.debian.org/security/2017/dsa-3999

Expressif:
    http://espressif.com/en/media_overview/news/espressif-releases-patches-wifi-vulnerabilities-cert-vu228519

Fedora - updates available in testing
    https://www.reddit.com/r/KRaCK/comments/76rbf6/fedora_updates/

FreeBSD:
    Patched:
        https://www.freebsd.org/security/advisories/FreeBSD-SA-17:07.wpa.asc
    Discussion
        https://lists.freebsd.org/pipermail/freebsd-current/2017-October/067193.html
    VuXML
        https://www.vuxml.org/freebsd/d670a953-b2a1-11e7-a633-009c02a2ab30.html

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

Intel
    https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00101&languageid=en-fr

Juniper
    https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10827

Microsoft (released Oct 10 as part of Patch Tuesday):
    https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080

MikroTik (patches published previous week?)
    https://forum.mikrotik.com/viewtopic.php?f=21&t=126695

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

OpenBSD - fixed (ahead of the embargo, so they will be notified later in the embargo cycle next time?):
    https://marc.info/?l=openbsd-announce&m=150410604407872&w=2
    https://mastodon.social/@stsp/98837563531323569

pfSense - wpa_supplicant and hostapd vulnerable
    Fix committed to source tree
        https://redmine.pfsense.org/issues/7951
    Fix available in OS snapshots, not yet released to release
        https://twitter.com/pfsense/status/920287612262371329
        https://snapshots.pfsense.org/

Red Hat
    https://access.redhat.com/security/cve/cve-2017-13087

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

Sophos - affected, fixed TBD:
    https://community.sophos.com/kb/en-us/127658

SUSE - affected
    https://bugzilla.suse.com/show_bug.cgi?id=1063479

Synology:
    https://www.synology.com/en-us/support/security/Synology_SA_17_60_KRACK

TP-LINK (in progress):
    Official statement, with list of affected/unaffected devices:
        http://www.tp-link.com/us/faq-1970.html
    Forum link: http://forum.tp-link.com/showthread.php?101094-Security-Flaws-Severe-flaws-called-quot-KRACK-quot-are-discovered-in-the-WPA2-protocol

Ubiquiti - affected, some patches available:
    https://community.ubnt.com/t5/UniFi-Updates-Blog/FIRMWARE-3-9-3-7537-for-UAP-USW-has-been-released/ba-p/2099365
    (per NANOG post:)
    Unconfirmed: patched in UniFi firmware release 3.9.3 (see forums or /r/ubiquiti.
    3.8.15 for Broadcom based APs like the first gen UAP-AC and ACv2 should be soon from what I read.

Ubuntu:
     https://usn.ubuntu.com/usn/usn-3455-1/

wpa_supplicant - affected, patched upstream:
    https://w1.fi/cgit/hostap/commit/

Zyxel (roadmap, some fixes not expected until Feb 2018!)
     http://www.zyxel.com/support/announcement_wpa2_key_management.shtml

CVE list

CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame

Detection and testers

• krackattacks-test-ap-ft - test tool by the authors: https://github.com/vanhoefm/krackattacks-test-ap-ft
• Kismet: https://twitter.com/KismetWireless/status/919911322451632128 (and his blog post
• Aruba WIPS configurable to detect it, after upgrade.

Exploitation

• Non-trivial. Announcement coming from original authors when presenting a paper at a conference November 1st.
• Scripts published: https://github.com/vanhoefm/krackattacks-scripts
• Unverified: https://pastebin.com/aZyyS16w
• Android WIFI KRACK PoCs

News and posts

• Ars Technica
• The Register
• techau.com.au
• https://www.alexhudson.com/2017/10/15/wpa2-broken-krack-now/
• Twitter account of author: https://twitter.com/vanhoefm/with_replies
• Reddit: https://www.reddit.com/r/sysadmin/comments/76lj5q/this_is_a_core_protocollevel_flaw_in_wpa2_wifi/ and https://www.reddit.com/r/sysadmin/comments/76pgfo/krack_attack_website_now_live/
• SANS - https://securingthehuman.sans.org/blog/2017/10/16/28748/
• Threatpost - https://threatpost.com/krack-attack-devastates-wi-fi-security/128461/
• ZDNet - http://www.zdnet.com/article/here-is-every-patch-for-krack-wi-fi-attack-available-right-now/
• The Verge - https://www.theverge.com/2017/10/16/16481252/wi-fi-hack-attack-android-wpa-2-details
• Schneier - https://www.schneier.com/blog/archives/2017/10/new_krack_attac.html
• The Guardian - https://www.theguardian.com/technology/2017/oct/16/wpa2-wifi-security-vulnerable-hacking-us-government-warns
• Krebs - https://krebsonsecurity.com/2017/10/what-you-should-know-about-the-krack-wifi-security-weakness/
• Daily Beast - https://www.thedailybeast.com/theres-a-huge-wifi-security-hole-but-dont-panic [caveat: i think Weaver is over-simplifying the risk here]
• HITB - https://news.hitb.org/content/serious-flaw-wpa2-protocol-lets-attackers-intercept-passwords-and-much-more
• Teen Vogue - https://www.teenvogue.com/story/krack-wifi-flaw-what-to-know
• HN - #1 https://news.ycombinator.com/item?id=15481819
• HN - #2 https://news.ycombinator.com/item?id=15480895
• Rapid7 - https://blog.rapid7.com/2017/10/16/the-wi-fi-krack-vulnerability-what-you-need-to-know/
• aircrack-ng - https://aircrack-ng.blogspot.com/2017/10/krack-wpa-vulnerability-key.html
• EFF - https://www.eff.org/deeplinks/2017/10/krack-vulnerability-what-you-need-know
• BGR - http://bgr.com/2017/10/16/krack-wi-fi-wpa2-patches-available-android-ios-windows/

Return to The Story So Far (list of notable security events)