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
https://meshmarauder.net
#defcon #meshtastic #meshmarauder #cybersecurity
I responded to the OP about authentication in another reply, how Meshtastic developers aren’t hiding the fact it’s completely missing.
On the channel security element: I dived into it a little bit and looked at the MeshMarauder code.
Edit: I’ll quickly preface with appreciation that the developer of MeshMarauder brings attention to these issues with open-sourced implementation of the vulnerability exploit. Review and constructive criticism would not be possible without it.
Essentially the DefCon 33 channels were pre-defined keys for users of that event, “DEFCONnect”, “HackerComms”, “Default” etc. So any user with knowledge of the key can wreak havoc, but if there’s another channel with the PSK kept secret, that has not been necessarily defeated by MeshMarauder. Though the documentation says that divulging the key through any means to an untrusted person, guessing an insecure key, access to a device to extract the key, or any undiscovered bug that might give away the key, would fully compromise the security.
DMs are vulnerable to the lack of authentication (allowing impersonation and changing of keys that are notified but may go unnoticed by the user), but this is where network bandwidth limitations come in. Setting up a 1-on-1 channel with a shared key sent via a separate trusted and secure means, is currently the best alternative Meshtastic can offer from a security standpoint, still with significant but known limitations.
I responded to the OP about authentication in another reply, how Meshtastic developers aren’t hiding the fact it’s completely missing.
On the channel security element: I dived into it a little bit and looked at the MeshMarauder code.
Edit: I’ll quickly preface with appreciation that the developer of MeshMarauder brings attention to these issues with open-sourced implementation of the vulnerability exploit. Review and constructive criticism would not be possible without it.
From this file: https://github.com/datapartyjs/meshmarauder/blob/main/src/lorapipe-raw-packet.mjs
Essentially the DefCon 33 channels were pre-defined keys for users of that event, “DEFCONnect”, “HackerComms”, “Default” etc. So any user with knowledge of the key can wreak havoc, but if there’s another channel with the PSK kept secret, that has not been necessarily defeated by MeshMarauder. Though the documentation says that divulging the key through any means to an untrusted person, guessing an insecure key, access to a device to extract the key, or any undiscovered bug that might give away the key, would fully compromise the security.
DMs are vulnerable to the lack of authentication (allowing impersonation and changing of keys that are notified but may go unnoticed by the user), but this is where network bandwidth limitations come in. Setting up a 1-on-1 channel with a shared key sent via a separate trusted and secure means, is currently the best alternative Meshtastic can offer from a security standpoint, still with significant but known limitations.