POODLE ou la morsure d’un (vieux) caniche (CVE-2014-3566)

POODLE ou la morsure d’un (vieux) caniche (CVE-2014-3566)

Les trois chercheurs Bodo Möller, Thai Duong, and Krzysztof Kotowicz viennent le 14 octobre de remettre le monde dans la torpeur des vulnérabilités du protocole SSL.

En effet POODLE (pour Padding Oracle On Downgraded Legacy Encryption) est une vulnérabilité touchant le protocole SSLv3 et le moins que l’on puisse dire c’est qu’elle semble avoir enterré cette version du protocole pour de bon.

Pourquoi pour de bon ?

Eh bien parce que malgré l’effet de surprise généré par l’annonce, il faut rappeler que le protocole TLS qui a fait suite au SSLv3 est disponible depuis 1999 (RFC 2246). Et depuis, plusieurs dates ont marqué l’histoire du SSL.

POODLE est donc une vulnérabilité, de plus, dans le protocole et non une erreur d’implémentation comme l’a été HEARTBLEED très récemment.

Cette vulnérabilité a été rendu possible par deux choses :

  • Le fait de pouvoir réduire la sécurité d’un échange SSL entre un client et un serveur pour des besoins d’interopérabilité.
  • Une faiblesse cryptographique présente dans SSLv3.

The downgrade dance:

Le terme de « downgrade dance » est un terme utilisé en informatique pour désigner un échange dans lequel un des participants affirme à l’autre qu’il ne peut fonctionner sur ce niveau de chiffrement et qu’il lui faut donc passer à un chiffrement moins récent pour conserver l’interopérabilité.

Ainsi, pour POODLE, le client affirmera au serveur qu’il ne peut fonctionner autrement qu’en SSLv3 et le serveur (dans une très grande majorité des cas) acceptera cette demande.

Il faut comprendre qu’aujourd’hui avec POODLE plus aucun mode de chiffrement n’est fiable en SSLv3

BEAST, CRIME et Lucky13 visaient le mode RC4
POODLE vise le mode CBC

 

Padding oracle attack :

L’origine de la faiblesse cryptographique n’est pas nouvelle, en effet en 2001, Serge VAUDENAY, dans le document « CBC Padding Security Flaws in SSL, IPSEC, WTLS, … » expose une attaque possible sur les échanges chiffrés n’utilisant pas un canal sécurisé.

Dans ce type d’échange, un attaquant dans une position active (Man-in-the-middle) est libre de modifier le contenu dans un échange sans que celui-ci soit invalidé pour autant. Le contenu déchiffré ne sera pas correct mais le serveur aura quand même répondu.

Ainsi, il devient possible pour l’attaquant de tirer des conclusions sur les messages chiffrés en observant les réponses du serveur.

C’est ici que le padding oracle intervient.
Sans rentrer dans des considérations cryptographiques bien assez documentées sur le net, il est important de comprendre plusieurs choses :

  • Le padding ou rembourrage est un procédé qui va rendre la taille des données échangés compatible avec les algorithmes utilisés.
  • La méthode de rembourrage utilisée n’est pas la même d’un algorithme à un autre.
  • Certaines méthodes de rembourrage sont vulnérables à des attaques visant à observer le résultat du rembourrage une fois chiffré (Voir l’attaque de Serge VAUDENAY)

Le principe est le suivant :

Dans un mode de chiffrement en CBC (Cypher block channel) chaque bloc doit-être de valeur identique. Ainsi pour un fonctionnement avec 3DES il faudra des blocs de 8 octets.

Si la chaîne d’entrée, une fois découpé en bloc, ne satisfait pas cette condition, alors le rembourrage intervient en plaçant n-octets suivi d’un octet équivalant à la longueur du rembourrage. Ainsi pour un rembourrage complet la valeur de l’octet final sera 7.
La valeur des octets du rembourrage importe peut étant donné que seul le dernière octet sera utilisée pour vérifier l’intégrité.

Un attaquant pouvant modifier une requête va tenter l’opération suivante :

Prenant pour modèle une requête donnée en exemple dans l’annonce de sécurité :

POST /path\r\n
Cookie: name=value…\r\n
\r\n
body ‖ 20 byte MAC ‖ padding

Ici l’attaquant maîtrise le chemin et le corps.

Dans le cas hypothétique (une solution pour le forcer est proposée dans l’annonce de sécurité) où le bloc final, le padding, constitue un bloc complet alors nous aurons comme valeur
[X X X X X X X 7] (Bloc de 8 octets en 3DES)

Cette valeur va être remplacée par le bloc chiffré qui nous intéresse.

CBC mode decryption

CBC mode decryption

 

Ce qui se traduit dans notre exemple par :

[Cookie chiffré] [MAC] [Padding]

[Cookie chiffré] [MAC] [Cookie chiffré]

Déchiffrement suivant la formule :

E = Block chiffré
C = Block déchiffré
P = Texte final
i = un octet

Pi = Ci XOR Ei

La vérification ne se réalisant que sur le dernier octet, si celui-ci vient à correspondre au nombre d’octets ajouté en padding, soit 7 dans notre exemple, alors le serveur validera la requête.

Du fait que le chiffrement du bloc précédent est généré aléatoirement, nous avons une chance sur 256 (1 octet pouvant prendre une valeur comprise en 1 et 255) d’obtenir un 7.

Dans le cas où l’opération n’aboutit pas sur ce résultat, alors le serveur rejettera la connexion obligeant l’attaquant à rejouer l’attaque. Nouveau chiffrement, nouvelle clé, nouveau random et donc de nouveau 1 chance sur 256.

Ainsi en moyenne l’attaquant produira 128 tentatives avant de tomber sur le bon octet.

Si le serveur a validé la connexion, l’attaquant n’aura plus qu’à réaliser un XOR du texte final déchiffré avec l’avant dernier bloc chiffré.

Ci = Pi XOR Ei

Il obtiendra un bloc dont l’octet final correspond à la valeur déchiffrée du bloc que l’on a substitué.
Si le serveur et le client fonctionnent en TLS l’attaque, échoue car c’est l’ensemble du padding qui devra être vérifié et non uniquement le dernier octet.

La mise en place d’une telle attaque demande donc que l’attaquant soit en position de man in the middle et que le client ainsi que le serveur acceptent de passer leurs communications en SSLv3
Le problème est que par souci d’interopérabilité énormément de serveur et navigateurs continuent d’accepter le protocole SSLv3.

Le niveau de sévérité de cette vulnérabilité reste donc maximum même si la difficulté d’exploitation en fait une vulnérabilité moins impactante qu’une vulnérabilité type HEARTBLEED.

 

Comment se protéger? :

La correction de cette vulnérabilité demande de :

  • Désactiver le support du SSLv3 sur les postes clients.
  • Désactiver le support du SSLv3 sur les serveurs.

Une alternative :

  • Mettre en place de l’extension TLS_FALLBACK_SCS

Attention, désactiver le support du chiffrement en CBC sur le SSLv3 ne corrige pas le problème car, comme nous l’avons vu, il n’y a plus de mode de chiffrement sur cette version

TLS_FALLBACK_SCS

(draft disponible sur http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00)

Cette dernière solution propose l’ajout d’un nouveau mode de chiffrement au protocole TLS.
Ce nouveau chiffrement n’est toutefois pas sélectionné par le serveur comme mode de chiffrement. Sa présence n’est là que pour assurer la rétrocompatibilité entre le client et le serveur.

Pour faire simple :

Si TLS_FALLBACK_SCSV apparaît dans le message « ClientHello.cipher_suites » et que la version la plus élevée du protocole pris en charge par le serveur est plus élevée que la version indiquée dans ClientHello.client_version alors le serveur doit répondre à une alerte sur la demande de retour à une version antérieure car celle-ci est simulée.

Sinon, la connexion s’effectue correctement.

Il est fortement conseillé d’utiliser cette méthode dans les cas où l’interopérabilité du système oblige la régression vers SSLv3 en mode CBC.
Dans les cas contraires, la désactivation de SSLv3 reste la solution à appliquer.

 

Références :

http://openssl.org/~bodo/ssl-poodle.pdf
http://www.signelec.com/content/download/crypto/SSL_etude_J_C_Asselborn.pdf
https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html
http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation