Dipl.-Inform. Carsten Eilers

Im eigenen WLAN, insbesondere wenn es im WPA2-Enterprise-Modus mit Authentifizierung über z.B. einen Radius-Server betrieben wird, sind Clients gut geschützt. Aber WLAN-Clients sind ja i.A. mobil und nutzen auch anderen WLANs (sonst könnte man stattdessen ja auch Desktop-Rechner mit kabelgebundenen Anschluss verwenden), in denen sie nur unzureichend geschützt sind. Selbst wenn ein VPN oder andere Schutzmaßnahmen eingesetzt werden, bleiben Gefahren übrig. Im folgenden wird von der Nutzung eines offenen WLANs ausgegangen. Die Angriffe sind auch bei WEP-geschützten WLANs möglich, nachdem deren Schlüssel berechnet wurde.

Altbekannt ist der Einsatz eines "Rogue Access Points", eines bösartigen Access Points mit dem Namen (SSID, Service Set Identifier) des angegriffenen Netzwerks. Das 802.11-Protokoll stuft alle Access Points mit der gleichen SSID als zum gleichen Netzwerk gehörend ein und der Client verbindet sich mit dem Access Point mit dem stärksten Signal.

Auch das direkte Senden von Paketen an den Client ist möglich, wenn als gefälschter Absender der Access Point angegeben wird. Selbst wenn im Access Point Pakete von Clients an Clients ausgefiltert werden, greift die Schutzfunktion in diesem Fall nicht. Der Client denkt, die Pakete kommen von Access Point und akzeptiert sie, der echte Access Point hat keine Möglichkeit, die Pakete abzufangen.

TCP-Stream-Hijacking schlägt alles

Einen Schritt weiter geht das TCP-Stream-Hijacking, das analog dem TCP-Session-Hijacking in kabelgebundenen Netzen funktioniert, aber im WLAN noch einfacher ist. Die "Sicherheit" von TCP basiert darauf, dass dem Angreifer die Sequenz- und Quittungsnummern unbekannt sind. Im WLAN kann der Angreifer aber die TCP-Pakete beobachten, so dass ihm die Nummern bekannt sind. Der Angreifer kann dadurch beliebige TCP-Streams übernehmen und als Man-in-the-Middle die übertragenen Daten manipulieren.

Mike Kershaw hat dieses Hijacking mit Hilfe des um das Modul Airpwn erweiterten Metasploit Frameworks demonstriert.

Man-in-the-Middle - und weiter?

Nachdem der Angreifer die Kontrolle über den TCP-Stream übernommen hat, kann er beliebige Daten einfügen oder manipulieren. Mike Kershaw hat die Angriffe insbesondere auf das Austauschen von HTTP-Inhalten ausgerichtet. Das bietet einem Angreifer nahezu unbegrenzte Möglichkeiten: Er hat die Kontrolle über das DOM der Seite, die Formulare, sogar über den kompletten Browser. Er kann beliebige Aktionen im Kontext der manipulierten Seite ausführen.

Der Angreifer kann also z.B.

• die dargestellten Inhalte manipulieren,
• die Formulare so ändern, dass sie die Daten an seinen eigenen Server oder einen Proxy schicken,
• alle HTTPS-URL in HTTP-URL umwandeln um die dann unverschlüsselt übertragenen Daten auszuspähen,
• Exploits für Browser-Schwachstellen einschleusen,
• ...

Alle diese Angriffe richten sich sofort gegen den Client. Aber was wäre, wenn ein Angriff erst später ausgeführt würde, nachdem sich der Client wieder im geschützten Unternehmensnetz befindet?

Persistente Angriffe

Robert "Rsnake" Hansen hat beschrieben, wie der Cache des Webbrowsers für Angriffe auf Netze mit nicht öffentlich routbaren IP-Adressen ausgenutzt werden kann. Ein Angreifer kann Code in den Browsercache einschleusen, der später im geschützten lokalen Netz aktiv wird. Generell kann jeder Dienst, der seinen Status über Sicherheitsgrenzen hinweg erhält, für solche Angriffe ausgenutzt werden.

Besonders interessant sind in diesem Zusammenhang die verschiedenen JavaScript-Dateien, die von den Webseiten heutzutage eingebunden werden. Diese sind für den Benutzer unsichtbar und laufen mit den gleichen Privilegien wie die sie einbindende Seite.

Ein als Man-in-the-Middle agierender Angreifer kann die HTTP-Response-Header "Cache Control" oder "Expires" so manipulieren, dass eine manipulierte JavaScript-Datei länger im Browsercache gespeichert wird. Wird so Schadcode in eine vertrauenswürdige Seite eingeschleust, die der Benutzer später aus seinem eigenen, geschützten Netz aufruft, wird die JavaScript-Datei aus dem Cache verwendet und der im unsicheren Netz eingeschleuste Schadcode im geschützten Netz ausgeführt. Ein Angriff könnte dann so ablaufen:

• Ein Benutzer nimmt sein Notebook mit in eine unsichere Umgebung, z.B. ein offenes WLAN auf einer Konferenz oder in einem Restaurant.
• Der Benutzer besucht eine harmlose, öffentliche Webseite wie z.B. ein Social Network.
• Der Angreifer schaltet sich über TCP-Session-Hijacking als Man-in-the-Middle in die Verbindung ein, manipuliert den "Cache Control"- oder "Expires"-Header einer JavaScript-Datei und fügt in diese Datei seinen eigenen Code ein.
• Der Benutzer bringt sein Notebook zurück in das geschützte Netzwerk und ruft dort erneut die Seite auf, die die manipulierte JavaScript-Datei verwendet.
• Der Browser lädt die JavaScript-Datei aus dem Cache und der im unsichere WLAN eingeschleuste Schadcode wird im geschützten lokalen Netz ausgeführt.

Der eingeschleuste JavaScript-Schadcode kann weiteren Schadcode nachladen, und da er sehr lange im Cache bleibt, kann das auch problemlos erst zu einem viel späteren Zeitpunkt passieren. Bei jedem Besuch des Opfers auf der Seite mit der manipulierten JavaScript-Datei wird der eingeschleuste Code ausgeführt. Er kann dann eine Verbindung mit dem Server des Angreifers aufbauen und neue Anweisungen entgegen nehmen.

SSL und VPN bieten nicht zwingend Schutz

Prinzipiell ist jede Website für solche Angriffe anfällig, der Angreifer sitzt als Man-in-the-Middle zwischen Client und Server und kann alles manipulieren, was vorbei kommt. Theoretisch sollte die Verschlüsselung der übertragene Daten durch SSL solche Angriffe unmöglich machen, praktisch sind die Benutzer zu leicht dazu zu verleiten, ein gefälschtes Zertifikat trotz aller Warnungen zu akzeptieren, wie z.B. Forscher der Carnegie Mellon University herausgefunden haben ("Crying Wolf: An Empirical Study of SSL Warning Effectiveness", Konferenz, zugehöriges Paper (PDF) und zugehörige Präsentation (PDF)).

Auch die Nutzung eines VPN schützt nicht zwingend vor einem Angriff, da die Webbrowser nicht zwischen sicheren und unsicheren Umgebungen unterscheiden. Was in einer unsicheren Umgebung gecached wurde, wird auch in der sicheren Umgebung aus dem Cache geholt, sofern es noch gültig ist. Als Angriffsziel bietet sich dann die häufig vorhandene Startseite der Hotspots an, auf denen den Lizenzbedingungen o.Ä. zugestimmt werden muss. Diese Startseiten sind meist nicht verschlüsselt und damit ein ideales Ziel. Wenn danach ein VPN genutzt wird, ist es bereits zu spät: Der Angreifer kontrolliert den Browser. Er kann z.B. die Seiten, die der Benutzer wahrscheinlich besuchen wird, vorab laden und dabei seine präparierte JavaScript-Dateien unterschieben. Ruft der Benutzer die Seiten danach über das VPN auf, befindet sich der Schadcode bereits im Cache.

Übrigens sind auch Smartphones betroffen, die besonders zum Cachen neigen. Wird statt des Telefonnetzes über Wifi auf das Internet zugegriffen, sind die gleichen Angriffe wie gegen Computer möglich.

Auch DNS angreifbar

Ein weiterer Angriff richtet sich gegen DNS-Abfragen, für die gefälschte Antworten eingeschleust werden können. Auch dafür gibt es bereits ein Modul für das Metasploit-Framework: DNSpwn.

Der Angreifer kann so auch den DNS-Cache des Webbrowsers manipulieren und z.B. dafür sorgen, dass internen DNS-Namen des sicheren Netzes öffentliche IP-Adressen (die dann zu Servern unter der Kontrolle des Angreifers gehören) zugeordnet werden. Greift der Benutzer auf einen internen Rechner zu, landen die Anfragen beim Server des Angreifers.

Das gleiche gilt sinngemäß auch für DHCP: Der Access Point kann zwar Pakete, die nicht von offiziellen DHCP-Servern stammen, ausfiltern, dieser Filter kann aber durch das direkte Senden der Pakete an den angegriffenen Client umgangen werden.

Gegenmaßnahmen

Maßnahmen zum Schutz von WLANs sind gegen TCP-Stream-Hijacking i.A. wirkungslos, da der Angriff gar nicht erst erkannt wird. Drahtlose Intrusion Detection Systeme müssen jedes legitim übertragene Paket kennen und mit den tatsächlich übertragenen Paketen vergleichen, um Manipulationen erkennen zu können. Richtet der Angreifer seine Antenne auf den Zielrechner aus und sendet mit minimaler Energie, wird das IDS die Pakete sehr wahrscheinlich gar nicht empfangen.

Ein VPN bietet einen gewissen Schutz - wenn der Angreifer nicht schon vor dessen Aufbau den Browser übernehmen kann, weil eine unsichere Seite aufgerufen wurde. Virenscanner etc. können die manipulierte Datei erkennen, wenn der Angreifer so ungeschickt ist, bekannten Schadcode zu verwenden. Eine speziell angepasste Datei wird i.A. aber nicht auffallen - woher soll der Virenscanner wissen, welche Funktionen in welchen von einer harmlosen Seite nachgeladenen Skriptdateien sein sollen und welche nicht?

Eine WEP-Verschlüsselung ist nutzlos, der Angreifer muss nur den WEP-Schlüssel ermitteln und hat dann vollen Zugriff auf alle Pakete. WPA-PSK ist etwas sicherer, aber wenn der Angreifer den PSK kennt und den Verbindungsaufbau des zukünftigen Opfers beobachten kann, kann er den individuellen Schlüssel berechnen. WPA-EAP schützt theoretisch, praktisch scheitert der Schutz oft daran, dass den Benutzern zu leicht gefälschte SSL-Zertifikate untergeschoben werden können.

Mike Kershaw schlägt vor, die Sicherheitszonen für die Browser manuell zu erzwingen, indem fürs Einloggen und Surfen verschiedene Browser verwendet werden und der Cache manuell gelöscht wird, wenn zwischen unsicherem und sicherem Netz gewechselt wird. Auch sollten beim Wechsel zwischen den Netzen keine Fenster geöffnet bleiben.

Hiermit ist der Themenblock "Netzwerk-Sicherheit" vorerst abgeschlossen. In der nächsten Folge geht es um das "Binary Planting", das Einschleusen von Schadcode über unsichere Suchpfade.

Carsten Eilers

---

Übersicht über alle Artikel zum Thema

WEP, WPA, WPA2 - WLAN-Schutz, aber richtig!

"Hole196" - Eine neue Schwachstelle in WPA2

DNS-Rebinding - Ein altbekannter Angriff kompromittiert Router

Von außen durch den Client in den Router

Ciscos "WPA Migration Mode" öffnet den Weg ins WLAN

NAT-Pinning, Angriffe auf Cisco-WLANs und ein Tool

Angriffe auf den WLAN-Client

BEAST - Ein neuer Angriff auf SSL und TLS 1.0

Konfigurationsänderungen am Router per UPnP - aus dem Internet

WLAN-Sicherheit - Stand der Dinge

WPS-Schwachstelle gefährdet WLANs