You have probably heard a good deal about the earlier discovered and recently publicized flaw in WPA2 encryption used by WiFi providing devices. This flaw allows attackers in close proximity of your WiFi providing device to “read” your data from what you thought was a secured connection. This includes your home and cellphone WiFi devices.
Even if your WiFi providing device is vulnerable, and currently under attack, you can still safely use your WiFi signal, IF you do one of the following;
1. Install and properly configure a personal VPN (virtual private network) client on every device using the WiFi connection. Example: PrivateInternetAccess.com
2. Connect to your corporate/business systems by way of their Corporate VPN.
3. Access ONLY web sites that are fully encrypted. These websites will have the httpS prefix to every website page.
Using any of these three ways to access your data is still safe despite the recent vulnerability. Each way makes your data “unreadable” to the attackers. Everyone should be using a personal VPN anyway to anonymize their Internet traffic.
Update your WiFi device as soon as patch software becomes available.
Brian R. Kunick, is a CIO/CSO servicing the operational and security requirements of the enterprise.
Hey Brian, Thanks for sharing these tips. I agree with 1 and 2, however I would caution against option 3 as a sole method of security for a couple of reasons:
- Most computers are doing several activities in the background outside of what is happening in the browser. For example, perhaps you have a mail client running, a calendar sync with your local calendar.
- There are known techniques to highjack an HTTPS session that can be used by a malicious actor on an insecure network.
Although your 3rd suggestion is a great practice, I would recommend that it a VPN solution is also used as well. In addition, I would recommend that the VPN feature to run all network data through VPN. This feature may have different names in various VPN's, however the concept is the same. Some VPN clients will use the VPN when available but may continue to provide access to the internet even if VPN is off. Others will only tunnel certain information. So be very sure that all traffic is going through the VPN tunnel.
I hope this helps.
Very nice advice, I agree fully. For those of us that are a bit more paranoid:-) this is a good idea as a standard practice when using any untrusted network for access.
One question that bothers me a bit. It seems to me that all WPA2 implementations should be affected by the nonce replay whether client or server. At least one provider I know of is stating they are not affected despite the fact they can function as an wireless extender. I am curious about what other think about the need to fix the access point side in relation to the nonce replay.
I guess it depends on the view, yes VPNs as I've taught for years are a great way to secure communication from endpoint to endpoint. I prefer doing number 3 in my list personnally... but even doing that you can always use a VPN to help secure your connection better as you suggest.
Since you pointed out updating your Wi-Fi device, I think it's important to clarify that.
I also would add the following:
A) If you are a business and you have Wi-Fi available... first and foremost see if there is a firmware update to the access points and/or controller. A lot of mainstream products like Meraki, Cisco, Aruba, Ubiquity, etc. already have a patch for their access points. This includes home Wi-Fi access points. Apply the firmware ASAP as this will patch the flaw on those access points thus making it safer for others that want to connect.
B) The other part of the device that needs to be patched are the operating systems on all devices that use WPA2. Microsoft was the first to publish their patch, and yes even their cell devices are patched. Last I checked Google said they'll have theirs out on November 6th, but as you know it may take longer to get out to cell phone company branded Android devices. Apple is waiting for the next big release and already has the KRACK patch in their betas.
C) I personally never connect to an access point other than your business, home, or cell/hot spot. I'd like to recommend this to anyone that takes security and privacy seriously. I know some people will say they travel a lot etc. but I travel as well... I also will never connect to a business access point or coffee shop again after watching what happens on those networks. However even with this said I limit my connections... as devices like wireless pineapples can easily perform a man-in-the-middle on these connections. So when traveling I do my work... power on the access point... transfer the information and turn off the access point... go back in airplane mode.
Ya, I'm a little strange but I guess I also know the dark side of the force all too well.
Brian, I like the point about using a personal VPN. Do you have any recommendations on types of VPN?
I find #3 not practical at all. There are plenty of legit sites needed for my work as a software developer, where I get patches, libraries, etc., which are NOT https.
All that patching takes time and testing before a roll out. I think the real answers are to have behavioral analytics and DLP running in high gear at top RPM all the time. As I recall the best practice these days is to assume an APT has worked and bad guys are in your network. It seems like watching for them is perhaps even MORE important than keeping them out.
The problem is not everyone that has the capabilities of running DLP, etc. yet (I know... yikes right?). It takes more time to address symptoms of the root cause of the problem then it does to simply address the root cause. The root cause of the KRACK issue we are all talking about here can only be fixed by applying the firmware updates and OS updates as they become available.
Addressing the KRACK issue really does depend on your environment and as of this posting not everything is patched. The fact that the patch may not be available is the only reason why addressing the KRACK vulnerability via a workaround can be viable solution - otherwise your time is best spent on figuring out how to deploy the patches and deploy them. However, if you are in a Microsoft environment and the vendor of your technology has a patch for their Wi-Fi networks then addressing the KRACK vulnerability via VPNs, DLP, etc. really will take more time than applying the patch that fixes the issues surrounding this key reinstallation attack.
Why? Because you will still need to deploy the patches in order to mitigate the attack.
The fact of the matter is setting up DLP, using hotspots, or VPNS et. are great solutions, but they don't address the root cause of the issue here and thus are only applied as workarounds. This workaround technology also needs to be tested and they also cost money to deploy if it already hasn't been deployed (keep in mind not all our environments are the same).
I can only speak for myself in this regard and can honestly say my environment is already fully patched and I implemented all countermeasures for KRACK both at home and work (which is DoD related). I have a friend in the critical infrastructure sector and he has done the same. We utilize a complicated system (beyond WPA2) to ensure only trusted clients get connected. I had a roll back plan and implemented the patches realizing it could cause issues but also had a way to back out of it if it didn't work. So, yes we need to test, and we need to CYA... Patching does take time, and we should test... we should also have a back out plan. Yes... you get it! Good job!
Threat Hunting is also good and yes we should be doing that as well but it doesn't fix KRACK.
However, if you have the patch, I can't see "taking time before the rollout" as an excuse to delay the patching by complicating your environment by deploying workarounds that you may not otherwise need (or may even take longer to deploy as in the case where people don't have DLP, etc.). This also doesn't mean don't get DLP... get it... it's good stuff. However for the KRACK issue the time is best spent on figuring out how to deploy the patch, how to test the patch, and how to ensure you have a back out plan if it fails then worrying about DLP, etc. in general (oh and only if you have the patch available... otherwise again you are forced to use workarounds... again yikes).