Attaquer HTTPS et HSTS (2/2)

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.


Avant de lire cet article je vous invite à lire celui-ci et comprendre (vraiment) comment fonctionne TLS


Revenons quelques années en arrière, Moxie Marlinspike, un chercheur en sécurité informatique, est parti d’un constat simple : les utilisateurs ne vérifient pas les liens des sites sur lesquels ils se connectent, ils vérifient seulement s’il y a le petit cadenas vert symbole de la connexion sécurisée (et encore… Pas tous).

De ce constat est née l’outil SSLStrip qui permet d’empêcher la mise en place du protocole TLS tout en affichant sur le navigateur de la victime le cadenas vert.

SSLStrip va tout simplement bloquer la demande de connexion sécurisée. C’est ce qu’on appelle une « Downgrade attack ». La victime ne verra pas la différence mais pourtant il utilisera une connexion non sécurisée.

nopePour combler cette faille, les chercheurs ont créé le protocole HSTS (HTTP Strict Transport Security). HSTS s’active lors de la première connexion à un site. Une fois la première connexion établie, il va garder en mémoire dans le navigateur que ce site doit toujours être consulté via HTTPS et ce pour une durée x (définie dans le header Strict Transport Security).

Quid de la première connexion du coup ? Est-elle vulnérable ? Oui elle l’est. En effet quiconque intercepte cette première requête pourra se placer en position de Man In The Middle. Mais HSTS propose une solution : une liste de sites hard codés dans vos navigateurs qu’on ne pourra contacter que via HTTPS. D’ailleurs, si vous voulez ajouter votre site à cette liste hard codée, il faut vous rendre ici !

Comment faire pour bypass la sécurité du protocole HSTS tout en lisant les données envoyées par la victime ? Une première idée serait de se mettre en man in the middle full HTTPS entre le client et le serveur. Le client initiera une connexion sécurisé avec la machine en man in the middle et cette dernière initiera une connexion sécurisée vers le serveur. Oui mais non… Au moment où le navigateur de la victime initiera la connexion vers le serveur, HSTS s’attendra à récupérer le certificat de ce serveur et non pas celui de l’attaquant. Donc on aura une erreur venant de notre navigateur.

Pour éviter ce problème il faut donc initier deux connexions. La première entre la victime et le pirate qui ne serait pas sécurisée (qui permettrait de lire les données envoyées donc) et la seconde entre le pirate et le serveur qui serait sécurisée (pour ne pas avertir le serveur qu’une attaque man in the middle est en cours) comme ceci :

doubleco

Seulement voilà, si on se contente de se mettre entre les deux alors la victime va se connecter au serveur de façon sécurisée en envoyant une demande de mise en place du TLS (comme on a vu plus haut). Et même si la victime ne demande pas à se connecter de façon sécurisée, son navigateur pourra l’obliger avec le protocole HSTS. Dans ces cas-là, le pirate ne pourra pas lire le contenu des communications…

C’est là qu’entre en jeu SSLStrip+ (ou SSLStrip2). Cet outil cette fois ne se contente pas seulement de downgrade la connexion sécurisée, il va aussi modifier l’URL envoyée par la victime.

En effet le protocole HSTS s’applique pour des domaines spécifiques. Si vous entrez http://www.monsite.com et que ce site est sur la liste HSTS alors l’URL sera directement transformée. Mais qu’est-ce qu’il se passera si on entre cette URL http://wwww.monsite.com ? Aucune règle ne s’applique pour ce domaine « wwww ». Le problème c’est que les serveurs DNS ne connaîtront pas cette association domaine/nom du site. D’où l’intérêt d’avoir un DNS supplémentaire inclus dans Bettercap !!

Pour résumer le tout on va downgrade le protocole HTTPS en HTTP et en même temps on va transformer l’URL de base de manière à éviter les règles du protocole HSTS. Donc notre URL sera : http://wwwww.monsite.com !
Passons à la partie pratique !

Nous utiliserons l’outil Bettercap codé en Ruby. Bettercap n’est pas installé d’office sur Kali Linux. Il faudra ouvrir un terminal et lancer cette commande :

apt-get install bettercap

Vous pouvez aussi cloner le repository github ici

Bettercap est un outil tout en un : sniffer, arp poisoning, dns poisoning, sslstrip2, il fait tout ! Pour commencer nous allons tenter de voler les identifiants d’une personne qui se connecte sur sa boite mail gmx. Pour cela lancer la commande suivante :

sudo bettercap -I votre interface -G votre gateway -T la cible --proxy -P POST

Puis observer ahah ! Du côté de notre victime voilà ce qu’il se passera dans son URL :

httpunsafe

Et si la victime entre ses identifiants :

id

Voilà ce que le pirate obtiendra :

res

Voilà les identifiants de la victime !! Alors que pourtant la connexion est supposée sécurisée. Bien évidemment j’ai effectué plusieurs tests et il s’avère que cette technique marche sur de nombreux sites ! Mais je ne peux pas vous les dévoiler pour des raisons de sécurité 😛

L’inconvénient c’est que ce genre de procédé fait souvent buguer les pages web sur lesquelles la victime se rend. Par exemple j’ai tenté cette attaque sur la page filbanque.fr mais le serveur a refusé l’accès à ma machine victime. Dans le cas de GMX, j’ai réussi à récupérer les identifiants et mot de passe de ma victime mais celle-ci n’a pas pu se connecter à sa messagerie. De nombreux bugs apparaissent et de manière générale, le trafic sur le pc de la victime est très ralenti. Donc cela reste relativement repérable.


Vous voyez donc qu’il est assez simple de voler vos identifiants même si vos connexions sont supposées sécurisées ! Alors comment faire pour ne pas se faire piéger ? Eh bien le plus simple c’est d’éviter de se connecter sur des réseaux publics.

Tout le monde y a accès et donc n’importe qui peut y faire ce qu’il veut ! Ensuite il faut être vigilent. Faites un minimum attention aux liens sur lesquels vous vous rendez. En général une URL de ce type : http://wwwww.monsite.com n’est pas normale 😉 !

8 commentaires

  1. Salut !

    Un grand merci pour ce blog que je viens juste de découvrir et que je suis en train de dévorer 😀

    Juste quelques petites remarques. SSLstrip ne permet pas de downgrader une connexion. Il permet d’empêcher de l’upgrader en https. En fait, ce que fait SSLstrip (du moins la version 1), c’est de modifier la réponse du serveur afin de virer toutes les redirections 302 vers le port 443 et de remplacer tous les hyperliens https par des liens http. Ça implique que pour que SSLstrip fonctionne, il faut impérativement que la victime demande son site en http. Ça complique l’attaque parce que si la victime va sur son site en cliquant sur un lien depuis ses favoris, le navigateur l’aura enregistré en https et la victime va contacter son site directement sur le port 443, et SSLstrip ne te sera d’aucun secours dans cette situation. Lors du pentest que j’ai réalisé, j’ai contourné ce problème en présentant à la victime un lien non sécurisé (http donc) qui pointait sur son site, ce qui m’a permis de faire fuiter son cookie de session et de le sniffer. En fait, de mon expérience personnelle, c’est vraiment compliqué de sniffer des credentials si la victime a l’habitude d’aller sur un site particulier. SSLstrip est bien surtout pour sniffer des cookies (Mais encore faut-il que le cookie de session n’aie pas le flag secure. Sinon, la fête est finie…).

    Aimé par 1 personne

    1. Hola !

      Avec plaisir ahah ! Bonne lecture 🙂
      Concernant SSLstrip dans sa version première, on est bien d’accord sur le principe ^^, il faut que la victime utilise le protocole HTTP et en plus de ça que le site ciblé ne soit pas présent dans les listes HSTS pré chargés des navigateurs…

      Par contre pour la version 2 d’SSLstrip (SSLstrip+ de LeonardoNve https://github.com/LeonardoNve/sslstrip2), il y a bien un downgrade de HTTPS vers HTTP via l’utilisation du module DNS2Proxy utilisé pour bypass les règles HSTS. Alors après est ce qu’on peut parler de downgrade… Well je sais pas trop c’est peut être un abus de langage de ma part mais c’est comme ça que je le vois ahah 😀 !

      Anyway, dans tous les cas c’est clair que ça devient de plus en plus dur de mener ce genre d’attaques… Perso j’ai pas encore eu la possibilité de l’utiliser en pentest… GG à toi en tout cas pour le cookie 😛

      J'aime

  2. Oulah c’est devenu un peu compliqué à la fin 😀
    L’utilisateur n’est pas plutôt censé voir « http://wwwww.gmx.fr » plutôt que juste www en premier sous-domaine ?

    De ce que j’ai compris on veut ne pas utiliser le sous-domaine correspondant à l’adresse présente dans les listes HSTS, et utiliser du HTTP pour que le navigateur ne s’attende pas à ce qu’on lui renvoie le certificat du domaine gmx.fr.

    Une fois qu’on reçoit la requête GET wwwww.gmx.fr/, on établit nous-même une connexion HTTPS avec http://www.gmx.fr pour récupérer la page, puis on remplace toutes les références à https://www.gmx.fr par http://wwwww.gmx.fr avant de la passer à la victime, et rebelotte pour le formulaire de connexion envoyé par la victime, etc

    Où est-ce que j’ai faux ? :p

    De plus je ne comprends pas le commentaire de GladOS au-dessus : « En fait, ce que fait SSLstrip (du moins la version 1), c’est de modifier la réponse du serveur afin de virer toutes les redirections 302 vers le port 443 »
    C’est bien beau d’enlever la redirection, mais le serveur n’incluera pas la réponse à la requête HTTP pour autant, je ne vois pas trop l’utilité du coup ^^

    Je te remercie d’avance si tu peux m’éclairer, et merci pour ce billet de blog ! 🙂

    Aimé par 1 personne

    1. Hello, effectivement c’est comme ça que ça fonctionne, on va créer une connexion en deux temps :
      -HTTP entre la victime et l’attaquant
      -HTTPS entre l’attaquant et le serveur

      Pour établir cette connexion il faut duper le client en le faisant taper sur l’URL wwwww.gmx.fr qui n’existe pas dans les règles HSTS.

      Pour ce qui est de la version de SSLStrip, à la base il n’y avait pas d’HSTS à prendre ne considération. Du coup tout ce que l’outil faisait c’est empêcher l’upgrade HTTP vers HTTPS (qui se fait effectivement via un redirect).

      J’espère que ça répond à ta question. De toute manière je vais ré-écrire ces articles sous peu (d’ici le milieu du mois d’août je pense). Les explications seront beaucoup plus claires 😉

      J'aime

      1. D’accord, en effet je viens de lire dessus et on n’enlève pas les redirections, on les remplace vers le même site mais en http sur le port 80, ce qui a du sens. C’est la formulation de GladOS qui m’a confondu ^^

        Merci pour ta réponse !

        D’ailleurs pour l’anecdote, je voulais à tout prix être au courant de ta réponse à ce commentaire alors 1h après je suis revenu m’abonner aux commentaires, à 20:09, soit moins d’une minute après ta réponse que j’ai finalement manquée ! Haha :p

        Aimé par 1 personne

Répondre à Defte@WhiteFlag Annuler la réponse.

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 )

Photo Google

Vous commentez à l'aide de votre compte Google. 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 )

Connexion à %s