[Bug]: missing integrity checks let attacker forge arbitrary message content using a known plaintext attack and replaying messages even when PSK is not known #4030
Labels
bug
Something isn't working
help wanted
Extra attention is needed
high-priority
Issues that affect core functionality or are "show stoppers"
vulnerability
Protocol or firmware vulnerability
Category
Other
Hardware
Not Applicable
Firmware Version
all ¿ (fundamental protocol issue)
Description
This was discussed with @caveman99 in
#contributor-lounge
he gave me the go ahead to post it here.Here is pseudo code targeting the admin module, this would let an attacker observe an admin packet, modify it and change more or less any settings at will on all the nodes using this admin PSK:
The fix I recommend is to use AEAD.
I have prior experience with AES-GCM it is AES-CTR (what we are currently using) with a bit of extra math, this adds a 16 bytes hash after the message, it is accelerated on ESP32 and the extra math is not extremely expensive.
The main drawbacks:
This is not a very hard engineering problem, protobuf isn't that efficient and I guess we could find a way to gain a few bytes.
This can be solved by making this optional when configuring your channel, most channels like
AQ==
would gain nothing but we could enforce this foradmin
. So users would be able to toggle if they want integrity protectionESP32 chips also support AES-CCM acceleration.
So AES-CCM should be a good alternative, drawback 1 and 2 still apply.
AES-CCM is often what is used in WPA3.
AES-GCM is used in an overwhelming of TLS1.3 connections (altho Chacha20-Poly1305 is also often implemented as a fallback for CPUs who lack AES hardware acceleration), updated TLS1.2 clients also often prefer AES-GCM based suites. You are extremely likely to be using AES-GCM to view this very same issue.
This would not solve all the issue present in meshtastic's encryption, this only solve Integrity but not Perfect-Forward-Secrecy or Authentication.
Relevant log output
Is it dangerous to use the admin module ?
Probably not:
The admin module is most useful on unattended nodes where a physical attack is significantly easier and faster to perform.
This require to first capture a valid packet sent on the admin channel which is unlikely because how often do you change configuration settings ?
The attacker then need to identify which packet were sent on the admin channel, this is easier said than done, packets do not publicly indicate which channel they are a part of, there is no easy way to differentiate a packet on the admin channel to any random encrypted packet.
Then the attacker must correctly guess some bits in the admin message, in general each bit guessed correctly can be changed to attacker's value of choice. Admin messages a fair bit complex.
Examples of things that are "easy":
This is because a huge portion of the message is identical and the device role is broadcasted in nodeinfo making guessing easier.
Changing the target of an admin message that clearly reflect changes in public info is also "easy".
For example you have two nodes using the same admin channel, you update some configs on node A, an attacker can then send the same configuration to node B. The problem with this is that the attacker does not know which nodes share the same admin channel.
Tl;Dr: the vast majority of attacks are harder and it take significantly more time than gaining physical access to your node.
Most impacts of such attack would be making the mesh unreliable, using the same hardware this can be done by setting HOP_LIMIT=7, override the duty cycle checks and configure the node to spam random messages every second completely hogging the spectrum.
Workarounds:
The text was updated successfully, but these errors were encountered: