It has been about 3 months since CryptOMG was released and I will start going through the challenges one-by-one. CryptOMG is CTF-style testbed for exploiting various flaws in cryptographic implementations. It is available for free on the SpiderLabs Github.
The walkthroughs are written in a way to go over the methodology and thought process of testing for cryptographic flaws as oppose to just listing out the steps. Hopefully, this will help you apply this knowledge elsewhere.
The goal for the first challenge is to pull the contents of /etc/passwd (assuming you are on a *nix system). This lets us know that there is most likely a path traversal flaw in the application since the object is to pull a file that is otherwise not accessible. Opening the application does not yield anything too interesting and it seems to function like a normal website. Clicking on the links opens up their respective pages, however, instead of having a URL such as /links or /pictures we have a URL parameter 'c' with a whole bunch of gibberish at the end, in this case:
http://bts/cryptomg/ctf/challenge1/?&c=3349c4de2eaa6119ed92c916501d0b47a574f888dbc12cb7fee5dcc0c24e778c
Since this is the only parameter that differentiates between pages we can safely assume that this is most likely how the pages are being grabbed. Taking a closer look at the parameter values (or the encoding setting that is conveniently placed on the top of the page), we can tell that the data is encoded in hex. The first step is to try decoding the hex data to see if it gives us anything interesting.
Decoding just gives us garbage but taking a closer look at it, the length of the data is divisible by 8, so its worth treating this as some kind of ciphertext. The next step is to alter the data and see if we can get the application to spit out some useful errors. Lets see what happens when we change our ciphertext to this:
http://bts/cryptomg/ctf/challenge1/?&c=3349c4de2eaa6119ed92c916501d0b47a574f888dbc12cb7fee5dcc0c24e778d
….and now we have our crypto flaw. This particular flaw is called a padding oracle very similar to the one found in older ASP.NET installations. Lucky for us there is a nice tool to help out with exploiting this flaw. padBuster can be downloaded here and it is also installed by default in BackTrack under /pentest/web/padBuster.pl. We want to run padBuster against our ciphertext in an effort to decrypt it and see what the format of the text is. The command we will use is:
./padBuster.pl "http://bts/cryptomg/ctf/challenge1/?&c=3349c4de2eaa6119ed92c916501d0b47a574f888dbc12cb7fee5dcc0c24e778c" 3349c4de2eaa6119ed92c916501d0b47a574f888dbc12cb7fee5dcc0c24e778c 16 -noiv -encoding 1
The first parameter is the full URL with all parameters including a valid ciphertext sample. The second parameter is the sample ciphertext from the URL. The third parameter is the blocksize of the ciphertext, this is almost always 16 or 8. The -noiv switch is telling padBuster that there is no initialization vector in the ciphertext sample and that the entire ciphertext should decrypt. I generally will try it with the -noiv option first and if that does not work then I will try it without. More often than not the IV will not be in the given ciphertext. The last option is specifying the encoding used in the ciphertext sample which in this case is lower hex.
After starting padBuster we get this nice table asking us which response signatures we would like to test against. We will go ahead and use padBuster's recommendation here and select ID 2.
And bam! We have our decrypted ciphertext but we are not done yet. It looks like the format is <random_text>|<file path>. So now we need to encrypt our own text to try and gain access to /etc/passwd. We can do this by adding the -plaintext option to padBuster. Since we do not know exactly where the file is being stored we can just encrypt a bunch of "../" in front of /etc/passwd to make sure that we do get to the root of the filesystem. Our new command will look like this:
./padBuster.pl "http://bts/cryptomg/ctf/challenge1/?&c=3349c4de2eaa6119ed92c916501d0b47a574f888dbc12cb7fee5dcc0c24e778c" 3349c4de2eaa6119ed92c916501d0b47a574f888dbc12cb7fee5dcc0c24e778c 16 -noiv -encoding 1 -plaintext "spiderlabs_is_awesome|../../../../../../../etc/passwd"
And now we have our new ciphertext. It's important to note that because we do not have control over the IV in this case, the first block of data will be garbled when encrypting data using the CBC-R technique (which is what padBuster uses).
Lets just copy/pasta this into the ciphertext parameter so our new URL looks like this:
http://bts/cryptomg/ctf/challenge1/?&c=35d53757bb30755a4c8efd8e9b30610d8a44cc706f02aa5e5453eabbeeb6644fc507bcfb6c37bc121759fb4cc92ac8466a08c815969b49c145c60c0a5d5256b500000000000000000000000000000000
And now we have the /etc/passwd file <insert victory dance here>