Viele kennen den Hinweis: Vorsichtig sein in öffentlichen W-LAN-Netzwerken und keine unverschlüsselten Daten durch die Gegend senden. Was es mit diesem Hinweis auf sich hat und einige Beispiele über die Möglichkeiten (z.B. Spoofing oder Man-in-the-Middle Angriffe), die ein Angreifer in Netzwerken hat, möchte ich heute in meinem IT Security Blog aufzeigen.

Viele sind erstaunt, wie einfach Angriffe möglich sind und wie schnell sich auch die Sicherheitsvorkehrungen vorsichtiger, fortschrittlicher Nutzer mit wenigen Handgriffen aus dem Weg räumen lassen. Ziel dieses Beitrags ist eine Sensibilisierung der Nutzer und eine Erläuterung, warum es sich lohnt, nicht alle Warnmeldungen im Browser einfach zu bestätigen.

Spoofing in einem Testnetzwerk

Ich möchte das Ganze an einem Beispielnetzwerk erläutern:

Im Bild zu sehen ist ein typisches Netzwerk, ob jetzt ein LAN oder Wireless-LAN. In diesem Netzwerk ist ein Router an das Internet angeschlossen. Der Router hat nach außen die IP 85.191.xxx.yyy (die Buchstaben stehen stellvertretend für Zahlen, um nicht ausversehen jemanden echtes hier zu nennen). Nach Innen, also im W-Lan selber, hat er die IP 172.22.10.1.

Ein "normaler" Internetrouter hat mindestens zwei Adressen: Eine öffentliche, aus dem Internet erreichbar, und eine private. Router reichen Pakete vom internen Netzwerk, also etwa von John, an das Internet weiter und ordnen die Antworten der Server aus dem Internet wieder den Nutzern zu. Hierbei werden die Quell- und Ziel-IP-Adressen durch den Router dynamisch ausgetauscht ("NAT", Network Address Translation).

In unserem Szenario würde Mallory gerne die Zugangspasswörter für den Zugang zum sozialen Netzwerk Facebook von Alice erfahren. Oder er könnte wissen wollen, was sie bei Google alles sucht. Oder Ihre Zugangspasswörter für ihr Online-Banking herausbekommen. Er hat sogar die Möglichkeit, Daten auf dem Weg von Alice zum Server zu ändern, zu "manipulieren".

In unserem Beispiel gehen wir davon aus, dass einige Seiten über SSL/TLS verschlüsselt werden, andere nicht. Eine verschlüsselte SSL Verbindung kann man im Browser am "s" bei https in der Adressleiste erkennen.

Um nachvollziehen zu können, wie die Angriffe funktionieren, müssen wir uns einmal anschauen, wie in einem Netzwerk wirklich kommuniziert wird. Zum einen gibt es dort IP-Adressen, zum anderen MAC-Adressen. Eine MAC-Adresse ist eine einmalige Adresse eines Hardwaregeräts, wie etwa einer Netzwerkkarte, im Netzwerk. Ein MAC-Adresse lässt sich leicht fälschen und es ist auch ohne weiteres möglich, über eine Netzwerkkarte unzählige MACs zu simulieren. Zu jeder IP-Adresse gehört immer eine MAC-Adresse. Jedes Geräte im Netzwerk besitzt eine Art "interne Tabelle" (die "ARP-Tabelle") in dem die Zuordnungen der IP-Adressen zu MAC-Adressen gespeichert werden. Unter Windows kann die Tabelle in der Kommandozeile mit dem Befehl

arp -a

angezeigt werden, unter Linux mit dem Befehl

arp -n

Die Ausgabe hat folgendes Format:

In der Tabelle sind nur die MAC-Adressen des nächsten Geräts auf der Route zum Ziel gespeichert. Würde also Alice im Bild oben den Befehl aufrufen, würden dort nur die MAC-Adressen der anderen W-LAN Teilnehmer und des Routers auftauchen.

Fassen wir zusammen: Hinter jeder IP-Adresse steckt eine MAC-Adresse. Die Zuordnungen von IP-Adressen zu MAC-Adressen werden in einer ARP-Tabelle lokal zwischengespeichert. Wird eine IP außerhalb des lokalen Netzwerks angesprochen, wird die MAC des nächsten Routers verwendet.

Eine schematische Darstellung des Vorgangs sieht wie folgt aus:

Die Schwachstelle der ganzen Sache liegt im Punkt "Ermittlung der MAC-Adresse". Hier kommt ARP Spoofing ins Spiel: Ich sorge dafür, dass der Client eine MAC-Adresse meiner Wahl zur IP-Auflösung verwendet. Da MAC-Adressen für alle sichtbar öffentlich im Netzwerk abgefragt werden, ist dies, auch im einem geswitchen Netzwerk, nicht sonderlich schwer.

Ein Man-in-the-Middle Angriff mit ARP Spoofing im Detail

• Alice (.12) sendet ein Paket an alle PCs des (Sub-)Netzwerks über einen Brodcast. Wer jemals einen Sniffer im Netzwerk verwendet hat, wird die Meldungen sicherlich kennen:
• Mallory's Notebook, auf dem der Paketsniffer lief, hatte die .13. Alice, mit der Adresse .12, hat versucht, sich mit der IP 172.22.10.14 (im Beispielbild nicht existent) zu verbinden. Diesen Vorgang konnte ich vom Mallory's Notebook aus beobachten, siehe die Pakete Nummer 2, 4, 5, 8, 9 und 11 im Screenshot.
• Normalerweise antwortet nur der PC, der die IP-Adresse auch hat (siehe Pakete 6 und 7 im Bild).
• An diesem Punkt setzt ARP Spoofing ein: Ich antworte auf Anfrage, die mir gar nicht zugeordnet worden sind.

Resultat: Alice denkt, sie verbindet sich mit der IP 172.22.10.14, in Wirklichkeit verbindet sie sich jedoch mit der IP .13 (Mallory). Um das ganze zu verbergen, leite ich die Pakete anschließend von der IP .13 an .14 transparent weiter. Was wir nun gebaut haben, nennt sich "Man-in-the-Middle"-Angriff.

Ich möchte an dieser Stelle keine Anleitung zum Hacken veröffentlichen, aus diesem Grund nur eine Übersicht über die technischen Details, die bei einer ARP-Spoofing-Attacke auftreten:

• Schritt 1: ARP Spoofing beginnen, Pakete mit der gefälschten IP Auflösungen im Netzwerk verbreiten:
  
• Schritt 2: Traffic von Alice abfangen, hierbei können auch alle unverschlüsselten Passwörter mitgelesen werden, sowohl von E-Mailadressen als auch von Webseiten:
  
• Schritt 3: ARP Spoofing beenden, korrekte Zuordnungen wieder herstellen.
  

Alles in allem keine zeitaufwendige Sache und schwer zu identifizieren. Viele Leute haben sich Angriffe dieser Art in öffentlichen Netzwerken zum Hobby gemacht! Daher: Keine Passwörter oder Zugangsdaten in öffentlichen Netzwerken eingeben!

Ein Wort zu SSL: Ja, prinzipiell ist SSL vor MITM Angriffen sicher, aber 2 Szenarien sorgen dafür, dass ich trotzdem Zugriff auf die Daten erhalte:

• entweder bin ich in der Lage gültige Zertifikate zu fälsche, da ich eine vertrauenswürdige CA unter mir habe (öffentliche, staatliche Akteure) oder
• ich baue zwischen dem Ziel und mir eine SSL Verbindung auf und leitete die Daten unverschlüsselt weiter zum Client. Den wenigsten würde es auffallen, wenn beim Login meines Lieblings-Onlineshops plötzlich nicht mehr https:// sondern http:// in der Adressleiste steht. Gerade bei http Seiten mit verstecktem https Login wird dies relativ schwierig.

Was sollte jeder Nutzer aus diesem Beitrag mitnehmen?

1. Das Mitschneiden von Daten in einem öffentlichen Netzwerk ist möglich und einfach. Wirklich einfach.
2. Keine wichtigen oder persönlichen Daten in öffentlichen Netzwerken eingeben. Auch keine E-Mails abrufen oder ähnliches.
3. Darauf achten, ob bei Seiten, auf denen ich relevante Zugangsdaten eingebe, https oben in der Adressleiste steht.
4. Die Meldung "Die verschlüsselte Seite versucht Daten über eine unsichere Verbindung zu versenden" des Browsers nicht einfach ignorieren, sondern beachten!

Bildnachweis:

• © Warakorn - Fotolia.com