Gefährdungen durch Man-in-the-Middle-Angriffe (Teil 2)

Im ersten Teil wurden bereits einige grundlegende Man-in-the Middle (MitM) Angriffe beschrieben. Darunter waren klassische Angriffe wie APR-Spoofing, IP-Spoofing, DNS-Spoofing/Cache Poisoning und SSLStripping. In diesem zweiten Teil beschäftigen wir uns nun mit der Anwendungsschicht und deren Schwächen. Schwachstellen in der Ausgangskonfiguration von Fernsteuerprotokollen wie RDP sowie Sicherheitslücken in Webanwendungen wie z.B. Cross-Site-Scripting lassen sich durch Werkzeuge für Man-in-the-Middle bzw. Man-in-the-Browser Angriffe ausnutzen – und das nahezu vollständig automatisiert.

Fernsteuerung auf Umweg

Die Kritikalität von entfernten Verwaltungsschnittstellen wie SSH und RDP machen diese zu besonders interessanten Diensten für MitM-Angriffe. Das Remote Desktop Protokoll (RDP) ist ein proprietäres Microsoft-Protokoll und dient der graphischen Fernsteuerung von Systemen. Dabei wird von einem Server der Bildschirminhalt übertragen, ein verbundenes Clientsystem empfängt diesen und kann durch Maus und Tastatur mit dem entfernten System wie mit dem eigenen interagieren. RDP ist ein typisches Werkzeug im Betrieb von Windows-Umgebungen und wird von Administratoren u.a. für Verbindungen zu kritischen Systemen verwendet.

Regelmäßig lässt sich in unserer Arbeit eine unsichere Konfiguration des Dienstes beobachten. RDP verschlüsselt die Daten während der Übertragung. Die hierzu benötigten TLS-Zertifikate sind meist nicht durch eine vertrauenswürdige Certificate Authority signiert. Dem Benutzer wird dies durch eine deutliche Warnung des Systems signalisiert [Abb.-1]:

Abb.-1: Zertifikatswarnung zeigt die Unfähigkeit die Identität des zu verbindenden Systems zu ermitteln

Die im Folgenden dargelegten Angriffe gehen davon aus, dass auf den Systemen keine individuellen TLS-Zertifikate installiert wurden und somit die Standardkonfiguration vorliegt.

RDP kennt drei Sicherheitsstufen: „RDP Security“, „Enhanced RDP Security“ und „CredSSP“. Die erste Stufe verwendet einen RSA-basierten Schlüsselaustausch, um einen Sitzungsschlüssel zwischen den beiden beteiligten Systemen zu etablieren. Da durch den Administrator kein individuelles TLS-Zertifikat einer vertrauenswürdigen CA installiert wurde, wird an dieser Stelle ein Standard-Zertifikat von Microsoft verwendet. Dieses Zertifikat ist mithin in allen Windows-Installationen vorhanden. Das Zertifikat enthält stets den gleichen öffentlichen Schlüssel und somit auch stets den gleichen privaten Schlüssel. Dieser lässt sich also aus einer beliebigen Windows-Installation extrahieren. Einem Angreifer, der den Netzwerkverkehr einer RDP-Kommunikation der Sicherheitsstufe „RDP Security“ mitschneiden kann, ist es somit leicht möglich, diese im Nachhinein zu entschlüsseln, bzw. sich über eine Man-in-the-Middle-Position aktiv in die Kommunikation der beiden Systeme einzuklinken. 

Mit ebenso geringem Aufwand kann ein Angreifer eine RDP-Kommunikation der zweiten Sicherheitsstufe „Enhanced RDP Security“ übernehmen. Da auch diese Verbindung kein prüfbares Zertifikat benutzt, kann durch ARP-Spoofing die TLS-Verbindung entgegen genommen werden und vom Angreifersystem zum Zielsystem weitergeleitet werden. In der TLS-Verbindung werden die Zugangsdaten im Klartext übertragen.

Um erfolgreich in eine RDP-Sitzung der dritten Sicherheitsstufe „CredSSP“ einzubrechen, sind einige Voraussetzungen erforderlich. Insbesondere darf das Zielsystem die Verwendung von CredSSP nicht erzwingen, was jedoch nicht die Standard Konfiguration ist. Ist dies der Fall, kann ein Angreifer einen so genannten Downgrade auf eine niedrigere Sicherheitsstufe erwirken und die oben beschriebenen Angriffe ausführen.

Das Programm Seth unterstützt bei der Automatisierung des Angriffs und ist in der Lage, Tastatureingaben aus dem Datenstrom herausfiltern. Seth bringt sich mittels ARP-Spoofing in die MitM-Position. Will ein Clientsystem nun eine RDP-Verbindung mit dem Server aufbauen, empfängt Seth die Anfrage, manipuliert diese, so dass das Sicherheitsprotokoll „RDP Security“ eingesetzt wird und gibt dies als neue Anfrage an den Server weiter. Die Antwort des Servers nimmt es entgegen, tauscht das Zertifikat gegen ein eigenes aus und leitet alles an das Clientsystem weiter. An dieser Stelle bekommt der Client eine Warnung zu sehen. Da dies eine übliche Warnung für die meisten Endanwender ist, wird kaum jemand an dieser Stelle Verdacht schöpfen. Ignoriert also ein Anwender die Warnung und baut die Verbindung auf, können wir mit Seth Systembefehle auf dem Server im Kontext des angemeldeten Nutzers absetzen und Tastatureingaben vom Clientsystem mitlesen. 

Zur praktischen Demonstration eines solchen Angriffs verwenden wir drei virtuelle Maschinen. Zwei VMs unter Windows 10 mit deaktiviertem NLA, sowie eine Linux-VM als Angreifersystem.

Zur besseren Übersicht sind nachstehend die in diesem Versuchsaufbau verwendeten IP- und MAC-Adressen wiedergegeben [Abb.-2]:

Abb.-2: Beschreibung der Versuchssysteme

Um effizient eine MitM-Position einnehmen und auch halten zu können, ist es notwendig, den Verkehr zwischen den beiden Windows-Systemen zu kontrollieren. Insbesondere ist es notwendig, dafür zu sorgen, dass das initiale SYN-Paket des Opfers, nicht den Zielserver erreicht, denn dieses enthält wichtige Informationen für einen erfolgreichen Verbindungsaufbau. Haben wir durch ARP-Spoofing (oder anderweitig) eine initiale MitM-Position erreicht, so können wir mittels des iptables-Programms dafür sorgen, dass das erste SYN-Paket des Opfers an den RDP-Server nicht weitergeleitet wird [Abb.-3].

Wird durch das Opfer eine RDP-Verbindung auf den Zielserver initiiert, so wird diese auf dem System des Angreifers abgefangen und der eigentliche Angriff kann beginnen [Abb.-4]: 

Bereits während der Angreifer nach Start des Programms Seth mit dem Befehl „./seth.sh eth1 169.254.6.42 169.254.182.62 169.254.6.87“ auf eine einkommende Verbindungsanfrage vom Opfer auf den RDP-Server wartet, ist der Angriff auf Netzwerkebene deutlich zu erkennen [Abb.-5]:

Abb.-5: Mitschnitt von ARP-Anfragen

Unser Angreifersystem flutet das lokale Netz mit ARP-Paketen, in denen das Angreifersystem sowohl die MAC-Adresse 00:0C:29:1C:BA:9F des Opfers als auch die MAC-Adresse 00:0C:29:AC:03:80 des RDP-Servers für sich reklamiert. Neben der Mehrfachverwendung von MAC-Adressen innerhalb einer Ethernet-Kollisionsdomäne, fällt auf, dass keinerlei ARP-Requests zu beobachten sind. Dies ist für ein Network Intrusion System bzw. einen Analysten ein deutlicher Hinweis auf den Versuch, eine MitM-Position einzunehmen [Abb.-6]:

Abb.-6: Erkennung von ARP-Angriffen

Da das durch das Angreifersystem präsentierte TLS-Zertifikat nicht verifiziert werden kann, wird das Opfer mit einer Warnung konfrontiert, die auf diese Tatsache hinweist. 

Der Angreifer hat erfolgreich die RDP-Verbindung aufgebrochen und so das Kennwort des Benutzers ausspähen können [Abb.-7]:

Abb.-7: Eingabe eines Passworts wurde vom Nutzer User erkannt.

Vergleichbare Angriffe sind auch bei SSH möglich. Ein Werkzeug für Man-in-the-Middle Angriffe auf SSH-Verbindungen ist ssh MITM. Ist es im Einsatz, wird dem aufrufenden Client eine Warnung präsentiert, dass sich der Server-Key geändert hat. Ignoriert der Client bzw. der Nutzer diese Warnung, gilt die Verbindung als vertrauenswürdig und erlaubt ein Mitlesen für den Man-in-the-Middle.

Das Ausspähen von Passwörtern ist in der Praxis nicht immer so einfach möglich bzw. in Windows-Umgebungen häufig auch gar nicht erforderlich. Für die Ausweitung von Zugriffsrechten z.B. durch Pass-the-Hash- oder Relaying-Angriffe sind in der Regel die Hash-Werte hinreichend. Ein Werkzeug, welches auf vielfältige Art und Weise versucht, an Authentisierungsdaten zu gelangen ist das von SpiderLabs entwickelte Responder. Es lässt sich effektiv mit den im ersten Teil des Artikels beschriebenen Methoden wie ARP-Spoofing kombinieren. Allerdings ist dies je nach gewählter Konfiguration nicht unauffällig, wenn die gespooften Dienste nicht wie gewohnt antworten. Hierzu liest Responder den über ihn geführten Netzwerkverkehr mit. Protokolle, die zur Namensauflösung dienen, wie etwa das Protokoll DNS oder die in Windows-Umgebungen eingesetzten Protokolle LLMNR oder NBT-NS, werden durch den Responder erkannt und es wird versucht, die anfragenden Systeme auf das System des Angreifers umzuleiten. Weiter stellt der Responder die entsprechend gewünschten Dienste wie Datei und Druckdienste (SMB, FTP), Webdienste (HTTP oder HTTPS), Verzeichnisdienste (LDAP) und E-Mail-Dienste (SMTP, IMAP oder POP3) zur Verfügung. Oft sind die in Windows-Umgebungen betriebenen Dienste so eingestellt, dass die Zugangsdaten automatisch, als Klartext oder in gehashter Form übertragen werden. Die Zugangsdaten, die als Hashes übertragen werden, können von dem Angreifer für sogenannte Relaying-Attacken verwendet werden. So werden die gehashten Werte vom Angreifer an einen Dienst weitergeleitet, um sich damit zu authentifizieren.

Entführter Browser

Dieser Angriff zielt auf den Browser ab und steht damit zwischen einem Anwender und dem Server, dessen Webseite aufgerufen wird. Bei dem Aufruf einer Webseite mit einem Browser wird auf dem Server, auf dem die Webseite betrieben wird, die Anfrage verarbeitet. Der Server beantwortet diese durch das Senden von statischen Elementen, wie etwa einem Bild oder dynamischen Elementen, die wiederum selbst aus Programmcode bestehen, der durch den Browser ausgeführt wird. Dieser Programmcode sorgt beispielsweise dafür, dass wenn ein Untermenü in einer Seite geöffnet wird, die Anfrage nicht vom Server beantwortet werden muss, sondern schon lokal im Browser verarbeitet werden kann und das passende Untermenü dargestellt wird. Dies sorgt für sehr geringe Wartezeiten in der Webseite, hat jedoch weitgehende sicherheitsrelevante Implikationen. Ist es einem Angreifer möglich den Programmcode, der vom Server zum Browser geschickt wird zu manipulieren, ergeben sich verschiedene Möglichkeiten zur Ausnutzung. Angefangen beim Mitlesen der Tastatureingaben, Stehlen von Sitzungsmerkmalen (Cookies), dem Ausführen von Aktionen in der Anwendung, bis hin zum Ausbruch aus dem Browser und somit Zugriff auf das Betriebssystem. Letzteres stellt keine triviale Aufgabe dar, die anderen Szenarien sind erheblich einfacher auszunutzen.

Um den Man-in-the-Browser Angriff auszuführen, sind zwei grundlegende Fähigkeiten notwendig. Zunächst geht es um die Initialisierung, d.h. den Schritt, Programmcode in den Browser des Anwenders einzuschleusen. Danach gilt es, die Kontrolle zu behalten.  Aktionen, die ein Anwender in der Webseite unternimmt, dürfen den eingeschleusten Programmcode nicht aushebeln/unbrauchbar machen. Weiter soll der eingeschleuste Code auf Befehle des Angreifers hören und so als Fernsteuerungseinheit dienen. Zum Beispiel sollte das Schließen und Neuöffnen des Browsers auf der Seite des Anwenders nicht den Angriffsfluss stören. Programmcode, der diese beiden Fähigkeiten vereint, wird unter Browser-Hackern als Hooking bezeichnet. Ein erfolgreich angegriffener Browser ist somit „am Haken“. Das Browser Exploitation Framework (kurz BeEF) bietet diese Funktionalität, wie auch weitere vordefinierte Angriffsoptionen an.

• Die Initialisierungsphase

Um Programmcode in eine Anwendung einzuschleusen, gibt es drei Wege. Einen Angriff des Servers, ein Angriff auf den Datenverkehr (MitM) oder einen Angriff auf einen Anwender. Angriffe auf den Datenverkehr können über die Mittel aus dem vorangegangenen Teil 1 des Artikels gesteuert werden. Für Angriffe auf Anwender und Server wird sogenanntes Cross-Site-Scripting (XSS) verwendet. Cross-Site-Scripting ist das Einbinden von Programmcode in Eingabefelder einer Webseite oder an die URL, mit der eine Seite aufgerufen wird. Die Webseite muss jedoch den eingefügten Code als Teil der Webseite ausliefern. Wird der Programmcode im Browser nicht als ausführbar gewertet (durch Schutzmaßnahmen, wie das nicht Zulassen bestimmter Zeichenfolgen), ist kein Cross-Site-Scripting möglich. Die zumeist verwendete Programmiersprache für im Browser ausgeführten Code ist JavaScript, weshalb wir diese für unser Beispiel verwenden. 

Für die Simulation einer (persistenten) Cross-Site-Scripting Schwachstelle fügen wir in unserem Test-Forum ein JavaScript-Element zur Ausgabe einer Warnbox hinzu (Abb.-8). Laden wir die Seite neu erhalten wir eine Warnbox (Abbi.-9). Somit bietet die Webseite, die notwendigen Voraussetzungen für die folgenden Techniken.

Für den geplanten Angriff fügen wir das Laden einer externen JavaScript-Datei in den Angriffscode hinzu. Der Browser wird diese vom System des Angreifers in die dargestellte Seite nachladen und somit die Verbindung zum Angreifer herstellen (Abb.-10).

Abb.-10: Einbinden der Hook für die Kontrollübernahme

• Beibehalten der Kontrolle

Damit sich die im Browser des Anwenders nachgeladene JavaScript-Datei mit dem System des Angreifers verständigen kann, wird in regelmäßigen Abständen vom System des Anwenders eine Datenabfrage am Server des Angreifers durchgeführt (Polling). Durch dieses Verfahren kann der Angreifer Kommandos an die Anwendung senden oder den Browser auffordern, Daten zu senden. Der nachstehende Screenshot veranschaulicht das regelmäßige Polling (Abb.-11).

Abb.-11: Polling aus Sicht des Anwenders

Haben wir den Hook in einer Webseite untergebracht, können wir über die Anwendungsoberfläche von BeEF sehen, welche Systeme sich verbinden und welche Eingaben Nutzer in der Oberfläche tätigen (Abb.-12).

Abb.-12: Verfolgung der Nutzereingaben durch BeEF

BeEF bietet bereits einen hohen Automatisierungsgrad, jedoch lassen sich die Angriffe mit dem MitM-Framework (MitMF) noch weiter vereinfachen bzw. mit anderen Techniken ergänzen. MitMF bietet ähnlich dem BetterCAP eine Sammlung von Werkzeugen für Man-in-the-Middle-Angriffe. Die Stärke dieses Produkts liegt in der Einbindung von Plugins. So kann neben BeEF beispielsweise das Werkzeug Responder als Plugin geladen und auf eine bereits übernommene Verbindung angewandt werden. Weitere nennenswerte Plugins sind:

• BeEFAutorun für die Ausnutzung von Browser-Schwachstellen, um so ein Betriebssystem zu kompromittieren.

• JSkeylogger um Eingaben zu lesen, die womöglich extra verschlüsselt übertragen werden.

• BrowserSniper für Angriffe gegen veraltete Browser Plugins.

• HTA Drive-By gibt eine Nachricht aus mit der Anweisung zum Download einer HTA-Anwendung. Fällt ein Nutzer auf einen solchen Aufruf herein, kann Schadcode auf das System geladen werden.

Hat ein Angreifer noch keinen Zugriff auf ein Unternehmensnetzwerk erlangt, um sich durch die im Teil 1 dieses Artikels beschriebenen Verfahren in eine Man-in-the-Middle Position zu bringen, bieten sich ihm durch den Betrieb eines fingierten Wireless LAN Access Points (sogenannte Rogue Access Points) vereinfachte Bedingungen. Für die Automatisierung des gesamten Angriffsablaufs über den Rogue Access Point bis hin zur Sammlung von Authentisierungsdaten und auch bei Angriffen auf die beteiligten Browser greift das Werkzeug Karmetasploit hilfreich unter die Arme. 

Fazit

Ein Man-In-The-Middle-Angriff ist mit den verfügbaren Werkzeugen und den richtigen Voraussetzungen vergleichsweise leicht zu bewerkstelligen. Die Herausforderung besteht im Wesentlichen darin, dies möglichst unerkannt und ohne Störungen auszuführen. Um Man-in-the-Middle-Angriffen entgegenzuwirken, sollten die eingesetzten Protokolle von einer gegenseitigen Authentifizierung (z.B. Client- und Server-Zertifikate) Gebrauch machen und die jeweiligen Identitäten erfolgreich verifizieren (z.B. über eine Vertrauensstellung zur ausstellenden CA). Zudem sollten die Protokolle Schutzmaßnahmen zur Gewährleistung der Integrität (z.B. digitale Signierung) bieten, um Manipulationen erkennen zu können und die Übertragung gegenüber neugierigen Blicken durch eine Verschlüsselung nach Stand der Technik abzusichern. Trotz aller technischen Maßnahmen verbleibt am Ende der Faktor Mensch. Die Nutzer sollten daher regelmäßig hinsichtlich der Bedeutung von Fehlermeldungen bei der Authentisierung und den Konsequenzen einer falschen Entscheidung geschult werden. Derartige Fälle sollten durch eine sichere Konfiguration auf ein Minimum reduziert werden, um im Fall der Fälle die Aufmerksamkeit der Nutzer sicher zu stellen. 

Autor: Tobias Mayer. GAI NetConsult GmbH

Quellen / Links

• Responder – https://github.com/SpiderLabs/Responder 

• MiTMF – https://github.com/byt3bl33d3r/MITMf 

• ssh MITM –  https://github.com/jtesta/ssh-mitm 

• BeEF – http://beefproject.com/

• Seth – https://github.com/SySS-Research/Seth/ 

Autor: Tobias Mayer