Hack into the REPL maliciously

[jadjuanan]

Hi guys,

I am wondering if there is a way to get access to the REPL prompt wirelessly with obscure tools or hacking tools.

My concern is for security reasons. I don't want anyone to get access to a micropython based ESP32 or ESP8266 or any other wifi capable device.

The devices is configured like this for the ESP-NOW protocol:

• WebREPL is deactivated. Of course!.
• The wifi interface is active, meaning that network.WLAN.active([is_active]) returns True.
• The wifi interface is disconnected, meaning that network.WLAN.isconnected() returns False.
• ESP-NOW messages are transmitting.

The assumption here is that no one can access the physical device directly for wired connection.

Thanks for the help.

[Josverl]

The most secure way to do that is by removing (as in not including) the (web)repl from the (production) firmware.

Recycling electrons from below thread:

You can freeze your code into a custom firmware build that's got the entire compiler disabled.
building with MICROPY_ENABLE_COMPILER (0)
To completely omit the _webrepl module, you could add #define MICROPY_PY_WEBREPL (0)

based on the known vulnerabilities -it may be best to disable Bluetooth classic / Mesh while you are at it ( although I'm not sure if the MicroPython BT stack is also exploitable)

For more details see https://github.com/orgs/micropython/discussions/12303

And as Sun Tzu said: don't forget about threat modelling

[projectgus]

Thanks @Josverl for generally sensible advice, and particularly the threat modelling cheat sheet link.

based on the known vulnerabilities

For sake of completeness, I want to point out that these are known vulnerabilities that were all patched in earlier versions of Espressif ESP-IDF. The ESP-IDF version used by current versions of MicroPython on ESP32 is newer than anything listed here. A future security issue would have to exploit a new vulnerability.

Given we're talking about a theoretical vulnerability, it's hard to say if taking an action like removing the (already disabled) WebREPL from the firmware binary would make any difference or not (although it's also unlikely to make anything worse.)

Similarly, if you're not enabling the Bluetooth stack from Python code then it's unlikely that simply having it unused in the MicroPython firmware would provide an attacker with any new way to attack the device wirelessly.

[Josverl]

Thanks for confirming that these vulnerabilities doe not apply anymore today.
And most hacks are theoretical before becoming reality. But agree that the security controls should be balanced with the threats and the value of what needs protecting. if is is a crypto wallet, or the food/water supply of one of my pets , then shelling out some extra $ for security capable hardware is money well spend.

[jadjuanan]

Thanks @Josverl for the answer and the resource links, it was very helpful.

Definitely disable WebREPL before compiling the firmware is a plus as discussed on that thread. The question is if that make a real difference in practice compared to disable (or not enable) it by code in micropython as @projectgus pointed out. Physical access is not a threat scenario in my case.

[andrewleech]

There's also more extreme levels you can go to, such as building with the python compiler disabled - this means that even if someone could get to a repl it couldn't execute any commands because it can't compile them.

#define MICROPY_ENABLE_COMPILER 0

On a related note, this topic comes up a lot (not surprisingly) so it would be well worth writing up tips / strategies like this for a wiki / doc page!

[glenn20]

I didn't experiment with it since the documentation says it can't. I'll check that. Is the doc not updated properly for recent upgrades?

Ive had a look through the docs... I cant see where it says esp8266 cant do encryption - on my reading, but, as the author I could be overlooking some ambiguity. Let me know if anything is ambiguous or misleading and I'll look at rewording.

[jadjuanan]

@glenn20 I have deeply checked the doc. Ive found only one mention. But I think there were more instances saying that in the past. Here it is:
https://docs.micropython.org/en/latest/library/espnow.html#espnow.ESPNow.add_peer

ESPNow.add_peer(mac[, lmk][, channel][, ifidx][, encrypt])

• encrypt: (ESP32 only) If set to True data exchanged with this peer will be encrypted with the PMK and LMK. (default = True if lmk is set to a valid key, else False)

[glenn20]

Ah, I see. The "(ESP32 only)" note is referring to the fact that the optional fifth positional argument (encrypt) is not supported in the underlying espressif api on esp8266. You can still enable encryption by setting the second positional argument (lmk). The esp32 api allows having an lmk loaded, and toggling encryption on and off with the encrypt argument (which is not supported on esp8266). I'll think about making that clearer....

[jadjuanan]

I see, @glenn20. Ive checked that with a pair of boards and indeed does encryption. Inspecting the packets everything seems ok. (it uses counter Mode with cipher block chaining, perfect👌)

[glenn20]

@jadjuanan Excellent. Thanks for testing...and verifying.