Known-plaintext Attack on AES/CFB8 Encrypted Packets

Minecraft uses symmetric encryption with AES/CFB8. While reviewing the protocol I noticed that there is no checksum or signature for individual packets. This allows a malicious server or active network attacker (MITM) to perform a limited known-plaintext attack.

Attack Idea:

1. An attacker registers a minecraft account with an admin name similar to an admin on a known server. In this example the real admin is SomeOtherAdmin and the attacker registers SomeOtherAdmiX
2. Then lure an admin/op from the target Minecraft server to connect to your malicious server.
3. The malicious server is a simple TCP proxy forwarding everything to the real target server.
4. Get the admin to send an op command for the player who is already admin
   /op SomeOtherAdmin
5. The malicious server proxy modifies the last byte of the op command, so the real server receives the following command
   /op SomeOtherAdmiX
6. The attacker has now op on the target server

Root Cause:

The issue is basically a known-plaintext style attack against AES/CFB8. As can be seen in the image. In CFB8 mode the cipher feedback is happening for 8-bits, so byte-by-byte. To decrypt one byte, the ciphertext is XORed with the result of the block cipher.

In the reproduction steps below the attacker knows that the last byte is an 'A' (0x41). The attacker also knows the encrypted byte (ciphertext). So if the attacker wants to turn the 'A' into an 'X', simply calculate:

'A' (xor) 'X' = 0x19.

Then XORing the encrypted byte with 0x19 will result the real server to decrypt the byte into an X. After this the CFB mode is corrupted. Any following bytes and packets are basically garbage and the client is probably getting disconnected. However at this point the server has already processed the carefully corrupted chat message.

Steps to Reproduce:

1. Setup Server-A and give Player-A op permissions
2. Setup a basic TCP proxy (I just copied some random code) which forwards anything to Server-A. I added the following code to modify an encrypted byte:

   printf("read %d bytes from CLIENT (%d)\n", n, cfd);
     if(n==124) {
         printf("CHAT MESSAGE DETECTED!\n");
         (cbuf+cbo)[123] ^= '\x19';
     }
   

3. Connect with Player-A to the TCP proxy (basically connecting to a malicious Minecraft server).
4. Move the Player-A far up into the sky so that the network traffic is minimal
5. Send a chat message such as AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
6. Even though the chat packet is encrypted, the TCP proxy can still see the size of packets. This particular chat message would be 124 bytes of data. The 124th byte is then XORED in the code above with 0x19: 
   read 124 bytes from CLIENT (4)
7. Looking at the log from Server-A the last byte of the chat message was turned into an X
   paper | [19:15:36 INFO]: <LiveOverflow> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX

Impact and Precondition:

• An attacker has to be an active network attacker (MITM)
  • OR lure a victim to connect to a malicious server
• The victim has to perform certain actions that can be exploited by an attacker being able to control the last byte of a packet
  • The example above exploits a chat command like op. The victim has to perform a very specific action the attacker anticipates and prepares for
  • There are other packets that could be targeted, but chat commands are generally the most interesting target
• The attack is "one-shot". After the corrupted byte, the CFB mode will generate garbage data. disconnecting the player from the server.
• The proxy has to recognise the correct encrypted packet in the flood of data to corrupt the correct byte. The packet size provides good heuristic, but in an area with lots of network activity this is very difficult.

Recommendation:

A 1-2 byte checksum at the end of each packet would generally mitigate the issue. When everything aligns perfectly as described above, a checksum would turn the reliable condition into a probabilistic event (checksum could randomly be correct). A 1-byte checksum has a chance 1/0xff of success, but a 2 bytes is already at 1/0xffff which is probably good enough.

Considering the limited impact and the large amount of planing and "luck" necessary, I see a very very low risk. The weakness is probably already known anyway, as it is a pretty standard attack on encrypted channels. So to be honest, if I were in charge, I would probably not even fix it myself.

Usually I would have not reported it because of this very low impact. Though full transparency, I have a YouTube channel where I make videos about IT security and this would be a really cool topic to cover. It's a great introduction into weaknesses of encryption and being able to learn about it with Minecraft is an awesome opportunity! So before I accidentally cause a panic in the wider Minecraft community, I probably should make sure I have reported it - just in case.
Also in case this is a duplicate report, would it be possible to get access to the previous one? It would be really great to share the details and comments in a future video.

Thanks!