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.
| Chiffrement | Déchiffrement |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
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.