-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.20.1: Chat Packet Issue #2664
Comments
FYI, the paper docs on plugin messaging specifically call out this spoofing possibility as a warning when using plugin messaging: You can also see that it is discussed here and determined that the only truly safe approach is to encrypt the data: |
@kangarko I believe this should be a high priority |
Thanks. I am busy fixing paper breaking our plugins on 1.20.5 but I will have a look with high priority in a few days |
By the way, thank you so much for providing a great bug report. This is one of the best tickets I've seen in a long time. If you have a chance to add your suggested changes, I've invited you to ChatControl's source code. All you need to compile is ChatControl and Foundation. Here is the logic for sending messages to bungee, and here is for reading them. Bungee/Velocity parts are found here and here and their libraries are on my github with the same packaging/structure/logic. |
I use the channel name plugin:chcred, not sure if the problem would go away if I just rename it to BungeeCord and then store the channel name in the byte array as the first utf? |
I have reworked the protocol to work under BungeeCord channel since that one appears not to be spoofable by clients. Use the next releases out by tonight. |
Awesome thank you so much! Sorry I've been extremely busy so I hadn't gotten a chance to respond, but I just updated to the latest version and everything seems to be working well! I'll be sure to make PullRequests if I encounter any further issues :) |
"/version ChatControlRed" - plugin version
10.25.9
Are you using MySQL?
Yes
Are you using BungeeCord?
Yes
Error log (if applicable)
N/A
"/chc debug" output (strongly recommended)
debug.zip
Information about the issue/bug
Players are able to spoof any message on the Bungee sub-server that they are currently on through custom clients by sending plugin message packets with the correct arguments and the server name is the same as the current server.
This is related to Bungee command forwarding, but the Bungee server is not involved I think. This all happens on the spigot server. However, I think this issue is also abusible on the Bungee server.
I do not have access to these clients or the exact code of how they are doing it, since these are being used my malicious players on my server and not by me, but here is what I think is close to an example of what a dangerous packet sent on an example "Hub1" server would look like:
There is no way to block these right now without disabling Bungee integration entirely.
Can you please add an OPTIONAL configurable secret key to bungee.yml (same on every server) that is used to encrypt the Bungee packets that is needs to match with all servers on the network?
So whenever either the sub-server or the Bungee gets a Bungee packet, then it will encrypt the packet using the secret key before sending, and decrypt it upon receiving?
The packet needs to be encrypted, because if it was just a key, then attackers could intercept the plugin message and get the secret key from that interception.
The config would be something like:
Then the code would be something like the below:
(Using encryptWithAES_CTR() and decryptWithAES_CTR() code from: https://stackoverflow.com/questions/30511903/what-is-the-simplest-way-to-encrypt-decrypt-a-byte-array-using-bouncycastles-b)
On plugin loading:
Sending plugin message:
Receiving a plugin message:
The text was updated successfully, but these errors were encountered: