mpgn/poodle-poc🐩 Poodle (Padding Oracle On Downgraded Legacy Encryption) attaque CVE-2014-3566 🐩
Une preuve de concept de l'attaque Poodle (Padding Oracle On Downgraded Legacy Encryption) :
une attaque de l'homme du milieu qui profite de la rétrogradation des clients Internet et des logiciels de sécurité vers SSL 3.0
L'attaque Poodle vous permet de récupérer les données chiffrées envoyées par un client à un serveur si la couche Transport Layer Security utilisée est SSLv3. Elle ne vous permet pas de récupérer la clé privée utilisée pour chiffrer la requête.
SSLv3 est un protocole permettant de chiffrer/déchiffrer et de sécuriser vos données. Dans notre cas, il utilise le mode de chaînage de blocs CBC. Le texte en clair est divisé en blocs selon l'algorithme de chiffrement (AES, DES, 3DES) et sa longueur est un multiple de 8 ou 16. Si le texte en clair ne remplit pas la longueur, un padding est ajouté à la fin pour combler l'espace manquant. Je vous conseille fortement d'ouvrir ces images de chiffrement et de déchiffrement pour lire ce readme.
En gros, ce n'est qu'un simple XOR, vous pouvez aussi regarder cette vidéo (pas la mienne) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Une requête envoyée via HTTPS utilisant SSLv3 sera chiffrée avec AES/DES et le mode CBC. La particularité de SSLv3 par rapport à TLS1.x est le padding. Dans SSLv3, le padding est rempli d'octets aléatoires, à l'exception du dernier octet qui est égal à la longueur du padding.
Exemple :
T|E|X|T|0xab|0x10|0x02 où 0xab|0x10|0x02 est le padding.
T|E|X|T|E|0x5c|0x01 où 0x5c|0x01 est le padding.
Le dernier bloc peut également être rempli d'un bloc complet de padding, ce qui signifie que le dernier bloc peut être entièrement rempli d'octets aléatoires à l'exception du dernier octet.
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 où |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 est le padding et seul 0x07 est connu de l'attaquant. Ainsi, si un attaquant est capable d'influencer le bloc de padding, il pourra savoir que le dernier octet du dernier bloc est égal à la longueur d'un bloc.
Un attaquant doit pouvoir faire envoyer des requêtes à la victime (en utilisant JavaScript via l'exploitation d'une XSS par exemple). Il peut alors contrôler le chemin et les données de chaque requête :
Exemple : ajout d'un octet « A » au chemin de la requête
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
Avec cette technique, il peut influencer le padding.
SSLv3 utilise également HMAC pour vérifier l'intégrité et l'authenticité du texte en clair.
le code d'authentification de message à clé basé sur une fonction de hachage (HMAC) est un type spécifique de code d'authentification de message (MAC) impliquant une fonction de hachage cryptographique (d'où le « H ») combinée à une clé cryptographique secrète
Avec cela, un attaquant ne peut pas intercepter et modifier la requête puis la renvoyer. Si le serveur rencontre un problème, il enverra une erreur HMAC.
Le protocole SSLv3 utilise la routine suivante : il reçoit les données du client, déchiffre les données, puis vérifie l'intégrité avec le HMAC.
MAC-then-Encrypt : N'offre aucune intégrité sur le texte chiffré, puisque nous n'avons aucun moyen de savoir, avant de déchiffrer le message, s'il était réellement authentique ou falsifié. Intégrité du texte en clair. Si le schéma de chiffrement est malléable, il peut être possible de modifier le message pour qu'il paraisse valide et possède un MAC valide. C'est un point théorique, bien sûr, car en pratique le secret du MAC > devrait offrir une protection. Ici, le MAC ne peut pas non plus fournir d'informations sur le texte en clair, puisqu'il est chiffré.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
Cela signifie que nous pouvons modifier le texte chiffré sans que le serveur le sache. C'est génial, vraiment :)
Premièrement, le dernier bloc doit être plein de padding. Comme nous l'avons vu précédemment, l'attaquant utilise le chemin de la requête et vérifie la longueur de la requête.
Puisque le dernier bloc, à l'exception du dernier octet, est plein d'octets aléatoires, il peut remplacer ce dernier bloc Cn par le bloc qu'il veut déchiffrer Ci. La requête modifiée est envoyée au serveur.
Le serveur :
En remplaçant le dernier bloc, l'attaquant modifie également le dernier octet du dernier bloc (la longueur du padding). Il y a 1/256 de chance que le dernier octet remplacé dans le bloc de padding soit identique à l'original ; dans ce cas, il n'y aura pas d'erreur de padding et l'attaquant pourra utiliser cette opération XOR pour récupérer le dernier octet du bloc Ci en suivant cette opération :
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 ou xxxxxxx15, avec x un octet aléatoire)
Le dernier octet du bloc peut être récupéré : Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] En cas d'erreur de padding, l'attaquant doit fermer la session SSL pour effectuer un nouveau handshake (nouvelle clé AES) et obtenir un nouveau chiffré, puis remplacer le dernier bloc, etc. (généralement +300 handshakes nécessaires)
Une fois qu'un octet est récupéré, il obtiendra tous les autres octets du bloc en ajoutant un octet dans le chemin et en retirant un octet des données :
| Requête pour récupérer les octets 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 |
Même si les spécifications TLS exigent que les serveurs vérifient le padding, certaines implémentations ne le valident pas correctement, ce qui rend certains serveurs vulnérables à POODLE même s'ils désactivent SSL 3.0
TLS est normalement sûr contre Poodle, mais certaines implémentations ne vérifient pas le padding ; c'est comme si on utilisait SSLv3, c'est pourquoi certaines versions de TLS sont vulnérables.
Il y a trois fichiers dans ce dépôt :
Cette poc explore la cryptographie derrière l'attaque. Ce fichier nous permet de comprendre simplement comment fonctionne l'attaque.
python3 poodle-poc.py
Le fichier parallelization-poodle.py est un projet, une idée :) consultez https://github.com/mpgn/poodle-PoC/issues/1
python3 parallelization-poodle.py
C'est le véritable exploit. Très utile si vous voulez faire une preuve de concept sur l'attaque Poodle pour un client lors d'un pentest, s'il utilise d'anciens serveurs et navigateurs. Il suffit de mettre l'IP de votre proxy malveillant dans la configuration du navigateur avec le bon port, le proxy s'occupera du reste.
Prérequis :
security.tls.version.min: 0 par exemple. Alternativement, si le client utilise aussi TLS, vous pouvez forcer le downgrade
💀 Si vous avez ces prérequis, vous pouvez démarrer l'attaque 💀:
Deux options sont disponibles pour cet exploit :
$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337
arpspoof, ettercap ou bettercap pour lancer une attaque de spoofing ARP$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on
⋊> ~/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
Choisir un bloc : si vous ne spécifiez pas l'option de bloc, tous les blocs seront déchiffrés, mais cela peut prendre beaucoup de temps. Je vous conseille fortement de « savoir » comment la requête sera formatée et d'utiliser le script request-splitter.py pour connaître le bloc que vous voulez déchiffrer (idéalement le bloc du cookie ! :)
Insérez ensuite le code JavaScript malveillant (poodle.js) dans le site web vulnérable en utilisant une XSS par exemple. Lancez le script Python et tapez help, puis search, et enfin active. Pendant ce temps, seules deux interactions avec le JavaScript seront nécessaires (les commandes search et active).
Mise à jour 01/04/2018 : l'option de downgrade a été ajoutée à l'exploit. Lorsque l'exploit détecte le protocole TLS, entrez la commande downgrade pour passer à SSLv3.0.
Comment ça marche ? pendant le handshake (après le hello client), l'exploit envoie un handshake_failure 15030000020228, puis le navigateur devrait renvoyer un hello client avec SSLv3.0 comme protocole par défaut. Testé sur Chrome version 15 mais cela ne fonctionne pas sur Firefox (je pense qu'il ne supporte pas la renégociation de protocole), consultez #4
Vidéo complète de l'exploitation :
Asciinema :
| Chiffrement | Déchiffrement |
|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |