mpgn/poodle-poc🐩 Poodle (Padding Oracle On Downgraded Legacy Encryption) attack CVE-2014-3566 🐩
A proof of concept of the Poodle Attack (Padding Oracle On Downgraded Legacy Encryption) :
a man-in-the-middle exploit which takes advantage of Internet and security software clients' fallback to SSL 3.0
The Poodle attack allow you to retrieve encrypted data send by a client to a server if the Transport Layer Security used is SSLv3. It does not allow you to retrieve the private key used to encrypt the request.
SSLv3 is a protocol to encrypt/decrypt and secure your data. In our case, he uses the CBC cipher mode chainning . The plaintext is divided into block regarding the encryption alogithm (AES,DES, 3DES) and the length is a mulitple of 8 or 16. If the plaintext don't fill the length, a padding is added at the end to complete the missing space. I strongly advice you to open this images of encryption and decryption to read this readme.
| Encryption | Decryption |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
Basically this is just some simple XOR, you can also watch this video (not me) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
A request send over HTTPS using SSLv3 will be ciphered with AES/DES and the mode CBC. The particularity of SSlv3 over TLS1.x is the padding. In SSLv3 the padding is fill with random bytes except the last byte equal to the length of the padding.
Example:
T|E|X|T|0xab|0x10|0x02 where 0xab|0x10|0x02 is the padding.
T|E|X|T|E|0x5c|0x01 where 0x5c|0x01 is the padding.
Also the last block can be fill with a full block of padding meaning the last block can be full a random byte except the last byte.
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 where |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 is the padding on only the 0x07 is know by the attacker. So if an attacker is able to influence the padding block, he will be able to know that the last byte of the last block is equal to the length of a block.
An attacker must be able to make the victim send requests (using javascript by exploiting an XSS for example). Then he can control the path and the data of each request:
Example: adding "A" byte to the path of the request
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
With this technique he can influence the padding.
SSLv3 also use HMAC to check the integrity and authenticate of the plaintext.
keyed-hash message authentication code (HMAC) is a specific type of message authentication code (MAC) involving a cryptographic hash function (hence the 'H') in combination with a secret cryptographic key
With this an attacker can't intercept and alter the request then send it back. If the server encounter a problem, he will send an HMAC error.
The protocl SSLv3 use the following routine: he receives the data from the client, decrypt the data, check the integrity with the HMAC.
MAC-then-Encrypt: Does not provide any integrity on the ciphertext, since we have no way of knowing until we decrypt the message whether it was indeed authentic or spoofed. Plaintext integrity. If the cipher scheme is malleable it may be possible to alter the message to appear valid and have a valid MAC. This is a theoretical point, of course, since practically speaking the MAC secret > should provide protection. Here, the MAC cannot provide any information on the plaintext either, since it is encrypted.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
This mean that we can alter the ciphered text without the server knowing it. this is great, really :)
First the last block need to be full of padding, like we see previously the attacker use path of the request and check the length of the request.
Since the last block except the last byte is full of random bytes he can replace this last block Cn by the block he wants to decrypt Ci. The altered request is send to the server.
The server :
By replacing the last block the attacker also changes the the last byte of the last block (the length of the padding). There is 1/256 the last byte replace in the padding block is the same than the orginal, in this case there will be no padding error and the attacker can use this XOR operation to retrieve the last byte of the block Ci by following this operation :
Pn = Dk(Cn) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
xxxxxxx7 = Dk(Ci) ⊕ Cn-1
Dk(Ci) = xxxxxxx7 ⊕ Cn-1
Pi ⊕ Ci-1 = xxxxxxx7 ⊕ Cn-1
Pi = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1
(xxxxxxx7 or xxxxxxx15 and x random byte)
The last byte of the block can be retrieve Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] In case of padding the attacker need to close the SSL session to make another handshake (new AES key) and get new cipher then replace the last block etc. (generaly +300 handshake needed)
Once one byte is retrieve he will get all the other byte of the block by adding a byte in the path and remove one byte in the data :
| Request to retrieve byte E,I,K,O |
|---|
| GET /a SECRET_COOKIE dataazerty PADDING_7 |
| GET /aa SECRET_COOKIE dataazert PADDING_7 |
| GET /aaa SECRET_COOKIE dataazer PADDING_7 |
| GET /aaaa SECRET_COOKIE dataaze PADDING_7 |
Even though TLS specifications require servers to check the padding, some implementations fail to validate it properly, which makes some servers vulnerable to POODLE even if they disable SSL 3.0
TLS is normaly safe against Poodle, but some implementations don't check the padding, it's like if we used SSLv3, this is why some TLS version are vulnerable.
There is three files in this repository:
This poc explore the cryptography behind the attack. This file allow us to understand how the attack works in a simple way.
python3 poodle-poc.py
The file parallelization-poodle.py is a project, and idea :) check https://github.com/mpgn/poodle-PoC/issues/1
python3 parallelization-poodle.py