The Codegate CTF last weekend was finally an event that I was able to spend some time playing with – it was unfortunately only couple of hours but it was fun nevertheless!

As I haven’t seen any writeups about the crypto 400 – here go hell come (bonus question – guess the E! channel's host name who likes exploiting this :).
So, we are presented with a log file (mirror available at http://repo.shell-storm.org/CTF/CodeGate-2011/Crypto/400/2404656D5DA22F5DBA41CDD7AA1C1F7B) that has 2468 HTTP requests coming from a single host. An excerpt is shown below:

We can see a valid request (HTTP status code 200) and then a series of 500 requests, as well as a single 403 request. If you were paying attention last year you almost certainly heard about oracle padding attacks that were demonstrated at BlackHat Europe – these attacks allow an attacker to decrypt certain data (and encrypt, depending on some other circumstances) when CBC encryption is used. An excellent description of how these attacks work is available at http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/.

Knowing how oracle padding attacks work, we can analyze the logs of our (Codegate) server. The URLs shown in the picture are base64 URLSafe encoded – after decoding we are left with 32 bytes. Since the attacker started changing the 16-th byte, this means that the block size here is 16 bytes too.

The 500 server errors were clearly caused by an incorrect padding sequence. However, we can see one 403 error (forbidden) – it means that the attacker guessed a correct padding sequence. The attacker simply cycles from byte 0x00 to 0xFF, until the response is something different than 500. When the first value has been guessed, the attacker has to XOR it with 0x01 to get the intermediate value (read more at the link shown above). Now the attacker needs to find the second byte of the intermediate value, so the padding needs to be 0x02 – the value that has been already found is first XORed with 0x02 and the second byte is again cycled from 0x00 to 0xFF until a valid sequence has been found. And the process repeats for 0x03 … to 0x10.

This can all be seen in the log file as there are 16 requests that resulted in HTTP status code 403 (among thousands of other requests).
The challenge here was to guess what the attacker retrieved with the first (200) request. In order to decypher this we need to find all the intermediate values by following the process described above. Then we need to XOR the intermediate values with the initialization vector (IV) of the 200 request – the IV are first 16 bytes of the request.

In order to solve this I wrote a simple perl program that does this:

Now we just need to feed the 16 403 requests as STDIN and the program will solve the challenge for us:

This was a fun challenge (my team ended up as #24, but we were too casual ;-).

Anyway, in case you haven’t checked your servers/web applications for oracle padding please do so (there are lots of resources describing how to protect from such attacks). The attacks are real, they work and there are dozens of tools out exploiting this vulnerability.

--
Bojan
INFIGO IS