Attaque MITM avec des sites Web implémentés HSTS

Question

Je souhaite lancer une attaque Man-in-the-Middle contre mon propre réseau à des fins éducatives. Je veux le scénario suivant: effectuer une attaque MITM avec Bettercap, accéder à un site Web et accepter l'avertissement de certificat, ce qui signifie accepter le certificat présenté par Bettercap (l'attaquant).

Question 1:

Je veux savoir si cela est possible de nos jours avec la politique de sécurité HSTS mise en œuvre sur les sites Web et la liste de préchargement HSTS?

Question 2:

Mes seules possibilités sont-elles les sites Web sur lesquels le HSTS n'est pas implémenté ou existe-t-il un moyen de supprimer le HSTS et d'effectuer l'attaque en acceptant le certificat?

Answer 1

Question 1: Oui, c'est possible. Le fait que le site figure sur la liste de préchargement HSTS indique uniquement au navigateur qu'il doit toujours se connecter au site par https et non par http. La liste de préchargement HSTS ne contient aucune information sur le certificat lui-même.

Question 2: Non, à cause de la réponse à la question 1.

Answer 2

Bien que non normatifs , les navigateurs suivent généralement les conseils de mise en œuvre de l'agent utilisateur bien raisonnés de la RFC 6797, 12 pour ne pas laisser l'utilisateur contourner les erreurs s'il existe une politique HSTS connue.

12.1. Aucun recours de l'utilisateur

L'échec de l'établissement d'une connexion sécurisée en raison d'avertissements ou d'erreurs (selon la section 8.4 («Erreurs dans l'établissement de transport sécurisé»)) doit être effectué sans «aucun recours de l'utilisateur». Cela signifie que l'utilisateur ne doit pas être présenté avec une boîte de dialogue lui donnant la possibilité de continuer. Au contraire, elle doit être traitée de la même manière qu'une erreur de serveur où l'utilisateur ne peut rien faire d'autre pour interagir avec l'application Web cible, à part attendre et réessayer.

Essentiellement, «tout avertissement ou erreur» signifie tout ce qui amènerait l'implémentation UA ​​à annoncer à l'utilisateur que quelque chose n'est pas entièrement correct avec l'établissement de la connexion.

Ne pas faire cela, c'est-à-dire autoriser un recours utilisateur tel que "cliquer dans les boîtes de dialogue d'avertissement / d'erreur", est une recette pour une attaque de type "man-in-the-middle". Si une application Web émet une politique HSTS, elle opte implicitement dans l'approche «sans recours de l'utilisateur», selon laquelle toutes les erreurs ou avertissements de certificat provoquent une interruption de la connexion, sans aucune chance de «tromper» les utilisateurs pour qu'ils prennent la mauvaise décision et se compromettent .

Si vous avez besoin de pouvoir MitM vos propres connexions, par exemple à des fins de test ou de débogage, le seul moyen de contourner HSTS est d'installer le certificat d'autorité de certification racine de votre proxy HTTPS en tant qu'autorité de certification racine de confiance. De cette façon, le certificat utilisé par le proxy devient un certificat valide et, par conséquent, HSTS n'est pas un problème.

Selon Fournir un certificat CA de Bettercap à intégrer dans le navigateur # 536 , le certificat CA racine de Bettercap serait stocké dans /root/.bettercap-ca-cert.pem.