Wi-Fi Security Flaw Not As Bad As It’s KRACKed Up To Be
Don’t panic about the new Wi-Fi security problem that you’ve likely seen trumpeted on news sites. Yes, the KRACK exploits reveal a fundamental flaw in the process by which a Wi-Fi device — like a Mac, iPhone, Windows computer, point-of-sale terminal, or smart fridge — connects securely to a Wi-Fi access point. You shouldn’t underestimate how significant that is (it’s huge), but also don’t overestimate how likely it is to affect you (very unlikely).
The KRACK exploits involve how Wi-Fi Protected Access version 2, known as WPA2, lets a client device negotiate encryption keys and cryptographic elements with a base station, while keeping those elements secret from any parties trying to intercept communications, masquerade as the client, or decipher data later.
Every operating system and every device that can initiate a Wi-Fi network connection and that supports WPA2 encryption is vulnerable to at least one of the lines of attack revealed, and the researcher who discovered them has already found more attacks that he hasn’t yet released. Wi-Fi access points aren’t directly affected.
However, just because every device in the world could have its traffic sniffed doesn’t mean that every device will. Remember that Wi-Fi is local area networking: attackers must be within range of their targets.
The KRACK vulnerabilities can be easily patched in hardware that can be updated. Apple told me that all four of its operating systems already have patches in place in the current beta releases, which will roll out in the near future for macOS, iOS, watchOS, and tvOS. Other operating systems and older Apple hardware will not be so lucky. Fortunately, many experts see ways for base stations to be updated too, but with the same proviso: many base stations lack an automatic update process, meaning they’ll remain unable to prevent unpatched clients from becoming targets.
A Quick Look at KRACK — On 16 October 2017, security researcher Mathy Vanhoef presented proofs-of-concept of several different kinds of attacks in a paper he wrote months ago and only now released in advance of an upcoming presentation. He dubbed the series of attacks “KRACKs” (Key Reinstallation AttaCKs), as all major vulnerabilities now need clever names. He disclosed the vulnerabilities carefully, and US-CERT ultimately took over disseminating the information so many companies would have patches ready or nearly so by the
disclosure date. (Details were accidentally disclosed earlier than intended, as Ars Technica explained.)
The various WPA2 negotiations rely on what’s called a “four-way handshake” and take into account a client failing to receive the key (or failing to acknowledge receipt) during the stage in which the key is delivered. This might be due to interference or an operating system glitch or another anomaly — remember that WPA2 was developed in 2004, when everything, especially wireless devices, was slower and less reliable.
As a result, the Wi-Fi access point can retransmit the key when it believes the client hasn’t received it, and the client device then installs it and resets a counter that’s used to create a stream of encrypted information that only it and certain other parties like the access point can decipher.
That’s where the flaw lies: an attacker can record and replay the transmission of the key, and the client dutifully resets the counter. With that information in hand, a malicious party knowing the contents of certain data packets or guessing they contain plain text (even in an email or Web page) can then decrypt other packets without obtaining the encryption key. An attacker can’t join the Wi-Fi network, but can still extract information from it!
Not every operating system suffers from this problem for every kind of negotiation. Windows and iOS, for instance, weren’t vulnerable to several types of attack, but were to others. As long as one sort of handshake can have a KRACK used against it, data in transit is vulnerable. Forged data could also be inserted into a network, which could allow ransomware and other malware to be delivered to vulnerable devices.
More terrifying than the flaw itself is the fact that it has existed since WPA2 appeared in 2004, and that it was found by a single person — a graduate student, not a team of veteran security researchers at an anti-intrusion software company — following a slender thread of an idea of something to test after writing a paper on a related topic. (Vanhoef credits his research supervisor on the paper for his guidance.)
So far, there’s no evidence of KRACKs being used in the wild. However, the ease with which Vanhoef found it means that it’s likely that government intelligence agencies have already found and have exploited the flaw in targeted surveillance, because it’s exactly the kind of thing that they would be looking for.
Although all this sounds bad, Vanhoef’s disclosure of the KRACKs is actually good news: a researcher dedicated to a responsible disclosure ensured that companies had time to patch before cracking tools were updated. Plus, if bad actors have been exploiting these vulnerabilities, their windows of opportunity will be closing, as I explain next.
Everything That Can Be Patched Will Be — Apple already has patches in its update stream to fix the various KRACKs in all its operating systems (see “Apple Has Already Patched the WPA2 KRACK Weakness in OS Betas,” 16 October 2017). (Apple said nothing about AirPort base stations, but we can always hope.) On 10 October 2017, Microsoft shipped updates to Windows 7 and later and Server 2012 and later. Google has more vaguely promised Android updates in the coming weeks, according to the Verge, but individual Android hardware vendors will have their own schedules. Other operating system and hardware makers have updates shipping now or will release them soon. The Wi-Fi Alliance, which certifies gear that bears the Wi-Fi label, will also update its testing. These responses will rapidly close the largest and most lucrative vectors of attack, those against people with recent hardware, especially mobile devices.
The biggest problem, as with many security attacks, come from three related areas: Google’s Android OS, Linux, and Internet of Things (IoT) devices, which are often powered by a form of Linux. In this case, it’s also because there’s a serious flaw in a commonly used software module that handles the WPA2 negotiation. That flaw is bad: the encryption key in hardware running this module resets to all zeroes when an attacker attempts to replay the captured encryption key — that’s right: all zeroes! Because the attacker now knows that key, they can immediately decrypt all data sent by the client. With other operating systems, an intruder has to work harder and capture a lot of data and run more KRACK attacks before deciphering some
of the communication. This glaring bug isn’t old — it was introduced in a relatively recent update that’s incorporated into Android 6.0 and other newer hardware, and affects about 50 percent of all Android devices in use.
Android has long suffered from an update abandonment problem, with Google and its partners quickly dropping support for older releases. A lot of older Android hardware can’t be upgraded to even the next major release of the system — or to any incremental improvement. This abandonment problem affects hundreds of millions of older Android devices that can never receive security updates. Review MasterKey, Stagefright, and Broadpwn for three examples. (Apple typically supports Macs for at least 7 years
and sometimes releases very late-in-cycle security updates for even older Macs. With iOS, it’s closer to 5 years.)
Even worse are Internet of Things devices that use embedded operating systems with which you never interact directly, many of which can’t be updated at all. Even when products can be updated, dodgy manufacturers and cut-rate prices often result in the abandonment of support for a particular model months after it appears. Updates are often difficult to install and manufacturers don’t notify customers (or have any way to do so), making it unlikely that an average user will learn of a security fix or, discovering it, be able to install it. KRACK will become another tool in an attacker’s kit for recruiting devices like DVRs and nursery webcams into botnet armies.
Conversations with a few security experts made it clear that while the Wi-Fi access point side of the equation isn’t at fault for these negotiation flaws, even consumer-focused access points could be updated to block, resist, or report KRACKs. (There’s one exception: corporate-scale access points that support “fast handoff” act a little bit like a client in that mode, and routers with that feature have to be patched, too.)
At the enterprise level, vendors are already on top of the problem. In addition, corporate-scale intrusion-detection systems have long monitored for the unauthorized or fake access points that KRACKs require. Cisco, for instance, has provided a short primer to customers to make sure they have enabled the right options to detect KRACK-style intruders.
Public Wi-Fi networks are unlikely to be affected by the KRACK attacks. Most rely on a portal page to control access to an unsecured network, rather than WPA2. If they do employ WPA2 for access, it’s typically to restrict usage to customers, as it doesn’t provide real security from other users on the same network. In either case, you should always treat public hotspots as untrustworthy.
What You Can Do — You can and should take steps to protect yourself against KRACKs. Here’s how:
- Install KRACK-related updates as soon as they are available for any Wi-Fi-enabled device you have.
- Check your Wi-Fi base stations’ configuration settings and make sure you aren’t using the mixed WPA/WPA2 Personal mode in an Apple base station or TKIP encryption or TKIP/AES on other makers’ hardware. You’ll typically find these settings under Wireless or Wireless Security. These modes are more easily broken in general and offer more risk with KRACKs, too. Instead, make sure to use only WPA2 Personal (or WPA2 Enterprise where available) and AES-CCMP, sometimes listed just as AES. (You can’t set WPA2 security on a phone or computer, only at the router.)
-
Check your email client and make sure that you’re using an encrypted connection to your mail host and that any advanced option to allow backing down to an unencrypted connection is disabled.
-
For macOS Web browsers other than Safari, install HTTPS Everywhere from EFF. (Apple doesn’t allow https redirection at the right stage to prevent an insecure connection at the start of a Web session.)
-
Use a VPN when working on any untrusted network, which could include your home network if updates haven’t been released for all your hardware devices. While a VPN doesn’t prevent KRACKs, it does ensure that the data encrypted by the VPN client and server is protected from someone intercepting traffic.
KRACKs won’t disappear. Because hundreds of millions of unpatched devices will remain on the Internet, these attacks will surely be added to research-oriented hacking software and black-hat cracking tools, and will be used by governments and criminal organizations to target individuals who use an old Android phone or an outdated webcam.
But the odds are against KRACKs having a significant impact on overall Internet security.
IMHO this article neglects to point out that Apple (as many others unfortunately) tends to tie security updates to feature updates. Basically, if you want to stay safe, you have to update to their latest or 2nd-latest OS release. If OTOH you do not want those releases (for example because they're full of fluff or they lack stability) you're basically out of luck. It's a nasty little trick Apple plays to force people to update to their latest and greatest and to make support easier and cheaper.
What I would like to see Apple do is release patches for older OS X or iOS versions. Especially those still used by lots of people because they were the last to run well on popular hardware.
No user should be forced to install fluff or sacrifice performance, just because they want to make sure their system stays safe. It's time to unbundle security updates from other updates.
That’s not quite right: a few cavils.
I’m talking here about the yield (how many devices will be affected) and the things you can do personally.
I do dislike that Apple locks down older versions of iOS so that they can’t be updated with security improvements. Every version of iOS outstanding has unaddressed problems, some major. Apple is counting on herd immunity of sorts: with most devices that can be updated taking the latest iOS release, the potential pool of targets becomes so slow that there’s typical no value in targeting them. No disagreement there.
However, with macOS, Apple regularly releases security updates going back two and sometimes three releases, which in turn can cover Macs that are over 10 years old. When you say "lots of people," that’s not supported by usage statistics. It’s not thousands, but it’s also not millions upon millions.
"No user should be forced…" Apple acts in its own best interest, despite its customer focus, and making that statement won’t change the company. It’s a reality you have to accept: unless there’s a compelling business case (or regulatory requirement), Apple will continue to follow its policies, and you should consider purchases based on whether that’s ok. Some people have switched to Android as a result—it’s not that Android phone makers are better about updates, but some models can be updated as long as you’re willing to do the work, with older versions of Android patched with security and other updates.
"It's a nasty little trick Apple plays to force people to update to their latest and greatest and to make support easier and cheaper.": Apple is a business. I don't think it's a trick at all. It's part of a long-running strategy, which you as a consumer can mark your disapproval by not buying its products!
Take iOS. Apple is obsessed with comparisons to Android showing how most of their users are always on the latest iOS version. So after buggy releases or releases that offered mainly fluff but no real gain, how do they make sure people still upgrade to the latest iOS? Easy peasy. Tell them it's either that or your device becomes vulnerable to all kinds of nefarious business.
IMHO that's a sleazy trick. If Apple wants people to upgrade they should entice them with great features or better performance. But using security as a gun to their heads to force them to upgrade is just nasty. And yes, people do notice that. And they do indeed feel less inclined to buy Apple because of sleazebag tactics like that.
You seriously believe Apple has made a business decision not to release security updates for older versions of iOS, for the reason it will encourage people to upgrade?
Wow.
I won't do business with companies I think are immoral — Facebook, Uber… you should consider the same.
I don’t understand how setting base stations to use only WPA2 Personal encryption protects against this vulnerability, after noting KRACK exploits a flaw in the WPA2 protocol.
Great question, and one that is fairly technically so I didn’t get into it. The KRACKs don’t allow straightforward extraction of data from a client (except for Android/Linux/IoT ones with the all-zero encryption key flaw).
Instead, the exploits allow replaying cryptographic information that’s already been used. By replaying data over and over with different encrypted information, including some that an attacker can guess (network messages, etc.), an attacker can statistically and automatically recover the underlying information. (And only when it’s not wrapped in transport encryption, like https/TLS.)
However, that’s true only with AES-CCMP, the WPA2 native encryption protocol. If you use TKIP, a transition standard (used with WPA), meant to fix problems in the very broken original WEP encryption used with Wi-Fi, a lot more information can be extracted a lot more easily.
So while AES-CCMP or WPA2-only modes don't protect you *generally*, they do provide some additional protection that's worthwhile.
"And only when it’s not wrapped in transport encryption, like https/TLS."
Does this, and the recommendation for HTTPS Everywhere, mean that information in a web page using HTTPS is secure, even if an attacker has penetrated the Wi-Fi network?
Yes, mostly. KRACKs only decrypt Wi-Fi traffic, and then only when sufficient known traffic can be intercepted to help crack the unknown prats. It doesn't have any component that breaks into VPNs, end-to-end encryption, https or the like—that's a different layer. And you're just as vulnerable to anything that could attempt to crack that kind of traffic when you're at a public hotspot network, so it's not a set of unknown risks. When vulnerabilities exist that can affect open networks, they're patched.
The reason I don't emphasize this above is that https security relies on a dance between the version of browser someone is using, the operating system integrity the browser runs on, the server configuration on the remote end, and the certificate management on the remote end.
Servers can be well configured with browsers of the last several years so that there's no way for a man-in-the-middle to bump a browser trying to make an https connection to use a non-https one. On Web pages that have mixed http/https content, this is still possible in some cases. And with certain outdated configurations and components, an attacker might be able to leverage KRACKs to then deploy an MitM exploit.
However, for most users and browsers with any well-configured site (which includes TidBITS! Check us on Qualys' SSL configuration checker), it should be effectively impossible today to break into the connection and decipher traffic.
In this day and age, tech companies should be required to provide security updates for 10 years after a product is discontinued both hardware and software. In cases where the hardware is superseded but can still run newer software, then the 10 year rule would go into effect based on the last year the software was available for that hardware. Example, a Mid-2008 iMac that was discontinued in 2008 can still run MacOS El Capitan that was discontinued in September 2016 so Security Updates would be required through September 2026.
There’s no regulatory structure in the U.S. to make that happen, and there’s no will to change that. And it’s not feasible to enforce over that period of time. I agree with the general gist of it, but not the 10-year period, as technology simply changes too much. Five years seems reasonable, and 7 isn’t pushing it.
I'm not sure about 10 years, but I agree entirely with the sentiment. I'd rather have 10 years enforced than nothing like we have now.
It would help if you said where to find the the WPA, etc... on my IMac! I am running Maverick. It is not in Sysytem Preferences Network/ Internet accounts/ Security & Privacy. Not in Airport utility. So where do I find it?
On my El Cap system I can open AirPort Utility, select my AirPort Extreme, click Edit, and then in the Wireless tab there's a pull-down menu labeled Wireless Security.
It's illustrated in the article, but not explained as well as I could. Thanks for the head’s up!
Hi Glenn -
I use Apple-Mail as my client. How do I ensure I'm using encryption with the host? (per your recommendation in the article). I've looked on Apple-Mail, but the solution does not seem obvious to me. Thanks.
In my Mail preferences, when I select an account and hit the Advanced tab I can make sure SSL is checked which forces IMAP (or POP) to use a secure connection to communicate with the mail server for incoming mail.
Likewise, in the Account Information tab there is a Outgoing Mail Server pull-down menu and when I select Edit... and hit the Advanced tab, I can again ensure SSL is selected for communication with the outgoing mail server.
Thanks, Simon! If you don't see SSL selected or indicated, visit your mail host and find the instructions for setting up a secure connection. If it's iCloud, Apple automatically makes the most secure connection. if it's another provider, you may have to read their help instructions (it often gets configured securely, however).
Thanks to both Simon and Glenn, for the responses. This information helps. I did check and I do have encryption between the mail client and server.
--Phil
Side note: I am running Sierra macOS 10.12.6, and its accompanying version of Apple-Mail. I believe some of the stuff mentioned above regarding settings from within Preferences (for Mail) have been abstracted out.
However, if you go to https://www.apple.com/support/mail-settings-lookup/, you can simply find out what your settings are. If you need to adjust settings further, it appears you need to go to the server.
Every time I try to configure my AT&T router, Airport Utility runs for a while, telling me it's "Reading settings on '[address]'"... and then gives a message: "An error occurred while reading the configuration." This has happened multiple times, so I can't get anywhere. Any thoughts?