pluginCMD "exploitable"

[Bluscream]

I just talked with @Flakebi and @Splamy about your implementation and they pointed out that someone who recieves the command can resend it to others and they would assume the cmd was sent by you. Take the following scenario as example:

You have two music bots and one (main) is playing and second (backup) is not playing

1. main sends a plugincmd with ping every 30 seconds
2. main does get a timeout for some reason (DoS-attack or similar)
3. backup does not recieve the ping from main for 1 minute and starts playing to replace the timed out main
4. main comes back online; starts sending pings again
5. backup notices the pings and stops playing

Now imagine some malicious user trying to tamper with the system:

1. main sends a plugincmd with ping every 30 seconds
2. attacker recieves the plugincmd and saves it 1:1
3. main does get a timeout for some reason (DoS-attack or similar)
4. attacker starts sending the plugincmd he intercepted
5. backup will think main is still running and therefor stay silent.

[pathmann]

Yes, that's true but I have some clarifications:

• This works only if main sends the plugin command to the attacker (or the attacker received the message with some kind of man-in-the-middle-attack).
• As soon as backup receives the client disconnected event of main (after 3.), the public key of main will be deleted by backup, so the copied messages which are sent from the attacker will be ignored.

But apart from that this sort of attack could work (without testing).

Three fixes come to my mind:

• add a global package num to all plugin commands, which will be stored by every receiving client. So if a lower or equal package num is received, the command will be ignored
• adapt the pkgkey of each plugin command to use the solution above
• add a local package num ("local" for two communicating clients), which has the benefit to recognize dropped valid commands because of network routing (command 2 arrives after command 3 and would be dropped) and request a resend (store command 3 and the following until the resend command 2 arrived and then pop all stored commands)

Solution 3 sounds like the cleanest one, but needs some work.

Just for the record: The cleanest solution would be if TeamSpeak Systems would add the sending client id in the original plugin sdk :)

[Bluscream]

I am with you at the last part, i mean Teaspeak took ~3 days to do it and im sure in Teamspeak it wont happen at all.

About your workarounds: I'm not too much into encryption but @Flakebi pointed out that a "nonce" might be what you're looking for. Tho i'm certain that using local pkg counters would be sufficient to avoid resending and gives the benefit of network redundancy