Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

HTTPS ... pwned !

HTTPS ... pwned !
2009-02-252013-02-11Web/Techfr
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...
Publié le 25 Février 2009 par Olivier Rodier dans Web/Tech

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.

2 Commentaires

  • 25 Février 2009
    2009-02-25
    par
    @ Jean-Sébastien

    Merci de votre commentaire.

    Pour répondre à la question : oui, le verrou, ou plus globalement, les signes extérieurs (verrou en bas de fenêtre du navigateur, changement de couleur au sein de la barre d'adresse, ...) se manifestent lorsqu'une connexion sécurisée est établie. Mais uniquement quand la totalité de la page est chargée en HTTPS (lien maitre). Hors, de très nombreux sites, demandant une authentification entre autre, appellent justement cette page principale en HTTP (souvent pour des raisons de performance, le SSL/handshake est généralement couteux en ressource CPU/RAM et donc, en temps) et seule l'action de click sur le bouton login déclenchera une requête en HTTPS. On se retrouve donc avec des mix HTTP/HTTPS intra-page.

    Pour illustrer à quel point cette approche est trompeuse, ces sites "détournent" les mécanismes d'alerte des navigateurs, le meilleur exemple est très certainement l'affichage d'un verrou, sous forme d'image, au sein de la page d'accueil (Hotmail, ...). La bidouille du Favicon (qui n'indique absolument pas que la connexion est sécurisée) ajoute de la confusion : on affiche l'habituel verrou, image emblématique de la sécurité, en entête de la barre d'adresse. Couplons à cela le fait que le navigateur n'affiche aucun warning de part l'action de MitM avec réécriture des liens HTTPS en HTTP, et nous nous trouvons donc dans une situation où, à coup sur, l'utilisateur lambda sera trompé.
  • 25 Février 2009
    2009-02-25
    par
    Jean-Sébastien H.
    Intéressant mais une petite question : le verrou n'est il pas sensé apparaitre parce que le navigateur a établie une connexion sécurisé ?

    D'autre part, le favicon n'indique pas que la connexion est sécurisé. Par contre si le certificat est d'un certain type (class 3?) et que l'autorité de certifications est reconnu comme autorité reconnu (Root CA ?) par le navigateur alors celui affiche le logo sur fond vert.

    Par contre si le trafic est crypté coté clients avec un certificat hacké (cf md5), alors la le client ne verra rien.

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage