Récemment, des chercheurs ont fait une brillante démonstration de la faiblesse de MD5. Ils ont réussi à exploiter des collisions dans la fonction de hachage, et à prédire des serial numbers sur une AC afin de créer un rogue certificat d'Autorité de Certification (AC). Conséquence ? Possibilité de signer un certificat d'AC signée par une AC de confiance. Donc possibilité à gogo de créer de vrais certificats acceptés par les navigateurs. Je vous laisse imaginer les conséquences désastreuses.

Explication de la méthode

Comme dit dans l'introduction, le cœur de l'attaque est MD5.  Mais pas seulement. L'utilisation d'un Serial Number trop facilement prévisible ainsi que de la date de création du certificat a permit l'exploit.

MD5 : fin d'une vie

Son but, comme toute fonction de hachage, est de donner une empreinte numérique de 16 octets. Elle doit posséder plusieurs propriétés :

  • résistance à la première pré-image :réputé difficile de trouver un antécédent connaissant son image.
  • résistance à seconde pré-image : réputé difficile de trouver une entrée différente possédant le même condensé.
  • résistance aux collisions : réputé difficile de trouver deux entrées possédant le même condensé.

Mais MD5 ne respecte plus la dernière propriété. Il existe des algorithmes suffisamment performants pour générer des collisions.

Rapide autopsie d'un certificat X.509

Structure

Dans un certificat X.509, nous trouvons plusieurs champs comme :

  • Version
  • Serial Number
  • Algorithme de hash (ici, ce sera MD5)
  • Nom du signataire
  • Validité
  • Détendeur
  • Algorithme de clé publique
  • Clé publique
  • ...
Vérification

Ces informations (M) vont être signées par l'AC avec sa clé privée D (dont sa clé publique associée est E) empêchant toute altération du certificat. Grosso modo, le certificat est donc de la forme : M | S, avec S=D(M) et | opérateur de concaténation.

En effet, à la réception du certificat sur un site HTTPS, le navigateur va :

  • regarder la date du certificat,
  • comparer  MD5(M) et P(S),
  • vérifier de proche en proche la validité des certificats des signataires jusqu'à en trouver un de confiance dans sa base.

Si le certificat n'est pas valide, ou si le navigateur est remonté au certificat root sans en trouver un de confiance, celui-ci émettra un avertissement.

Prérequis de l'attaque

En plus de trouver une AC utilisant MD5 en hachage, il faut que celui-ci utilise une génération de serial number prévisible et qu'on puisse deviner la date de création du certificat. RapidSSL a donc logiquement été choisi comme cible :

  • six secondes entre la demande et la création du certificat,
  • le serial number est simplement incrémenté à chaque certificat

Attaque

Les deux champs que l'attaquant ne maîtrise pas dans le certificat sont la date de création du certificat et le serial number. Le but est donc de réussir à ce que l'AC signe notre certificat avec un serial number donné à une date donnée.

Sachant qu'il faut environ trois jours pour obtenir une collision "jouable" sur 200 playstations mises en clusters (configuration des chercheurs), il faudra être capable de prédire un serial number trois jours à l'avance.

Ainsi, trois jours à l'avance, on achète un certificat pour connaître le serial number SN. On prévoit que 72 heures plus tard, le serial number sera un peu plus petit que SN+1000, sachant que SN+1000 correspond au serial number que nous voulons obtenir à la date T pour respecter notre collision. Comment faire ?

Quelques heures avant T, on achète des certificats pour se rapprocher de plus en plus de SN + 1000 de sorte que 30 secondes avant T, le serial number soit à SN+999. Ensuite, il ne reste plus qu'à envoyer une demande de certificat à T-6 (cf prérequis) pour obtenir un certificat signé avec pour serial number SN+1000 dont la date de création est T.

Il ne reste plus qu'à mettre la signature du vrai certificat sur le rogue certificat d'AC créé lors de notre collision. Et comme les MD5 sont les mêmes, la signature sera la même. Nous sommes dont en présence d'un certificat d'AC ayant une signature valide puisque signée par une AC de confiance bien que cette dernière ne l'a pas vu.

Conséquence

Avec un certificat d'AC valide dont on a la clé privée, il est possible de bypasser complètement l'intérêt de SSL. En effet, il est possible de créer les certificats qu'on veut grâce à notre rogue certificat. Le navigateur n'y verra que du feu. Les attaques Man-in-the-Middle n'échoueront donc pas, même en SSL. Désastreux. En combinaison avec la vulnérabilité récente du DNS trouvé par Kaminsky, un pirate parviendra à faire du phishing indétectable.

Solution

Pour les AC, ne pas utiliser MD5 en tant que fonction de hachage. Même si on le sait depuis longtemps que MD5 n'est plus sûr, on a enfin un PoC. Il faut utiliser au moins SHA-1 ou mieux SHA-256.

Il est également important pour les AC de fournir un Serial Number non prévisible.

Il faut renouveler toutes les AC impactées et tous les certificats générés par ces dernières.

Pour les particuliers, il peut être intéressant d'utiliser Perspectives comme plugin pour firefox qui se base sur un réseau de notaires.

Note

Il est important de souligner que c'est MD5 le fautif et non SSL.

Lien

  1. http://www.win.tue.nl/hashclash/rogue-ca/
  2. http://eprint.iacr.org/2005/067
  3. http://sid.rstack.org/blog/index.php/316-ssl-n-est-pas-mort-contrairement-a-md5
  4. http://www.unixgarden.com/index.php/securite/les-fonctions-de-hachage-sortiraient-elles-de-lombre