Description
In the current Meshtastic architecture, a Node is identified by their NodeID, generated from the MAC address, rather than their public key. This aspect downgrades the security, specifically by abusing the HAM mode which doesn't use encryption.
An attacker can, as such, forge a NodeInfo on behalf of a victim node advertising that the HAM mode is enabled. This, in turn, will allow the other nodes on the mesh to accept the new information and overwriting the NodeDB. The other nodes will then only be able to send direct messages to the victim by using the shared channel key instead of the PKC.
Additionally, because HAM mode by design doesn't provide any confidentiality or authentication of information, the attacker could potentially also be able to change the Node details, like the full name, short code, etc.
To keep the attack persistent, it is enough to regularly resend the forged NodeInfo, in particular right after the victim sends their own.
PoC
Due to time constraints, this PoC was performed experimentally rather than making a dedicated firmware and script that allows for node spoofing and automatic exploitation of this issue.
The configuration used is as follows:
- Device A - T-Echo 2.6.2
- Device B - T1000-E 2.6.2
- Client Android - 2.5.19
The steps to reproduce the observed behavior are:
- Device A is in PKC mode.
Device B is in PKC mode.
-
Device B enables HAM mode.
-
Device B sends new NodeInfo.
Device A sees device B as having enabled HAM mode, whereas previously they were using PKC.
Remediation
It is suggested to use the NodeDB feature as an append-only file, disallowing the possibility of a seen node to be changed to HAM mode. Moreover, when a Device enables HAM mode, change their NodeID so that it is different from when the node was in PKC mode. This new MAC could be calculated deterministically to allow for freely switching between PKC and HAM mode.
Note that this remediation is specifically based on the current Meshtastic architecture, where a node is identified by their NodeID, generated from the Device's MAC address. Consider the possibility of identifying nodes by their Public Key in a future firmware version, which would also help with other attack scenarios found by other security researchers.
Description
In the current Meshtastic architecture, a Node is identified by their NodeID, generated from the MAC address, rather than their public key. This aspect downgrades the security, specifically by abusing the HAM mode which doesn't use encryption.
An attacker can, as such, forge a NodeInfo on behalf of a victim node advertising that the HAM mode is enabled. This, in turn, will allow the other nodes on the mesh to accept the new information and overwriting the NodeDB. The other nodes will then only be able to send direct messages to the victim by using the shared channel key instead of the PKC.
Additionally, because HAM mode by design doesn't provide any confidentiality or authentication of information, the attacker could potentially also be able to change the Node details, like the full name, short code, etc.
To keep the attack persistent, it is enough to regularly resend the forged NodeInfo, in particular right after the victim sends their own.
PoC
Due to time constraints, this PoC was performed experimentally rather than making a dedicated firmware and script that allows for node spoofing and automatic exploitation of this issue.
The configuration used is as follows:
The steps to reproduce the observed behavior are:
Device B is in PKC mode.
Device B enables HAM mode.
Device B sends new NodeInfo.
Device A sees device B as having enabled HAM mode, whereas previously they were using PKC.
Remediation
It is suggested to use the NodeDB feature as an append-only file, disallowing the possibility of a seen node to be changed to HAM mode. Moreover, when a Device enables HAM mode, change their NodeID so that it is different from when the node was in PKC mode. This new MAC could be calculated deterministically to allow for freely switching between PKC and HAM mode.
Note that this remediation is specifically based on the current Meshtastic architecture, where a node is identified by their NodeID, generated from the Device's MAC address. Consider the possibility of identifying nodes by their Public Key in a future firmware version, which would also help with other attack scenarios found by other security researchers.