Les attaques par oracle de bourrage en détail

En mode CBC (chaînage de blocs de chiffrement), le déchiffrement de chaque bloc consiste à déchiffrer le bloc de texte chiffré avec le chiffrement par blocs, puis à effectuer un XOR du résultat avec le bloc de texte chiffré précédent. Cette opération XOR introduit une propriété critique : en modifiant des bits dans un bloc de texte chiffré, un attaquant peut influencer de manière prévisible certains bits du texte en clair déchiffré dans le bloc suivant. Cette propriété permet l’attaque par oracle de remplissage.

Les chiffrements par blocs exigent une entrée composée de blocs de taille fixe. Le remplissage PKCS#7 complète le dernier bloc : si 3 octets de remplissage sont nécessaires, ajoutez trois octets ayant chacun la valeur 0x03. Si le bloc est déjà complet, ajoutez un bloc de remplissage entier dont les 16 octets ont tous la valeur 0x10. Lors du déchiffrement, les octets de remplissage sont vérifiés pour s’assurer de leur cohérence (les N octets ont tous la valeur N), puis supprimés. Si le remplissage est invalide, le déchiffrement doit échouer.

Un oracle de remplissage est tout système qui révèle si un texte chiffré déchiffré possède un remplissage PKCS#7 valide. L’oracle peut être : un message d’erreur explicite (« Remplissage invalide »), un code d’état HTTP différent (500 contre 403), un corps de réponse d’erreur différent, ou même une différence de temps (le déchiffrement avec un remplissage valide est légèrement plus rapide). L’attaquant n’a pas besoin de connaître la clé ; il lui suffit de disposer de ce signal binaire : remplissage valide ou non.

L’attaquant cible un bloc de texte chiffré précis. Pour récupérer le dernier octet du texte en clair, il modifie le dernier octet du bloc de texte chiffré précédent, puis envoie le texte chiffré modifié à l’oracle. Il essaie les 256 valeurs possibles jusqu’à ce que l’oracle indique que le remplissage est valide. Pour la valeur qui produit un remplissage valide (0x01), la valeur intermédiaire du déchiffrement est connue : le XOR de cette valeur avec l’octet modifié produit 0x01. Le XOR avec l’octet du texte chiffré d’origine révèle l’octet du texte en clair.

Une fois le dernier octet récupéré, l’octet avant-dernier est ciblé. La valeur intermédiaire du dernier octet étant déjà connue, il est possible de le forcer à 0x02. Les 256 valeurs de l’octet avant-dernier sont ensuite essayées jusqu’à ce que le remplissage 0x02 0x02 soit valide. Le processus se répète pour chaque octet et permet de récupérer un bloc complet de 16 octets avec 256 * 16 = 4,096 requêtes adressées à l’oracle en moyenne par bloc. Avec un oracle rapide, l’opération peut être terminée en quelques secondes.

Le processus est répété pour chaque bloc de texte chiffré, à l'exception de l'IV, qui ne peut pas être récupéré sans le bloc précédent. Un texte chiffré de 128 octets, soit 8 blocs AES, nécessite en moyenne environ 32 000 requêtes à l'oracle pour être entièrement déchiffré. Face à un serveur web traitant des centaines de requêtes par seconde, cela prend quelques minutes. L'attaquant récupère la totalité du texte en clair sans jamais connaître la clé de chiffrement.

POODLE, pour oracle de remplissage sur chiffrement hérité rétrogradé, exploitait la validation du remplissage CBC de SSL 3.0. SSL 3.0 utilisait un schéma de remplissage différent de PKCS#7, mais l'attaque adaptait le concept d'oracle. Un attaquant capable d'injecter du contenu dans une session SSL 3.0 et de forcer les clients à rétrograder vers SSL 3.0 pouvait récupérer les témoins de session à l'aide de la technique de l'oracle de remplissage. POODLE a entraîné l'abandon de SSL 3.0.

Lucky Thirteen, en 2013, exploitait un canal auxiliaire temporel dans le schéma MAC-then-encrypt de TLS utilisant CBC. La durée de vérification du MAC variait de quelques nanosecondes selon que le remplissage était valide ou non, créant ainsi un oracle temporel. BEAST, en 2011, exploitait l'IV prévisible du mode CBC de TLS 1.0 pour mener une attaque à texte en clair choisi contre les témoins de session. Ces deux attaques ont montré que le mode CBC de TLS était fondamentalement difficile à implémenter correctement.

La défense définitive contre les attaques par oracle de remplissage consiste à utiliser les modes AEAD, c'est-à-dire le chiffrement authentifié avec données associées, plutôt que CBC. Les modes AEAD comme AES-256-GCM et ChaCha20-Poly1305 vérifient l'authentification avant tout déchiffrement ou toute vérification du remplissage. Si la balise d'authentification est invalide, le déchiffrement n'a jamais lieu et aucune information sur le remplissage ne fuit. TLS 1.3 impose AEAD et supprime entièrement CBC.

Si AEAD n'est pas disponible, la construction Encrypt-then-MAC ajoute un MAC au texte chiffré, et non au texte en clair. Le MAC est vérifié avant le déchiffrement ou la vérification du remplissage. Si le MAC est invalide, l'opération est immédiatement interrompue sans révéler la moindre information sur le remplissage. Cette vérification doit être effectuée en temps constant pour empêcher les oracles temporels. L'échec de la vérification du MAC ne révèle rien sur la validité éventuelle du remplissage.

Pour rechercher les vulnérabilités d'oracle de remplissage, chiffrez un message connu, puis envoyez à l'application un texte chiffré modifié et observez la réponse. Si un remplissage valide et un remplissage invalide produisent des réponses sensiblement différentes, par exemple un message d'erreur, un code d'état ou une durée de réponse différente, un oracle de remplissage existe. Des outils automatisés comme padbuster et PadBuster recherchent spécifiquement les oracles de remplissage dans les applications web en modifiant systématiquement les textes chiffrés et en analysant les réponses.

De quoi un système cible a-t-il besoin pour qu'une attaque par oracle de remplissage déchiffre le texte chiffré sans la clé ?

Récapitulatif de l'oracle de remplissage : la propriété XOR du déchiffrement CBC permet de modifier de manière contrôlée les octets du texte en clair ; la validation du remplissage PKCS#7 révèle un oracle binaire ; l'attaquant parcourt les valeurs d'octets et observe les réponses valides ou invalides pour récupérer le texte en clair octet par octet ; les attaques réelles comprennent POODLE, Lucky Thirteen et BEAST ; la défense consiste à passer à AEAD, notamment GCM et ChaCha20-Poly1305, qui vérifie l'authentification avant le déchiffrement.