When I began writing about the wireless security lessons learned from the WPA2 vulnerability, I decided to start looking into my own level of exposure. My home network runs WPA2 on a combination cable modem/wireless router leased by my internet service provider (ISP), so I assumed the cable company might have sent me an alert. A search of previous emails turned up nothing.

I visited the ISP’s website for instructions, but there were no alerts on the home page and no messages. I asked the automated assistant about the status of a patch and it responded with the chatbot equivalent of a blank stare. There were a couple of questions posted in the community forums, but no one from the ISP had responded.

It wasn’t until I called technical support and got a person on the line that I learned my router was unaffected. That was a relief, but how many consumers would have gone to such lengths? How many would even know that this KRACK vulnerability existed, much less how to apply a patch?

Flying Under the Radar

Therein lies one of the biggest wireless security lessons of the WPA2 vulnerability: Few people are aware of it, fewer know how to patch it and fewer still will bother to do so.

The KRACK compromise is a game changer because it affects internet infrastructure rather than end-user devices. That makes tracking down and fixing the problem exponentially more difficult than expunging a virus. PC and mobile device-makers can automatically patch new vulnerabilities in their periodic updates, but few of the millions of off-the-shelf routers and wireless access points in small businesses and homes around the world have such capabilities.

A lot more semi-intelligent wireless devices are about to come online with the Internet of Things (IoT). Most will communicate over Wi-Fi or Bluetooth, the latter of which has recently been shown to be vulnerable to the BlueBorne attack. These weaknesses may be rather arcane and difficult to exploit for now, but as the Electronic Frontier Foundation (EFF) recently pointed out, “it’s the kind of thing that will likely soon be automated in software,” distributed on the Dark Web and used by attackers to target the masses of unpatched equipment.

That’s the second major wireless security lesson of the WPA2 vulnerability: The attack surface has now expanded to include infrastructure. Vulnerabilities at the infrastructure level affect many more people and devices than those at the device level because the resource is shared. In the case of WPA2, attackers don’t even have to connect to the network, said David Gorodyansky, CEO of AnchorFree, in an interview with The Next Web. They can “listen to the data you exchange with an access point and emit their own packets to change things on your system and the router.”

Infrastructure vulnerabilities are not only more insidious, but also harder to repair, because core devices are intentionally made to be difficult to access. Patching them often requires technical expertise that the average consumer or small business owner doesn’t have.

Assume Nothing When It Comes to Wireless Security

There’s no guarantee that just because a technology is widely used that it’s safe. The Heartbleed OpenSSL vulnerability proved that fact. WPA2 is even worse because it’s been around for 13 years and there are a lot more devices that use it than used Open SSL. This is a third major lesson: Don’t assume that popular means protected.

One reason it took so long for researchers to identify the KRACK vulnerability is because WPA2 isn’t easy to test. As the EFF put it, “Important protocols like WPA and WPA2 should be open and free to the public so that security researchers can investigate and catch these sorts of vulnerabilities early … before [they’re] embedded in billions of devices.” How many IoT device-makers open source their software?

Waiting for researchers to stumble upon a problem isn’t an enterprise security strategy. Current security strategies have focused on protecting endpoints on the corporate network, but many IoT devices communicate directly with manufacturers or control hubs over the public internet, 4G networks or Bluetooth.

Protecting Networks and Endpoints

That’s why the fourth major lesson of WPA2 is that enterprise security needs to protect endpoints and the corporate network alike. One recent survey of federal agencies found that 44 percent of endpoints are unknown or unprotected, meaning there is no way to detect if they have been compromised. Once these devices connect to the network, whatever exploits have affected them become the organization’s problem.

Device-makers can do their part by building basic functionality like simple network management protocol (SNMP) compatibility and remote update features into their products. Security companies can take connected device threats more seriously in their product development. All this needs to be wrapped in enhanced user training based on the belief that security is everyone’s responsibility.

The most alarming lesson I learned from this exercise is that my own ISP didn’t take very seriously a flaw that potentially could have affected all its customers. As long as we trivialize these vulnerabilities as the domain of tech geeks, the bad guys will have an open field.

more from Endpoint

IOCs vs. IOAs — How to Effectively Leverage Indicators

Cybersecurity teams are consistently tasked to identify cybersecurity attacks, adversarial behavior, advanced persistent threats and the dreaded zero-day vulnerability. Through this endeavor, there is a common struggle for cybersecurity practitioners and operational teams to appropriately leverage indicators of compromise (IOCs) and indicators of attack (IOAs) for an effective monitoring, detection and response strategy. Inexperienced security […]

TrickBot Gang Uses Template-Based Metaprogramming in Bazar Malware

Malware authors use various techniques to obfuscate their code and protect against reverse engineering. Techniques such as control flow obfuscation using Obfuscator-LLVM and encryption are often observed in malware samples. This post describes a specific technique that involves what is known as metaprogramming, or more specifically template-based metaprogramming, with a particular focus on its implementation […]