HTTPS et HSTS : Duo gagnant

Salut à tous !

Jusqu’ici, la principale limitation que j’ai soulignée à propos de Sergio-Proxy (cfr. la série sur les Rogue AP), c’est qu’il ne fonctionne qu’en HTTP et pas en HTTPS. On pourrait tenter de « forcer » le trafic à passer en HTTP, mais quand on creuse un peu on se rend compte qu’avec les navigateurs récents, ça coince sur un certain nombre de sites. Nous allons voir pourquoi dans cet article, et en profiter pour répondre à une question existentielle :

Pourquoi SSLStrip ne fonctionne-t-il plus sur certains sites bien connus ?

(Si avec ça j’ai pas un bon référencement… :P)

Je ne ferai pas de long rappel sur le HTTPS, mais je vais resituer un peu le contexte quand même. Le but du HTTPS est de chiffrer le contenu entre le client et le serveur, rendant les données indéchiffrables pour tous les intermédiaires (même un attaquant en MITM). En tant qu’utilisateur c’est une bonne nouvelle, en tant qu’attaquant c’est plutôt un obstacle.
L’attaque « traditionnelle » contre le HTTPS consistait à se mettre en MITM et présenter un certificat bidon à la cible, pour être capable de déchiffrer soi-même le trafic HTTPS. Ettercap (et d’autres) se basaient sur ce principe, mais il fonctionne de moins en moins aujourd’hui (tous les navigateurs récents affichent un avertissement flippant s’ils reçoivent un certificat non-vérifié).

Google Chrome - Bad CertificateLa plupart des gens se méfieront en voyant ça, le cas où une fraude au certificat représente un risque, c’est avec les « autorités douteuses » acceptées par défaut dans les navigateurs. Plus d’info ici ou (conclusion méfiez-vous des ordis du boulot), et plus d’infos sur les attaques contre le HTTPS ici →  Détecter que l’on sniffe votre trafic SSL/HTTPS – 0xGONE

Une autre approche, plus récente et plus subtile, est celle choisie par SSLStrip. On se place à nouveau en MITM, on force tout le trafic web à travers SSLStrip, et celui-ci détecte les connexions HTTPS. Quand c’est le cas, il va « couper » cette connexion en deux : d’un côté (vers le serveur) il va établir lui-même la connexion sécurisée, et de l’autre (vers le client) il va créer une connexion HTTP simple (non protégée) dont il pourra lire les données. Le serveur ne voit aucune différence, et au niveau du client c’est discret (même si les navigateurs font un effort pour que ça soit plus visible).

SSLStrip

Ca fonctionne redoutablement bien, tant que le site-cible accepte les connexions en HTTPS (sinon le navigateur verra qu’il y a un problème). Pour des raisons de facilité et de compatibilité, la plupart des sites acceptent à la fois le HTTP et le HTTPS (en tout cas en partie), ce qui représente une forme de danger.

C’est ici que débarque le HSTS : HTTP Strict Transport Security. Pour faire simple, c’est une tentative pour « forcer » l’utilisation du HTTPS : quand un client contacte un serveur en HTTP, si le serveur a activé le HSTS il va répondre « écoute Coco, tu vas me faire le plaisir de discuter en HTTPS ! » (ce que le navigateur fera parce qu’il est docile). Donc tous les échanges suivants se feront en sécurisé et les oreilles indiscrètes en seront pour leurs frais. C’est un peu l’équivalent de l’extension « HTTPS Everywhere » pour Firefox, mais en plus standardisé. Concrètement, comment ça marche ? Lors de la première connexion au serveur (en HTTP, donc), le serveur ajoutera dans sa réponse un « header » qui stipule qu’il préfère exige une connexion sécurisée. Et en bon attaquant à l’esprit perverti, vous vous dites tout de suite « Si ce n’est que ça, je peux surveiller les headers et supprimer tout ce qui concerne le HSTS« . Ainsi, le client ne recevra jamais de demande pour passer en HTTPS et il restera bien sagement en clair. En plus ça tombe bien, Sergio-proxy permet d’écrire des plugins en Python qui affectent les en-têtes, je donnerai le code en commentaire s’il y en a qui sont intéressés 😉

« Tout ça pour ça« , le HSTS est-il donc mort-né ? On pourrait le croire, sauf que ce n’est pas si simple… Certains navigateurs (Google Chrome en tête, puis Firefox depuis la version 17) ont mis en place une liste statique de domaines « importants » pour lesquels la connexion en HTTPS est O-BLI-GA-TOIRE, et ce depuis le premier contact. Le navigateur refusera de se connecter en HTTP à des sites, même si on l’y « force » (avec SSLStrip par exemple). Alors que trouve-t-on sur cette liste ? Bah du côté de Chrome, sans surprise, tous les services de Google mais aussi quelques grands noms comme Twitter ou Paypal (mais pas Facebook, curieusement……). Chez Firefox, je n’ai pas trouvé la liste mais il paraît (← lien très intéressant !) qu’elle est basée sur celle de Chrome donc elle doit être similaire. Notez que cette liste est « statique » et intégrée à la compilation, pas moyen de la modifier après coup (enfin si mais c’est compliqué). Voilà en fait la réponse à notre question : pourquoi SSLStrip ne fonctionne-t-il plus avec Gmail ou Paypal ? Parce que le navigateur refusera de communiquer en clair avec ces domaines (donc évidemment dans ces conditions, SSLStrip ne peut pas fonctionner). HTTPS et HSTS : vos meilleurs ennemis 😀

Bon, vous commencez à me connaître, je suis pas du genre à dire « Voilà une technique infaillible, on est foutus« . Car oui, faille potentielle il y a, même si je n’ai pas encore réussi à l’exploiter. Si on lit l’article du blog Mozilla (j’avais bien dit qu’il était intéressant), on y voit le passage suivant :

When the browser receives an HSTS header with “max-age=0″, a knockout entry is stored that overrides the corresponding entry in the preload list. The knockout entry essentially says, “We have no HSTS information regarding this host.” As a result, the browser behaves as if the host were not on the preload list.

Donc si on arrive à injecter cet en-tête particulier « max-age=0 » dans la réponse du serveur, on court-circuitera le problème de la liste statique. Le souci, c’est que l’en-tête en question est intégré dans une réponse HTTPS (vu que pour l’instant, le site est toujours sur liste sécurisée), donc on tourne en rond… Mais je ne renonce pas encore ! 😀

Tout ça pour dire que choper un mot de passe Gmail ou Facebook dans une session HTTPS, c’est pas encore gagné… Enfin, pour ceux qui utilisent un navigateur sérieux, Internet Explorer continue à se faire avoir comme un bleu 🙂 Pour les autres, reste à ruser et rediriger la victime vers les versions mobiles des sites, en espérant qu’elles ne soient pas aussi sécurisées que les portails principaux. A bon entendeur… 😉

EDIT 07-DEC-14 : un début de piste pour contourner le HSTS –> contournement HSTS pour MITM A coupler éventuellement avec Sergio-Proxy pour la redirection, et un certificat gratuit de Let’s encrypt (quand ça sera disponible)

Advertisements
Cet article a été publié dans blabla. Ajoutez ce permalien à vos favoris.

9 commentaires pour HTTPS et HSTS : Duo gagnant

  1. d’un certain coté, si on redirige vers https://www.google.com http://www.google.com on peut aussi rediriger vers http://www.googie.com voire https://www.googie.com by passant ainsi le HSTS

  2. Merci pour cet article extrèmement bien fait !

    The quieter you become … the more you are able to hear qu’ils disaient ? 😉

  3. Noireaude dit :

    Et Alors, à quand le prochain!!!

    • antares145 dit :

      Quand j’aurai un peu de temps ET une idée de contenu original (c’est ça le plus dur). Si c’est pour refaire un Nième tuto de crack WEP, ça n’apportera rien… J’ai envie de traiter de sujets moins connus et moins abordés ailleurs 😉

  4. eric dit :

    Salut Antares, j’ai lu pas mal d’article / post que tu as rédigé sur ce site / crack wifi. Tout d’abord, un grand merci a toi de prendre ce temps pour rédigé de façon si pointu c’est différents articles, il est vraiment rare de trouver des articles aussi garnis.
    Bravo site soigneux, liens article précédent / suivant en haut / bas de page. Rien a redir.
    En attente des prochains.

    • antares145 dit :

      Salut, merci pour le commentaire positif 🙂 Oui, si je poste peu c’est parce que je préfère la qualité à la quantité. Mais là il serait quand même temps que je m’y remette… En ce qui concerne le layout du blog, je n’ai aucun mérite, c’est un WordPress de base avec le thème « Twenty Ten », je me suis vraiment pas fatigué pour la mise-en-page 😀

  5. Koala dit :

    Salut Antares !

    ça fait pas mal de temps que je suis pas passé par ici, je vois que tu ne post plus trop mais vaut mieux ça que faire des articles sur ce que l’on sait déja je suis d’accord la dessus 🙂

    Je cherche un moyen de Bypasser le HSTS qui ai devenu une plaie quand on a une redirection a faire.C’est bien qu’ils aient mis ça en place mais la ils ont visé juste.Je n’ai pas essayer de passer par la version mobile des sites mais ç’est un plan intéressant.Par ailleurs j’ai constaté que je n’avais pas de « HSTS failure » avec chrome et ma boite hotmail 😦 pas très rassurant.Quand tu dis:

    « Donc si on arrive à injecter cet en-tête particulier « max-age=0″ dans la réponse du serveur, on court-circuitera le problème de la liste statique. Le souci, c’est que l’en-tête en question est intégré dans une réponse HTTPS (vu que pour l’instant, le site est toujours sur liste sécurisée), donc on tourne en rond… »

    -1 Si on héberge un serveur apache avec le module SSL d’activé peut-etre que ça pourrait marché, le serveur n’est pas sur la liste des sites sécurisés et on a accès a notre serveur en https, après il suffirait de renvoyer le client sur le vrai site une fois qu’elle a rentrée les bons renseignements, le but étant de le dévier temporairement chez nous si on peut pas passer par les vrais sites.

    -2 Pour ma part a cause du HSTS seul les demandes HTTP sont correctement redirigé sur mon serveur, pour le reste meme si mon serveur et en HTTPS et qu’une redirection est en place, sur google, youtube, gmail, facebook impossible de impossible d’effectuer la redirection sur mon serveur, on est bloqué avant: détail technique « HSTS failure » néanmoins on s’aperçoit en analysant ce blocage que le problème vient de mon certificat, Google se fie a mon certificat grace a la redirection et me renvoi une erreur donc en activant sslstrip après avoir mis en place la redir sur ma page https je devrai (théoriquement) retomber sur ma page en http vue que j’ai un certificat gratuit et bidon sans module HSTS…Du coup on aurait une redirection propre et sans bavure quitte a pirater sa propre page https avec sslstrip.Bref tout ça est a teste avec des pincettes et je reve peut-etre un peu mais ça vaut le coup de tenter.

  6. Bofahe dit :

    juste te dire merci car ton article m’a servi

  7. kamikazz dit :

    très bon article avec de très bonnes explications ! Merci Antares

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s