The KRACK vulnerability publicly announced yesterday dropped like a bombshell, because the decade and a half old WPA2 protocol was not only thought to be secure, but the attack presented seems so obvious in retrospect. There is a lot of online coverage and one of the best summaries was written by security expert Bruce Schneier.
I am skeptical that devices will be patched in a timely manner. Vendors had a head start to get patches ready before the public announcement, and while this is a rare time I will commend Microsoft, who patched the flaw ahead of public release, many vendors were left sitting on their hands.
The Android ecosystem is particularly vulnerable to KRACK, due to the so-called null key issue. Google won't have an official patch available for a couple weeks (although the LineageOS team has it fixed), but my guess is the large majority of Android devices in the wild will never see that patch applied to their phone.
Likewise, I don't have high hopes that my home FiOS router will be patched, considering that it's up-to-date with a firmware version over a year old. Something tells me KRACK isn't the only issue that may be lurking within the device.
I never trusted that router anyway.
KRACK underscores an important lesson. You can't trust your network. As soon as a packet leaves your computer or smartphone, assume always that it's being sniffed and manipulated. If not by your ISP, then by some compromised router deep on the internet, or perhaps now a couple hundred feet away from you by that wardriver cruising your neighborhood or corporate parking lot.
Fortunately, you can protect yourself, with encryption.
To have good operational security one must use a layered approach. Assume that every point is a failure and guard against it. In the case of KRACK, it's more important that ever to use SSL/HTTPS encryption when browsing the web. If you aren't already using the HTTPS Everywhere plugin on all your browsers then you need to start today. Throw in Privacy Badger for good measure.
Are there flaws with SSL? Sure, but it's better than nothing. The researcher who discovered KRACK posted a video which used the tool sslstrip to convert a poorly configured HTTPS website back to HTTP which could then be sniffed and then manipulated via KRACK. Poor sever configurations are out there, but most important traffic will be properly encrypted and configured, and your risk will be reduced. Note that I said reduced, not eliminated. Remember, you can't trust the network.
Is SSL the magic bullet for KRACK? Definitely no. SSL can only protect certain types of internet traffic and there are many other types of communications that may still be greatly impacted.
All that said, the risk of KRACK for regular people is likely low. The biggest issue you may face is a cleverly targeted phishing attack. That's certainly a real issue, but you should be using HTTPS Everywhere, so that your risk is reduced, and you wouldn't type your email password in to some random site... right?
Corporate networks do face a bit higher risk. There are bound to be unencrypted data transmissions within many corporate WiFi networks. Anyone resting on the laurels of WPA2 security has a lot of catch up work. Networks already set up with a layered security approach will be a lot better off, but employee smartphones and the myriad of devices that may join the network each day could still put some data at risk. Segmentation and encryption again are the answer.
So, moral of the story. Apply the patches if/when they come down the pipeline, but don't hold your breath like our friends at CommitStrip. In the meantime do something proactive to improve your online security today.
Posted: Oct 18, 2017
Keyword tags: securityhackingkrackwpa2
S3 Buckets: Now With Both Leak & Fill Vulnerability
Stealing Data With CSS: Attack and Defense
Move Over S3: Open Directory Indexes Continue to be a Problem
Security Researchers Lose a Favorite DNS Recon Tool Jan 2018
KRACK: How To Protect Yourself on a Flawed Network
Equifax, SEC, & Now Deloitte: Organizations Must Employ Offensive Security
Equifax Redux Part 1: Assume You Are Already Compromised