Attaquer HTTPS et HSTS

Comment faire pour accéder à un site web via HTTPS ? Eh bien il existe deux manières. La première consiste à cliquer sur un lien qui impose le schéma HTTPS comme c'est le cas ci-dessous:

https://whiteflag.blog

Si nous cliquons sur une URL ayant pour schéma https:// un tunnel chiffré SSL/TLS sera automatiquement mis en place.

La seconde méthode consiste à contacter un serveur sur le port 80 et être redirigé par ce dernier d'une connexion HTTP (port 80) vers une connexion HTTPS (port 443) via l'émission d'une réponse HTTP 302 (Redirect). C'est d'ailleurs ce qui se passe sur le serveur qui héberge whiteflag. Si vous essayez d'accéder à l'application via le port 80 vous serez automatiquement redirigé vers le port 443:

 

Quoiqu'il arrive un tunnel chiffré SSL/TLS est mis en place afin d'empêcher tout attaquant de lire le contenu des communications émises entre le serveur et le client. Que se passerait-il si la redirection émise par le serveur web n'était jamais reçu par le client ? Eh bien aucun tunnel SSL ne serait mis en place.

De ce constat un chercheur en sécurité informatique, Moxie Marlinspike, développa un incroyable outil : SSLstrip. SSLstrip est un outil dont le principe de fonctionnement est assez simple:

  1. Il remplace tous les liens HTTPS par du HTTP de manière à éviter tout établissement de tunnel chiffré TLS
  2. Il empêche toute redirection 302 d'une connexion HTTP vers une connexion HTTPS

Pour que cela soit possible il faut bien évidemment que l'attaquant soit en position de Man in the Middle.

Ainsi si le serveur émettait une demande de redirection vers HTTPS, l'attaquant pouvait bloquer cette redirection de manière à ce que le tunnel SSH/TLS ne soit pas établis entre la victime et le serveur web:

 

Pour combler cette vulnérabilité il fallait trouver un moyen d'indiquer au navigateur du client qu'il devait forcer la connexion en HTTPS et que si cette dernière n'était pas mise en place alors il ne devait pas émettre de données. Ce moyen, c'est le header HSTS.

Le header HSTS peut être configuré de deux manières : au niveau applicatif ou au bien au niveau du serveur en lui même comme c'est le cas pour ce serveur:

tls14.png

Le header 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 tout simplement supprimer le header HSTS et ainsi empêcher la mise en place d'un tunnel SSL. Encore une fois 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 :

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 à cause du header 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 en:

https://www.monsite.com

Mais qu’est-ce qu’il se passerait si on entrait cette URL http://wwww.monsite.com ? Aucune règle ne s’applique pour le domaine « wwww.monsite.com » et pour cause il n'existe pas d'entrées DNS pour ce nom de machine. 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 ! Heureusement pour nous il existe un excellent outil qui s'occupe de faire tout ça pour nous : bettercap que l'on pourra installer de cette manière:

apt-get install bettercap

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

Si la victime entre ses identifiants :

tls15.png

Voilà ce que nous obtiendrons :

tls16.png

Les identifiants de la victime.