Cette attaque n'est vraiment pas complexe, la partie vraiment intéressante est l'implémentation qui est un peu différente de la 'théorie'.

Vérifions la méthode naïve telle que décrite dans l'article, c'est un bon moyen de comprendre comment cela fonctionne :

L'attaquant peut contrôler les requêtes envoyées par le client (en utilisant JavaScript par exemple). L'objectif est de récupérer le cookie secret. L'attaquant envoie plusieurs requêtes comme celle-ci et vérifie la longueur des données chiffrées :

Comme cookie=q correspond à cookie=quokkalight du cookie secret, la longueur des données chiffrées sera la même et l'attaquant sait qu'il a trouvé un octet.

Mais cette méthode échoue parfois et ne peut pas être fiable, alors nous allons plutôt utiliser une autre méthode. D'abord, nous envoyons une requête avec le caractère que nous voulons trouver suivi de plusieurs caractères qui ne peuvent pas être trouvés dans la requête initiale, comme certains caractères spéciaux :chr(i) + "#:/[@/&". Ensuite, nous envoyons une seconde requête mais nous inversons la charge utile comme ceci : "#:/[@/&" + chr(i) et nous comparons les deux longueurs. Si len(enc(req1)) < len(enc(req2)) alors nous avons trouvé un octet. Cette méthode s'appelle : two_tries et elle est beaucoup plus fiable :

L'attaquant a trouvé un octet !

La méthode two_tries que j'ai implémentée est entièrement récursive, mais pourquoi ? Parfois, plus d'un octet peut être trouvé car la compression correspond à plusieurs motifs.

Prenons le secret : cookie=quokkalight, si nous exécutons l'algorithme two_tries, nous trouverons le résultat suivant :

L'algorithme doit emprunter tous les chemins de l'arbre afin de trouver toutes les solutions possibles. Nous pouvons voir tous les résultats comme un arbre qui peut être représenté ainsi :

Preuve de concept

Chiffrement de flux RC4

La preuve de concept de l'attaque CRIME contre le mode de chiffrement de flux se trouve dans le fichier : CRIME-RC4-poc.py. C'est une implémentation en Python de l'explication précédente.

Démo complète et résultat :

Mode de chiffrement CBC

Lorsque le mode de chiffrement CBC est utilisé avec AES ou DES, l'attaque n'est pas aussi simple qu'avec RC4. Comme tout est divisé en blocs, l'attaque est un peu plus délicate (mais pas trop).

Par exemple, disons que nous utilisons AES avec le mode de chiffrement CBC, le bloc sera divisé avec une longueur de 16 et un padding sera ajouté à la fin si len(data)%16 != 0. Dans le mode CBC, il est important de noter que la charge utile payload=rand produira une longueur de 16 et non de 12, car un padding sera ajouté à la fin des données avant le chiffrement. Notre attaque précédente ne peut donc pas fonctionner.

Exemple :

Dans cet exemple, la longueur sera toujours la même car si nous ajoutons ou retirons un octet, la longueur sera toujours la même, seul le padding changera. L'attaquant ne voit que les données chiffrées et il n'a aucun moyen de connaître le padding à partir des données chiffrées.

Solution : jouer avec les spécifications du mode CBC, afin que la longueur du padding soit de 1 en ajoutant une valeur aléatoire dans la variable GARB (dans le paramètre GET, puisque l'attaquant contrôle les données GET et POST)

Si l'octet correspond à un motif, la longueur sera la même ; s'il ne correspond pas, la longueur sera différente.

Ensuite, il suffit d'utiliser la même méthode expliquée dans la partie RC4, nous ajoutons simplement une étape avant.

1. nous appelons la fonction adjust_padding() afin d'obtenir un padding de longueur 1
2. nous appelons la fonction two_tries_recursive() et nous pouvons trouver le FLAG secret !

Exploit

arrive très bientôt...

Références

https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/ssl_attacks_survey.pdf https://github.com/cloudflare/cf-nocompress https://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf https://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor/19914#19914