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 00.

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:

The first block of plaintext has been entirely corrupted, just like you’d probably expect. But what happened to the second block? The “V” at the end has changed to a “W”, yet the rest of it is intact. To understand why, recall how CBC works. Before encryption, each plaintext block is XORed with the previous ciphertext block. Therefore, CBC decryption needs to work by first decrypting each ciphertext block and then XORing the result with the previous ciphertext block. Therefore, flipping a bit in a ciphertext block will cause the corresponding bit in the next plaintext block to get flipped, without impacting the rest of the block or any succeeding block.

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. Why 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 56 93 47 = 82.

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.

In the context of web browser, if we have a man-in-the-middle position on the victim’s network and the secret I’m trying to steal is inside an HTTPS-only cookie, it’s easy for me to force the client to keeping resending the same message until this attack succeeds. All I have to do is wait for the victim to visit any plain-HTTP site, and insert an invisible iframe into it which runs some Javascript. The Javascript will keep making requests to site whose cookie I’m trying to steal, and I’ll keep tampering with each request as it occurs. Each failed attempt will result in the connection dropping and then being renegotiated with new key material, so each attempt has an independent 1-in-256 chance of succeeding. Once I’ve successfully determined one byte of the secret cookie, I then increase the length of the URL being requested by one, so that the next unknown byte is now positioned at the end of a block. I also adjust the length of something after the cookie, such as the POST body, so that there is still a full block of padding at the end. I repeat my attack in this fashion until I’ve decrypted the entire cookie.

How to test the browsers vulnerability?

Check if your browser is vulnerable to poodle!!!