NotSoSmartConfig: broadcasting WiFi credentials Over-The-Air

During one of our latest IoT Penetration Tests we tested a device based on the ESP32 SoC by EspressIF. While assessing the activation procedure we faced for the first time a beautiful yet dangerous protocol: SmartConfig.

The idea behind the SmartConfig protocol is to allow an unconfigured IoT device to connect to a WiFi network without requiring a direct connection between the configurator and the device itself – I know, it’s scary.

We have found an interesting and very detailed paper “Discovering and Understanding the Security Hazards in the Interactions between IoT Devices, Mobile Apps, and Clouds on Smart Home Platforms” describing how the protocol works and which are its security implications.

After the end of the Penetration Test I chose to spend part of my research time offered by Shielder on the SmartConfig protocol, also called ESPTouch in the ESP environment, to write a tool able to intercept WiFi credentials Over-The-Air.

How does SmartConfig work? 🤔

This is how a standard activation procedure works:

1. The IoT device sets itself in WiFi monitor mode
2. The IoT device stats capturing every WiFi (encrypted) packet Over-The-Air
3. The configurator opens the IoT device’s App on her smartphone
4. The configurator sets the WiFi BSSID (network name) and the WiFi password in the App
5. The configurator starts the activation process
6. The application encodes the WiFi information in the length field of some UDP multicast packets sent to the WiFi AP
7. The IoT device reads the length of the captured packet (they are encrypted, but the length is still readable since encryption adds a fixed 40 bytes) and decodes the WiFi information
8. The IoT device connects to the WiFi network
9. The IoT device advertises itself with mDNS / Bonjour
10. The configurator’s smartphone detects the IoT device connection
11. 🤯

Post-quantum encryption to the rescue!

“You said they are encoded, you meant encrypted, isn’t it?”
“No.”

Back in 2013 Texas Instruments started using the SmartConfig protocol on the CC3000 module and George Hawkins, a Particle.io community member, pointed out for the first time how insecure this procol is.

So… yes(!), it’s possible to encrypt the BSSID and the password with AES, but:

• nobody uses it;
• official ESPTouch application removed the support because “(the) device doesn’t support (the encryption) currently”;
• even though encryption would be used, static keys would be necessary to have the same zero-interaction experience, making the encryption useless.

In other words no, encryption is not in place and it wouldn’t even be a useful remediation.

PoC || GTFO

The idea behind the tool is to extract WiFi credentials from a passive network sniffing recording.

The attack in a nutshell is:

• using a WiFi card in monitor mode and a tool like airodump-ng all the traffic is captured to a pcap file;
• once the SmartConfig traffic has been captured the NotSoSmartConfig.py script is executed with the pcap file as input;
• both BSSID and password of the WiFi network are recovered.

You can download NotSoSmartConfig from the dedicated repository on Shielder’s Github profile.

Conclusions

A more secure way to implement the activation procedure for ESP devices would be the SoftAP WiFi provisioning.

This is just another™ episode of the endless fight between security and usability. Choosing the right balance between the two aspects is always hard, but the IoT industry seems to just ignore any security principle in the design phase.

If you are developing an IoT solution consider engaging Shielder for a Penetration Test of your product before reaching the production stage and for a security review during the design phase.