Ce verrou vous inspire confiance ? Il identifie avec certitude, au sein des navigateurs Web tel que Firefox ou Internet Explorer, que vos échanges avec le serveur sont chiffrés ? Il vous garantit que les sites sur lesquels vous saisissez vos identifiants de connexion utilisent un mécanisme d'authentification sécurisé ?
Vous en êtes sûr ?
Destiné à sécuriser les échanges sur IP et initialement développé par la société Netscape (souvenir, souvenir), le protocole SSL, pour Secure Socket Layer, est indéniablement le mécanisme de chiffrement le plus utilisé dans l'industrie du e-Commerce, et en particulier pour les transactions en ligne. Victime de son succès, ce protocole a déjà fait l'œuvre de multiples tentatives d'attaque directe, la dernière en date s'appuyant sur les problématiques de collision autour de l'algorithme MD5.
Cependant la démonstration faite il y a quelques jours au cours de la dernière conférence sécurité Black Hat propose une approche beaucoup plus sympathique, une attaque moins frontale, moins brutale : l'objectif n'est pas de s'en prendre directement au protocole SSL mais plutôt d'en comprendre son implémentation, son utilisation, et en particulier lorsqu'il est couplé à HTTP et aux pages HTML.
Le postulat de base est le suivant : la plupart des requêtes de type HTTPS ne sont pas initiées par l'utilisateur, il ne saisit que très rarement une URL HTTPS directement dans la barre d'adresse du navigateur. Elles sont donc principalement à l'initiative :
- soit d'une redirection de type HTTP 302 : l'utilisateur subit alors un renvoi automatique de la page courante, en clair, vers une page sécurisée
- soit d'une balise HTML de type HREF, un sous-lien HTTPS au sein de la page : l'exemple type est la fenêtre proposant les champs login et password qui n'activera le chiffrement de la communication que lorsque l'utilisateur cliquera sur le bouton "se connecter" (on ne protège que l'action d'authentification)
La technique utilisée pour fomenter l'attaque est de type Man in The Middle : le principe consiste à se mettre entre le client et le serveur, et à intercepter le trafic. Jusque là, rien de bien transcendant. Mais la subtilité de ce Proof of Concept réside principalement dans le fait que l'on va chercher à agir sur les informations renvoyées in fine aux navigateurs en modifiant dans le corps même de la page, les liens HTTPS et en les replaçant par des liens HTTP. Le schéma d'échange devient donc :
- se positionner, avec un moteur proxy, entre l'utilisateur et le service accédé et intercepter le trafic dès le début des interactions
- remplacer la totalité des liens HTTPS par des liens HTTP dans la page renvoyée par le serveur au client, et conserver en mémoire la table d'association
- par voie de conséquence, n'échanger donc qu'en clair avec le client et qu'en mode chiffré avec le serveur
- coté serveur, le proxy se comporte comme un client lambda
- coté client, il est délicat de voir la différence entre une page contenant des liens HTTPS ou HTTP. Petit raffinement, la requête favicon pouvant être interceptée comme toutes les autres afin d'afficher une image dans la barre d'adresse ... allez, au hasard : un verrou
Une fois cette proxyification transparente mise en œuvre, la totalité du trafic peut donc être lu, et on y retrouvera au final des identifiants de connexion à des services de banque en ligne, de paiement type Paypal ou encore de Webmails. Sur le fond, cette attaque s'appuie essentiellement sur des manquements qui ne sont pas d'ordre techniques : des sites mixant maladroitement des pages en clair et des liens sécurisés, des utilisateurs certainement pas assez vigilants et des browsers aux comportements d'alerte trop peu explicites. Voilà un cocktail bien détonant !
Ah, j'en vois au fond qui s'agite : oui, la proxyification en mode transparent avec interception du flux SSL à la volée n'est pas une nouveauté. Oui, les moteurs de réécriture, d'URL et de contenu, existe déjà. Oui, des solutions commerciales implémentent depuis quelques années certains de ces mécanismes. Mais on notera le juste équilibre entre utilisation de la technologie, le détournement des Best (mauvaises) Practices actuellement mise en œuvre pour coder les pages, et la volonté de vouloir donner à l'utilisateur, au final, un sentiment de ... totale sécurité.
PS : Pour les besoins de la démo, le réseau Tor aura été malmené. Quand à l'outil SSLStrip utilisé, il est désormais disponible ici.
nsp