MozillaCTF Write-Up Underwater Camouflage (250)

January 27, 2012

One of the challenges in MozillaCTF was to determine the way of how the Password Recovery Token was generated.

There’s something fishy about the generation of recovery token. Find out how to generate them for other accounts!

The token could be viewed directly after logging in and looking at the user details. To gather some intelligence on the generation algorithm, we first created three accounts and looked at the difference in the tokens.


We can see that there is distinct difference between the first and second user, but only a slight one between the second and third. Looking at the generated tokens, we see that there is a difference in the 8th byte. The difference between sqrts1 and sqrts2 is very clear, between sqrts2 and sqrts3 it is just one bit. This leads us to believe that the e-mail address is used to generate the token and not the username (the usernames only differ in one resp. two bits between each the usernames.

We know that base64 encodes 6 bytes in base256 to 8 bytes. So, lets use the first 8 bytes of the token and the first 6 bytes of the e-mail address. Looking at the result, they differ – maybe it’s XOR encryption?

Lets do an XOR on the results

print xor_crypt_string(base64.b64decode("NR0TE0kS"), "sqrts2")

This gives us


Ok, looks like we are on the right way. However, we entered an e-mail address that only has 21 chars, but the base64 decoded token has 47 chars. So, lets use a very long e-mail address! We signed up again with the e-mail address

which gave us the token


Taking the first 47 chars from the email address and the base64 decoded token and XORing them gives us:

Flag: 'Many sea creatures hide in plain sight!'

Afterwards, looking at the other strings, we determined that the token was just the e-mail address concatted and then cut to 47 chars. However, the method was changed slightly later, so that the e-mail address was seperated by | as a delimiter (so email-address|email-address|…).

Leave a Reply