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.
Krebs – as several others have mentioned, Thank You. I appreciate your calm and reasoning approach to this and other security matters. When I saw your site in the results, it was mere instinct, like muscle reflex, to click on your article. Even my fingers know that I gotta see what you have to say. So keep up the great work, man, the Internet needs sanity such as you provide.
FYI the October Security Only Windows Update fixes this flaw for Windows 7/8_1/10…stay calm and patch often.
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080
Read the fine print. MS only patched one CVE and you still need to update WiFi drivers.
you are correct, but the Win patches are available now, not all wlan drivers will be updated as fast if at all…
intel has been on the ball but not all vendors have been.
Damn. The biggest wifi security hole this side of the 10’s and wifi vendors are slacking. Where are the patched wireless drivers for Atheros, Broadcom, Mediatek, Realtek?
Even EOL Intel wifi cards are left out in the cold.
Understand it all sounds very noble to keep the findings under wraps for a period to give hardware and software experts to come up with remedies but has anyone seen this actually work?
The sky isn’t falling, but this is still very, very bad and I think most people are missing some of the implications.
At the risk of sounding overly pedantic, the notion being pushed that “an attacker must be within Wi-Fi range to exploit this vulnerability” is incorrect. That the attacker must control a device with Wi-Fi capabilities within range is more correct. Now kick back and consider how many pwn3d devices there are out there. Then consider that unpatched Linux devices are susceptible to packet forgery (manipulation, injection, etc.), even if aes-ccmp is being used. Then consider that most IoT devices run Linux and will never be patched. Such devices include WiFi-enabled:
* Anything running Android that’s more than a year old, and at least half of everything else running Android
* Printers and copiers
* Handheld scanners (warehouse / retail environments)
* Point-of-Sale systems (very common now in small businesses)
* VoIP phones
* Streaming media players (Amazon Fire, Roku, Google ChromeCast, etc.)
* Gaming consoles
* Smart home devices (thermostats, lighting, refrigerators, doorbells, etc.)
* Smart televisions
* eBooks
* Security cameras
* Medical devices
* Any industrial control equipment running Wi-Fi – we can barely get them to stop using Telnet, for crying out loud.
Controlling a Wi-Fi-enabled device within range of one of these devices is almost as good as having a wired connection into their network. This is potentially the ultimate lateral attack platform – you can not only attack the home or office in question, but other homes or offices within KRACK attack range. Considering the Wi-Fi density in many urban and suburban areas, there are a lot of potential avenues here.
And lets not forget about the WiFi cars now have 🙂
Yeah.
But there’s that proximity problem that’s pretty easy to deal with. Wifi has a limited range, so any data thief will need to be nearby. Even then, it’s mostly home users at risk.
Most critical networking is set up for Ethernet, because everyone’s always felt that wifi was never secure and, until recently, wifi was slow.
Wifi is fine for guests, visitors, and some employee work, but most businesses keep the wifi separate from the wired part of the business network.
Ironically for someone using the handle “Reader,” I think you somehow missed reading these sentences:
At the risk of sounding overly pedantic, the notion being pushed that “an attacker must be within Wi-Fi range to exploit this vulnerability” is incorrect. That the attacker must control a device with Wi-Fi capabilities within range is more correct. Now kick back and consider how many pwn3d devices there are out there.
Now consider that a properly secured network will not be particularly vulnerable to KRACK beyond the ability to replay some packets. Virtually nobody implements 802.11r or GCMP, TKIP was phased out years ago, all they have left are the limited exploit of WPA2/AES.
The real vulnerability in KRACK comes from phone vendors who have so far flat-out refused to push security or OS updates to devices they sold and even are currently selling. I smell a class action suit.
Have you ever paid with a Debit card at the table in a restaurant? did you see a network cable attached to the POS device they bring?
I’ve seen those things at a mobile carrier’s retail store and at the Apple Store and refused to use them. I never trust wifi or mobile data for secure transactions. I tell retailers to look up my info over a wired connections and only do card transactions using dedicated wired machines.
Why would anyone want their personal or financial stuff broadcast through the sir? It just astounds me, the carelessness of it.
Continued from comment above, https://krebsonsecurity.com/2017/10/what-you-should-know-about-the-krack-wifi-security-weakness/comment-page-2/#comment-443743
……
So, that basically just leaves home users of wifi. What saves them from a headache is that a data thief will have to be nearby and that’s very noticeable. And home users can just shut off SSID broadcasting of their private wifi.
I hate to be that guy, but….
https://www.youtube.com/watch?v=mPU4Ci6QcF8
Turning off SSID broadcasts creates its own privacy problems and has been considered a poor practice for most situations (especially home users) for some time now. It’s now only recommended in certain situations where the Wi-Fi clients do not ever leave the site.
You’re giving me a case of the sads. 🙁
Bingo. We have years-old POS terminals (with credit card transactions!) and barcode scanners running WinCE for vital business purposes in a publicly accessible facility. They will never be patched by either the hardware vendor or Microsoft.
The problem is that replacing all of the hardware is cost prohibitive, so I’ll just try not to think about this too much when trying to fall asleep.
“The problem is that replacing all of the hardware is cost prohibitive, so I’ll just try not to think about this too much when trying to fall asleep.”
Think again next time you order proprietary hardware. Where there are OpenHardware alternatives, the security advantage of those devices must be taken into account. Linux/BSD patches are usually available within a few days after publication of a CVE, often, patches are available before the news gets out.
Now, you think of the advantage of being able to patch your device yourself! No vendor out-of-business or vendor no longer cares for that “old” device stories for you anymore ;-).
“Think again next time you order proprietary hardware.”
You won’t have to tell that to any regular reader here. The problem is, most of the regular readers here don’t have final say in the ordering process. The beancounters do and typically they don’t care about securit much.
One thing that makes me VERY unhappy is the hardware that comes from the ISPs. I have a Frontier DSL gateway (the device is less than a year old) & have asked several times for a patch. Frontier has very courteous customer service but I suspect nobody I have spoken with understands anything that is not on their call script.
While I live in a rural area, I can “see” other SSIDs on my PCs so I expect the houses having those devices can see mine as well.
Thanks, Brian. I spent some time this morning checking with my router vendor, etc., on this problem and yours was the first site that mentioned that using https:// was still safe.
I called D-Link about their DWA-182 wireless adapter. Their rep said that only routers need to be patched and that wireless adapters are not vulnerable. Is that correct?
Not to speak for Brian, but: It’s not really correct to think that a single wireless adapter is or isn’t vulnerable. Rather, the vulnerability is centered in the WPA2 standard that an operating system uses. So, it’s about whether your Windows or Mac OS or Linux build is properly updated rather than what wireless adapter you use.
So in short: D-Link is correct, a single adapter is *not* what’s vulnerable to the KRACK vulnerability. It’s the operating system that is.
(Ps. Routers run operating systems too. That’s why they have to be patched.)
The attack described operates against WPA2 clients, not the access points as such. In addition to the computers connecting to access points that would include range extenders or routers that connect to other access points.
Every device that connects to a wireless access point should be patched, but most wireless routers used only as access points probably do not – for this set of vulnerabilities.
Operating system patches being issued generally are backward compatible; they will work with either patched or unpatched device access points. That is a very good thing, because past experience suggests that manufacturers of consumer grade wireless routers and access points more than a year or two old are quite unlikely to issue patches.
Those who use wireless routers to connect to other wireless routers may wish to consider replacement firmware such as dd-wrt or OpenWRT, which will be patched. That is not for everyone, however, since those do not support all routers, have limited and somewhat obscure documentation, and may not perform as well as factory firmware. In addition, if applied incorrectly they may render the route inoperable, although that usually is recoverable.
It’s exactly the opposite of what they told you. Most APs are NOT affected (unless they are being used as network extenders).
Is this a correct summary of this issue?
Very much like a a copy-cat rouge open (non wep/wpa/wpa2) access point could be set up to trick wireless clients, and become a man-in-the-middle device, this attack, because of way WPA/WPA2 protocol lets nonces get reset to 0 with the same key, they can therefore can be predicted, and a WPA/WPA2 device can essentially become a MITM.
And in the same way a public WAP can be used more securely, a VPN and HTTPS (assuming it’s implemented correctly on the server), and SSH or other tunneling encryption standards, can be relied upon to mitigate this attack.
LOL BC you said: ‘protected end-to-end with Secure Sockets Layer (SSL) encryption’. Real oxymoron in play here because SSL died, any use of it today is considered vulnerable. TLS v1.2 sure (*at least for the time being). Need a new version or improved protocol already, else we may have to go back to using…. wait for it…..
Sneaker_net!
Lots of people are trumpeting what the author has said, but I haven’t seen anyone independently verify the claims. While I do believe the linux-specific bug is probably very bad (where TK is zero’d out)… I’m suspect about the impact of claims against all APs and all other clients.
No slight against Brian, but I think the tech press is reticent to downplay it.
The CERT writeup of this vulnerability (http://www.kb.cert.org/vuls/id/228519) does cite one researcher who’s apparently unassociated with the original researchers. The writeup notes that this person – John A. Van Boxtel – had found that the flaw does exist in a Linux component (wpa_supplicant v2.6). So on the one hand, sure, that’s not really replication of the original authors’ work; it’s extending it. But on the other, that’s another pair of eyes on it who’s managed to use it to find problems elsewhere. Generally in research that won’t happen much if the original research is shaky to begin with.
Also: Microsoft, Aruba, Netgear, the developers behind DD-WRT, etc. have looked at the research and, while it’s unknown whether they replicated it, they each independently believed it enough to put out their own fixes for their own products.
Furthermore, Vanhoef has been completely transparent on what he did, and how to replay the attack. On top of that, he and fellow researcher Frank Piessens are presenting a whitepaper to a security conference in Dallas later this month. That’ll be an awful lot of eyes on the original work.
My point is that it’s not always necessary to outright replicate a finding for it to have validity. Individual manufacturers may want to at least investigate their code and see if it’s susceptible to this sort of attack, and some writers/bloggers/tech pundits may want to try it out for themselves just to see how it works. But there is sufficient detail out there to make developers, security professionals, and industry engineers take it seriously, even if they don’t replay it step by step. The fact we haven’t seen replication attempts being published doesn’t mean the claim is unproven.
Will this Microsoft update solve the problem??
Microsoft shuts down Krack with sneaky Windows update
The company last week quietly patched vulnerabilities in the WPA2 protocol used to secure wireless networks, but did not reveal the fix until today.
By Gregg Keizer
Senior Reporter, Computerworld |
Oct 16, 2017 1:44 PM PT
Microsoft today revealed that it quietly patched Windows last week against vulnerabilities in the Wi-Fi Protected Access II (WPA2) protocol used to secure wireless networks.
Details of the security update were only published Monday to Microsoft’s Security Update Guide, the catalog-like portal that earlier this year replaced the decades-old practice of delivering explanatory bulletins.
All supported versions of Windows received the update, according to the catalog listing, including Windows 7, Windows 8.1, Windows 10, Windows Server 2008, Windows Server 2012 and Windows Server 2016.
The vulnerabilities were revealed today by Mathy Vanhoef, a researcher at Katholieke Universiteit Leuven in Belgium. On a website that went live Monday, Vanhoef said that weaknesses in WPA2 allowed criminals to read information transmitted over a Wi-Fi network thought to be encrypted by the protocol.
“Attackers can use this novel attack technique to read information that was previously assumed to be safely encrypted,” Vanhoef wrote on the site. “This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on.”
Vanhoef dubbed the attack “Krack,” for “Key Reinstallation Attacks.”
Microsoft included the anti-Krack update in its October security slate released on Oct. 10, but the company held the news until today because information about Krack was scheduled to be issued this morning by Vanhoef, numerous security organizations and multiple vendors. “In partnership with the International Consortium for Advancement of Cybersecurity on the Internet (ICASI), Microsoft participated in a multi-vendor coordinated disclosure to acknowledge and describe several Wi-Fi Protected Access (WPA) vulnerabilities,” Microsoft said in its update description.
The Windows security updates patched the client and server flavors of Microsoft’s OS, but even then, users may be at risk, the firm warned. “When affected Windows-based systems enter a connected standby mode in low-power situations, the vulnerable functionality may be offloaded to installed Wi-Fi hardware,” Microsoft said. “To fully address potential vulnerabilities, you are also encouraged to contact your Wi-Fi hardware vendor to obtain updated device drivers.”
I’m haveing trouble finding out whether using EAP-TLS mitigates the risk. I see that you state that using up to date TLS keeps your data encrypted which which separate to the encryption provided by WPA2. I’m presuming that this also applies to EAP-TLS?
It depends on the circumstances. If it’s a situation where KRACK only allows eavesdropping (example: unpatched Windows devices) then it should be effective. It’s more complicated in circumstances where packets can be modified or injected (unpatched Linux or Android devices)- at that point an attacker can play games with DNS, use tools like SSLstrip, mess around with systems that don’t do correct certificate checking (many of these), etc.
The attack is on the key exchange between the router and the client, and forces reuse of key material from an already authenticated session. This means that using EAP for authentication does not protect you, because the client is already authenticated. Likewise, the reused key material would be for the TLS stream. The short answer is no, EAP-TLS is not protection from the attack.
McAfee is blocking the https://www.krackattacks.com/ website. It’s triggering multiple reasons.
URL Categories: Potential Criminal Activities, Potential Hacking/Computer Crime, Information Security
Virus Name: BehavesLike.HTML.BadDownload.nq McAfee Threat Center (83%)
MD5: 97d8cabc06c122e337c0a2f85fd0d938
Pretty sure it’s bogus, but thought I’d report it.
They fixed it.
Status:Closed
URL: https://www.krackattacks.com/
Initial categories: Potential Criminal Activities,Potential Hacking/Computer Crime,Information Security Post-review categories: Information Security Web Reputation: Minimal Risk Please allow the Web Reputation some time to update.
In some cases, the Web Reputation shown at the time of the ticket closure may not reflect the updated Web Reputation.
Updates at times may take longer to complete. Please consult TrustedSource.org to verify the published Web Reputation for any given URL or IP address.
List Number Closed: 70586
I wonder if anyone can answer these questions:
– Do both the client and wireless access points need to be patched or is patching one enough.
– Can the attacker launch further attacks, or only to eavesdrop on traffic.?
This is a client vulnerability. Patch *all* of your wireless clients. Patch any access points that can also act like clients and connect to other access points (uncommon).
Per the researcher’s report at https://www.krackattacks.com:
“However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available. Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!”
Everything needs to be patched if a patch is available. That’s the reason a patch was made, to patch a known vulnerability. You don’t match and you will get AIDS.
Of course an attacker will attack the weakest link, IOT. Your smart fridge is probably looking mighty tempting to your sneaky neighbor. I actually had multiple certificate security errors pop-up on my smart TV last night and it makes me wonder who or what was trying to peep my actions.
And then I find this article.
Its times like these that I’m glad all my “smart” devices are driven by “dumb” PCs. Not the least because they’re attached via Ethernet…
I completely agree with you. if you take necessary precautions, this attack is not so scary as the media tries to portray. Please check our digest if you want to have a quick snippet on it: https://medium.com/@digestize
Just trying to understand the risk behind : Is only the connection between the endpoint and the access point at risk or does the attacker have access to the corporate network (intranet, etc…) if he can hack one device connected to the corporate network ?
Asking this cause I ready somewhere that injecting traffic might be possible … hence if I’m in a man in the middle position, nothing prevents me to send forged packets on the corporate network and “browse” it to my wishes right ?
I’m wondering something similar. What about workplaces that provide dockable laptops to employees? The laptops are attached to corporate networks while docked but utilize WiFi elsewhere. Any potential problem there?
Injection is only possible in limited poorly-secured circumstances that are easily fixed by disabling the poor security.
Using TKIP? Switch to AES/CCMP.
Using GCMP? Switch to AES/CCMP.
Using 802.11r? Silly boy, no clients implement 802.11r, disable it.
Voila, no possibility of traffic injection. All they can do now is depend on client bugs to replay traffic that’s in a state that’s more easy for them to decrypt. Assuming the underlying traffic isn’t encrypted. In which case they get nothing.
If what you say is true then this definitely isn’t as big a deal as they make it out to be.
I am not really that concerned if the extent of reasonable intrusion to expect is limited to the neighbor’s kid listening in on the communication between say my wireless thermostat and my router.
For “important” devices I expect vendors to issue patches soon.
I wonder if WPA (not just WPA2) is vulnerable to KRACK
Who cares if it’s got a whole host of other vulnerabilities.
When traffic gets passed it’s visible to everyone in range that its using WPA instead of WPA2, at which point they can just use the boatload of WPA-based exploits instead.
A large portion of WiFi data is sent in-the-clear without any encryption at all. Using this data you can determine which clients are which and what types of encryption they’re using.
No one has mentioned the fact that RF doesn’t stop at your building perimeter. So saying this is a “local” attack glosses over the fact that a wireless signal can be amplified using a directional antennae for anywhere from 328 feet (for the CARD KING KW-3016N) to several miles. If it even works from half a kilometer, the risk exposure in a metropolitan environment is astronomical.
BDJ,
You are correct, but not only because of high dB gain/amplification antennas. Yes, some proximity to the target device is required; but by all normally accepted terminology this should be referred to as a Remote exploit, not a “Local” exploit. Physical access is not required, nor is a local/authorized user account required to exploit the vulnerability. Almost all correctly categorized “Local” exploits are Priveledge Escalations.
I realize this is basically semantics; but I do agree with your sentiment that technical writing, and also reporting should be more accurate than what we’ll get from CNN,etc.
It was my understanding that WPA2 Entierprise (RADIUS) authenticated networks are not affected. Is that not the case?
If WPA2 Enterprise uses the 4-way handshake (which it apparently does) then it’s vulnerable.
Damn. Key Reinstallation Attacks Breaking WPA2 by forcing nonce reuse *_* Mathy Vanhoef of imec-DistriNet is a genius.
Thanks for posting this information. With that being said, Comcast seems to know nothing about their own equipment, and cannot tell me what chipset is in their cable modem.
After the so-called “Tech” gave me a model number (Cisco DPV3939B), no such item is on their website.
I guess the best thing to do is just shut off the wireless part and ask Comcast for a partial refund.
I wish myself luck.
William,
It should be DPC3939, not DPVx.
https://wikidevi.com/wiki/Cisco_DPC3939
Maybe the B is different, but it’s probably the Atheros AR9381 as well.
Regarding Comcast: Our experiences at a small clinic in FL with Comcast for Business
1) Comcast does not provide nor permit user install-able firmware upgrades.
2) Previously, when we asked for a newer router, we were told that we could make that request but whatever was on hand {probably the same model} is what we would get. There would also be a swap charge for a user requested swap.
3) Comcast firmly controls and force installs firmware upgrades on their schedule when they deem appropriate.
In other words, don’t expect too much from Comcast.
If I’m reading the article and comments right, routers do NOT need to updated. Only devices that connect to wi-fi do. Comcast need not do anything for this vulnerability. Please correct me if you think I’m wrong.
Speaking of https – Brian you need to force https as a user can access your site under http only.
A follow-up on vendor responses would be appreciated. In one case, Netgear has been posting things on their community forum that would indicate that they are only focusing their efforts on wifi routers that have bridging capability (see https://community.netgear.com/t5/Nighthawk-WiFi-Routers/R8000-still-vulnerable-to-KRACK-WPA2-attack/td-p/1395876).
While many owners of end-of-life devices may be disappointed that older devices are not getting updated firmware, I would expect that most customers would expect that supported devices would receive a timely update.
WiFi password cracking is one kind of Bruteforce attack.If victim password has in my password file then it will be worked otherwise not.
If fixing the access point still leaves it vulnerable to attack if I client isn’t patched and can be attacked for sure a potential hacker is not going to update his phone, laptop, access point, etc. So, if patching the access points in your network don’t protect you then this is still a wide open problem.
I’m also having problems with the statement that using a VPN will protect you. The initial security and handshake is with the access point and is using WPA2 and making a connection does not involve the VPN server until you are on the network and reaching back to the VPN server to authenticate. It sounds like this attack happens again at the access point so the VPN will not protect you. An attacker would be on the network and could spawn attacks against other IP based devices and PC’s.
Can anyone shed more light on this after the storm of conflicting comments. Norton of course sent out warning emails linking all of their customers to an additional service they could buy to protect against KRACK.
What precautions we need to take prevent attack?
It all sound like a lot of paranoia to me, has this been proved to work?
Understand it all sounds very noble to keep the findings under wraps for a period to give hardware and software experts to come up with remedies but has anyone seen this actually work?
Video impressive but many tricks can be used with digital media.
Geffers
Yes, it’s been proved to work. I’ve read the paper they published and it’s very clear that both in theory and in practice, this can be pulled off with much less work than trying to break the encryption of the handshake itself. It’s a packet replay attack, basically.
And you *don’t* need to physically be in range. All you need is a compromised device with wi-fi capability that is in range, so this attack can be perpetrated from anywhere in the world. There are a LOT of vulnerable devices with wi-fi capabilities.
Tarek,
Your post is incorrect. This cannot be exploited from “anywhere in the world”. It requires the same “Proximity” as almost every other Wifi based attack vector like any other Wifi MITM Attack. If the antenna/interface cannot receive and transmit to and from the target, it will not function. This vulnerability does not exist “over a pipe”
It’s my understanding that only these dual band Intel network cards are affected? or are all wifi cards? I have a Toshiba laptop that only allows for 2.4 connections.
-Intel® Dual Band Wireless-AC 3160
-Intel® Dual Band Wireless-AC 3165
-Intel® Dual Band Wireless-AC 3168
-Intel® Dual Band Wireless-AC 7260
-Intel® Dual Band Wireless-AC 7265
-Intel® Dual Band Wireless-AC 8260/8265/9260
My first comment was deleted for some reason but here it is again.
It’s my understanding from what Intel says on their site that only these specific dual band network cards are affected?
-Intel® Dual Band Wireless-AC 8260/8265/9260
-Intel® Dual Band Wireless-AC 7265
-Intel® Dual Band Wireless-AC 7260
-Intel® Dual Band Wireless-AC 3168
-Intel® Dual Band Wireless-AC 3165
-Intel® Dual Band Wireless-AC 3160
Along with the Intel Atom® Processor C3200 Series for Yocto Project BSP and Intel Active Management Technology.
I’ve read the comment about iOS products being not/little affected in multiple places, but the link below seems to indicate otherwise. Being fixed in a beta version reads “affected” to me.
https://twitter.com/reneritchie/status/919988216501030914
Speaking of https – Brian you need to force https as a user can access your site under http only.
We’ll see how cruel and heartless phone/tablet makers and cellular carriers can be. They’ll use Krack as a sales pitch to force you to buy new replacements.
Instead of patching older products.
I doubt Samsung or T-Mobile will release a patch for Android 6.0.1. on S5 phones. Or even S6 or S7.
Avoid buying any tablet or phone with old Android versions. Lots of new tablets with old Android versions STILL IN STORES, even on Amazon.
The same goes for phones: used phones traded in for the latest Galaxy S or iPhone, are re-sold to prepaid vendors. They end up in the hands of users who won’t know they just signed up for a huge Wi-Fi security hole never to be patched.