MITM-Angriff mit HSTS-implementierten Websites
Ich möchte zu Bildungszwecken einen Man-in-the-Middle-Angriff gegen mein eigenes Netzwerk durchführen. Ich möchte das folgende Szenario: Führen Sie einen MITM-Angriff mit Bettercap durch, navigieren Sie zu einer Website und akzeptieren Sie die Zertifikatwarnung. Dies bedeutet, dass Sie das von Bettercap (dem Angreifer) vorgelegte Zertifikat akzeptieren.
Frage 1:
Ich möchte wissen, ob dies heutzutage möglich ist, wenn die HSTS-Sicherheitsrichtlinie auf Websites und in der HSTS-Preload-Liste implementiert ist.
Frage 2:
Sind meine einzigen Möglichkeiten die Websites, auf denen das HSTS nicht implementiert ist, oder gibt es eine Möglichkeit, HSTS zu entfernen und den Angriff durch Akzeptieren des Zertifikats auszuführen?
Antworten
Frage 1: Ja, das ist möglich. Die Tatsache, dass sich die Site in der HSTS-Preload-Liste befindet, teilt dem Browser nur mit, dass immer eine Verbindung zur Site über https und nicht über http hergestellt werden soll. Die HSTS-Preload-Liste enthält keine Informationen zum Zertifikat selbst.
Frage 2: Nein, wegen der Antwort auf Frage 1.
Obwohl dies nicht normativ ist , befolgen die Browser im Allgemeinen die gut begründeten Implementierungsempfehlungen für Benutzeragenten aus RFC 6797, 12 , damit der Benutzer die Fehler nicht umgehen kann, wenn eine bekannte HSTS-Richtlinie vorhanden ist.
12.1. Kein Benutzerregress
Wenn ein sicherer Verbindungsaufbau bei Warnungen oder Fehlern (gemäß Abschnitt 8.4 ("Fehler beim sicheren Transportaufbau")) fehlschlägt, sollte dies ohne "Rückgriff des Benutzers" erfolgen. Dies bedeutet, dass dem Benutzer kein Dialogfeld angezeigt werden sollte, in dem er fortfahren kann. Vielmehr sollte es ähnlich wie ein Serverfehler behandelt werden, bei dem der Benutzer in Bezug auf die Interaktion mit der Zielwebanwendung nichts weiter tun kann, als zu warten und es erneut zu versuchen.
Im Wesentlichen bedeutet "Warnungen oder Fehler" alles, was dazu führen würde, dass die UA-Implementierung dem Benutzer mitteilt, dass beim Verbindungsaufbau etwas nicht ganz korrekt ist.
Wenn Sie dies nicht tun, dh den Benutzer auf "Klicken durch Warn- / Fehlerdialoge" zurückgreifen, ist dies ein Rezept für einen Man-in-the-Middle-Angriff. Wenn eine Webanwendung eine HSTS-Richtlinie ausgibt, entscheidet sie sich implizit für den Ansatz "Kein Benutzer-Rückgriff", bei dem alle Zertifikatfehler oder Warnungen zu einem Verbindungsabbruch führen, ohne dass Benutzer die Möglichkeit haben, die falsche Entscheidung zu treffen und sich selbst zu gefährden .
Wenn Sie in der Lage sein müssen, Ihre eigenen Verbindungen mitzuschalten, z. B. zu Test- oder Debuggingzwecken, besteht die einzige Möglichkeit, HSTS zu umgehen, darin, das Stammzertifizierungsstellenzertifikat Ihres HTTPS-Proxys als vertrauenswürdige Stammzertifizierungsstelle zu installieren. Auf diese Weise wird das vom Proxy verwendete Zertifikat zu einem gültigen Zertifikat, und daher ist HSTS kein Problem.
Laut Bereitstellen eines CA-Zertifikats von Bettercap zur Integration in Browser Nr. 536 wird das Stammzertifizierungsstellenzertifikat von Bettercap in gespeichert /root/.bettercap-ca-cert.pem.