Researchers this week published information about a newfound, serious weakness in WPA2 — the security standard that protects all modern Wi-Fi networks. What follows is a short rundown on what exactly is at stake here, who’s most at-risk from this vulnerability, and what organizations and individuals can do about it.
Short for Wi-Fi Protected Access II, WPA2 is the security protocol used by most wireless networks today. Researchers have discovered and published a flaw in WPA2 that allows anyone to break this security model and steal data flowing between your wireless device and the targeted Wi-Fi network, such as passwords, chat messages and photos.
“The attack works against all modern protected Wi-Fi networks,” the researchers wrote of their exploit dubbed “KRACK,” short for “Key Reinstallation AttaCK.”
“Depending on the network configuration, it is also possible to inject and manipulate data,” the researchers continued. “For example, an attacker might be able to inject ransomware or other malware into websites. The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected.”
What that means is the vulnerability potentially impacts a wide range of devices including those running operating systems from Android, Apple, Linux, OpenBSD and Windows.
As scary as this attack sounds, there are several mitigating factors at work here. First off, this is not an attack that can be pulled off remotely: An attacker would have to be within range of the wireless signal between your device and a nearby wireless access point.
More importantly, most sensitive communications that might be intercepted these days, such as interactions with your financial institution or browsing email, are likely already protected end-to-end with Secure Sockets Layer (SSL) encryption that is separate from any encryption added by WPA2 — i.e., any connection in your browser that starts with “https://”.
Also, the public announcement about this security weakness was held for weeks in order to give Wi-Fi hardware vendors a chance to produce security updates. The Computer Emergency Readiness Team has a running list of hardware vendors that are known to be affected by this, as well as links to available advisories and patches.
“There is no evidence that the vulnerability has been exploited maliciously, and Wi-Fi Alliance has taken immediate steps to ensure users can continue to count on Wi-Fi to deliver strong security protections,” reads a statement published today by a Wi-Fi industry trade group. “This issue can be resolved through straightforward software updates, and the Wi-Fi industry, including major platform providers, has already started deploying patches to Wi-Fi users. Users can expect all their Wi-Fi devices, whether patched or unpatched, to continue working well together.”
Sounds great, but in practice a great many products on the CERT list are currently designated “unknown” as to whether they are vulnerable to this flaw. I would expect this list to be updated in the coming days and weeks as more information comes in.
Some readers have asked if MAC address filtering will protect against this attack. Every network-capable device has a hard-coded, unique “media access control” or MAC address, and most Wi-Fi routers have a feature that lets you only allow access to your network for specified MAC addresses.
However, because this attack compromises the WPA2 protocol that both your wireless devices and wireless access point use, MAC filtering is not a particularly effective deterrent against this attack. Also, MAC addresses can be spoofed fairly easily.
To my mind, those most at risk from this vulnerability are organizations that have not done a good job separating their wireless networks from their enterprise, wired networks.
I don’t see this becoming a major threat to most users unless and until we start seeing the availability of easy-to-use attack tools to exploit this flaw. Those tools may emerge sooner rather than later, so if you’re super concerned about this attack and updates are not yet available for your devices, perhaps the best approach in the short run is to connect any devices on your network to the router via an ethernet cable (assuming your device still has an ethernet port).
From reading the advisory on this flaw, it appears that the most recent versions of Windows and Apple’s iOS are either not vulnerable to this flaw or are only exposed in very specific circumstances. Android devices, on the other hand, are likely going to need some patching, and soon.
If you discover from browsing the CERT advisory that there is an update available or your computer, wireless device or access point, take care to read and understand the instructions on updating those devices before you update. Failing to do so with a wireless access point, for example can quickly leave you with an expensive, oversized paperweight.
Finally, consider browsing the Web with an extension or browser add-on like HTTPS Everywhere, which forces any site that supports https:// connections to encrypt your communications with the Web site — regardless of whether this is the default for that site.
For those interested in a deeper dive on the technical details of this attack, check out the paper (PDF) released by the researchers who discovered the bug.
Microsoft says they already patched this on their last patch Tuesday, the 10th of October.
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080
That page was updated today. It looks like Microsoft updated October’s patches to include this mitigation. See https://portal.msrc.microsoft.com/en-us/security-guidance and search for CVE-2017-13080
Further info – Computerworld indicating this was part of October’s patches when released on 10/10, not updated 10/16 as I originally mentioned:
https://www.computerworld.com/article/3233198/microsoft-windows/microsoft-shuts-down-krack-with-sneaky-windows-update.html
Thanks for the sober commentary, useful guidance and potential impacts of this potential WiFi security weakness.
Please correct me if I’m wrong. From what I understand the security of the https site depends on how it was set up. Is there a way to determine which https sites are not really secure due to improper set-up?
https://www.ssllabs.com/ssltest/
If the site has a properly issued certificate it’ll contain the site’s name or domain name in the certificate.
If someone tried to launch a MITM attack using this (or another) exploit they would have to inject an SSL certificate that didn’t match their domain name. At that point you would be trying to go to a site whose DNS name doesn’t match the SSL certificate, at which point browsers will pop up huge warnings.
An alternative for the attacker would be to use a certificate that does match the domain name, but registrars who issue those certificates to third parties typically have the root certificate revoked, which returns you the same error message, since a revoked certificate is an invalid certificate.
Whether the SSL certificate contains enough bits to be secure, etc. is mildly irrelevant since that only helps attackers brute force your packets later to decrypt their contents. Important, sure, but you’re not going to subjected to a MITM attack just because the key’s weak.
The most common way this attack is going to be used is in forced downgrading of https to http. If I setup an AP to spoof your network, I can force your machine to connect to my AP and run downgrade attacks where I can see information in cleartext. Not all sites enforce HTTPS, which is where the problem really lies.
Thanks for a clear, written explanation on this; media has been running a muk on this exploit and scaring everyone without fully understanding the details.
What is the status of Apple iOS 11 (and the previous later versions of iOS 10 as far as vulnerability? Is it correct that “the most recent versions of… Apple’s iOS…” means version 11.xxx, but NOT versions 10.xxx?
The most significant of these attacks affects Linux devices and Android phones, they don’t affect Macs, iPhones, or Windows systems.
Apple have also patched this.
Following John Gruber (https://daringfireball.net/), I found this page which reports the following:
“Apple’s AirPorts, including Express, Extreme, and Time Capsule don’t seem be vulnerable to the exploit, even if using one as a bridge.”
“The KRACK exploit has already been patched in iOS, tvOS, watchOS, and macOS betas.” These are betas only, and have not been released to the public.
How far back Apple will patch this is unknown to me. I doubt my Mac OS X 10.6.8 will be patched, though.
https://www.imore.com/krack-wpa2-wi-fi-exploit-already-fixed-ios-macos-tvos-watchos-betas
HTTPS Everywhere is not compatible with Firefox 57
True, unfortunately.
I do not know what Mozilla was thinking with this version (57), but it is incompatible with a few other favorite add-ons of mine.
Firefox updates itself w/o asking you if you want to allow that. It should first determine if any of the installed extensions would become incompatible with the update, let you know the result, and ask you if you want to proceed anyway.
There’s a test build that is compatible, luckily: https://www.eff.org/files/https-everywhere-test/index.html
How about: use a VPN at all times on any device using wireless for other than casual browsing or streaming. Perhaps eventually it will come to needing VPN even with wired connections t0 the Internet.
I do not think that a VPN will work “at all times,” as I understand it.
In order to establish the VPN tunnel, the device’s VPN client must first reach out to the VPN server, establish a connection, then create the encrypted tunnel. Until the tunnel is created, the connection is not secured by the VPN.
I use a commercial VPN, which is pretty good performance-wise, but from time to time on an otherwise fast running MacBook Pro, the connection takes its sweet time (up to several minutes) to become established; and even then there are times when the connection drops, then picks up again, then drops…
I’d avoid any sensitive communications while a VPN was trying to establish itself. And, yes, I’d use a VPN on every network, as long as performance was satisfactory.
It looks like this also affects devices with wifi, not just network infrastructure. If that’s the case, then people be waiting months if ever to get updates for their phones, IoT devices, etc.
Think I’ll make sure I use a good VPN service on my Android device. I wasn’t aware until today that the security varies with the exact software you use.
Try out Opera’s free unlimited VPN for Android (and iOS). It gives you access to servers in the US, Canada, Germany, the Netherlands, and Singapore. You can read more and find it at https://www.operavpn.com/
A vast has a good VPN app.
“Just patch your device and you are ok, if you can’t patch it ask yourself why”. This summarises it.
In an ideal world where all devices are updatable this would be a no problem.
In the real world lots of IoT devices can’t be patched, lots of phones too. They will remain vulnerable forever.
If we learn the lesson we’ll have turned something bad into something good.
Just got off a live chat with my ISP [who is also a landline phone company, with all that imlies] who also provided the modem. “We’re workin’ on it” was all that was said. When I asked who manufactured the WIFI modem so I could look it up and determine its status they said [company name of the ISP]. When I asked who was the subcontractor who actually built the hardware the chat person said basically “don’t know”, ditto for the software builder. They then reverted to their standard of “change the password every two months”. First time I’ve heard that recommendation. Don’t think it’s an effective strategy for the KRACK given the interpretation by the KRACK researchers that it’s a placebo, nothing more. I wonder how much stonewalling will occur by big name ISP’s like mine?
@John
There are multiple websites that can help determine the real OEM for any network device with a MAC address.
For example:
http://coffer.com/mac_find/
http://curreedy.com/stu/nic/
https://www.miniwebtool.com/mac-address-lookup/
etc.
If you are not familiar with MAC address check out the Wikipedia article: https://en.wikipedia.org/wiki/MAC_address
@John
If you have received a Router-plus-Wireless-access-point from your internet provider, and you’d like to know who manufactured that hardware:
There is one simple method.
Find the router hardware in question.
Pick it up, and examine top/sides/bottom. Often, some sort of manufacturer emblem is embedded on it.
Most such devices have a label on the bottom or rear. For items sold in the United States, that label contains ModelNumber/SerialNumber/FCC-ID-Number. That information should make it trivially easy to trace the designer/manufacturer.
(If you are not inside the United States, there is probably an equivalent identifying-label that can be found.)
As an aside: and ISP (whether their primary business is Telephone, Cable TV services, or Internet Service) typically has millions of customers. Those customers have several generations of Router hardware, often from one of a half-dozen manufacturers.
Thus, anyone calling the Help Desk and asking about router hardware will probably get a brush-off response.
Often, the Help Desk has a Router-Serial-Number listed on your account. It’s probably as easy for them to figure out the device manufacturer from that as it is for you to deduce it from the sticker on the bottom. But the help desk person you talked to may not understand how to link that information to the question you were asking.
Or they have a policy of not talking about the router unless you are reporting that your ISP-supplied router is broken, and you’d like a replacement.
Home routers/APs are not susceptible to the Krack attack unless you have multiple APs in your home and are doing FT roams between them with your mobile devices.
Are VPN connections subject to this attack?
VPNs are a way to mitigate this, especially for enterprise WiFi. That is, so long as the VPN is set up correctly with signed certificates, etc.
I think android and IOT devices are going to be the issues as patches have been rolled out for Apple, Linux and Windows.
VPN is still secure as is HTTPS
End to end encryption is your only defense period.
In contradiction of your opening sentence, the flaws aren’t limited to WPA2. In fact, the flaws are even worse for those silly enough to still be utilizing WPA1 due to the insecure TKIP. ALL WiFi devices are impacted, neither WPA2-Enterprise nor MAC filtering offer any form of protection, and the only thing you can (continue to) do is wait until the updates roll out (if they haven’t already; thanks OpenBSD!).
Do we think this is likely to be a concern for transmission of credit card data between retail point of sale devices and local servers aggregating payment info? One would like to think that all those devices would be using an appropriately authenticated encrypted connection, but that’s probably not universal reality. Maybe it doesn’t matter anymore in the US given that most of our social security numbers are now exposed via the Experian debacle, but I’ve seen it suggested elsewhere that this may be a common environment for this attack to be used.
Err, Equifax debacle, sorry.
Could be used for capturing CC transactions. It’ll require a device to be installed locally, faking the real AP’s SSID. A properly managed wireless network is going to detect any managed SSIDs being spoofed by rogue APs, but I doubt many of those exist in the retail or hospitality space.
Sorry, to interrupt, but any wireless transmission can be intercepted. Think of an old am radio, all the frequencies can be received, intercepted, but live time use, that’s the question. Just as in old time radio, out of area signals can propagated, or hindered.
Now with built in listening devices set, reading the nearby signals,
If sites properly use TLS for all transactions, they should be safe from KRACK. Anyone who performs an http (as opposed to https) or similarly unencrypted/unauthenticated transaction is at risk.
In six months nobody will be talking about “Krack” it will be something else, and it just keeps going on and on.
Just a observation !
Looks like “replay” attack concerns were NEVER thought about, as this is really what is being talked about………
I don’t like using WiFi, so I connect via wired connections whenever possible.
I have never liked the idea of allowing connections from unverified devices.
The tech industry is rushing headlong to supersede wired connections. I recently read an article stating that two generations from now, wireless connections will be faster than wired connections.
Great – they’ll stop researching wired connections altogether and we’ll be hacked wirelessly at many times the speeds of today….
I’m not sure what people’s points are in praising wired over wireless regarding security unless they’re simply talking about a simple wired network that might run in their own bedroom or office. It’s pretty easy to access access a network when it’s wired but it’s all about location, location, location if you don’t want to get caught. In an enterprise environment there are methods to lock down wired access but if you invest in that then you should invest in good methods to lock down wireless.
“Two generations?” I recently clocked my Verizon LTE connection at 39.73 Mbps down, 6.78 Mbps up with a 68 msec ping. Does your home or work connection go that fast?
VPN will help, in the same way SSL/TLS will help.
There is a possibility of this being used in a blended attack. If an attacker can get on a network within the firewall boundary, they may then be able to leverage other vulnerabilities on other computers reachable on that network.
Another thing which could help is “guest” mode on a WiFi router if it has one. Use only the guest network instead of the standard main network. The guest network does not route packets between clients. This would also mean no access to printers, NAS, Chromecast, etc. over the WiFi network. But direct connection may be an option or as mentioned a wired connection.
I still have and am using a Linksys wifi router at one of my locations. Linksys isn’t even in the list.
For what it’s worth, Linksys is owned by Belkin.
Worth a lot, but I found it at linksys.com.
I hope Belkin runs it better than CISCO did – the support is some of the world’s worst – or at least it was.
Hmmm… I wonder if this affects NG routers updated with Tomato software?
CNET states that SSL can even be bipassed and that this was observed in researching this vulnerability. Is there any truth to this claim since it seems to be contradictory to what you are saying here Brian?
Citation or link? Thanks.
You can see that on the officiall “KrackAttacks” website: https://www.krackattacks.com/
They bypass https and make a downgrade to http, demonstrated here: https://www.youtube.com/watch?time_continue=3&v=Oh4WURZoR98
To be honest, this can only be used when the client connects to a missconfigured webserver and the webserver itself doesn’t use HTTP Strict Transport Security (HSTS), Perfect Forward Secrecy (PFS) and other stuff.
I think people reporting these findings need to be a little more careful in how they phrase things. Yes, it’s possible to turn around and do such a bypass attack once you’ve gotten the foothold in the middle of a wifi connection. But this does **not** mean that this KRACK exploit somehow makes the HTTPS bypass appear out of nowhere. Rather, it means nothing more than that it allows someone to get into a position to execute an attack. And then they might be able to bypass HTTPS **if** the destination server the client is connecting to is susceptible to this to begin with.
Comparison: A burglar is confronted with an exterior glass door, and an interior keypad door. The burglar uses a hammer to break the glass, then guesses the keypad PIN by some method (social engineering, fingerprints on the keys, etc.). The exploit of the keypad is not dependent on the use of the hammer. The hammer merely gave the burglar an opportunity to take advantage of some other existing weakness. If the keypad entry didn’t allow simple PINs, or were cleaned regularly, or needed a second factor like a keycard, then the use of the hammer didn’t suddenly make it susceptible.
KRACK is the hammer in this case, and the keypad analogizes to whatever server is not hardened against an HTTPS bypass.
I wish that the people discussing this (reporters mentioning the HTTPS bypass possibility, the researchers themselves who noted it) would make this clear. The lack of nuanced explanation makes it look like the HTTPS layer is irrelevant, when in fact it’s actually a very good level of protection in the face of this vulnerability.
I believe Linksys is currently owned by Belkin, before that Cisco. Who knows where to find an update, anything that old probably won’t be updated.
It’s moot to me. Every Linksys device I’ve ever bought has lost one or more ports due to nearby lighting strikes. I think they induce currents in the Ethernet wires but most devices can handle it.
I am also wondering if a VPN client on my smartphone, tablet, laptop, would protect against this on an affected Wi-Fi network. A couple of people have already mentioned VPN but no one confirmed or denied their usefulness against this.
Anyone care to comment?
Yes, a properly configured VPN should cover most things.
Caveats:
1. If there are bugs in the VPN software, using it puts you at risk, but no more than using it in any other hostile environment — VPN software needs to be resilient.
2. The VPN needs to ensure that DNS queries are tunneled (they really should be, but it’s worth pointing out that for normal users, DNS is probably the riskiest link in their normal activities). Basically the first thing almost every network based application does in order to do anything is perform a network address lookup, mapping a domain name to an IP address (the equivalent of looking up a phone number in a telephone book). An evil hotspot is in a very good position to give out fake answers to these requests, and can arrange for traffic to go elsewhere. (Technically, an access point can also just capture/replace any traffic, but it helps if it knows the intended destination.)
3. Any software that eagerly uses a network before the VPN establishes its connection is still at risk.
Beyond that, https everywhere is a good idea.
This attack makes nonce sense to me.
So does your comment to me
It’s a crypto pun. Look up nonce:
nonce
näns/
adjective
adjective: nonce
(of a word or expression) coined for or used on one occasion.
“a nonce usage”
I think Brian wasn’t yet awake when he wrote this article.
“I don’t see this becoming a major threat to most users unless and until we start seeing the availability of easy-to-use attack tools to exploit this flaw.”
The major issue is that it concerns all wifi capable devices. Also your unpatchable IoT stuff, your ‘I never receive updates after I leave the shop’ mobile phones, your car, your not-so-smart TV etc etc.
The fact that your WiFi connection isn’t secure is bad, but not too bad. You MUST rely on secure protocols (https/imaps/dnssec/…). The fact that your session(s) can be compromised via rough APs (up and running in 5 minutes), that’s the real devastating news.
Would’ve loved HSTS mentioned article. Assuming that a site I visit is either on the preloaded HSTS list ( https://www.chromium.org/hsts ) or I visited earlier and my browser still remembers the Strict-Transport-Security header, would that prevent the downgrade attack the same way the HTTPS Everywhere extension does?
It should, yes
WPA2 is 14 years old clearly. Surprised it made it this long.
really, it’s the best blog post you explain here all about business so I can understand, it very easily because it’s language is very simple. your posted blog is user-friendly
“First off, this is not an attack that can be pulled off remotely: An attacker would have to be within range of the wireless signal between your device and a nearby wireless access point.”
First of all, how is that not “remotely”? To meet that criteria, I’m thinking of every one of the thousands of public wifi access points.
“I don’t see this becoming a major threat to most users unless and until we start seeing the availability of easy-to-use attack tools to exploit this flaw. Those tools may emerge sooner rather than later..”
Second sentence kinda’ contradicts the first with the latter being inevitable.
“’There is no evidence that the vulnerability has been exploited maliciously’, reads a statement published today by a Wi-Fi industry trade group.”
Oh, my, that’s encouraging. Sounds like an Equifax statement…
The guy linked to below who established, owned and operated a Chicago ISP disagrees on the severity of this for a number of good reasons, one being millions orphaned phones which will never be updated and:
“As things stand right now commercial WiFi networks in places such as bars, restaurants and other retail environments are extraordinarily vulnerable as these tend to rely on embedded software, some of which will probably not be patched and most of these networks carry sensitive customer data including credit card swipe data. PCI requires encrypted storage and transmission but if the encryption is in fact worthless then the integrity of these networks are in big trouble. The recent proliferation of “at table” tablets for bill paying and similar is going to make this much worse than it would otherwise be.
Our failure as a nation to force chip cards across-the-board, unlike virtually every other country (chip cards have a one-time negotiated key used for transactions and thus “capturing” them is of little value) is likely going to result in severe exposures across the retail landscape for the next several years.
Oh by the way, when the WPA2 “standard” was being debated and discussed may we examine who was in the room? I have to wonder why this wasn’t caught a long time ago, given that WPA2-AES/TKIP/etc has been around now for a hell of a long time. When something this nasty is found you have to wonder if the process was corrupted either negligently or on purpose.”
https://market-ticker.org/akcs-www?post=232470
Sorry if I’m not on board with “the sky is falling” mantra of most media outlets regarding this flaw. I don’t agree there’s a contradiction in what I said. Normally, we don’t start to see mass exploitation of these bugs until relatively easy-to-use attack tools are made available to the public. By remotely, I was talking about exploitation over the Internet from afar; obviously, one would have to be within relatively close range of the target physically to exploit this.
A critique from elsewhere on the claims found at the link I posted:
Even with unpatched devices all around me, I still cannot get the network key. “All” I can do is decrypt your communication and change a few things in your packets. When you’re gone, I loose all access.
Also, this attack requires the original access point to be out of range. Tricks like having the strongest transmitter won’t work, as the client will still receive both signals and will not be able to understand what’s happening. Jamming the original isn’t going to work either, since I still need to be able to talk to it to make the attack work. Creating a second network with a different SSID “REAL free wifi” won’t work either.
And even if I manage to destroy the antenna of the original access point without destroying the AP itself, and place my device on top of it, which admittedly is still plausible though risky, I’d still have to hope no one notices my attack. Half of the patches I’ve looked at today inform the user of such attempts.
So, yes, this is BAD. But it’s not WEP-bad. The scenario pictured in your excerpt is never going to work. There isn’t a single payment provider that relies on a restaurant owners WPA settings for secure communication. They rely on technology like SSL/TLS and other encryption schemes. Yes, you’ll be able to capture an encrypted stream of data. No, you won’t be able to do a thing with it. You might as well have generated random data.
Ah, the Aruba Networks blog rant that’s been passed around a bit. I would respond with: “Kinda, sorta, maybe, assuming everything else is done correctly. Good luck with that.”
First of all, patching on PoS systems is generally somewhere between miserable and nonexistent. Those running Windows are limited to eavesdropping, where TLS is an effective additional layer. Models running Linux will be vulnerable to packet manipulation and injection until patched. These are becoming far more popular as low-cost cloud-based PoS systems proliferate. There is a great deal more potential for MITM mischief here, especially if TLS certificate checking and enforcement is imperfect ( a real sucker’s bet there).
“First of all, patching on PoS systems is generally somewhere between miserable and nonexistent.”
About that:
“There isn’t a single payment provider that relies on a restaurant owners WPA settings for secure communication. They rely on technology like SSL/TLS and other encryption schemes. Yes, you’ll be able to capture an encrypted stream of data. No, you won’t be able to do a thing with it. You might as well have generated random data.”
On an unrelated security topic in today’s news:
https://www.engadget.com/2017/10/17/dhs-federal-agencies-basic-email-security/
“After suffering several security breaches over the past few years, the US government will finally require federal agencies to implement basic email security measures. According to Reuters, Homeland Security’s deputy undersecretary for cybersecurity Jeanette Manfra has revealed at an event in New York that the agency will soon require other federal agencies to adopt DMARC and STARTTLS. DMARC helps detect and block spoofed emails to prevent impersonation of government officials. STARTTLS prevents emails from being intercepted en route to the recipient. Both are at least a decade old and have already been widely adopted by email providers like Google and Microsoft.”
Gosh, what a concept… Can we also work on prosecuting or at the very least revoking the security clearances of people who keep unencrypted TOP SECRET//SCI//TK//NOFORN (TK is Talent Keyhole – spy satellite products) on their personal home servers? Nope. All animals on Orwell’s farm are equal, but some are more equal than the others.