I've been busy as hell this past week.
A lot of people have been asking hard questions about the security of LoRa systems when they hear about mesh radios.
I'm not one to trust the marketing so I and several friends put together two new LoRa tools to help us audit the security claims of LoRa mesh systems!
🤘🏿 📡 ✨
#radio #cybersecurity #privacy #meshtastic #lorapipe #meshmarauder #lora #mesh
The first new tool is lorapipe, a firmware that runs on most consumer LoRa radios.
We've tested it a ton on ESP32-S3 based Xiao Wio boards.
This turns your lora radio into extremely minimal serial device that sends and receives packets in a dirt simple CSV format.
The radio can be tuned on the fly to switch between meshcore, meshtastic and LoRaWAN sync words and frequencies.
And because all the lorapipe firmware is doing is sending and receiving packets it means you can handle the encoding and decoding on a different device.
We tried to keep some of the dispatch behavior in lorapipe so that the firmware will automatically wait for gaps in traffic to find a good time to transmit.
It's pretty damn zippy . . .
Which brings me to part two, MeshMarauder.
An open source tool demonstrating proof-of-concept exploits against the DEFCON 33 Meshtastic firmware.
MeshMarauder will demostrate:
- Tracking user activity on any mesh regardless of encryption usage
- Hijack all meshtastic user profile metadata
- Change any users public key
- Send messages as any user in channel chats that appear authentic
- MITM direct messages
One of the exploits demonstrated is PKI poisoning, this is where we listen for a complete user profile and only change the public key to one we control.
In the case of mesh marauder we also add a little 🥷to the user name so people can see something is wrong.
If they never have seen this user before they will appear as a green contact.
If this is a contact they already knew the meshtastic app provides a warning but appears to replace the original key without user input.
The core issue to the above PKI poisoning attack is that NO core parts of meshtastics protocol is signed.
The user profile transmits the public key and there is no way to verify any of the information in it was even sent by that included public key 🙄
Nothing is signed and simply setting someone else's MAC address in the unencrypted header makes you that user.
The scale of meshtastics avoidance of building security into the design is pretty epic.
It allows for the formation of an entire mesh just for MITMing it.
This ONE liner here in the PKI attack means that once a node gets poisoned the key we created is based on the MAC so -anyone- who knows your MAC can read your MITM'd traffic.
When attackers run mesh marauder against the DEFCON 33 firmware they are all working together. Anyone in range can read the MITM'd DMs.
https://github.com/datapartyjs/meshmarauder/blob/channel-chat/src/lorapipe-raw-packet.mjs#L191-L193
So when it's this easy to get a MITM going things like making posts in public chats as anyone you want feels kinda low key.
But I do hope that extended warranty works out, everyone seems pretty concerned about them.
There's been a ton of bad advice for the privacy conscious and in particular for activist to use meshtastic.
I think that's very bad advice, because meshtastic is in no way architected to meet modern security expectations.
I hope this provides the proof of the dangerously lacking state of security on meshtastic today and some tools to verify if it ever improves.
Expect a more detailed blog post of all the exploits and findings soon.
Yes, meshcore needs more review but the design+code appears to match the marketing.
I don't see any obvious way to do the same attacks on meshcore, needs more thinking about seems very hard to exploit.
I could have written the meshtastic exploits a year ago but I didn't want to release any meshtastic exploits until there was a viable alternative.
nullagent
Adam Gessaman 