Good morning guyzzz and a very happy republic day to you all. Today is a holiday, but hackers are not taking a day off, neither do we!! So lets learn something new and devastating.
What is Poodle Vulnerability?
Google researchers have discovered a security vulnerability in SSL 3.0 that allows attackers to decrypt encrypted website connections. However, some security experts disagree that the bug is particularly serious and they think that it only affect the public wifi.
How Poodle works?
Suppose an SSL client sends the following message to a server, using AES-128 (block size = 16 bytes) for encryption and HMAC-SHA-1 (tag size = 20 bytes) for authentication:
Before encryption, a hex dump of the message would look like this:
The lines are broken at 16-byte intervals, so every line corresponds to one AES block. The 20 bytes following the body of the message, starting with
bc and ending with
5b, are the MAC tag. After the end of the MAC tag, weâ€™re 15 bytes into a 16-byte block, so we append no padding, and then a padding-length byte of
Hereâ€™s the above message after encryption:
Letâ€™s see what happens if we start flipping bits in this ciphertext. See that
47 byte at the end of the first block? Letâ€™s change it to
46 and then see what happens after decryption:
Now letâ€™s try another experiment. Iâ€™ll take the second ciphertext block, the one that contains the password, and copy it to the end of the message, where the padding belongs. So my ciphertext now looks like this:
If you decrypt this you get:
The last byte, where the padding-length belongs, is now
82? The plaintext byte from that block that I copied to the end was originally
56, or â€śVâ€ť, the last character of the password. But now itâ€™s preceeded by a ciphertext block whole final byte is
93 rather than
47 like it was originally. So the plaintext ends up as
Recall that SSL v3.0 treats its padding differently than TLS does. In TLS, every padding byte is determined: it must take the same value as the padding-length. In SSL v3.0, the padding is random: it can be anything. Therefore, in SSL v3.0, since thereâ€™s no such thing as an â€śinvalidâ€ť padding byte, it may be impossible to determine whether it has been tampered with. This is especially true when the padding fills an entire block. Iâ€™ll add an extra space to the plaintext from my previous example, so that it pushes into the next block and results in an entire block of padding:
Hereâ€™s the ciphertext:
Iâ€™ve padded this message the way that TLS v1.0 would, but if weâ€™re speaking SSL v3.0 then all but the last of those bytes would be ignored: you could fill anything at all in there and the message would still be accepted. That means I can modify the final ciphertext block any way I want, and since the final byte is the only one that matters, thereâ€™s a 1-in-256 chance that the message will be accepted: even the MAC will still be valid! That means, in particular that I can do this:
We took the block containing the password and copied it into the final block, much like before. 255 times out of 256, this will result in an error and the session will abort. One time in 256, though, it will just contiune along as normal â€” and then I can do the simple XOR math which tells me what the last character of the password must have been.
How to test the browsers vulnerability?
Check if your browser is vulnerable to poodle!!!