Wi-Fi / WPA2 Security Flaw - How to remain secure

[BrianKunick]

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.

[DarrenG]

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. 

Cheers,

Darren

[shall1569]

Hi Darren

I also agree with 1 and 2, but three I find a little impractical. There are alot of http pages out there, and sites that require password and sensitive information are normally https.

With the KRACK flaw that was found, it was proven that the encrypted traffic would be decrypted at will so Https was not safe as well.

VPN is a great solution for the short term but hardware vendors are all bringing out or have already brought out firmware updates to patch devices that are vulnerable. I have found that nearly all hardware vendors have released that they are only affected if 802.11r is being used which by default is normally turned off. This is used to allow faster roaming between access points

In a business environment, I feel short term could be VPN and long term would be patching, but if your hardware has reached end of life then a replacement with a upgraded device would be required

Thanks
Sam

[miedaner]

Hi Brian,

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.

Thanks

[dan9126]

These are all good ideas in principle. Unfortunately in a large application where you have many diverse types of devices using WiFi for lots of reasons this just doesn't scale. And even if you could engineer it rolling it out quickly is almost impossible in any kind of production environment. Possibly good advice for home users but it doesn't seem like a practical solution for a work environment. Some other additional form of network access control that can be rolled out quickly that doesn't reach up to the application Level and impact installed software seems like a better approach. I know it's a kludge and not a complete fix but something like mac address whitelisting as part of a defense in depth. This might at least buy you a little time to come up with something more permanent and more rigorous.

[DVD]

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.

[amckay]

Brian, I like the point about using a personal VPN.  Do you have any recommendations on types of VPN?

[mgoblue93]

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.

[dan9126]

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.

[DVD]

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).