Open Source im professionellen Einsatz
Linux-Magazin 01/2004

Gravierende Fehler in VPN-Protokollen und deren Lösung

Schutz(be)dürftig

Ein VPN strahlt Sicherheit aus - aber wie es um sie tatsächlich bestellt ist, bleibt meist im Dunkeln. Jenseits der drei wichtigen Protokolle SSL, SSH und IPsec finden sich fast nur Applikationen mit gravierenden Mängeln. Das Linux-Magazin erklärt die Hintergründe und beschreibt Auswege.

1123

Protokolle und Programme für VPNs (Virtuelle Private Netze) gibt es viele, sowohl als Open Source als auch proprietär. Unklar ist aber meist, wie es um ihre Sicherheit bestellt ist. Der naive Ansatz mancher Entwickler, etwas Blowfish-Verschlüsselung und RSA-Schlüsselaustausch auf einen Netzwerksocket zu legen, reicht bei weitem nicht aus. Dieser Beitrag erklärt die typischen Fallen beim Entwickeln einer VPN-Applikation und beschreibt, wie Krypto-Experten diese Schwächen vermeiden.

Wer seine eigene VPN-Software entwickeln oder eine vorhandene Applikation um VPN-Funktionalität ergänzen will, sollte diese Grundlagen kennen und berücksichtigen. Leider finden sich für fast alle Fehler auch Beispiele aus der Praxis, die zu teils schwerwiegenden Sicherheitslücken führen. Bereits die in dem Kasten "Sicherheitsanforderungen" genannten Punkte korrekt zu implementieren ist recht verzwickt. Abbildung 1 zeigt, wie eine sichere VPN-Implementierung aussehen sollte. Links ist das Handshake-Protokoll angedeutet, rechts die Datenübertragung.

Sicherheitsanforderungen

Ein VPN muss einige Anforderungen erfüllen, um tatsächlich sicherer zu sein als das Internetprotokoll. Dazu gehören:

Vertraulichkeit: Ein Angreifer darf den Inhalt einer Nachricht nicht erfahren. Die Nachricht einfach nur verschlüsseln ist nicht ausreichend. Ein Angreifer kann unter Umständen schon Schaden anrichten, wenn er nur die Länge der Nachricht weiß, bestimmte Bitmuster in den verschlüsselten Daten bemerkt oder ein einzelnes Datenbit aufdeckt (etwa ein Flag).

Authentizität und Zugangskontrolle: Ein Angreifer sollte es nicht schaffen, unbemerkt Daten unter falschem Namen ins VPN einzuschleusen. Die Abwehr kann sehr knifflig sein - der Saboteur könnte eine authentische Nachricht aufzeichnen und später ins VPN einfügen. Der Empfänger muss das bemerken.

Integritätssicherung: Ein Angreifer soll den Inhalt einer Nachricht nicht unbemerkt manipulieren können. Diese Anforderung lässt sich noch erweitern, um auch die Integrität des Datenflusses sicherzustellen. Dem Angreifer soll es nicht gelingen, Nachrichten einzufügen oder zu wiederholen (»Zahle 10000 Euro auf mein Konto«), zu löschen (»Achtung, jemand manipuliert deine Nachrichten«) oder die Reihenfolge zu ändern (»rm backup«, »mv valuable_data backup«). Für viele Angriffe auf den Datenfluss muss der Angreifer weder die Vertraulichkeit und Authentizität noch die Integrität der Nachrichten brechen.

Verfügbarkeit: Eine weitere, etwas schwächere Anforderung ist der Schutz vor Denial-of-Service-Attacken. Auf die Verfügbarkeit hat eine Sicherheitsschicht häufig keinen Einfluss, beispielsweise muss sich der IP-Stack selbst vor SYN-Flooding-Angriffen schützen. Dennoch ist DoS-Schutz eine wichtige Aufgabe für ein VPN, da es viele aufwändige Krypto-Algorithmen berechnet (RSA oder Diffie-Hellman-Schlüsseltausch). Ein Angreifer könnte den Server mit vielen Client-Connect-Nachrichten überfluten. Den Client belastet das kaum, es genügt, wenn er Zufallswerte schreibt. Der Server muss jedoch kostspielige Krypto-Berechnung durchführen, nur um zu bemerken, dass die Nachricht Datenmüll enthält.

Abbildung 1: Ein sicheres VPN-Protokoll besteht aus einem Handshake-Protokoll (gute Vorlagen sind TLS, SSH oder das IKE von IPsec), mit dessen Schlüsselmaterial es dann die Daten chiffriert (etwa mit 3DES) und sie Integritäts-gesichert (etwa per HMAC-SHA1) überträgt.

Für den Handshake eignen sich Protokolle, wie sie auch TLS[11], SSH[12] oder IPsec-IKE[13] verwenden. Während dieser Phase handeln beide Seiten das Schlüsselmaterial aus, das sie dann bei der Datenübertragung einsetzen. Jedes Datenpaket erhält mehrere Schutzschichten: Die innerste Hülle sorgt für Vertraulichkeit (etwa mit 3DES), die nächste stellt die Integrität sicher (per HMAC-SHA1) und die äußere Schutzhülle kümmert sich um die Integrität des Datenstroms (hier mit dem Sliding-Window-Algorithmus von IPsec).

Viele VPN-Implementierungen halten sich aber nicht an diese Vorlage, sei es aus Unwissenheit oder um die vermeintlich überflüssige Komplexität zu vermeiden. Dabei stolpern die Entwickler immer wieder in die gleichen Fallen.

Einige VPN-Protokolle verschlüsseln mit RC4. Seit Windows 3.1 hat Microsoft diesen Algorithmus bis in die späten 1990er an allen möglichen Stellen eingesetzt. Sie haben es fast jedes Mal geschafft, RC4 falsch zu verwenden - daher meiden sie ihn inzwischen. Microsoft-freie Software setzt ihn aber heute noch ein, beispielsweise Eclipt [http://freshmeat.net/projects/ecliptsecuretunnel/] und Mirrordir [http://mirrordir.sf.net].

RC4: Eine Stromchiffre ...

RC4 ist eine einfach zu verwendende und daher populäre Stromchiffre, die mit einer Pseudozufallszahlenfolge arbeitet. Zum Verschlüsseln verknüpft der Absender den Schlüsselstrom per XOR mit den Klartextdaten (Abbildung 2, oben). Der Empfänger erzeugt denselben Schlüsselstrom und entschlüsselt den Chiffretext wieder mit XOR.

Dummerweise ist XOR aber kommutativ. Oft sind Chiffre und Klartext schon bekannt, etwa weil jemand eine E-Mail an einen VPN-Anwender sendet oder weil er die Reaktion einer E-Commerce-Applikation beobachtet, bei der er etwas eingekauft hat - dann deckt XOR direkt den Schlüsselstrom auf (Abbildung 2, mitte). Mit diesen Daten sind dann auch VPN-Pakete zu entschlüsseln, deren Inhalt vorher noch verborgen war.

Abbildung 2: Bei RC4 generiert der Absender einen Schlüsselstrom, den er per XOR mit dem Klartext verknüpft (oben). Wer Klartext in das System injiziert und das Chiffrat abhört, kann den Schlüsselstrom ermitteln (mitte). Aus zwei Chiffretexten lässt sich die XOR-Verknüpfung der Klartexte entschlüsseln (unten).

Selbst ohne eigene Daten in das VPN einzuschleusen, kann ein neugieriger Zeitgenosse immerhin die XOR-Verknüpfung zweier Klartextpakete ermitteln: Er muss nur die verschlüsselten Pakete per XOR verknüpfen, die Schlüsseldaten beider Pakete heben sich dabei gegenseitig auf. Microsoft versuchte einmal, die eigenen RC4-Programme durch den Wechsel von 32- auf 128-Bit-Schlüssel besser zu sichern. Das Kunststück konnte nicht gelingen, da die Schlüssellänge für diese Sicherheitslücken irrelevant ist.

Ein besonders einfacher Angriff gelingt bei RC4-basierten Challenge-Response-Protokollen: Die Challenge und die (ver- oder entschlüsselte) Response genügen, um den Schlüsselstrom per XOR zu erfahren. Übrigens haben 802.11-Hersteller (WLAN) diesen Teil von WEP klammheimlich aufgegeben, als ihnen jemand erklärte, was sie da standardisierten.

... mit vielen Problemen

RC4 hat noch weitere kryptographische Schwächen, die teilweise schon seit Jahren bekannt sind. Sie sind zwar weniger gravierend, aber es bleibt fragwürdig, wenn ein neu entwickeltes Produkt heute noch RC4 ohne besondere Vorkehrungen einsetzt. Zudem erlaubt es RC4 dem Angreifer, die Nachricht nach Belieben zu ändern. Dazu später mehr.

Die Alternative zu Stromchiffren sind Blockchiffren. Die bekanntesten Vertreter heißen DES und 3DES, das recht aktuelle AES, IDEA (aus PGP 2), Blowfish (aus Bruce Schneiers Buch "Angewandte Kryptografie") und CAST (PGP 5). Es gibt keine grundlegenden Unterschiede zwischen diesen Algorithmen. 3DES ist die konservativste Wahl, es wurde am genauesten analysiert, ist seit einer Ewigkeit bekannt und wird von praktisch allem unterstützt. Der Nachfolger AES ist zwar schneller, aber auch jünger und hatte daher weniger Zeit, sich im harten Krypto-Alltag zu behaupten. Der Vorteil ist zudem relativ: Selbst eine ältere 1-GHz-CPU verschlüsselt mit 3DES immerhin etwa 50 MBit/Sekunde, mit AES schafft sie rund 100 MBit/Sekunde. Auf der Freeswan-Homepage sind weitere Performance-Daten zu finden[1].

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Standard-Tunnel

    IPsec ist der De-facto-Standard für den Aufbau virtueller privater Netze (VPNs). Freeswan integriert dieses Sicherheitsprotokoll in den Linux-Kernel und unterstützt dabei sogar die opportunistische Verschlüsselung. Installation und Konfiguration sind jedoch nicht trivial.

  • Stahlnetz

    Ipsec gilt für viele als der Standard unter den VPN-Technologien. Wer dabei ganz auf Nummer sicher gehen will, speichert seine Zugangsberechtigung in Form von X.509-Zertifikaten auf verschlüsselten Tokens oder USB-Sticks. Wie das geht, zeigt dieser Artikel am Beispiel von Strongswan.

  • Sicherer Transport

    Der kommende Linux-Kernel 2.6 wird IPsec enthalten, und zwar nicht mit Freeswan-Patches, sondern mit einer neuen Implementierung. Dazu gesellen sich spezielle Userspace-Tools. Dieser Artikel zeigt, wie damit sichere IP-Transportwege entstehen.

  • Neue Öffnung

    Neuere Windows-Versionen ersetzen PPTP durch L2TP. Das Layer 2 Tunneling Protocol bietet aber selbst keine Sicherheitsfunktionen, daher kommt es zusammen mit IPsec zum Einsatz.

  • Open VPN und IPsec

    Dass zwei Protokolle, die letztlich zum gleichen Ziel führen, nicht zwingend in Feindschaft zueinander stehen, beweisen Open VPN und IPsec seit Jahren. Obwohl es sich um konkurrierende VPN-Lösungen handelt, haben beide ihre Daseinsberechtigung und kommen gut miteinander zurecht.

comments powered by Disqus

Ausgabe 09/2016

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.