Skip to content

GHSA-h79x-98r2-g6qc CVE-2022-51016

Impersonation of other users (passing XBOX Live authentication) by theft of logins in PocketMine-MP

Medium Packagist
Severity
5.3 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.24%
Chance of exploitation in the next 30 days. Higher than 15.16% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-294 Authentication Bypass by Capture-replay
Fix
4.0.0
Upgrade pocketmine/pocketmine-mp to this version or later

Description

Impact

Minecraft Bedrock authentication and its protocol encryption are inseparably linked. One is not complete without the other.

This vulnerability affects servers which are able to be directly connected to via the internet (i.e. not behind a proxy).

If you are using a proxy, please check that it supports protocol encryption and that it is enabled.

Technical details

<details> <summary>click to expand</summary>

Basics

  1. The client generates a private ECC key clientPriv which it uses to complete ECDH for encryption.
  2. A JWT containing the public key clientPub corresponding to this key is signed by Microsoft servers with the Mojang root public key mojangPub.
  3. The server verifies that the token was issued by Microsoft servers by verifying the JWT signature with mojangPub.

Why this is a problem

However, this only ensures that the token was issued by Microsoft. It does not ensure that the client actually possesses the private key corresponding to the public key in the token. In a login replay attack, the attacker sends a login captured from another session. This login is valid because it is verifiable by mojangPub; however, without encryption, the server doesn't know that the client actually possesses clientPriv, and the authenticity of the client cannot be verified.

How encryption prevents the attack

  1. The server calculates a shared secret for encryption using ECDH of serverPriv and clientPub.
  2. It then signs a return token using serverPriv and sends this to the client, along with serverPub.
  3. The client then verifies the JWT using serverPub, and calculates the same shared secret as the server using clientPriv and serverPub.

If the client does not possess clientPriv (i.e. because it replayed a stolen login), then the session cannot proceed once encryption is enabled, since the client cannot calculate the shared secret needed to decrypt the server packets and encrypt its own packets.

Since PM3 does not implement protocol encryption, this means that ALL versions of PM3 are affected by this login stealing attack.

How does the attacker capture a login in the first place?

The typical way to do this would be to trick a player into joining a server controlled by the attacker. This would allow the attacker to grab the login from the connection and store it for future use.

Are the logins valid forever?

No. All the JWTs have expiry dates after which they cannot be used. These expiry dates are typically 2-3 days after the token was issued by XBOX servers. PocketMine-MP 3.x does verify these expiry dates, so the use-by dates of these attacks are limited.

</details>

Patches

This problem has been fixed in all 4.x versions by implementing Minecraft protocol encryption.

This has not yet been addressed on 3.x, but since this vulnerability is already public knowledge, the advisory has been released early to make sure people are aware of it and the mitigation steps they can take.

Update 2022-01-22: This has been fixed on 3.x by d28be4eaf24a890f7ef110a51181a3d806a6acca.

Workarounds

  • Use a proxy that supports encryption such as gophertunnel between your server and players. Make sure that the server only accepts connections from the proxy. If the proxy is on the same machine as the server, you can use server-ip=127.0.0.1 to ensure that only the proxy can create connections for you.

The following things may help mitigate the problem:

  • Verify that the LoginPacket serverAddress field is the same as the server's exposed domain name. For example: https://github.com/JustTalDevelops/AntiLoginForger WARNING: THIS DOES NOT SOLVE THE ROOT ISSUE. YOU WILL REMAIN VULNERABLE UNLESS YOU UPGRADE.

For more information

If you have any questions or comments about this advisory:

Affected versions

Packagist

PackageVulnerableFixed in
pocketmine/pocketmine-mp
>= 3.0.0, < 4.0.0
4.0.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

pocketmine/pocketmine-mp Packagist → 4.0.0

composer
composer require pocketmine/pocketmine-mp:^4.0.0

Severity breakdown

CVSS 4.0 5.3

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
Passive
Confidentiality (vulnerable system)
Low
Integrity (vulnerable system)
Low
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
Low
Integrity (subsequent systems)
Low
Availability (subsequent systems)
None
Exploit maturity
Not defined
Scope
X

CVSS 3.1 4.7

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
Required
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
None

Weakness

CWE-294: Authentication Bypass by Capture-replay

A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).

How to prevent it
  • Architecture and Design: Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.
  • Architecture and Design: Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-pg53-p7qp-65cv
PocketMine-MP has potential memory/network vulnerability from repeated ResourcePackClientResponsePacket packets
Low Also affects pocketmine/pocketmine-mp
GHSA-xp4f-g2cm-rhg7
PocketMine-MP has LogDoS by many junk properties in client data JWT in LoginPacket
Medium Also affects pocketmine/pocketmine-mp
GHSA-f9jp-856v-8642
PocketMine-MP: Player entities can still die and drop items in flaggedForDespawn state
Medium Also affects pocketmine/pocketmine-mp
GHSA-7hmv-4j2j-pp6f
PocketMine-MP: Network amplification vulnerability with `ActorEventPacket`
Medium Also affects pocketmine/pocketmine-mp
GHSA-788v-5pfp-93ff
PocketMine-MP: JSON decoding of unlimited size large arrays/objects in ModalFormResponse Handling
Medium Also affects pocketmine/pocketmine-mp
GHSA-h6rj-3m53-887h
PocketMine-MP: LogDoS by large complex unknown property logging in clientData in LoginPacket
High Also affects pocketmine/pocketmine-mp
GHSA-fqqv-56h5-f57g
PocketMine-MP `ResourcePackDataInfoPacket` amplification vulnerability due to lack of resource pack sequence status checking
Medium Also affects pocketmine/pocketmine-mp
GHSA-g274-c6jj-h78p
PocketMine-MP allows malicious client data to waste server resources due to lack of limits for explode()
Medium Also affects pocketmine/pocketmine-mp
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor