Sneaking your data in – hash length extension attacks

As you will recall from our brief introduction to hashes in Chapter 3, Windows Passwords on the Network, hashing isn't encryption. An encrypted message can be decrypted into a readable message. A cryptographic hash, on the other hand, has no plaintext representation; it cannot be reversed. However, a particular input sent through a particular hashing algorithm will always result in the same hash output (called a one-way function). This makes hashing algorithms useful for integrity checks, as even a slight change to the input produces a radically different hash output. However, let's consider the fact that a hash output is a fixed length, regardless of the message being hashed; for long messages, the hash function is done in rounds on blocks of message data, over and over until the entire message is hashed. With the result depending on all of the previous inputs, we could – in theory – add blocks to the message, and the data used as input to the next round would be the same as if the whole operation had ended on that last block. We'll leverage that juicy tidbit to attack message authentication mechanisms with hash length extension attacks – length extension, referring to the fact that we're adding our chosen data to the end of the message.   

This is a little more sophisticated than our bit-flipping adventure, so we're going to introduce the inimitable web application testing framework Burp Suite to give us a bird's eye view. Burp Suite is powerful enough for its own long chapters, but in this demonstration, we're setting it up as a local proxy so we can see and easily manipulate HTTP traffic in transit.