Hijacking Devices From Another App

End Devices (Nodes)
1

Hi all,

I was reading this reverse engineering post about a LoRaWAN occupancy sensor today:

Although I disagree with much of its tone (eg. “who needs more than one gateway!!1!!”, “never use an unprotected UART!”) I was interested to see how the author hijacked a device on TTN once they had extracted the AppKey. I have tried to recreate this but have been unable to divert traffic from a TTN Button into a new app with duplicate AppEUI and a DevEUI with the same AppKey as the old app. The device always joins the old app.

Looking for related posts I came across this: How can I reuse hardcoded AppEUI and AppKey after I deleted an application? which may be related.

Any thoughts on this? Has anyone managed to recreate this?

Thanks
Ben

Edit: Reading the article’s comments, it’s interesting to see the correct use of the RN2483A which can store the keys itself. No need to re-send from the microcontroller each time.

1 Like
2

and that could be, in some use cases, dangerous.
'important nodes should be protected physically against tempering as well.
(example, if I just could screw off The Antenna, nowThe node can’t reach the gateway anylonger …it keeps on trying draining the battery ?)

imagine a flood sensor node, when high water it transmit a signal and the backend that receives it, switches on a waterpump, logical .
now someone ‘hijackes’ this node and keep sending a false signal ‘high water help… high water help’
The backend software is not very well written and keeps the pump running and finally it overheats… :scream:

3

I can put my hand under the sensor to create the same effect.

1 Like
4

:roll_eyes::sweat_smile:

5

Some really good points are made particularly in regards to physical security such as tamper protection and not leaving EUI stickers on deployed devices.

Going from device hijacking to data breaches is a bit of a stretch. Social engineering in order to access applications is not just an IoT issue. And if devices are hijacked then that data is not much use anyway.

In regards to privacy, sensors under set desks is a bit on the nose, but there are reasonable use cases for use in meeting rooms and in hot desking situations where individuals are not identified (i.e. to get efficient usage from shared resources).

6

I think one really interesting take from the article is “do not store secrets hard-coded in the firmware”.
This is basic for applications I have been involved with in the past, but I am not certain what the options are for typical arduino-based LoRa nodes?
Using the RN2483A to store the AppKey as floodnetwork writes, is one way, but are there others?
Has anyone tested microcontrollers with secure storage?
Do you agree with the article that it is more secure to have integrated LoRa on the uC, or can a separate LoRa module be equally secure?

I know a lot of people on this forum are professionals or semi-professionals, I’d really like to see some thoughts on the “pro” way to do this…

7

Have you tried searching the forum? I recall there have been discussions on the subject in the past…

8

Potting compounds can be used to physically protect access to the PCB/UART.

Also: https://www.microchip.com/pressreleasepage/industry-s-first-end-to-end-lora-security-solution

9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.