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’m not familiar with the design philosophy of the original protocol, or if they decided the protocol should or should not attempt to impose any kind of a security model, but given that the project grew out of the same kind of ethos as HAM, I’d bet it was never a high priority.
That said, these exploits make the mesh untrustable and should be mitigated. If the devs don’t want to implement fixes, maybe the answer is stripping out all encryption entirely and adding a plugin system that allows anyone to implement a solution themselves. They could even move the current broken implementation to a plugin and make it the default.
In the future, they’d only ever need to handle requests for maybe new entry points or tweaks to the plugin system.
It is mitigated in 2.6.11 https://github.com/meshtastic/firmware/releases/tag/v2.6.11.60ec05e. When I re-generate keys on a node I get warnings that the public key of that node is changed, and I need to delete the node and wait for the next advertisement to update it. I haven’t tried running meshmarauder myself to see if the user profile tampering still works, if they sign and check the updates correctly I don’t see why that would still be broken. The other impersonation stuff does not seem to be released yet.
That said, I think Mestastic works as a kind of hobby, out of band public communication network first and foremost. Even in that kind of setting, knowing who sent which message is valuable, but not a deal breaker in my opinion. Not sure I’d trust it as a network for encrypted person to person messaging. And to be fair, compared to “normal” HAM, any kind of attestation is a bonus. And it’s license free and relatively cheap to get into.
That release mitigates a previous issue, where different devices would sometimes generate identical secret keys due to lack of entropy in their random number generation.
I’m not familiar with the design philosophy of the original protocol, or if they decided the protocol should or should not attempt to impose any kind of a security model, but given that the project grew out of the same kind of ethos as HAM, I’d bet it was never a high priority.
That said, these exploits make the mesh untrustable and should be mitigated. If the devs don’t want to implement fixes, maybe the answer is stripping out all encryption entirely and adding a plugin system that allows anyone to implement a solution themselves. They could even move the current broken implementation to a plugin and make it the default.
In the future, they’d only ever need to handle requests for maybe new entry points or tweaks to the plugin system.
It is mitigated in 2.6.11 https://github.com/meshtastic/firmware/releases/tag/v2.6.11.60ec05e. When I re-generate keys on a node I get warnings that the public key of that node is changed, and I need to delete the node and wait for the next advertisement to update it. I haven’t tried running meshmarauder myself to see if the user profile tampering still works, if they sign and check the updates correctly I don’t see why that would still be broken. The other impersonation stuff does not seem to be released yet.
That said, I think Mestastic works as a kind of hobby, out of band public communication network first and foremost. Even in that kind of setting, knowing who sent which message is valuable, but not a deal breaker in my opinion. Not sure I’d trust it as a network for encrypted person to person messaging. And to be fair, compared to “normal” HAM, any kind of attestation is a bonus. And it’s license free and relatively cheap to get into.
That release mitigates a previous issue, where different devices would sometimes generate identical secret keys due to lack of entropy in their random number generation.
This is their response to the issues which this post is about.