Das Vorgehen der Angreifer - und der Verteidiger
Workshop: SSL Stripping erkennen und bekämpfen - Teil 2: Abwehr
Ergebnisse des Angriffs auf verschiedene Verbindungen
Um dies beispielhaft in der Praxis vorzuführen, soll das Verhalten mehrerer Webseiten in einer Testumgebung überprüft werden. Hierzu haben wir uns Zugänge bei mehreren namenhaften Online-Angeboten eingerichtet oder unsere bestehenden Accounts verwendet.
Facebook.com: Die Networking-Seite macht keinen besonderen Aufstand. Man meint lediglich, eine kleine Verzögerung zu erkennen. Die einzige größere Auffälligkeit ist, dass plötzlich eine Anfrage des Passwortmanagers auftaucht, der sich das Login sonst nicht merken will. Das Passwort landet jedenfalls beim Angreifer.
Web.de: Überraschenderweise schneidet der in die Jahre gekommene Webmail-Anbieter noch am besten ab: Das Interface will sich nicht öffnen, die Verbindung bricht ab. Problem: Der Angreifer hat die Passwortdaten trotzdem erhalten.
Online-Banking der Sparkasse: Hier erwartet man wohl die größte Sicherheit, bekommt sie aber leider nicht. Zwar läuft das Login spürbar langsamer ab als im Normalfall, außer diesen zwei Sekunden ergeben sich aber keine Auffälligkeiten. Der Angreifer muss allerdings eine Weile suchen, bis er in den abgefangenen POSTs die PIN des Opfers findet.
Google.com: Google schneidet von allen geprüften Angeboten am schlechtesten ab. Die Website scheint fast noch schneller zu laufen als im Normalbetrieb, und sämtliche Datenströme werden abgefangen. Auffälligkeiten: Keine.
- Spoofer: Traffic-Umleitung zu SSLstrip
Der Angriff läuft im Wesentlichen gleich ab wie der zuvor für eine unverschlüsselte Verbindung geschilderte. Der Unterschied ist hier: HTTP und HTTPS leiten wir zu einem speziellen Port. - Spoofer: Start von sslstrip.py
Nun starten wir das Skript sslstrip.py. Es lauscht an diesem Port und fischt SSL-Verbindungsversuche aus den empfangenen Daten. - Opfer: Login trotz Stripping
Wieder loggen wir uns beim Opfer auf Facebook ein, dieses Mal wieder voll verschlüsselt. Ein minimaler Geschwindigkeitsunterschied fällt auf - außerdem fragt Firefox, ob er das Passwort speichern soll. Dies passiert bei einem voll verschlüsselten Facebook-Login sonst nicht - doch ob das der Nutzer merkt? - Spoofer: Facebook-Vollzugriff
Währenddessen ist das Passwort ohne Probleme vom Angreifer abgefangen worden. SSLstrip loggt das freudlicherweise für uns mit. - Opfer: Loginversuch bei Web.de
Als nächstes probieren wir es bei Web.de. Zwar öffnet sich die Oberfläche nicht, doch wahrscheinlich würden die wenigsten Anwender merken, was gerade passiert ist. - Spoofer: Logindaten von Web.de
Da das Login schon versendet wurde, passiert es auch den MITM - und taucht dort genauso im Klartext auf wie bei Facebook. - Opfer: Nichtsahnender Bankkunde
Nun wird es kritisch: Das Opfer greift auf sein Bankkonto zu. Das dauert deutlich länger als sonst, etwa zwei Sekunden mehr. Sonst funktioniert alles einwandfrei. - Spoofer: Banking-PIN in falschen Händen
Der Angreifer hätte nun einen Freifahrtsschein, wenn es die TAN nicht gäbe. Trotz aller Sicherheitsmaßnahmen liegt die PIN offen vor ihm. Sicherheitshalber ist dies Mal die komplette Zeile zensiert. - Opfer: Google - kein Problem
Zu guter Letzt loggen wir uns noch bei Google ein - in Zeiten des Data Mining könnte das für Kriminelle fast interessanter sein als die Sparkasse. Die Seite scheint nun sogar schneller zu laufen als ohne Angriff. - Spoofer: Gleiches bei Google
Wie zu erwarten war, sieht es auch bei Google nicht besser aus. Fazit: Vier Versuche, vier Logins gestohlen.
Offensichtlich ist es nicht möglich, jede denkbare Verbindung mit sslstrip zu knacken, ohne zumindest ein bisschen Aufsehen zu erregen. Allein die Verwundbarkeit des Bank-Logins macht jedoch deutlich, warum TANs doch keine schlechte Idee sind.