Description
An attacker is able to send an unencrypted direct message to a victim impersonating any other node of the mesh. This message will be displayed in the same chat that the victim normally communicates with the other node and it will appear as using PKC, while it is not. This means that the victim will be provided with a false sense of security due to the green padlock displayed when using PKC and they'll read the attacker's message as legitimate.
PoC
Due to time constraints, this PoC was performed experimentally rather than making a dedicated firmware and script that allows for 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.
-
A enables HAM mode.
-
A sends new NodeInfo.
B sees A as using HAM mode.
-
Using the client app with Device B, for example, the Android one, go on the list of nodes and pick to send a direct message ("DM") to A. This will create a new entry in the messages tab. In fact, reusing an already open message entry would fail due to it using PKC, hence it is necessary to manually go on the DM option again.
-
B sends messages to A using the new chat, which uses the default shared key of the Meshtastic channel. Device A receives messages even though the app with Device B shows that messages can't be delivered. +
B sees the messages sent by A in a new chat automatically created that has no PKC.
-
A switches back to PKC.
-
A sends new NodeInfo.
B can send messages to A both in the no PKC and in the PKC channel.
.Screenshot PKC chat - Device B
.Screenshot shared Key chat - Device B
- A receives both the PKC message and the one encrypted using the shared key inside the PKC chat, causing a loss of integrity in the direct messages.
.Screenshot of the victim Device A
.Screenshot Debug Info
Remediation
It is suggested to implement a stricter control on whether a message has been received using PKC or using the shared Meshtastic channel key.
Moreover, instead of showing no green padlock icon in the chat with no PKC, consider using an explicit indicator like, for example, the yellow half-open padlock displayed when in HAM mode. This remediation, however, applies to the client applications rather than the Meshtastic firmware.
Issue as reported originally on the Meshtastic Firmware repo: https://github.com/meshtastic/firmware/security/advisories/GHSA-377p-prwp-4hwf. The issue was already fixed in MR #1720.
randshell Reporter
Description
An attacker is able to send an unencrypted direct message to a victim impersonating any other node of the mesh. This message will be displayed in the same chat that the victim normally communicates with the other node and it will appear as using PKC, while it is not. This means that the victim will be provided with a false sense of security due to the green padlock displayed when using PKC and they'll read the attacker's message as legitimate.
PoC
Due to time constraints, this PoC was performed experimentally rather than making a dedicated firmware and script that allows for automatic exploitation of this issue.
The configuration used is as follows:
The steps to reproduce the observed behavior are:
Device A is in PKC mode.
Device B is in PKC mode.
A enables HAM mode.
A sends new NodeInfo.
B sees A as using HAM mode.
Using the client app with Device B, for example, the Android one, go on the list of nodes and pick to send a direct message ("DM") to A. This will create a new entry in the messages tab. In fact, reusing an already open message entry would fail due to it using PKC, hence it is necessary to manually go on the DM option again.
B sends messages to A using the new chat, which uses the default shared key of the Meshtastic channel. Device A receives messages even though the app with Device B shows that messages can't be delivered. +
B sees the messages sent by A in a new chat automatically created that has no PKC.
A switches back to PKC.
A sends new NodeInfo.
B can send messages to A both in the no PKC and in the PKC channel.
.Screenshot PKC chat - Device B
.Screenshot shared Key chat - Device B
.Screenshot of the victim Device A
.Screenshot Debug Info
Remediation
It is suggested to implement a stricter control on whether a message has been received using PKC or using the shared Meshtastic channel key.
Moreover, instead of showing no green padlock icon in the chat with no PKC, consider using an explicit indicator like, for example, the yellow half-open padlock displayed when in HAM mode. This remediation, however, applies to the client applications rather than the Meshtastic firmware.
Issue as reported originally on the Meshtastic Firmware repo: https://github.com/meshtastic/firmware/security/advisories/GHSA-377p-prwp-4hwf. The issue was already fixed in MR #1720.