Hacking UART (What are the implications for us using PN532)?

[nelsonic]

If we are going to be powering/communicating with our NFC/RFID Reader over UART, we need to be aware that if the PN532 is accessible from outside the building, our system is insecure by definition.

Watch the first 14 mins of this DEF CON presentation: https://youtu.be/h5PRvBpLuJs

In the immediate term the implication is: don't put the PN532 outside. We will need to mount it on the inside of the building, with a custom 3D printed enclosure:

Obviously the people on the inside of the building are welcome (encouraged) to try and (White Hat) hack the systems in the building if they have physical access to them. We will have a bug bounty for people who can demonstrate a novel hack and along with write-up and a potential fix.

@th0mas in light of UARTs hack-ability, do you feel there are any other considerations/mitigations necessary for enhancing the security of the system? 💭

[th0mas]

First thing to note here: we're using UART as a communication method between our PN532 board and our Elixir Circuits UART-based library.

We are not running a tty connection over UART

This means, that, similar to any other protocol, potential attackers could theoretically write arbitrary commands to our Raspberry Pi. Unlike the video you linked however, our UART port does not link to a tty shell where they can write arbitrary shell commands. They could write spoof PN532 messages, but this does not give them control of the device.

Spoofing PN532 messages could work, as you could send a card read message with a spoofed ID - but this isn't a UART specific problem - its an "external peripherals" problem.

To mitigate against this -

• We currently send heartbeat requests to PN532, if these get interrupted (e.g. someones unplugged our PN532), we could put the lock in a "failsafe" mode until its manually reset from the hub.

• Solder on wires to headers, this makes "non-destructive" entry more difficult

I think the UART pins are connected to ttyAMA0 on boot until our application initialises, so the Pi will be vulnerable for ~ 30 seconds on reboot. However, the Pi hasn't booted into a shell yet either so it may not acknowledge commands.

TL;DR: This is a peripheral problem, not a UART problem

[nelsonic]

@th0mas agreed, it's definitely a general peripherals problem. 👍 An attacker is far more likely to clone or spoof an NFC/RFID ID than attempt to physically compromise the RPI via the UART interface. Given that there is a heartbeat between the edge device/node and the hub and that the device

I think that the heartbeat coupled with logging will be enough to mitigate or at least intercept and deal with potentially malicious activity on the network. With the 2FA for external doors we will have decent security.

Closing. 👍