mpgn/beast-poc💪 Preuve de concept de l'attaque BEAST contre SSL/TLS CVE-2011-3389 💪
Cette preuve de concept se concentre sur la cryptographie derrière l'attaque BEAST (Browser Exploit Against SSL/TLS) présentée par Thai Duong et Juliano Rizzo le 23 septembre 2011. Il s'agit d'une attaque à texte clair choisi et elle vous permet de récupérer des informations sensibles si la sécurité de la couche de transport (TLS) utilisée est TLS1.0 ou SSLv3. La preuve de concept originale peut être trouvée ici : Here come the Ninjas
Remarque : Ceci est également une implémentation de la vulnérabilité découverte à l'origine par Phillip Rogaway. Découverte en 2002, aucun exploit n'a été publié jusqu'à BEAST en 2011. OpenSSL connaissait déjà le problème et c'est pourquoi il a mis à jour TLS1.0 vers TLS1.1 en avril 2006.
2 L'IV CBC pour chaque enregistrement, excepté le premier, est le dernier bloc de texte chiffré de l'enregistrement précédent. Ainsi, le chiffrement n'est pas sûr contre les adversaires qui peuvent choisir adaptativement des textes clairs ;
SSLv3/TLS1.0 sont des protocoles pour chiffrer/déchiffrer et sécuriser vos données. Dans notre cas, ils utilisent tous deux le mode de chiffrement par chaînage CBC. Le texte clair est divisé en blocs selon l'algorithme de chiffrement (AES, DES, 3DES) et la longueur est un multiple de 8 ou de 16. Si le texte clair ne remplit pas la longueur, un bourrage est ajouté à la fin pour compléter 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 que du XOR simple, vous pouvez aussi regarder cette vidéo (pas moi) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Je présenterai l'IV au point suivant. Rappelez-vous que toutes ces propriétés nous aideront à mener notre attaque.
Lorsque nous utilisons le CBC, nous avons besoin d'un vecteur d'initialisation appelé IV. Cet IV est aléatoire (ou fixe), mais en aucun cas il ne doit être prévisible par quiconque. Dans TLS1.0 et SSLv3, le premier IV de la requête est aléatoire, très bien. Mais pour gagner du temps et ne pas générer un nouvel IV aléatoire à chaque fois, l'implémentation de TLS1.0 et SSLv3 utilise le dernier bloc du texte chiffré précédent comme IV. En d'autres termes, l'IV est désormais devinable. Nous supposerons que la longueur de chaque bloc sera de 8 (DES) et que l'attaquant dispose d'un MiTM pour récupérer tout le texte chiffré.
Exemple :
C0 | C... | Ci-1 | Ci | Ci+1 |Cn
Maintenant, la partie intéressante : voici les différentes étapes cryptographiques de l'attaque pour récupérer un octet :
bbbbbbbTHIS_IS_A_SECRET_COOKIE via la victime.Vous pouvez remarquer les sept b avant le cookie secret. Si la longueur d'un bloc est de 8, nous devons placer 7 octets connus. Cette information est très importante, l'attaquant connaît les 7 premiers octets du premier bloc.
Mais pourquoi ? Cela nous permet d'avoir seulement 256 possibilités pour trouver un octet et non 256^8 pour trouver 8 octets !
Maintenant, la victime envoie la requête et elle sera chiffrée comme ceci :
C0 | C1 | C2 | C3 | C4
Où C0 = Ek(IV ⊕ bbbbbbbT) = Ek(C²n ⊕ bbbbbbbT)
Puisqu'il s'agit d'une attaque à texte clair choisi, l'attaquant peut construire un bloc P'0 comme ceci :
P'0 = C²n ⊕ C4 ⊕ bbbbbbbX
Le seul élément inconnu est X, il y a 256 possibilités, donc il essaiera au maximum 256 caractères.
La requête est envoyée et chiffrée comme ceci :
C'0 = Ek(P'0 ⊕ IV')
C'0 = Ek(C²n ⊕ C4 ⊕ bbbbbbbX ⊕ IV') ou C4 ⊕ IV' = 0
C'0 = Ek(C²n ⊕ bbbbbbbX)
C'0 = Ek(IV ⊕ bbbbbbbX)
Maintenant, il compare C'0 et C0 : s'ils sont égaux, alors il vient de trouver l'octet X en position 8. Si cela ne correspond pas, il réessaie avec un autre caractère et compare à nouveau, etc.
Maintenant que nous avons un octet, nous pouvons en obtenir un autre en décalant la requête précédente d'un cran vers la gauche : bbbbbbTHIS_IS_A_SECRET_COOKIE. Il a maintenant six b et nous connaissons aussi le T, donc nous avons un caractère inconnu. Nous construisons un nouveau P'0 = C0 ⊕ C4 ⊕ bbbbbbTX, etc...
Remarque : une autre façon avec seulement deux requêtes consiste à définir le premier bloc du texte clair et à utiliser cette information pour les trois XOR. Nous n'avons plus besoin du dernier bloc C². C1 = Ek(C0 ⊕ bbbbbbbT) puis P'0 = C0 ⊕ C4 ⊕ bbbbbbbX. Il doit aussi comparer C'0 et C1. C'est une autre façon de faire, vous pouvez remarquer que dans le PoC, je code les deux possibilités :)
Nous pouvons maintenant récupérer tous les caractères !
python BEAST-poc.py
Un attaquant ne peut pas utiliser le protocole HTTP car le premier bloc sera rempli avec GET / HTTP/1.1\r\n.
... il ne peut pas contrôler les premiers octets de chaque requête car ils sont toujours définis comme une chaîne fixe telle que GET /, POST /, etc. À la place, il peut utiliser une socket.
Il doit aussi injecter du javascript dans une page malveillante. La victime doit être connectée à cette page et y rester jusqu'à ce que l'attaque soit terminée. Il s'agit d'une attaque à texte clair choisi, donc l'attaquant peut envoyer via le code javascript tout texte clair qu'il souhaite et intercepter le résultat avec un homme du milieu. Voici le schéma de l'attaque :
Cette attaque nécessite des conditions importantes pour réussir (TLS1.0 ou inférieur, mode de chiffrement CBC, MiTM, javascript malveillant). Mais Thai Duong et Juliano Rizzo ont prouvé que c'était possible et ont démontré leur exploit en volant un cookie sur le site web Paypal.
Tout est maintenant corrigé et cette attaque a peu de chances d'être réalisée.
| Chiffrement | Déchiffrement |
|---|
| Ci = Ek(Pi ⊕ Ci-1), et C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, et C0 = IV |