SSLv3 poodle attack analysis

SSLv3 poodle attack analysis
Attack Scenario:

(The attack scenario is harsh !)

For communication between A and C, attackers need to act as man-in-the-middle B, and B must be able to operate on a through JS scripts to send ssl3 requests (B can be a JS-based proxy request ), it can also steal the SSL ciphertext that a sends to C. Then, the encrypted cookie is restored through the CBC-mode padding Oracle attack.

 

 

Attack principle:

 

The CBC decryption process is as follows: (image is transferred from wiki)

 

 

 

SSLv3 adopts the end filling mechanism. The block size is generally 8 bytes or 16 bytes, And the last block is the filling block. In addition, SSLv3 does not specify that padding fills the content of block bytes. Only the last byte of the block is verified.

 

Take 8 bytes as an example:

 

Assume that the ciphertext block is:

C0, C1, C2... CN

Decryption:

P1, P2, P3... PN

The last fill block data is ******** 7.

After decryption, the server checks whether the end byte of PN is 7.

Attackers use this principle to overwrite any Ci in the ciphertext block to the CN of the last filling block and send it to the server to check whether the last byte is 7. As long as the server detects the block successfully, the following formula can be used, returns the plaintext of the last byte of the Ci block.

 

======================================

Proof: (CI covers CN)

 

PN [7] = dk (CI [7]) XOR Cn-1 [7] = 7

Launch:

DK (CI [7]) = PI [7] XOR Cn-1 [7] = 7 XOR Cn-1 [7]

Then:

Pi [7] = dk (CI [7]) XOR Ci-1 [7] = 7 XOR Cn-1 [7] XOR Ci-1 [7]

 

As a man-in-the-middle, attackers can obtain the plaintext of PI [7] If they know all the ciphertext of C1, c2... CN.

======================================

 

To decrypt the cookie, attacker B needs to be able to control a's sending and constructing HTTP requests to meet the following requirements:

(1) padding is the filling of the entire block

(2) The cookie bytes to be decrypted are exactly the last byte of the Ci block.

 

 

Then, hijack the SSL ciphertext sent from A to B, overwrite the CI block to the CN block, and send it to the server. Generally, the server will pass the verification at 1/256 probability.

 

Next, because there is only one decryption window, the attacker must construct the HTTP Request Path length, such as get/, get/a, get/Aa... top the byte to be decrypted to the decryption window. Each time you decrypt a byte, you need to send 256 requests.

 

Refer:

(1) https://www.imperialviolet.org/2014/10/14/poodle.html

(2) http://googleonlinesecurity.blogspot.nl/2014/10/this-poodle-bites-exploiting-ssl-30.html

(3) https://www.openssl.org /~ Bodo/ssl-poodle.pdf

SSLv3 poodle attack analysis