Is there a MQTT reverse proxy?

Configuration
1

I am considering to build a NFC reader for my smart lock. It consists of the actual reader (a “passive” element) and a NodeMCU that will do the heavy lifting (getting the readout of the badge ID, pushing it to HA).

My current plan is to have both in a 3D-printed case fixed on the outside of the entry door. This means that if someone grabs the box, they will be able to connect to the WiFi network (it will be a SSID and VLAN just for that reader).

The reader requires however to be able to contact HA in order to send the tag_scanned event and MQTT autodiscovery. I would like to pass these messages though a reverse proxy in order to whitelist the messages so that someone who controls the network cannot send anything sensitive to HA (there will be throttling for the ID management to mitigate brute force attacks).

Has anyone seen such a reverse proxy for MQTT?

2

Must be exciting living in an area with high tech thieves. The ones round here would just put a brick through a window or jimmy a sliding door if all sides of the house weren’t covered by security cameras.

I’m curious how you see this attack will be performed?

A reverse proxy (or even an mqtt broker ACL) isn’t going to help if the these genius thieves have your programmed NodeMCU.

3

:slight_smile:

I have a video of how thieves will break open the super-duper door with a hydraulic something I do not know the name in English that will push the door with great force and here we are.

I am mentally formatted because of my job in information security so here at least I would like to be clean and I do not expect anyone will poke around. But you never know! :wink:

If the nodemcu is retrieved by the high-tech thieves, they will find there the cleartext password for the WiFi network. They can then connect to that network and

  • attempt to guess the ID of the badge (bruteforce). Taken into account the key space an the throttling that risk is managed
  • they could also send MQTT messages such as “open the smart lock” which is highly annoying. This the reason to look for a way to reverse proxy these messages and whitelist the ones that are relevant.

I hope you now realize the stress I am in.

4

Do you intend to power the device by battery?

If not then you will probably pull a power wire to the device, but then it would be just as easy to just leave the device inside and only pull the sensor wires to the outside.

5

I don’t see how someone could decipher the binary on the device to work out the code on it / wifi details.

6

There are methods to decompile a flash dump. See Reverse engineering of esp32 flash dumps with ghidra or IDA Pro | by Olof Astrand | Medium

The ESP32 does support flash memory encryption but I’m almost certain ESPHome does not use it.

Also I’m not sure how applicable this decompiling is to read the wifi transceiver peripheral settings.

Honestly it’s a pretty difficult attack vector, well beyond the reach of most thieves.

7

Ok, I stand corrected.

Definitely not going to happen. Even if the device was ripped off the wall to try and undertake that process, the wifi could be changed to mitigate.

A tamper switch could be incorporated to alarm / alert HA if the reader is ripped of the wall or opened.

8

You wouldn’t even need a physical tamper switch, just implement this sensor: Status Binary Sensor — ESPHome

1 Like