I load up the CryptOMG main page and select the first challenge (like last time, we're out to get /etc/passwd). On the test page, I see nothing of interest in the actual content of the page, so I examine the URL: http://192.168.108.106/ctf/challenge1/?&c=df2a17a3cf9a378137b2838d8a440bf8ce680f494a8d57c2805c72ad6ca34858.

Take a look at the c= field. That's 64 hexadecimal characters (256 bits). It's safe to say we're dealing with some sort of ciphertext. Again, in the spirit of just breaking things to see what happens, let's flip some bits around.

First, I'll modify some bits at the beginning of the string and resubmit the request:

This is interesting because this error suggests the decryption was successful. The server is telling us that it decrypted a request for a file; the problem is that the file doesn't exist. The fact that the server is telling us this means it understood our request – and this is despite not knowing the encrypted message.

Now, I'll try modifying some bits around the trailing half of the 256-bit encrypted value and resubmit:

We've all had that one friend who just talks too much and ends up giving away too much information. In this case, our friend is an oracle – a system that inadvertently reveals information useful in an attack, even though the information itself is supposed to be meaningless. We've just learned that there is padding in this message, making it a block cipher; let's assume AES in CBC mode. And, most importantly, we know that the target is functioning as a padding oracle, letting us know the validity status of the padding in the encrypted message.

Let's bust out PadBuster to attack the padding oracle in this demonstration. Once we've nabbed our passwd file, let's take a look at what happened behind the scenes.