Glaubt man der Fernsehwerbung oder Wer Werbung in den Printmedien, ist das Wireless-LAN (WLAN) der neueste glückseligmachende Trend und das Killerfeature welches man unbedingt zuhause haben muß. Doch wie steht es eigentlich mit der Sicherheit?
Zugegebenermßen ist es praktisch vorm Fernseher zu surfen, seine Mails zu checken, zu chatten oder vielleicht sogar zu arbeiten. Die im Moment zur Verfügung stehenden 11Mbit (IEEE 802.11b) oder 54Mbit (IEEE 802.11g) sind auch fü anspruchsvollere Benutzer ausreichend -zumal der DSL Zugang bei weitem langsamer ist.
Klingt ja alles recht schön und gut. Nur: schon mal drüber nachgedacht, daß sich Radio-Wellen, (fast) beliebig ausbreiten und man somit nicht sicher sein kann, wo die landen?
Daß jemand der im Auto vorm Haus sitz durchaus mitlesen kann auf welcher Seite man grad surft und wie das Passwort zum EMail Server lautet?
Ja, schon, mag jetzt der eine oder andere sagen. Aber dazu gibt es ja Verschlüsselung. Stimmt. Und die sollte schützen. Zumindest wäre das vernünftig.
Und tatsächlich haben die Erfinder von der WLAN Protokolle auch daran gedacht und haben einen Standard definiert, wie man Wireless Daten verschlüsseln kann: Das Wired Equivalent Privacy (WEP).
Das Design des Wired Equivalent Privacy (WEP) ist aber wahrlich kein Paradebeispiel kryptographisch einwandfreiem Design. Vermutlich haben sich die Designer mit dem Thema Kryptographie vorher nicht wirklich ausgiebig beschäftigt. Anders kann man das -meiner Meinung nach- Desaster nicht erklären. Denn WEP ist alles andere als sicher.
Gleich drei große Designschwachpunkte enthält IEEE 802.11: Statische Schlüssel, ineffektive/inkorrekte Verwendung der Initialisierungsvektoren und das Fehlen von Integritätsüberpr“fungen der Datenpakete.
RC4 – Stream Verschlüsselung in WEP
WEP verwendet RC4 als Verschlüsselungsalgorithmus. RC4 ist ein symmetrischer Algorithmus und als solcher verwenden sowohl Absender als auch Empfänger die gleichen Schlüssel für die Verschlüsselung. RC4 erzeugt aus einem verhältnismäßig kurzen Schlüssel einen unendlich langen pseudo-zufalls- Stream. Der Sender XORt diesen Stream mit dem Klartextpaket und erzeugt damit den verschlüsselten Datensatz. Der Empfänger erzeugt mit dem selben Schlüssel ebenfalls den Schlßselstream. XORt er nun die verschlüsselten mit diesem, erhält er den Klartext.
Diese Art der Verschlüsselung ist zwar sehr effektiv und schnell, hat aber ein paar gravierende Nachteile. Wird z.B. währen der übertragung ein Bit geflippt (umgekippt), kommt beim Klartext ebenfalls ein geflipptes Bit raus.
Ansonsten ändert sich nichts, das heißt, daß so eine Veränderung unter Umständen gar nicht bemerkt wird. Das andere, noch größere Problem ist, daß es möglich ist aus mehreren mit demselben cipher-Stream verschlüsselten Datenschnipsel den XOR Stream herauszubekommen. Aus diesem kann man nun durch statistische Analyse den Klartext herausbekommen. Je mehr man nun Datenschnipsel hat die mit demselben Schlüssel verschlüsselt sind, desto einfacher ist es durch statistische Analyse die Klartexte herauszubekommen. Hat man erst mal einen errechnet, ist es trivial, den Schlüssel zu extrahieren und dann alle Pakete zu entschlüsseln. Der Code ist geknackt.
Schlüssel
802.11 schreibt nicht vor, WIE der Austausch bzw. eine Aktualisierung der Schlüssel im „laufenden Betrieb“ zu erfolgen hat. Letztendlich läuft es darauf hinaus, daß in der Regel die Schlüssel einmal bei der Ersteinrichtung des WLANs gesetzt werden und danach nie mehr verändert werden. Andere kryptographische Protokolle verwenden zwar auch symmetrische Algorithmen bei der Daten/Paketverschlüsselung selbst (etwa SSH oder SSL), die verwendeten Schlüssel aber werden jedoch bei JEDER neuen Session bzw. nach einer bestimmten vorgegebenen Zeit per Zufall immer wieder neu gesetzt. Dies kann dadurch erfolgen, daß diese Protokolle auf asymmetrischen Schlüsselpaaren (public/private Keys) basieren. Der Server erzeugt eine Zufallszahl die als Session-Schlüssel verwendet werde soll und sendet diesen, verschlüsselt mit dem Public Key des Clients, an den Client. Nur dieser kann anhand seines private Keys diesen wieder entschlüsseln und kennt dadurch den nur für diese eine Session gültigen Schlüssel. Dieser wird für die eigentliche Datenverschlüsselung verwendet, die aus Geschwindigkeitsgründen immer mit einem symmetrischen Verfahren verschlüsselt wird.
802.11 kennt so ein Verfahren nicht und verwendet statische Schlüssel, die immer gleich bleiben. Sowohl während einer Session als auch zwischen verschiedenen Session. Hat man also einmal einen Schlüssel herausgefunden kann man jede beliebige Verbindung abhören und entschlüssel. Hinzu kommt das Problem, daß jeder der Teilnehmer am WLAN den Schlüssel kennen. Was passiert, wenn ein Mitarbeiter — vielleicht auch noch im Bösen — aus der Firma ausscheidet? Eigentlich müssten dann die Schlüssel ausgewechselt werden. Das heißt aber auch, daß jeder Mitarbeiter den Zugangsschlüssel zum WLAN ändern muß. Bei Firmen mit hoher Fluktuation von Mitarbeitern bzw. bei vielen Benutzern im WLAN kann man sich vorstellen, welche Probleme das nach sich zieht.
Es gibt zwar einzelne Implementierungen von Herstellern von 802.11 Produkten die diese Probleme zu umgehen oder beseitigen versuchen. Dies sind aber Speziallösungen welche nur auf bestimmter untereinander kompatiblen Geräten und Karten funktionieren -meistens nur die desselben Herstellers.
Paketintegrität
Integritätsprüfung bedeutet, daß der Absender über ein versendetes Paket — vereinfacht ausgedrückt — eine Art Quersumme bildet und diese dann an das Paket selbst anhängt. Der Empfänger macht nun dasselbe — er bildet die Quersumme über das Paket und vergleicht den Wert mit dem, der der Absender mitgeschickt hat. Stimmen die Werte überein,wurde das Paket nicht verändert.
So eine Integritätsprüfung macht man aus zwei Gründen: einmal um zu überprüfen ob bei der übertragung alles auch richtig angekommen ist oder ob z.B. durch ein schlechtes Medium (bei WLAN -schlechter Empfang) die Daten „verzerrt“ wurden und z.B. einige Bits ümgekippt“ sind. Der zweite Grund ist der, daß Daten absichtlich unterwegs verändert worden sein könnten. Ein Angreifer könnte die Pakete dahingehend abänern, daß er eigene Daten unterschmuggelt oder versucht, die Verbindung zu „übernehmen“ (sogenanntes „hijacking“).
WEP verwendet zum Checken der Integrität der Pakete CRC32. Dieses Verfahren beruht aber auf keinem kryptographischen Hashalgorithmus (etwa MD5 oder SHA1). CRC32 ist ein lineares Verfahren. Das bedeutet, daß es möglich ist, den korrekten CRC aus der Bit-Differenz des Datensatzes zu berechnen. Weil aber ein bitweises verändern des RC4 Streams in ein ebensolches Verändern des Klartextes bedeutet, kann nun geschickt der Stream derart verändert werden, daß sich die CRC32 Prüfsumme ebenfalls korrekt mit ändert.
Hier ein Beispiel wie sowas aussehen kann:
Plaintext: Überweise den Betrag von 10000,00 EUR an Kto 2324561 BLZ 76350000
Ciffriert: aMz0rspLtxTghsnJDu278sdhdSkjdhgsfbfwuz&DJDWklfjshcUjlofwe8JWdq12uL
^
/ \
1101011
flip
1101101
\ /
.
Ciffriert: aMz0rspLtxTghsnJDu278sdhdSmjdhgsfbfwuz&DJDWklfjshcUjlofwe8JWdq12uL
Plaintext: Überweise den Betrag von 60000,00 EUR an Kto 2324561 BLZ 76350000
Initialisierungsvektoren
Ein Initialisierungsvektor ist eine Art Salt Wert (vergleichbar mit dem im UNIX crypt verwendeten), welcher zum symmetrischen Schlüssel hinzugefügt wird, etwa durch einfaches Anhängen oder über eine logische Operation draufgerechnet. Damit soll für jedes Datenpaket der Schlüssel abgeändert werden. IVs sind Zufallswerte, und diese sollen dem potenziellen Angreifer keine wiederkehrenden Muster im verschlüsselten Datenpaket erkennen lassen Solche Muster können auftreten wenn dieselben Daten mehrfach gesendet werden — etwa Login Informationen bei mehrfachen login, starten von denselben Programmen usw. — also durchaus normale Situationen bei der täglichen Arbeit. über solche Muster können Rückschlüsse auf den Schlüssel gezogen werden. Leider ist das Konzept der Initialisierungsvektoren in IEEE 802.11 nicht korrekt implementiert worden.
Der InitialisierungsVektor in WEP ist ein 24bit Wert, welcher als Teil des Datenpaketes im Klartext mitgesandt wird. Dies ist nicht gerade ein großer Wert wenn man bedenkt, daß sich der Vektor bei jedem Paket ändern muß. Noch schlimmer ist, daß die Spezifikation des 802.11 Standards besagt, daß ein ändern des IVs bei jemdem Paket optional ist. Die Folge ist, daß verschiedene WEP Implementierungen den Vektor überhaupt nicht ändern und nach einem Initialisieren der Geräte (etwa Neustart) der Vektor nicht mehr verändert wird und gleich bleibt.
Aber selbst wenn korrekterweise bei jedem Paket der Vektor brav geändert wird gibt es viele Implementierungen, die den Vektor vorhersehbar ändern. So starten manche WEP Geräte mit einem IV von „0“ und inkrementieren dann einfach den Wert bei jedem Paket um „1“…
Und selbst wenn ein Pseudozufallswert verwendet wird; Nach etwa 5 Stunden Datenübertragung bei 11 MBit müssen sich die Vektoren zwangsläufig wiederholen. Sagen wir, ein ausgelasteter AccesPoint sendet konstant 1500 Byte große Pakete über 11MBit. 1500 * 8/(11*106)*224 = ca. 1800 Sekunden. Also etwa 5 Stunden. Das heißt, daß ein Angreifer spätestens nach 5 Stunden zwei chiffrierte Datenpakete hat die mit denselben Schlüssel verschlüsselt sind. Auf diese kann er dann eine statistische Analyse fahren. Und je länder der Angreifer mitlauscht desto mehr Pakete hat er zur Analyse.
Fertige Software gibt es im Internet.
Passive Attacke
Die einfachste Attacke auf WEP/IEEE 802.11 ist, genügend Datenpakete zu sammeln. Wie wir gesehen haben, werden sich früher oder später die Initialisierungsvektoren wiederholen („IV Kollision“). XORt man zwei Pakete die denselben IV verwenden, bekommt man den XOR Wert des Plaintextes. Da nun besonders IP viele Redundanzen mit sich bringt und recht gut vorhersehbar ist (TCP Header, Paketnummerierung, Flags, usw. ) kann man nun recht gut vermuten, was das Paket beinhaltet. Man kann also recht gute statistische Analysen machen und meistens sogar den exakten Inhalt erraten. Auf diese Weise können in relativ kurzer Zeit eine große Menge von Pakete analysiert und erraten werden. Hat man erstmal einen Klartext gefunden, kann man alle weiteren Pakete, die den demselben IV verwenden, ebenfalls entschlüsseln. Nach und nach und mit etwas Geduld hat man alle IVs und kann so den kompletten Datenverkehr entschlüsseln.
Das Ganze kann man etwas verkürzen indem man bekannte (Klartext) Daten ins Netz schleust indem man Datenverkehr von außerhalb des WLANs ins Netz schickt. Etwa, indem man einen Benutzer im Netz dazu bringt, eine bestimmte Internet Seite zu besuchen. Oder man schickt eine EMail an einen Benutzer innerhalb des WLAN Netzes. Kann man nun genau diese Datenpakete abfangen, hat man den IV Vektor und kann nun alle Pakete entschlüsseln, die diesen verwenden.
Fazit
Nun, dem privaten Surfer mag das vielleicht nicht stoeren — muss es vielleicht auch gar nicht. Wen interessiert es schliesslich, welche Webseiten ein privater Nutzer, mein Nachbar, der Junge von Nebenan, besucht? Und falls doch — der Aufwand WEP zu knacken und Daten in einem WLAN mitzulesen ist doch recht hoch. Technisch gesehen zwar nicht, aber der Zeitaufwand ist beträchtlich. Wie weiter oben geschrieben, braucht man ne bestimmte Menge an Daten um sinnvoll mit einem Crack zu beginnen. Und bei einem privat genutzen Netz kann das, je nach Nutzung des WLANs, gut und gerne 2 Wochen dauern. Trotzdem möchte man sich gegen mögliche Angriffe oder heimliches Mitlesen von Daten schützen.
Das Beste wäre, wenn man sich ein VPN einrichtet. Allerdings ist das Aufbauen eines IPSEC Netzwerkes ziemlich aufwendig und kompliziert und so, als würde man mit Kanonen auf Spatzen schießen. Dafür bieten einige WLAN AccessPoints die Möglichkeit, IPSEC VPNs einzurichten. Dann sollte man ruhig diesen Weg gehen denn der Großteil der Arbeit liegt dann schon im AccessPoint. „Nur“ einen Client einzurichten sollte dann machbar sein.
Etwas einfacher und viel weniger aufwendig ist das Aufbauen eines VPNs mit öpenVPN“ (www.openvpn.org). Es gibt Clients für die verschiedenste Betriebssysteme — von verschiedenen Windows Versionen zu MAC OS und Unix/*BSD/Linux. Die Webseite bietet recht gute Beispiele und für die gängigsten Betriebssysteme sind Binärversionen von OpenVPN erhältlich — man muß sich die Software also nicht selbst übersetzen.
Manchmal reicht aber auch ein einfaches SSH um verschlüsselt Daten auszutauschen. Denn auch mit dem Secure Shell Protokoll kann man einfache VPNs aufbauen. Auch Webseiten die mit SSL verschlüsselt sind („https://“) können nicht mitgelesen werden. Somit sollte man z.B. bei Banküberweisungen auf der sicheren Seite sein. Allerdings nur dann, wenn man drauf achtet, daß die Seiten auch verschlüsselt sind (bei den meisten Browsern sieht man das an einem kleinen Schloß welches entweder zu (verschlüsselt) oder offen (unverschlüsselt) ist).
Auf die Einrichtung von IPSEC, OpenVPN, SSH usw. möchte ich hier nicht weiter eingehen, da dies den Rahmen sprengen würde. Bei großem Interesse kann ich aber auch gerne auch mal einen Artikel diesem Thema widmen. Ich denke aber, der Gedanke den ich vermitteln möchte ist klar — WLAN mit WEP Verschlüsselung ist unsicher. Besser als gar keine Verschlüsselung und für den Hausgebrauch meistens ausreichend, aber doch mit Vorsicht zu genießen. Für Firmen ist WEP inakzeptabel. Es gibt aber Auswege indem man sich selbst gesicherte Netzverbindungen mit VPNs schafft.
Allerdings bietet WLAN leider nicht die heile, schöne Welt die uns die Werbung suggeriert. Zumindest nicht out-of-the-box. Trotzdem: ich persönlich möchte die Annehmlichkeiten von WLAN nicht mehr missen…