Pentest Système et Réseau

Attaques liées à HTTPS et HSTS

Attaques liées à HTTPS et HSTS

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.

Attaques liées à HTTPS et HSTS

Comment fonctionne HTTPS

Dans le premier article sur l’espionnage sur les réseaux, je vous ai montré que l’on pouvait sniffer les communications entre deux hôtes ou encore que l’on pouvait rediriger les victimes vers des sites factices dans le but de voler leurs identifiants. Pour contrer ces attaques, un protocole à été créé : SSL (qui est devenu TLS un peu plus tard).

HTTPS est une version améliorée d'HTTP qui permet de créer un tunnel sécurisé entre deux hôtes dans le but que seuls ces deux hôtes puissent comprendre le contenu de leurs communications. Voici ce qu'un attaquant obtiendrait s'il sniffait les communications émises au travers d'un tunnel TLS:

tls1.png

Avant d’utiliser des outils informatiques il va falloir comprendre un sacré paquet de choses. Du coup cet article sera découpé en deux parties. Dans la première on parlera de HTTPS et dans la seconde d’HSTS et de comment attaquer ces deux protocoles. Et pour commencer on va parler cryptologie.

I/La cryptologie

La cryptologie est une science qui permet de cacher des messages à l’aide d’algorithmes mathématiques. Les premières méthodes de cryptologie sont apparues dans l’Antiquité. Le chiffrement de César est l’une d’entre elle. A l’époque César ne voulait pas que ses ennemies puissent lire les messages qu’ils envoyaient dans son empire. Il a donc pensé à chiffrer ses messages. Pour cela il remplaçait chaque lettre de son message par une lettre distante d’une distance n sur la droite ou la gauche.

Par exemple pour une distance de 3 sur la droite, le « a » était codé par un « d ». A l’époque ce code suffisait à duper les gens. Mais avec un peu de réflexion on se rend vite compte qu’il y a une faille majeure. En effet dans la langue française la lettre la plus courante est le « e ». Par conséquent il suffit de chercher dans le message codé la lettre qui est la plus souvent utilisée et à partir de là on obtient la distance et donc on peut déchiffrer le message.

On appelle ce genre d’algorithme des algorithmes symétriques. Car la même clé est utilisée pour chiffrer et déchiffrer le message. En l’occurrence si on choisit une distance de 5 pour chiffrer le message alors on pourra le déchiffrer avec cette même distance.

Avec le temps, de nouveaux algorithmes sont nés : plus complexe, plus rapide et surtout plus sécurisé. Un de ces algorithmes est le RSA (du nom de ses créateurs : Ronald Rivest, Adi Shamir et Leonard Adleman). Cet algorithme est apparu dans les années 70 et est très utilisé notamment dans le domaine du chiffrement web (étonnant que je vous en parle n’est-ce pas ?!  )

Contrairement au chiffrement de César, le RSA est un algorithme asymétrique dans le sens où il a besoin de deux clés pour fonctionner. La première c’est la clé publique, tout le monde peut l’avoir. La seconde est la clé privée, celle-ci est détenue par une seule personne. Alors comment ça fonctionne ?

On va prendre un message M que l’on va chiffrer à l’aide de la clé publique. Puis on va l’envoyer à son destinataire. Le destinataire, qui dispose de la clé privée, va le recevoir et déchiffrer le message pour en lire le contenu :

tls2.png

Seul celui qui dispose de la clé privée pourra déchiffrer un message chiffré avec la clé publique. En revanche l’inverse n’est pas vrai.

Avec ces bases en cryptologie il sera plus simple de comprendre le fonctionnement du protocole TLS !

II/ Le protocole TLS

Comme je vous l’ai dit le protocole TLS permet d’établir un tunnel qui chiffre les données émises entre deux hôtes.

Tout le protocole repose sur ce que l’on appelle des certificats numériques. Ces certificats sont l’équivalent numérique de nos cartes d’identités sauf qu’ici ils permettent d’authentifier un serveur. On retrouve plusieurs informations dans ces certificats : la version (1, 2, 3, 3+), le numéro de série, l’algorithme de signature utilisé, l’émetteur du certificat, la date de début/fin de validité, le propriétaire, ainsi qu’un tas d’autres informations dont on reparlera plus tard. Voici une partie du certificat du site wordpress.com :