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… 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 :

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 : (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…

Tags: SSL