[Bug]: missing integrity checks let attacker forge arbitrary message content using a known plaintext attack and replaying messages even when PSK is not known

[Jorropo]

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:

def encryptPacket(nodeid, packetid, key, message):
 bitstream = generateAesCtrBitstream(uint64bytes(packetid) + uint32Bytes(nodeid) + uint32bytes(0), key, len(message))
 return bitstream ^ message

decryptPacket = encryptPacket

setOwnerPacket = createSetOwnerPacket(to, newName) # this assume this has predictable output, the attack is harder if this does not, but not impossible, the main drawback is that it would require many round trip with modified packets to guess the order of fields
packetId = generatePacketId()
cypherText = encryptPacket(sourceNodeId, packetId, key, setOwner)
sendLora(sourceNodeId, packetId, cypherText)

# let's assume I am a an attacker, all of the following code run on my computer, I just observed some packet I couldn't decrypt it, and I then see a new nodeinfo with a changed name
# all of this to say, let's assume I was able to learn `to` and `newName` from contextual clues
# I also know `sourceNodeId`, `packetId` and `cypherText` since theses are sent in clear text
setOwnerPacket = createSetOwnerPacket(to, newName) # recreate the plaintext, there are many other ways to achieve this even when the whole content cannot be guessed by doing trial and error
bitstream = cypherText ^ setOwnerPacket # the whole magic is happening here
# I can now forge abitrary content that is len(bitstream) long
maliciousPayload = createSetChannelPSK(to, index=1, psk=PSKControlledByAttacker) # assume this is setting admin channel psk
cypherText = bitstream[:len(maliciousPayload)] ^ maliciousPayload # encrypt it back
sendLora(sourceNodeId, packetId, cypherText) # replay spoofed packet with modified content
# you might need to send other packets first to make the node forget it has seen this packet else it might disregard it as duplicated
# you could also jam the original packet so it never reach the target node

---

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:

1. The biggest admin packets don't have enough room for a 16 bytes auth.
   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.
2. Backward compat / extra 16 bytes cost on all packets.
   This can be solved by making this optional when configuring your channel, most channels like AQ== would gain nothing but we could enforce this for admin. So users would be able to toggle if they want integrity protection
3. nrf52 chips don't support AES-GCM acceleration, they do support AES-CCM tho, which also do AEAD, I am not familiar as familiar with AES-CCM but my limited opinion is that it should be good enough, it is based on AES-CBC instead of AES-CTR which GCM is based on.
   ESP32 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

N/A

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":

You use the admin module to change the role to ROUTER_CLIENT.
An attacker can then change the role CLIENT_MUTE.

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:

• Do not use the remote administration module, BLE and USB can do the job sometime.
• For nodes relying private channels ensure all channels your node is part of as private and secure, this will make extremely hard to guess valid values since all packets will look like encrypted garbage.
• Use different admin channel PSKs, this make it impossible to redirect config packets destined to one node, to an other node.

[Jorropo]

If implementing AEAD is not possible, a correct MAC (which include both message content, PSK and use a cryptographically secure hashing algorithm) is also acceptable, this historically created Side-Channel-Attacks in TLS1.2 which required TLS1.2 implementations to add mitigations and TLS1.3 removed all non AEAD support.

Even in the worst correct case MAC with SCA is way better than the current state of things.

[Jorropo]

Actually I over-complicated padding.
Message length is not encrypted (it is stored in the explicit LoRa header), you can simply truncate the message to the length you want. You can't forge a message longer than the longest message you were able to guess.

[xnyhps]

this adds a 16 bytes hash after the message

16 bytes is ideal, but shorter authentication tags can be used for AES-GCM/AES-CCM. 12 bytes would still be fine, and depending on the situation, even 8 bytes can be used. The slow rate at which messages can be sent could justify using shorter tags.

[xloem]

If the fundamental protocol will change, given issues like this have been so extant, I would propose finding existing cryptographic solutions and systems to use as much as possible, so as to share work in maintaining them with others. There is AI-driven attack research now.

[meshtastic-bot]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/meshtastic-encryption-implementation-flaw-corrected-yet/13539/2

[meshtastic-bot]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/meshtastic-encryption-implementation-flaw-corrected-yet/13539/6

[EternityForest]

#2610 is possibly relevant.

As I understand it, MACs are not subject to the birthday paradox (Reference: https://crypto.stackexchange.com/questions/50085/are-macs-vulnerable-to-birthday-attacks).

An 8-byte MAC, at 500 messages per second, would take hundreds of thousands of years to get one fake message through, if I understand the math: 2^63÷(500×3600×24×365)

A four-byte MAC at a still unrealistically high 10 messages per second would take 6 years. But, you could lock out for a few seconds if you get too many incorrect MACs, so it would be more like hundreds of years.

I think a more relevant attack would be replay attacks. Not likely for the admin channel, but very likely in some use cases.

I've mentioned this before in other threads, but rather than an 8-byte MAC, what about a 4-6 byte MAC, with a timestamp?

Setting the time could be done with a dedicated time sync packet, itself authenticated. If you don't get a time update in a few months, fall back to ignoring time.

The timestamp could actually just be implicit, you could make the MAC key a hash of (Timestamp+actual key). Then you only need the four extra bytes.

The timestamp would just have to only be precise to a few minutes, and you'd have to try decrypting with both possible keys, if you're right on the edge of a time boundary.

Or, you could have an explicit timestamp, in the plaintext associated data, which would incidentally also serve as a time sync packet, that any other node could also read, just without the authentication.

For replay attacks within few minute time window, a simple one byte message counter counter be used, that resets at the start of a time window. Just keep track of the time you last got each of the possible values.

It breaks down if you have multiple senders to one receiver within a time window, but that's fine for admin channel, and most home automation tasks, and could be disabled for the rest.

If nodes randomize their starting counter values it would mostly work with multiple nodes anyway.

With a tiny bit more memory you could also just keep track of all messages you got in the last few minute.

Security is such a big topic right now, and people like to black hat hack things just because they can. 4-6 bytes for some peace of mind and universal applicability in hypothetical stuff like garage door openers seems very much worth it.

[Jorropo]

Ok so I was implementing CCM-optin and rweather/arduinolibs#52 is a blocker for linux-native and rp2040 targets. Chances are I'll fix this upstream.

[fifieldt]

Hi @Jorropo . In 2.5.0 we've re-done the admin channel with some PKI , which should fix this issue.

https://www.youtube.com/watch?v=7q-dNZzpUlM

[xnyhps]

I'm a bit confused why this issue is reported only for the admin channel, and (as it appears currently) only addressed for the admin channel. Any private channel would be affected by this in the same way. Of course, the admin channel is the most tempting as it allows re-configuring a node, but even on other channels it would be an issue.

I could spin up a repeater that always flips a few bits before forwarding a message. Any receivers who got the message via this repeater won't be able to determine that the message was manipulated (unless it corrupts the protobuf structure, but I can probably guess where the actual meaningful part is). As repeaters are invisible, I think it wouldn't even be possible for the nodes around me to ignore all messages from my repeater.

Is this correct or am I missing something?

[Jorropo]

@xnyhps this has nothing to do with admin channel and affects everything as you correctly pointed out.

The idea I had is that if you randomly flipped bits there would presumably be a carbon based intelligence that would understand a glitchy hopefully not valid UTF8 message to be something wrong while a silicon based intelligence wouldn't.

[Jorropo]

I've tried fixing it by adding an AEAD channel mode option but changing the architecture of the C++ code to integrate an extra option, do it correctly on all targets, was not fun so I gave up.
If someone care about fixing this it is worth reopening, I don't really.