Bei diesem Artikel handelt es sich um den zweiten Teil unseres Workshops zum Thema SSL Stripping. Den ersten Teil finden Sie hier. Er befasst sich mit den technischen Grundlagen, die einen solchen Angriff erlauben, sowie mit deren Entstehungsgeschichte.
Über so grundlegende Dinge wie das Lesen eines Zertifikatefehlers hinaus kann vom durchschnittlichen Anwender vieles nicht erwartet werden. Hierzu gehört mit Sicherheit, einen SSL-Stripping-Angriff zu erkennen. Dieser ist keine eigentlich neue Methode, vielmehr wurden bestehende Konzepte lediglich leicht abgewandelt, um eine neue Strategie zu bilden.
Der Trick greift die Annahme auf, dass viele Nutzer nur die Domain oder höchstens noch deren Subdomain - etwa "www.tecchannel.de" - in die Adresszeile ihres Browsers eingeben. Bei dieser Vorgehensweise wird eine TLS-Verbindung nicht direkt vom Nutzer aufgebaut, was sehr viel sicherer wäre, sondern erst auf die Antwort "302 Found" des angewählten Servers hin. Unter Umständen ist dieses Verhalten dem Anwender nicht einmal bekannt - ideal, um den Verschlüsselungsversuch abzufangen. Der Angreifer präsentiert sich hierfür dem Server als der eigentliche Partner, akzeptiert dessen TLS-Verbindung und stellt zum Opfer lediglich eine ungesicherte Verbindung durch. Er agiert damit als sogenannter "Rogue Proxy". Durch die Manipulation der weitergegeben Website werden unter anderem alle mit "https://" beginnenden Links durch einfache "http://"-Verweise ersetzt.
Von der Theorie zur Praxis
Ein solcher Angriff ist dank einiger subtiler Hinweise zu bemerken; so färben einige Browser beispielsweise, wie erwähnt, ihre Adresszeile ein, um sichere Verbindungen zu kennzeichnen. Dies bleibt aus, wenn die TLS-Verbindung angefangen wurde. Andere stellen ein kleines Schloss als Icon neben die gewählte Adresse, wenn eine sichere Verbindung besteht. Da allerdings der Angreifer die volle Kontrolle über den Datenstrom hat, ist er sogar in der Lage, Letzteres durch die Injektion eines ähnlichen Favicons zu simulieren.
Zudem wickeln viele Webseiten nicht ihren vollständigen Datenverkehr über TLS ab. So baut die bekannte Social-Media-Seite Facebook nur für einen kurzen Moment eine verschlüsselte Verbindung auf, um das Passwort zu übertragen - völlig unbemerkt vom Nutzer. Entsprechend unbemerkt lässt sich diese Verbindung auch abfangen, und schon liegt das Passwort dem Angreifer im Klartext vor.
Selbst der aufmerksamste Nutzer wird kaum über diese Kleinigkeiten stolpern - es sei denn, er forciert den Aufbau einer TLS-Verbindung mit der Eingabe von "https://" vor der gewünschten Adresse. Dies einzufordern ist allerdings reichlich unrealistisch. Zu größeren Darstellungsproblemen kann es auf Opferseite höchstens in Einzelfällen kommen, denn einige Angebote sind in einer Weise gestrickt, die den Angriff unmöglich machen. Hierbei mag es sich meist um Zufall handeln, doch üblicherweise ist dann ein völlig zerschlissenes Layout die Folge, verbunden mit massiven Verzögerungen.
In der Praxis kommt dies allerdings kaum vor. Der Architekt des Angriffs verkündete schadenfroh, durch Anwendung der Methode auf einen TOR-Knoten mehr als 100 verschiedene Logins innerhalb kurzer Zeit gewonnen zu haben. Darunter sollen sich vertrauliche Kontodaten von diversen Armeen, Botschaften und Ministerien befunden haben. Nicht eines der Opfer schöpfte angeblich Verdacht.
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.
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.
Vielfältige Lösungen für Löcher im ARP-Konzept
So lange wie ARP Spoofing existiert, so lange gibt es bereits Gegenmaßnahmen. Heute ist eine Vielzahl unterschiedlicher Lösungen im Einsatz, die massive Unterschiede bei Kosten und Administrationsarbeit aufweisen.
Auf der Softwareseite wird meist angesetzt, indem ARP schlicht deaktiviert wird. Dies mag in kleinen Netzwerken praktikabel sein: Fügt man hier nicht ständig neue Rechner hinzu, so lässt sich die Liste der Teilnehmer auch von Hand verteilen. Neben der verstärkten Sicherheit kann dies sogar zu einem kleinen Geschwindigkeitsgewinn führen. Jedoch ist es bei größeren Unternehmen nicht mehr möglich, die vielen hundert Interfaces vom Smartphone bis zum Server händisch zu konfigurieren. Hier stünde der Aufwand in keinem Verhältnis zum Ergebnis.
Ähnlich sieht es bei der manuellen Subnet-Verwaltung aus. Grenzt man die Rechner entsprechend ihrer Sicherheitsstufe voneinander ab, so ergibt sich entweder ein monströser Aufwand mit sich ständig ändernden Zuordnungen oder ein sehr grobmaschiges Sicherheitsnetz.
Ein anderer Ansatz ist, aktiv das ARP zu überwachen. Hierfür gibt es ein von der Network Research Group am Lawrence Berkeley National Laboratory entwickeltes Tool namens arpwatch. Dieses überwacht das lokale Netz auf typische Anzeichen einer Protokollverletzung, etwa eine Überflutung mit ARP-Antworten, und schlägt Alarm. Ist man bereit, dem Programm voll und ganz zu vertrauen, so stellt es sicher eine brauchbare Lösung dar.
Wie erwähnt, existieren außerdem viele kommerzielle Lösungen, die dazu dienen, Eindringlinge abzuwehren, die meist auch ARP-Attacken mit einbeziehen. Dies können etwa spezielle Switches sein, die einzelne Ports bei typischen Angriffsmustern abschalten, Layer-3-Switches, die portweise VLANs erzeugen, oder Intrusion Detection Systems, die einen ganzheitlichen Ansatz verfolgen. Diesen Möglichkeiten ist jedoch gemein, dass sie sehr hohe Kosten verursachen und nebenbei auch nicht gerade trivial zu administrieren sind.
Schlussendlich gilt weiterhin die Warnung vor der grundsätzlichen Disparität von Sicherungs- und Angriffsmethoden. So muss ein Angreifer nur eine einzige erfolgreiche Methode finden, während der Verteidiger sich stets gegen sämtliche Eventualitäten zu versichern hat. Und ARP Spoofing ist bei Weitem nicht die einzige Technik, mit der ein MITM-Angriff eingeleitet werden kann. Als bekannteste weitere Beispiele seien nur das DNS Spoofing oder die Einrichtung eines Rogue DHCP Server erwähnt. Hat eine dieser Methoden Erfolg, so lässt sich SSL Stripping ohne Abwandlungen durchführen.
Maßnahmen gegen SSL Stripping: ein Experiment
Aufgrund der mangelnden Nachfrage existieren noch keine professionellen Lösungen. Jedoch gibt es einige Ansätze, mit denen das Risiko minimiert werden kann. Zuerst einmal ist die grundsätzliche Aktivierung von TLS zu nennen. Dies kann mittels Browser-Plugins geschehen, ein Beispiel ist HTTPS Everywhere für Firefox. Solche Plugins wählen direkt die gesicherte Adresse an, wenn der Nutzer nicht ganz bewusst eine unverschlüsselte Verbindung aufbauen möchte. Damit gibt es nichts, was der Angreifer abfangen könnte, da auch das erste Paket voll verschlüsselt bei ihm ankommt.
Auf Netzwerkebene gestaltet sich das Problem weitaus komplexer. Zurzeit findet sich ein einzelner Ansatz, der an der George Mason University entwickelt wurde. Laut diesem soll ein zusätzlicher Sicherheits-Proxy im Unternehmen eingerichtet werden, über den die eigentlich unverschlüsselte Kommunikation umgeleitet wird. Mit dem Proxy teilt der Client einen geheimen Schlüssel. Dieser wir nach dem Public-Key-Verfahren vereinbart. Mit ihm werden die Nachrichten per HMAC-MD5 auf ihre Integrität hin kontrolliert. Außerdem wird jeweils eine Zufallszahl zur Verhinderung von Replay-Angriffen weitergereicht. Eine ausführlichere Darstellung des Konzepts finden Sie im nebenstehenden Flussdiagramm.
Wie leicht ersichtlich ist, vergrößert dieser Ansatz die Komplexität des Netzwerks und seiner Komponenten ganz enorm, und Komplexität bedeutet weitere Angriffsflächen. Die Internet Engineering Task Force (IETF) verfolgt jedoch derzeit einen Entwurf, der den Einsatz von SSL Stripping erschweren soll. Deshalb kann das beschriebene System wenigstens als zeitlich beschränkte Maßnahme eingesetzt werden.
Jener neue Ansatz, die sogenannte HTTP Strict Transport Security (HSTS), befindet sich aktuell noch im Draft-Stadium. Durch HSTS sollen Sicherheitsinformationen mitgeteilt werden, die den Browser anweisen, dass in jedem Falle eine Verschlüsselung zu erfolgen habe. Dies lässt allerdings die gleichen Lücken, wie sie ein klassischer Angriff auf SSL-Verbindungen nutzt. Gelingt es, bereits den Verbindungsaufbau zu manipulieren, kann auch die Mitteilung des Servers schlicht unterschlagen werden. Mehrere andere Optionen werden darum diskutiert. So könnte beispielsweise ein modifizierter DNS-Server die nötigen Informationen tragen.
Fazit
Die Gefahr von SSL Stripping wird bei Weitem unterschätzt. Dabei hindert wenig an der Durchführung des Angriffs: Die Methode ist kinderleicht einzusetzen, findet sich sogar als fertiges Skript im Internet, ist beinahe vollkommen transparent und in einem Großteil der Fälle hoch effizient. Dennoch erwähnt der Wikipedia-Artikel zu TLS das Problem noch nicht einmal auf der entsprechenden Diskussionsseite.
Zwar mag die Gefahr eines klassischen MITM-Angriffs in modernen Netzen vergleichsweise gering sein, setzt man vorhandene IDSs und ähnliche Einrichtungen voraus. Doch diese Sicherheit kann trügerisch sein, denn hat das SSL Stripping doch einmal Erfolg, so ist der Schaden massiv. Noch viel extremer sieht es im Internet aus: Proxys, Anonymisierungsnetzwerke, VPN-Provider, ISPs - all diese Stellen haben mit dem Trick problemlos Zugriff auf sämtliche verschlüsselten Daten ihrer Nutzer.
Man kann also nur hoffen, dass SSL Stripping stärker in das Bewusstsein der Fachöffentlichkeit dringt. Denn nicht einmal der hier umrissene Weg wird in Zukunft verbaut werden. Das mit IPv6 statt ARP verwendete Neighbour Discovery Protocol (NDP) schließt zwar einige Lücken, weist aber dafür in anderen Bereichen Probleme auf. Hier wurde zwar als Erweiterung schon das gesicherte SEcure Neighbor Discovery Protocol (SEND) entworfen, doch dessen Einsatz muss nun erst einmal forciert werden. Auch die Entwicklung professioneller Maßnahmen zur Abwehr anderer Arten von Spoofing im IPv6-Netz ist ein dringendes Gebot. Denn der Kreativität der Angreifer ist selten eine Grenze gesetzt, sobald sie erst einmal Zugriff auf einen Datenstrom haben. SSL Stripping ist ein besonders hübsches Beispiel hierfür. (dre)