Lets talk about poodle :)

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:

My secret password is So8dYAd14V. I want you to log me in.

Before encryption, a hex dump of the message would look like this:

4d79 2073 6563 7265 7420 7061 7373 776f  My secret passwo
7264 2069 7320 536f 3864 5941 6431 3456  rd is So8dYAd14V
2e20 4920 7761 6e74 2079 6f75 2074 6f20  . I want you to 
6c6f 6720 6d65 2069 6e2e 0abc 3a1f 0cf3  log me in.
02c5 80dd c869 66c0 1b2c 2a53 3c9d 5b00

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:

33c5 3aa2 08a4 0ecf c408 c6df 0c7d ac47
c9fb a2e4 54c8 a316 78de 1ec2 cc6e 9600
0572 dcfd 25fc c941 e9fd 6ea9 9ca2 9e50
e4c3 5bc9 f4c6 d973 2412 03fb 1615 be93
7faf 2119 c740 becc 9095 c595 034a 6a61

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:

860b 238a 9fc2 b909 6dd6 7642 05a8 85fe
7264 2069 7320 536f 3864 5941 6431 3457  rd is So8dYAd14W
2e20 4920 7761 6e74 2079 6f75 2074 6f20  . I want you to 
6c6f 6720 6d65 2069 6e2e 0abc 3a1f 0cf3  log me in.
02c5 80dd c869 66c0 1b2c 2a53 3c9d 5b00
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:

33c5 3aa2 08a4 0ecf c408 c6df 0c7d ac47
c9fb a2e4 54c8 a316 78de 1ec2 cc6e 9600
0572 dcfd 25fc c941 e9fd 6ea9 9ca2 9e50
e4c3 5bc9 f4c6 d973 2412 03fb 1615 be93
c9fb a2e4 54c8 a316 78de 1ec2 cc6e 9600

If you decrypt this you get:

4d79 2073 6563 7265 7420 7061 7373 776f  My secret passwo
7264 2069 7320 536f 3864 5941 6431 3456  rd is So8dYAd14V
2e20 4920 7761 6e74 2079 6f75 2074 6f20  . I want you to
6c6f 6720 6d65 2069 6e2e 0abc 3a1f 0cf3  log me in.
a562 4102 8f42 84d3 d87e 9c65 7e59 2682

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:

4d79 2073 6563 7265 7420 7061 7373 776f  My secret passwo
7264 2069 7320 536f 3864 5941 6431 3456  rd is So8dYAd14V
2e20 2049 2077 616e 7420 796f 7520 746f  .  I want you to
206c 6f67 206d 6520 696e 2e0a f989 78d2   log me in.
7262 93f7 6423 9a42 a7ed 149a bcfa ba50
0f0f 0f0f 0f0f 0f0f 0f0f 0f0f 0f0f 0f0f

Here’s the ciphertext:

33c5 3aa2 08a4 0ecf c408 c6df 0c7d ac47
c9fb a2e4 54c8 a316 78de 1ec2 cc6e 9600
3c87 de66 3db9 6961 3cee 12b2 0391 e2ba
e68c 5ff0 800c 72f7 78a6 78be 0866 826e
6889 b648 f1bd cbd7 294a 76b9 a51c 0632
08ab db46 cf99 bc60 c772 e3ce 3d15 c11b

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:

33c5 3aa2 08a4 0ecf c408 c6df 0c7d ac47
c9fb a2e4 54c8 a316 78de 1ec2 cc6e 9600
3c87 de66 3db9 6961 3cee 12b2 0391 e2ba
e68c 5ff0 800c 72f7 78a6 78be 0866 826e
6889 b648 f1bd cbd7 294a 76b9 a51c 0632
c9fb a2e4 54c8 a316 78de 1ec2 cc6e 9600

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!!!

Leave a Reply

Your email address will not be published. Required fields are marked *