Angriff auf geschützte SSL-Verbindungen mit sslstrip

In meinen letzten Blogeinträgen habe ich gezeigt, wie man gefälschte WLAN-Access-Points aufsetzt und den Client dazu zwingen kann, sich mit diesen zu verbinden.
Man mag denken, dass das alles kein Problem sein sollte, solange man SSL-gesicherte Kommunikation mit dem Server betreibt.
Diese Verbindungen aufzubrechen, benötigt einen SSL-Proxy, der mit einem gefälschten, aber von einer vertrauenswürdigen CA unterschriebenem, Zertifikat bewaffnet ist. Solche Angriffe sind in einem üblichen Penetrationstest nicht zu bewerkstelligen.
Somit gibt es an dieser Stelle zwei Möglichkeiten:

  1. Man benutzt ein eigenes Zertifikat und überredet den Client, dieses zu akzeptieren oder
  2. der Client benutzt überhaupt gar kein SSL

Beide Angriffsmöglichkeiten zielen hier auf Benutzer ab, die keinen hohen Wert auf Sicherheit legen oder nicht das technische Wissen um die Überprüfung besitzen.
In diesem Artikel möchte ich den zweiten Angriffsweg beschreiben, wodurch das kleine Tool sslstrip ins Spiel kommt.

Bevor wir aber loslegen, möchte ich einmal kurz die Funktionsweise von sslstrip erläutern. sslstrip ist als Proxy für Webseiten gedacht, die eine nicht-verschlüsselte Startseite haben und von dort aus auf SSL-gesicherte Login-Seiten verweisen.
Dieses Programm muss dadurch selbstverständlich irgendwo innerhalb des Kommunikationsweges lauschen. Es nimmt HTTP-Traffic auf Port 80 entgegen und leitet diesen dann an den angesprochenen Server weiter. Von diesem Server untersucht es die Antwort, filtert aber alle Verweise auf HTTPS-Links heraus und ersetzt diese durch normale HTTP-Links.
Wenn der Client danach also einem dieser Links folgt, verbindet er sich wieder mit sslstrip, welches anschließend mit dem angesprochenen Server eine SSL-gesicherte Kommunikation betreibt und danach zwischen Client und Server vermittelt.

Wenn sich der Client auf www.heise.de verbindet und sich einloggen will, sieht der Link ohne Angriff mit sslstrip folgendermaßen aus:
heise-ohne-sslstrip1

Benutzername und Passwort werden per Post-Request sicher über SSL übertragen.
heise-ohne-sslstrip2

Doch um an diese Logindaten zu kommen, bauen wir folgendes Testszenario:

  1. Wir setzen einen Access Point auf
  2. Hier lassen wir sslstrip auf Port 7000 lauschen:
    root@kali:~# sslstrip -l 7000 --ssl -w /tmp/sslstrip.out
    

    -l definiert den zu benutzenden Port.
    –ssl analysiert den SSL-Verkehr vom und zum Server.
    -w gibt an, wo die Ausgabe gespeichert werden soll.

  3. Damit jeder durchgehende Web-Traffic den Proxy benutzt, müssen wir mit iptables noch eine kleine Regel hinzufügen:
    root@kali:~# iptables --table nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 7000
    

Falls der Client nun auf heise.de dem Einloggen-Link folgen möchte, ersetzt sslstrip diesen Link, nimmt normal auf Port 80 unverschlüsselt die Eingaben entgegen und sendet sie dann per SSL-Verbindung wieder an den Server, was für den Benutzer nun so aussieht:
heise-sslstrip1

heise-sslstrip2

Wenn man an dieser Stelle nicht genau hinschaut, wird man kaum bemerken, dass der Link geändert wurde und die Kommunikation unsicher ist. In der Ausgabe stehen nun auch unsere Logindaten.

sslstrip-heise-passwort

Dieser Angriff funktioniert in dieser Form nur bei Webseiten, die per Links auf eine HTTPS-Verbindung verweisen. Sollte der Webserver im Hintergrund ein Redirect auf Port 443 veranlassen, muss man schon ein bisschen tiefer in die Trickkiste greifen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.