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 😉 !

4 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

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 )

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