������

That’s one heck of a headline, I know, but things just got real for Wi-Fi security Monday morning. Mathy Vanhoef of imec-DistriNet and Frank Piessens at KU Leuven published the results of their hard work on the authentication mechanism of the WPA2 protocol (which is used by Wi-Fi as a security layer for data traveling over the connection)—and it's totally broken.

If panic just set in, you can find more . However, keep reading if you want to understand this attack from a high level and how it impacts IoT devices.

What is the KRACK attack?

The KRACK attack focuses on the four-step protocol used during the setup of a WPA2 Wi-Fi connection. The result is that an attacker, within range of the Wi-Fi router, can break the encryption on the connection allowing a secondary attack using a man-in-the-middle (MITM) attack to gain access to all HTTP data being sent from the client and data being received from the server. Your services and devices utilizing HTTPS should be ok because even if the attacker were to gain access to the connection, your data is encrypted by the HTTPS layer.

WPA2 utilizes this four-step negotiation process to set the encryption key for communication with a Wi-Fi access point, and can be tricked into using an incorrect key that allows the attacker to gain full access to the communications.

The weakness that KRACK exploits is at the protocol level within Wi-Fi, leaving all clients susceptible. However, Android and Linux client libraries are uniquely susceptible to a vector of this attack that resets the encryption communication key to a “Null Key” (a key with all zeros), making the attack more accessible and effective on those platforms. Android and Linux just have an additional bug that makes exploit a bit easier in this case.

This vulnerability means that all of the numerous client devices that utilize Wi-Fi in use today will need to be updated to prevent this attack from occurring. Wi-Fi routers and enterprise class equipment should get new firmware quickly, but IoT Devices, where update may be difficult or impossible to apply, will be hit the hardest.

What does this mean for IoT devices?

There are varying types of IoT devices including (but not limited to) devices used for industrial, healthcare, scientific, entertainment, home control and automation, and personal fitness purposes. The threat level of these devices varies widely, as does the implementation security levels each one uses.

A simple exercise to measure the spread of IoT devices would be to look around your home. You may have things like a smart TV, smart appliances, Amazon Dash, home security, sprinkler systems, smart meters, printers, and other home automation devices. This grows by an order of magnitude when you look into the enterprise setting.

Some IoT devices may only utilize HTTPS for the authentication step, but subsequent communications can occur over HTTP. Some IoT devices may utilize HTTPS for authentication and communication, but have other device services that are not utilizing HTTPS. Others may not utilize HTTPS at all. Those are the devices which will be impacted the most by the KRACK attack.

Let’s take a look at the simplified communication structure between a fictional home thermostat and the service provider for the device. The graphic below demonstrates the device sending a request to authenticate and receiving a response telling the device to update its firmware (two ordinary things that an IoT device can do). The request goes through the Wi-Fi Access Point (AP) to reach the service provider. The service provider sends the data back to the device, again, through the Wi-Fi AP.

As you can see in the graphic above, if an outside attacker can gain control of the Wi-Fi AP by breaking the encryption and setting up a MITM, and the device is not using HTTPS for communications, then the attacker would have the full capability to intercept the authentication credentials and inject anything into the response for a firmware update.

Now, to be fair, many devices may utilize HTTPS connections for a lot of the communications they use, and are thusly not impacted by this portion of the attack, but IoT security doesn’t stop there. Let’s say that a server response was over HTTP (as in the example above) for a firmware update request, and the attacker injected a URL to a compromised firmware binary image. The device would now install the firmware and introduce whatever additional vulnerabilities or trojan type services that the attacker is trying to use.

This creates many larger problems, and we will talk about how to manage these situations below.

How can I remediate this attack for IoT?

First, if you produce IoT devices then you need to update your Wi-Fi drivers, especially if you have Linux or Android (6+) on that device. While you are doing this you should also disable weak cipher suites to avoid future vulnerabilities around crypto and HTTPS.

That may sound simple, but it seems we are in a holding pattern waiting for some vendors to patch this vulnerability, so in many cases you may be waiting until your vendor(s) make a patch available.

You can to see if your device has been patched. Another helpful .

Aside from the Wi-Fi driver itself, there are three other general security considerations you should be mindful of as you are creating a IoT device infrastructure:

• Use HTTPS
• Use client certificate authentication
• Use code signing

HTTPS

All communications coming from and going to your IoT device should be over SSL/HTTPS. You should ensure you have a properly configured HTTPS stack on your device so that certificates are authenticated properly and trust can be made.

Client Certificate Authentication

All IoT devices should authenticate to the services they are talking with. You can pretty seamlessly include client certificate authentication in your device provisioning process to provide a cryptographically secure mechanism of authentication with the backend services. You can additionally provide revocation services on a credential like this, which is more difficult to do with password-based authentication.

Code Signing

The code that executes on the device itself should be signed. This will allow the device to ensure that it is only installing and executing code that came from a trusted source (you). If you utilize code signing, you provide a layer of security that will help mitigate the potential effects like the KRACK attack where someone may attempt to alter your firmware or applications running on the device.

Those are three generally good things you can do to provide a more robust layered security solution for your IoT device deployments.

What can I do for the devices in my company?

If you’re managing enterprise or SMB IT, assets you will want to also check with the vendors of the client devices that are on your network to ensure that they get updated.

One other internal attack vector to consider is internal employee systems, portals, dashboards, or services that maybe aren’t running over HTTPS. Now would be a great time to make use of an internal CA and create certificates for all those connections, or find a vendor that offers solutions and have them help you.

Help others by providing HTTPS for external resources that don’t already have it. If your company does provide some external services in use by others, ensure that YOUR company is serving all traffic for those resources over HTTPS, and if you control executables that are distributed, you should be code signing those as well. This will greatly help mitigate the effectiveness of attacks like this KRACK vulnerability.

Conclusion

This is a troubling development for Wi-Fi authentication, but you have to consider the threat level and how it applies to your resources. Also, remember that the attacker needs to be near the Wi-Fi network and device that is attempting to connect to it, so this is NOT a remote exploit that opens your entire environment to attack.

You will need to carefully watch your vendors and ensure that your Wi-Fi drivers and Access Points are up to date as soon as the vendors have those patches. In the meantime, ensure that all services you CAN control are running with HTTPS. That is the best you can do for right now.