Step E.2: Exercise 1
02_guess_who [10 pts]
Resources
- None
Challenge Instructions
This challenge is a little different. In this one, we’re cross examining what it means exactly to be “random”.
Randomness – or entropy – is a classic staple in secrecy and security. We find it in things like cryptographic keys, secure communication protocols, and password salting – to name a few. Randomness – or at least the appearance of being random – adds a layer of obfuscation and mitigation to malicious activity; if bad actors don’t understand or cannot effectively guess what the values are, then they are more readily barred from impacting the CIA triangle (confidentiality, integrity, availability).
So what’s the problem here?
PSEUDO RANDOM NUMBER GENERATORS (PRNGs)
With the exception of some select hardware RNG, most modern machines aren’t producing truly random values – just pseudo-random ones. Most software approaches to yielding random values just appear random, but are actually inherently deterministic (admittedly, that might not be transparent to us as end users). Many PRNGs make use of something called a “seed” value, which determines the trajectory of all random outputs the PRNG will ever make; using the same seed and PRNG will produce the same sequence of “random” outputs every single time. It’s not uncommon – for example – for folks to see a PRNG with a seed like the current datetime stamp (down to the millisecond) due to how difficult it can be for a bad actor to predict that in a running process. Simple seeds are – as you might imagine – problematic.
INSUFFICIENT ENTROPY
Even if thoughtfully designed, a PRNG may be made vulnerable in the way it’s presented. Take a coin-flip, for example. Now while we likely cannot know with certainty what value the coin will present itself at the end (shy of cheating), we do still have pretty good odds of guessing what it is all the same. Modern computers are – by design – powerfully adept at making many computations every microsecond, so any PRNG we look to adopt would need to be vastly more computationally difficult to estimate in order to prevent just brute-forcing the correct random value.
INCORRECTLY IMPLEMENTED
By-and-large, the most common vulnerabilities that emerge (as far as PRNGs are concerned) are failures in securely integrating them into one’s system design. Architectural design choices, inappropriate code, etc. can undercut (or even negate) the use of PRNGs entirely.
OUR SUGGESTIONS
This is not a buffer overflow exercise; that is not the intended approach to the problem. There are several different sources of randomness incorporated into this challenge, including /devurandom, rand(), and arc4random(). These all behave differently from one another, so we encourage you to research how they are being used and integrated into the source code. Try to identify which might be stronger than others, which are appropriately utilized, etc.
It’s important to note that python and C approach implementing randomness in subtly different ways (but consequential in terms of seeding). Reproducing random values in e.py can be pretty tricky; we suggest instead working with either toy code (e.g. https://programiz.com/c-programming/online-compiler/ or something resident on the VM with gcc), importing custom C shared libraries (i.e. custom.so) into your python script through ctypes, and/or working through some of the random behavior natively vs. trying to recreate the random seeding results through python exclusively. Know that the numbers you are meant to guess change each time you run the binary; as such, you cannot simply denote what they might be using GDB – they are not hardcoded anywhere. However, the numbers can be reliably predicted, guessed, or otherwise discerned.
