Seit der Frühzeit des Ethernet und dem Aufkommen des Address Resolution Protocol (ARP) ist dieses eine Achillesferse der Netzwerkkommunikation, zumindest wenn es ungesichert bleibt. Glücklicherweise war die Nachfrage nach einer professionellen Absicherung des ARP entsprechend groß. Heutige Systeme sind daher oft durch entsprechende Maßnahmen geschützt. Dennoch bleibt das sogenannte ARP Poisoning eine der am weitesten verbreiteten Methoden zur Einleitung eines sogenannten "Man-in-the-Middle"-Angriffs (MITM Attack).
Bei einer solchen Attacke leitet eine nicht befugte, dritte Person die Kommunikation zweier oder mehrerer Gesprächspartner auf ein eigenes System um. Dort werden die Nachrichten abgehört oder verändert. Als Reaktion darauf entwickelten viele Hersteller Sicherheitsstandards, die die Kommunikation verschlüsseln sollten. Das bekannteste zu diesem Zweck entworfene Protokoll ist der Secure Sockets Layer (SSL), der mittlerweile als Transport Layer Security (TLS) bekannt ist. Ursprünglich beschrieb Netscape diesen Standard, inzwischen wird er von allen großen Browsern unterstützt. Nach seinen Vorgaben wird die Identität des Servers dem Nutzer gegenüber durch ein Zertifikat einer unabhängigen Stelle bestätigt.
Theorie und Praxis - Zertifizierung mit SSL Stripping umgehen
In der Theorie ist das Zertifikatesystem ausgesprochen schwer anzugreifen, und nicht umsonst gilt TLS als ein sehr sicheres Protokoll. Doch unter realistischen Bedingungen kann das Konzept leicht durch einen kleinen Trick ausgehebelt werden. Diesen stellte Moxie Marlinspike am Black Hat DC 2009 der Szene der destruktiven Hacker vor. Der Angriff basiert auf einem Rogue Proxy, der die Internetverbindungen des Opfers nicht nur weiterleitet, sondern auch manipuliert. Vom Server kommende "302 Found"-Weiterleitungen auf gesicherte Seiten erreichen dem Konzept zufolge nie den Nutzer, da sie vom Angreifer durch unsichere Verbindungen ersetzt werden.
Bis heute allerdings findet dieser Angriff nur wenig Beachtung. Die Hauptkritik an TLS zielt auf die Zuverlässigkeit der Zertifikatstellen, die bereits mehrmals Opfer von Angriffen wurden. Dabei ist das sogenannte SSL Stripping im Gegensatz zu klassischen MITM-Angriffen auf TLS auch fähig, Verbindungen zu bereits bekannten Servern ohne Zertifikatfehler oder andere wesentliche Auffälligkeiten abzuhören.
Eine praktische Demonstration soll daher dazu dienen, das Bewusstsein für den Angriff zu stärken. Zum Einsatz kommen hierzu die verbreiteten Tools Ettercap und Wireshark sowie das Skript sslstrip.py selbst.
Bei diesem Artikel handelt es sich um den ersten Teil eines zweiteiligen Workshops. Er wird sich mit den prinzipiellen Grundlagen, den Hintergründen und der Geschichte solcher Angriffe befassen. Der zweite Teil folgt am morgigen Freitag.
Der MITM-Angriff auf ungesicherte Verbindungen
Das frühe Ethernet war ein Paradies für unbefugte Zuhörer: Die damaligen Hubs versandten jedes Paket blind an jedes Interface im Netzwerk. So konnten alle Teilnehmer völlig unbemerkt mitschneiden, was gesendet wurde. Wollte man die Kommunikation jedoch manipulieren, war ein direkter Zugriff erforderlich - der MITM-Angriff war geboren. Mit dem Umstieg der meisten Netze auf geswitchte Verbindungen, die Pakete nur noch selektiv weiterreichen, gewann er weiter an Bedeutung.
Wie der Name schon sagt, begibt sich der Angreifer bei MITM-Attacken als Zwischenstelle in die Verbindung zweier Interfaces. Dies kann auf verschiedenen Wegen erfolgen. Sieht man von Vor-Ort-Methoden ab - man könnte den Rechner schlicht mit zwei Netzwerkkarten ausstatten und ihn im abzuhörenden Kabel einbauen -, ist ARP Spoofing oder Poisoning sicherlich die einfachste und bekannteste Methode, diese Position zu erreichen.
Das ARP ist für die Auflösung von Adressen des OSI Layer 3 (IP-Adressen) auf solche des Layer 2a (MAC-Adressen) zuständig. Da Letztere theoretisch eineindeutig sind, ermöglichen sie den beteiligten Interfaces, einander zweifelsfrei zu erkennen. Weil ARP diese Auflösung allerdings mit Broadcasting erreicht, kann jeder Empfänger der Nachricht antworten - auch mit gefälschten Informationen. Selbst das ungefragte Versenden von Antworten ist möglich, denn die eingehenden Zuordnungsdaten werden von vielen Systemen akzeptiert.
Überflutet man also das Netz mit gefälschten ARP-Anworten, so erreicht man, dass statt der MAC-Adresse des eigentlichen Inhabers der IP die des angreifenden PCs angesprochen wird. Auf der Seite des ursprünglichen Gegenübers erfolgt das Gleiche, sodass nun beide Rechner an den Angreifer senden statt an ihren Partner. Dieser braucht die Pakete nur noch jeweils durchzustellen - nachdem er sie gründlich betrachtet oder abgeändert hat. So fängt man beispielsweise eine Verbindung zwischen Desktop und Internet-Gateway ab, um nicht verschlüsselte Passwörter oder auch Session Cookies unauffällig abzugreifen.
Vertrauensbasis durch TLS-Verschlüsselung
Auf das Konzept des MITM-Angriffs reagierte Netscape im Jahr 1994. Neun Monate, nachdem der erste WWW-Browser Mosaic veröffentlicht worden war, wurde SSL 1.0 als rein firmeninternes Protokoll entworfen. Kurze Zeit später erreichte die Version 2.0 auch die Öffentlichkeit. Die Kanonisierung erfolgte schließlich 1999, als die RFC 2246 eine Weiterentwicklung von SSL 3.0 als TLS 1.0 zum Standard erklärte. Spätere Versionsschritte brachten diverse Verbesserungen bei Sicherheit und Funktionsumfang. Aktuell wird TLS 1.2 eingesetzt.
SSL und TLS verwendeten im Laufe ihrer Geschichte verschiedene jeweils als stark bekannte Verschlüsselungen, und auch das zurzeit eingesetzte AES gilt als nahezu unangreifbar. Dies verhindert ein Abhören der Kommunikation in Echtzeit - es wird erforderlich, die Sicherung zu umgehen.
Um dies zu verhindern, muss der Benutzer sicher sein können, dass er tatsächlich mit dem Zielserver kommuniziert und nicht mit einer Zwischenstelle. Ein Betreiber eines TLS-fähigen Servers kann aus diesem Grund ein Zertifikat seiner persönlichen Identität erwerben. Dieses wird von einer Certificate Authority (CA) ausgestellt und bestätigt, dass der Server einen bestimmten privaten Schlüssel verwendet. Mit diesem privaten Schlüssel erzeugt der Seitenbetreiber nun eine Signatur, die an den Nutzer übertragen wird. Sie kann mit dem öffentlichen Schlüssel der CA auf ihre Zugehörigkeit zum privaten Schlüssel des Betreibers geprüft werden.
Optional sind zudem sogenannte Extended Validation Certificates (EV Certs) erhältlich, bei denen auch die hinter dem Domain-Namen stehende Firma beleuchtet wird. Auch die technischen Vorgaben für den Herstellungsprozess sind für sie schärfer definiert. Sie werden oft für besonders sicherheitskritische Seiten in Auftrag gegeben und finden sich bei vielen Banken oder Regierungsstellen.
Die Zertifizierung hat zwar den Nachteil, dass sie für teures Geld im Abonnement erworben werden muss, doch sie sichert in einer Vielzahl der Fälle gegen einen MITM-Angriff ab. Denn versucht ein Angreifer nun, sich in eine derart geschützte Kommunikation einzuklinken, so ruft er einen Zertifikatfehler hervor. Die von ihm präsentierte Signatur wurde nicht mit dem privaten Schlüssel des Serverbetreibers erstellt, sondern ist als gefälscht zu erkennen. Zumindest theoretisch.
Schwachstellen der TLS
Eine fortgeschrittene Variante dieses Angriffs besteht darin, auch als Angreifer ein Zertifikat zu erwerben, statt sich selbst eines auszustellen. Doch überzeugend gefälschte Bescheinigungen sind nur mit einigem Aufwand zu bekommen. Sie werden entweder von einer zwielichtigen oder schlecht geführten Zertifikatestelle erworben, oder sie fallen bei einem Angriff auf seriöse Stellen als Beute an. Besonderes Aufsehen erregte in diesem Zusammenhang ein Reseller der Comodo CA, der Zertifikate für jede Seite ohne Prüfung ausstellte und sich zudem mit dem Versenden von Spam ein Zubrot verdiente.
Manche Websites kranken zudem immer noch an einem schon längst behobenen Fehler in OpenSSL. Dieser veranlasste den Zufallsgenerator des Programms, nur noch wenige verschiedene Werte auszugeben. Da diese als Basis für den Private Key dienen, wurden für etwa drei Jahre unwissentlich große Mengen wenig zufälliger Schlüssel zertifiziert. Wurde ein solches Zertifikat nicht mittlerweile ausgetauscht und für ungültig erklärt, ist die betroffene Verbindung nicht wesentlich sicherer als eine unverschlüsselte.
Auch der von manchen CAs verwendete Hash-Algorithmus MD5 erwies sich vor einiger Zeit als unsicher. Aufgrund von Kollisionen war es mit massiver Rechenleistung möglich, gefälschte Signaturen und sogar Zertifikate zu erstellen. MD5 befindet sich allerdings auf dem Rückzug. Außerdem ist es nicht gestattet, den Algorithmus bei der EV-Zertifizierung zu verwenden.
Besonders verheerende, aber auch schnell behobene Schwachstellen in der Browsersoftware erinnern zudem immer wieder daran, dass ein Programm grundsätzlich nie als fehlerfrei betrachtet werden kann. So war es beispielsweise lange möglich, universell gültige Wildcard-Zertifikate auszustellen, indem ein Nullbyte im Host-Name-Bezeichner des Zertifikats platziert wurde.
In der Praxis ist als größte Schwachstelle immer auch der Mensch mit einzubeziehen. Viele Nutzer wurden von den langen Zahlenkolonnen der früher üblichen TLS-Fehler abgeschreckt, lasen den Hinweis gar nicht erst und surften einfach weiter. Irgendwann wurde die Fehlermeldung dann schlicht deaktiviert. Zwar haben die bekanntesten Hersteller die Benachrichtigung mittlerweile behutsam modernisiert, indem verschiedene Browser zum Beispiel ihre Adresszeile der Verbindung entsprechend einfärben. Insbesondere auf EV-Zertifikate reagieren viele Programme deutlich. Doch das Verhalten der User ist infolge der häufigen, früher unverständlichen Fehlermeldungen heute entsprechend abgestumpft.
Soweit zu den Hintergründen und zur Problemstellung für den Angreifer. Damit endet der erste Teil unseres Workshops. Unter anderem wird der zweite Teil mit der Durchführung des Angriffs, seiner Erprobung in der Praxis und den Möglichkeiten zur Abwehr befassen. (dre)