7

I've recently been looking at a few of the low-end WiFi modules used in IoT devices, such as the TLGUA06 and ESP2866.

As expected, it's possible to deauthenticate these devices by sending a deauthentication frame. This is as per the WiFi specifications.

However, both of these devices will re-join an open network with the same ESSID. There is no requirement to clone the MAC of the AP or anything.

This obviously leads to evil twin attacks. Combined with the common use of insecure protocols, an attacker can easily intercept or MITM communications.

OSX complains when you try this attack, as do many versions of Windows. My iPhone complains, but my Android phone doesn't.

Why do these devices not protect against evil twin attacks? I understand this may be a trade-off between security and reliability, but there are no settings or controls that would allow a manufacturer to chose to make a more secure system.

Have I missed another reason as to why these attacks are possible?

What strategies can be used to protect against evil twin attacks?

Cybergibbons
  • 1,191
  • 2
  • 8
  • 21
  • 2
    Similar to: How would you detect an Evil Twin attack, especially in a new environment? http://security.stackexchange.com/q/85138/77653 – dylan7 Dec 20 '15 at 22:07

1 Answers1

1

There are two parts to this answer.

Most browsers and mobile OS's will have a CA store with dozens of CA companies and hundreds of certs with which to validate TLS against. Evil Twin attacks rely on you not caching which requests need TLS with which certs so you can MitM to pass a request with no cert instead. This list gets updated with time but is pretty hefty for a lightweight embedded system.

IoT Platforms such as Electric Imp instead use a dedicated encryption coprocessor with secure storage like the ATSHA204 or other TPM2 style chip. All requests are routed through a known gateway (such as Electric Imp's Amazon Bucket) with a known key before going out to the wider Internet. (I believe Kindle also does this with their "Experimental" Browser). If the handshake fails the connection is dropped. Depending on how this is done the server side may be able to detect evidence of malfeasance and report misbehavior to the user as you suggest. The key stored on the device may be unique per every instance of the hardware and is associated/blessed at the factory before it ships out to the consumer.

You are essentially trading an evil twin for a trusted parent that brokers all your communication.

All outbound communications go through one known endpoint against which validation is simpler. That endpoint can then take more sophisticated requests to external resources. For low bandwidth requests it's simple and suitable for a lot of current IoT applications.

The appropriateness of this model depends on your application. If you are the weather channel and you are making a device that changes color based on weather temperature there are few concerns.

If your device reads your customers email outloud as it comes in (such as found in BMW cars) there are big concerns with you touching that data. Nokia got into trouble with this a few years back.

PMG
  • 11
  • 2