Fin du feuilleton de la faille TLS/SSL ?

En Novembre était révélée une faille dans le protocole de sécurité TLS/SSL (dite faille de la renégociation). C’est Marsh Ray (de la société Phonefactor) qui avait fait cette découverte (mon article sur ce sujet) et plus tard, elle avait pu être exploitée contre Twitter (et le deuxième article ici).

L’IETF vient donc d’annoncer la validation de la modification apportée à la RFC du protocole TLS, comme nous le révèle Marsh Ray sur son blog. En résumé, il s’agit de la correction au protocole telle qu’elle avait été proposée initialement. Elle devra être appliquée tant sur les serveurs (les serveurs Web notamment) que sur les clients (vos navigateurs). Vous risquez donc de voir apparaître dans le futur des messages d’avertissement sur des connexions vers des serveurs en https:// dont la sécurité n’aura pas encore été renforcée.

La vulnérabilité SSL/TLS démontrée sur Twitter

Twitter_Badge_1[1]Au début du mois de Novembre, une vulnérabilité touchant la fonction de re-négociation des protocoles de sécurisation SSL/TLS était rendue publique (et j’en avais déjà parlé ici). Cette semaine, une nouvelle démonstration de cette faille a été faite sur la plateforme Twitter. La société Twitter a déjà corrigé cette faille.

TLS-renegotiate[1]

Cliquer sur l'image pour aller vers l'article

D’abord, un pointeur vers un autre article qui décrit le principe de l’attaque découverte initialement par un joli schéma.

 

Beaucoup de spécialistes ont rapidement souligné que cette vulnérabilité ne devrait pas avoir d’application facile dans la vie réelle. Malheureusement il semble qu’il faille effectivement la prendre au sérieux. En effet, Anıl Kurmuş, jeune chercheur en sécurité Suisse, a rendu public une démonstration (il l’annonçait mercredi 11 novembre sur Full Disclosure) de la possibilité d’exploiter cette attaque sur Twitter.

Le principe sous-jacent est assez simple puisqu’il repose sur la fonctionnalité même de Twitter qui vise à laisser l’utilisateur publier n’importe quoi. Il a suffi à Anıl Kurmuş de détourner l’API (interface de programmation) de Twitter pour publier en lieu et place du message une partie du cookie, qui contient systématiquement le mot de passe codé, dans le cas de Twitter:

 

mitm

Démonstration d'Anil Kurnus

Il ne reste plus qu’à décoder l’identification qui est ici transmise en Base 64 (ou à la réutiliser telle qu’elle !). Twitter aurait depuis le 10 novembre corrigé la faille. On peut suivre l’évolution des publications des mises à jour des applications concernées par la faille de re-négociation SSL/TLS sur le site de Phonefactor, pour l’instant une version mise à jour d’OpenSSL 0.9.8l bloque déjà la fonction de re-négociation, en attendant un correctif plus pointu.

Une faille dans le protocole SSLv3/TLSv1

Une faille des protocoles SSL/TLS qui assurent notamment la sécurité des connexions vers les serveurs web (lorsque l’adresse est en https://) a été révélée hier. (click here if you want an automated translation to English)

Histoire récente de la découverte de la faille

Marsh Ray annonce sur son blog qu’il aurait découvert cette faille lors de travaux pour sa société Phonefactor. Les premiers cercles ont été informés de cette découverte au début septembre 2009 et une réunion s’est tenue le 29 septembre 2009 à Mountainview, CA. Nom de code utilisé par le groupe qui s’est donné pour mission de corriger cette faille: « Project Mogul ».

Hier, 4 novembre 2009, Martin Rex (SAP) a présenté publiquement sur la liste de discussion TLS de l’IETF une idée approchante et depuis l’annonce à commencé à faire le tour des blogs et autres twitts.

Description de la faille

La faille porte sur les phases de re-négociation entre le client et le serveur.

Les étapes du dialogue TLS (entre un client et un serveur):

  • Le client dit bonjour et indique les technologies de chiffrement acceptées,
  • Le serveur répond et précise quelle technologie de chiffrement il préfère, il joint un certificat de chiffrement et indique qu’il a fini la phase de premier contact,
  • Le client calcule une clé de chiffrement, la transmet de façon sécurisée grâce au certificat fourni par le serveur et lance une commande Change Cipher Spec pour activer le chiffrement,
  • A partir de ce moment tous les messages échangés sont chiffrés.

Le protocole permet à chacune des parties à l’échange de demander une re-négociation à n’importe quel moment.

Les scénarios d’attaque décrits par Marsh sont les suivants:

  1. Lors de l’authentification des clients sur la base de certificats,
  2. Lorsque le serveur nécessite plusieurs technologies de chiffrement,
  3. Lors d’une re-négociation initiée par le client (fonctionne sur des serveurs Apache).

Dans tous les cas, il s’agit pour l’attaquant placé en « man in the middle » d’insérer des commandes au début du dialogue (donc avant le chiffrement) qui seront rejouées au moment de la re-négociation. Et cela même si la re-négociation passe dans le canal chiffré.  Ainsi, si le texte inséré au début est fabriqué de façon intelligente, il permet d’imaginer différentes solutions pour contourner le chiffrement (dans les exemples donnés, il s’agit d’insérer une commande de chargement d’une page web malicieuse et une commande pour ignorer ce qui suit, c’est-à-dire la requête normale du client).

marsh-exemple

Code inséré

Et maintenant ?

Il aurait été démontré qu’aussi bien Apache qu’IIS de Microsoft étaient sensibles selon les cas à ces attaques. Il n’est pas certain que toutes les situations aient été explorées. Même si un tel mécanisme est très complexe à mettre en œuvre en pratique (les attaques de type man in the middle sont complexes) et suppose un certain nombre d’hypothèses, il démontre que les protocoles de sécurisation ne sont pas suffisamment intégrés avec les protocoles applicatifs tels qu’HTTP. Marsh décrit aussi dans son papier un scénario hypothétique où il serait possible d’obtenir des informations confidentielles sans que le client se connecte volontairement au site web objet de l’attaque.

Il existe encore un débat pour savoir si des utilisateurs de sites Web simples (donc sans authentification du client par un certificat) sont concernés, Marsh affirme que c’est bien le cas.

Très rapidement des propositions devraient être faites par l’IETF pour des modifications au protocole TLS et des mises à jour de GNU TLS et OpenSSL sont en cours de validation. Des annonces plus rapides que prévu sont donc à venir.

Techniques fines d’attaque SSL

Lors de la récente conférence Black Hat DC 2009, un certain Moxie Marlinspike a fait une présentation intéressante montrant les différentes techniques qu’il a explorées permettant de contourner de façon efficace et aussi discrète que possible vis à vis de l’utilisateur la sécurisation SSL des sites Web.

Vous pouvez visualiser sa présentation ici.

Technique présentée

Il y a quelques années, l’auteur a présenté l’outil « SSLSniff » permettant de gérer une attaque de type « man in the middle » sur une connexion SSL entre un client et un serveur Web. C’est un des outils utilisés dans l’attaque des certificats SSL basés sur des MD5 dont j’ai parlé ici-même voici quelques semaines. Il s’agit ici d’améliorations de ce programme d’attaque.

Une des premières particularités des sites web sécurisés que Marlinspike met en avant est l’habitude très courante des banques et autres services en ligne de mettre en place des boîtes de dialogue de connexion qui sont effectivement sécurisées (l’identifiant et le mot de passe sont envoyés par une connextion HTTPS) mais sont lancées à partir d’une page web elle-même non sécurisée (http://www.exempledebanque.fr). L’utilisateur n’est donc pas familiarisé avec les fonctions de sécurité et il faut en fait être assez savant, aller dans le code de la page web qu’on visite pour s’assurer que son mot de passe est bien transmis de façon chiffrée.

A contrario, l’auteur démontre que lorsqu’on essaye d’impliquer l’utilisateur dans la vérification de la sécurité, il peut être rapidement perdu : d’une version à l’autre d’un navigateur la façon dont est affichée la sécurité varie beaucoup, le petit cadenas n’apparaît pas toujours au même endroit, les couleurs ne sont pas toujours les mêmes, etc…

L’idée présentée par l’auteur est donc de profiter du fait que la plupart du temps l’utilisateur accède à une page sécurisée en passant par la page d’accueil non chiffrée du site visité. En remplaçant à la volée, dans le code de la page les https:// par des http:// il force le navigateur à rester en clair. La connexion https est effectuée uniquement entre le serveur web et l’attaquant. L’avantage de cela est que l’utilisateur ne voit sur son navigateur aucun message d’avertissement lié à la détection d’un certificat SSL invalide.

Ensuite, l’attaquant introduit dans la communication une icone « favorie » ressemblant au petit cadenas que l’utilisateur a l’habitude de voir… firefox-google Sur le présent blog, vous voyez par exemple le petit logo en forme de W sur fond bleu de wordpress.com à côté de l’URL : firefox-wordpress

Enfin, son programme SSLSniff gère un certain nombre de particularités des échanges entre le navigateur et le site Web (les cookies sécurisés, la gestion des sessions, …) soit en les empêchant d’arriver jusqu’au navigateur, soit en les manipulant (voir la présentation vers la 34ème minute pour comprendre les détails).

Résultats

Ses essais lui ont permis en 24 heures d’intercepter (en se positionnant sur un noeud Tor) des identifiants yahoo, Gmail, ticketmaster, rapidshare, hotmail, paypal, linkedin, facebook… Ce qui montre la faisabilité de cette attaque sur des sites web très utilisés. L’auteur profite de l’occasion pour rappeler que des mots de passe sont souvent utilisés à l’identique sur plusieurs sites par les mêmes utilisateurs.

Les essais suivants lui ont aussi permis de s’assurer que sur 24 heures, aucune tentative de connexion sécurisée forcée (qui contournerait donc son programme SSLSniff) n’a été remarquée.

Encore plus fort

La suite de sa présentation est encore plus intéressante. Tout d’abord il rappelle la possibilité d’utiliser aujourd’hui des noms des domaine comportant des caractères spéciaux, comme les caractères accentués du français, les caractères chinois, etc… Certains d’entre eux sont très ressemblants aux caractères classiques, comme le « a » cyrillique qui ressemble à un a classique à l’affichage, mais est codé différemment.

Ensuite, il a enregistré un nom de domaine (ijjk.cn), pour lequel il a fait signer un certificat SSL pour le domaine entier (donc pour *.ijjk.cn) et ensuite, en utilisant des caractères du codage IDN (noms de domaines internationalisés) qui ressemblent aux . / et ?, comme les caractères / de l’exemple ci-contre : firefox-google-slash (regardez bien ceux qui entourent « accounts », ce sont en fait des caractères différents du /). Et donc on se retrouve à visiter un site appartenant au domaine possédé par l’attaquant du type https://quelque-chose-de-long-ressemblant-à-mon-adresse-de-banque.ijjk.cn dont le certificat SSL sera correct !

Comment faire pour se protéger contre ce type d’attaques ?

La première fois que vous vous connectez sur le site sécurisé de votre banque (ou autre), vérifiez bien que le certificat correspond au site que vous voulez visiter et possède une chaîne de certification sans intermédiaire louche. Ensuite, mémorisez dans votre navigateur l’adresse sécurisée de connexion du site plutôt que de taper à chaque fois l’adresse de la page d’accueil…

La sécurité des certificats SSL en cause

lock-iconDes spécialistes venant des USA, des Pays-Bas et de Suisse (Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger) ont annoncé avoir mis en défaut les certificats de sécurité SSL de sites Web émis par des sociétés de sécurité reconnues, lors du 25C3, la conférence Chaos Communication Congress 2008 organisée par le Chaos Computer Club allemand, qui s’est tenue à Berlin du 27 au 30 décembre 2008.

Tout d’abord, à quoi cela sert-il ? Différents algorithmes sont utilisés pour produire des « hachages » sensés représenter de façon unique tout document numérique. Les fonctions de hachage à usage cryptographique doivent posséder différentes caractéristiques :

  • la très grande difficulté de retrouver ou de recalculer le document numérique initial ;
  • à partir d’un premier document et de sa valeur de hachage, il est très difficile de retrouver un document numérique ayant la même valeur de hachage (en particulier, toute modification, même mineure, du document initial, entraîne une modification très importante de la signature calculée) ;
  • il est très difficile de tomber au hasard sur deux documents ayant la même valeur de hachage.

Par document numérique, on entend une suite d’octets de longueur non nulle (un fichier informatique, un flux d’informations numériques, …) Mais, on comprend donc très bien que ces fonctions qui à tout document numérique associent un nombre dont la longueur est donnée, ont forcément un risque de collision non nul. En effet, puisque la variété des documents numériques de toutes tailles est infinie et que l’on cherche à la représenter par une valeur finie, il y a pour chaque valeur de hachage un grand nombre de documents numériques théoriquement possible.

Il existe différentes fonctions de hachage utilisées classiquement: MD5, SHA-1, Tiger,… La longueur des signatures MD5 est de 32 octets ou 128 bits. Dans un certificat utilisé pour identifier un serveur web, cette fonction de hachage est utilisée sur l’ensemble des informations contenues dans le certificat (le nom du serveur, ses dates de validité, etc.) et c’est cette valeur qui est ensuite signée numériquement par une fonction cryptographique. Sur l’image ci-dessous vous pouvez-lire ces différentes informations pour le certificat SSL du site web http://www.verisign.com :

Certificat www.verisign.com

Plus précisément, ces certificats sont signés par une autorité de certification qui est elle-même reconnue par une autorité de certification « racine ». Ce sont – normalement – les certificats de ces autorités de certification « racines » qui sont pré-installés dans nos navigateurs (il est possible d’en installer volontairement d’autres, en fonction de besoins internes à son entreprise par exemple).

Dès 2004, des chercheurs ont démontré qu’il était possible de fabriquer des documents différents possédant la même signature MD5.  Ce qui a été rapidement très inquiétant c’est qu’il était possible de fabriquer des documents très ressemblants (des PDF par exemple) ayant la même signature, mais dont un élément important était différent (dans l’exemple présent sur ce site : http://www.win.tue.nl/hashclash/Nostradamus/, 12 documents prédisant le résultat de l’élection présidentielle avec des noms différents).

Ce qui est inquiétant aujourd’hui c’est que d’importants prestataires en matière de fourniture de certificats permettant d’identifier des sites web (et d’autres fonctions de signature électronique en fait), autorités de certification reconnues par tous les navigateurs Internet, autorisent encore la fabrication de certificats basés sur des hachages MD5.

De façon assez amusante, mais pas surprenante étant donnée la puissance de calcul des consoles de jeux, les chercheurs qui ont présenté leurs résultats au 25C3 ont utilisé des batteries de consoles Sony Playstation 3. Ils ont ainsi démontré qu’il était possible de fabriquer, pour un coût assez raisonnable un certificat pour une autorité de certification « pourrie ». Cette autorité de certification leur permet de fabriquer des certificats reconnus par la plupart des navigateurs Internet.

Quelle réponse apporter ?

Les auteurs de cette démonstration donnent un certain nombre de recommandations :

  • ils confirment tout d’abord que les autorités de certification identifiées comme utilisant encore des fonctions MD5 ont été prévenues et sont en train de prendre des mesures immédiates (voir par exemple l’annonce de Verisign) ;
  • ne plus utiliser MD5 dans des fonctions de signature, et éviter sur de nouveaux projets d’utiliser SHA-1 (en effet, il existe différents indices montrant que SHA-1 devrait rencontrer le même sort assez rapidement…).

On peut aussi souhaiter que la profession d’autorité de certification soit un peu mieux réglementée. En effet, différentes publications ont montré récemment qu’il était possible, dans certaines conditions, d’obtenir un certificat pour un nom de domaine dont on n’est pas propriétaire…

Pourquoi est-ce que tout cela est important ? Ce n’est pas tant le risque que votre communication soit interceptée, mais surtout que vous ayez confiance dans l’identité du serveur auquel vous vous connectez.

Mais que peut faire l’utilisateur individuel en pratique ? Peut-être faire confiance aux sociétés émettrices de certificats, qui grâce au système des listes de révocation vont rapidement débarrasser l’Internet de ces certificats malhonnêtes (note du 06 janvier 22:20, encore qu’il semble qu’ils ne soient pas décidés à utiliser la révocation, pour éviter de léser leurs clients). Mais pour les applications les plus importantes (votre banque par exemple), vous pouvez jeter un coup d’œil à l’algorithme utilisé pour la signature. Voici la marche à suivre :

Sous Mozilla, par exemple, une fois connecté sur le site de ma banque, je double clique sur le cadenas de sécurité ce qui me permet d’afficher le certificat utilisé (semblable à l’image d’illustration utilisée plus haut) et je demande ensuite à afficher les détails de ce certificat. Dans la liste des caractéristiques, je retrouve un champ intitulé : « Algorithme de signature des certificats » (sous Internet Explorer, on retrouve « Algorithme de signature »). Dans mon cas cela affiche : « PKCS #1 SHA-1 avec chiffrement RSA ». Pas de MD5 ici !

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 135 autres abonnés

%d blogueurs aiment cette page :