For this challenge, you are tasked with auditing C source code for a security vulnerability. Below is the code from the authenticate function, the comments are a mix of ones I put in and what they had originally. This function will make do some basic checks on the password, then hash and pass it to the const_memequal function to compare.
The const_memequal function will read from the hash in four byte increments and compare with the expected value. This takes constant time, since it will check the whole password before returning. The only way for the function to return 0 is if all bytes match. Below is the code provided, on the right is an example of the function if the password length is 4. When the length is greater than 4, the function will OR the result of each XOR together. This will preserve any differences in the XOR result, and therefore the passwords.
The hint they gave was that the authentication scheme was modified to allow the flexibility to change the hashing scheme when needed. This can make it easier to upgrade, but it opens up a vulnerability. The data sent to the server must included the length of password to be hashed, which can be controlled by the attacker. The length is used to tell how many bytes to hash, and to then compare to the expected hash. By controlling the length data the attacker can do an attack called a partial hash collision.
This would normally be extremely difficult in SHA3 256. It’s made possible since the collision only needs to be 4 bytes long. Now that I have found the vulnerability a proof of the exploit needs to be done. To do this I needed to find the correct password to use to find the partial hash collision. Using Wireshark the initial authentication sent in the test environment was captured.
Below is a python script to find the 4 bytes needed.
I then formatted it as 0x045cca7cfb5cca7cfb, encoded it with base64 and submitted it.