🪲 The dangers associated with non-cryptographically-secure random number generators should not be understated.

How often do you encounter generic random number generators in production code? From generating one-time passwords and 2FA secrets, to rolling results for roulette-like games.

Some developers are already aware that random numbers are not fully random. The correct name would be pseudorandom, as they are sourced mathematically from some combination of external inputs, such as system time, PID, internal system state, and so on.

The industry standard for pseudorandom generators prescribes using cryptographically secure algorithms to determine the output. However, most developers have never encountered the consequences of using insecure PRNG algorithms, and thus are not aware of the dangers exposed by such. Such developers will continue to use insecure PRNG algorithms in critical infrastructure, exposing users to the dangers which are commonly understated, misrepresented and otherwise misconceived.

This post will expose a critical security vulnerability discovered by me in a popular Minecraft profile search database, laby.net

laby.net is a Minecraft profile database that allows users to search Minecraft skins, usernames, capes, and so on. The website allows users to log in using their Minecraft account. For that, the user should connect to a specialized game server using a licensed copy of Minecraft and receive a numerical code from the game server.

This code can then be entered on the website, effectively verifying that the Minecraft account is owned by the user, and allowing complete control over his entries on the website: hiding/showing skins, usernames, and capes.

However, as it later turned out, the algorithm used by the game server is insufficiently secure.

Through simple observation of the PIN generated by the system, it's easy to notice it's always a positive 4-digit number, which gives us the range of [1000; 9999]. Combined with the knowledge of Minecraft, a game developed in Java, a sufficiently educated attacker can assume that the server is also coded in Java.

It should be noted that the default implementation of a PRNG - java.util.Random - uses a linear congruential generator (LCG) for generation of random numerical artifacts. LCG is well-known as an extremely insecure implementation of PRNG with widely available exploits. The attack is then reduced to figuring out the internal PRNG state and mathematically deriving all past and future PIN values.

Operating on an assumption that the game server utilizes equivalent code for PIN code generation:

Random rng = new Random();

rng.nextInt(9000) + 1000

the attacker can then proceed to aggregate the sufficient amount of PRNG outputs (in our case, around 5-7 unique consecutive values) and successfully recover the complete internal state.

The internal state can then be used to predict any future PIN codes, allowing a very determined attacker to log into anyone's laby.net account under specific conditions and with enough preparation.

PoC attached to this post demonstrates the complete successful attack on a live auth.laby.net service.

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.