🐩 🐩 🐩
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.
🐩 Concept of the attack 🐩
SSLv3 and CBC cipher mode
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.
|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.
0xab|0x10|0x02 is the padding.
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.
|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.
Influence the padding
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.
This mean that we can alter the ciphered text without the server knowing it. this is great, really :)
🔑 Cryptography 🔑
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.
- He saves the length of the original cipher
- He adds one byte in the path and check the length.
- If the length doesn't change he adds another byte etc.
- Else : the length of the cipher request change, he knows the last block is full of padding.
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 :
- remove the padding regarding the length of the last byte
- get the hmac from the request = HMAC
- get the plaintext
- compare hmac(plaintext) and HMAC
- if equal => good padding
- else => bad padding
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 = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1 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.
💥 Start the attack 💥
There is three files in this repository:
- poodle-poc.py -> A Proof Of Concept that doesn't require any prerequise
- parallelization-poodle.py -> ANother Proof Of Concept but using parallelization (really fast)
- poodle-exploit.py -> An exploit for real-case scenario
1. The poodle-poc.py file
This poc explore the cryptography behind the attack. This file allow us to understand how the attack works in a simple way.
2. The poodle-poc.py file
parallelization-poodle.py is a project, and idea :) check https://github.com/mpgn/poodle-PoC/issues/1
3. The poodle-exploit.py file
This is the real exploit. Really usefull with you want to make a proof a concept about the Poodle Attack for a client during a pentest if he used old server and browser. Just put the ip of your malicious proxy into the config browser with the correct port, the proxy will take care of the rest.
- make sure the client and the browser can communicate with the protocol SSLv3 only, force only SSLv3 in firefox using
security.tls.version.min: 0for example. Alternatively, if the client also use TLS you can force the downgrade
- make sure the server is vulnerable, use the tool testssl.sh
- make sure you can intercept the connection between the client and the server
Tow options ara available for this exploit:
- Setup the IP adress and the port of the proxy directly on the client side and run the exploit ( go to the part 3)
- Setup an ARP spoofing attack to redirect all the traffic between the client and the server on your machine
- Enable the forwarding and set an Iptable rule to redirect the traffic from the client to your proxy
$> echo 1 > /proc/sys/net/ipv4/ip_forward $> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337
- Use the tool
bettercapto run an ARP spoofing attack
$> bettercap -iface vmnet1 net.show set arp.spoof.internal true arp.spoof on
- Run the proxy
⋊> ~/T/poodle-Poc on master ⨯ python3 poodle-exploit.py -h 13:10:24 usage: poodle-exploit.py [-h] [--start-block START_BLOCK] [--stop-block STOP_BLOCK] [--simpleProxy SIMPLEPROXY] proxy port server rport Poodle Exploit by @mpgn_x64 positional arguments: proxy ip of the proxy port port of the proxy server ip of the remote server rport port of the remote server optional arguments: -h, --help show this help message and exit --start-block START_BLOCK start the attack at this block --stop-block STOP_BLOCK stop the attack at this block --simpleProxy SIMPLEPROXY Direct proxy, no ARP spoofing attack $> python3 poodle-exploit.py 192.168.13.1 4443 192.168.13.133 443 --start-block 46 --stop-block 50
Choosing a block: if you don't specify the block option, all the block will be decrypted but this can take a long time. I strongly advise you 'know' how the request will be formated and use the script
request-splitter.py to know the block you want to decrypt (idealy the cookie block ! :)
poodle.js) into the vulnerable website using an XSS for example. Launch the python script and type
search, and finaly
Update 01/04/2018: downgrade option has been added to the exploit. When the exploit detect the TLS protocol, enter the command
downgrade to downgrade to SSLv3.0.
How it works ? during the handshake (after the hello client), the exploit send a handshake_failure
15030000020228 then the browser should resend a hello client with SSLv3.0 as default protocol. Tested on chrome version 15 but it's not working on Firefox (I think he doesn't support protocol renegociation), check #4
Full video of the exploitation: