04.12.2007 | Autor / Redakteur: Wilhelm Dolle und Christoph Wegener / Ulrike Ostler
Mit der Version 6 des Internet Protokolls (IPv6) wird alles gut, könnten Unbedarfte meinen. So gehört die Sicherheitsarchitektur IPsec ab IPv6 – im Gegensatz zur jetzt am meisten verbreiteten Version IPv4 – zwar nun untrennbar zum Standard, doch ohne zusätzliche Sicherheitsvorkehrungen kommen Administratoren nicht aus. Das zeigen einige Schwachstellen aus dem möglichen Repertoire von IPv6.
IPv6 wird sicherlich die Performanz und das Management, insbesondere von großen Netzen, erheblich verbessern. So steht außer Zweifel, dass die Techniken sich kurz- und mittelfristig durchsetzen werden. In puncto Sicherheit gibt es im Vergleich zu IPv4 keine wesentlichen neuen Schwachstellen. Ganz im Gegenteil: Einige, bereits verfügbare Sicherheitserweiterungen, zum Beispiel IPsec und Neighbor Discovery Protocol (NDP) wurden direkt implementiert.
Das könnte Anwender in falscher Sicherheit wiegen. Denn das Protokoll, das im RFC 2461 spezifiziert wurde, und seine Sicherheitserweiterung „Secure Neighbor Discovery“ („SEND“; RFC 3971) bieten interessante Ansätze für Angreifer. Zum Beispiel bietet NDP neben einigen anderen Features einen mit dem „Address Resolution Protocol“ („ARP“) aus der IPv4-Welt vergleichbaren Dienst an:
Unter Benutzung der „Duplicate Address Detection“ („DAD“) kann ein Gerät eine freie IP-Adresse finden und eine Liste aller Geräte am lokalen Link („Local link“) erstellen, die dann mit der ARP-Tabelle von IPv4 vergleichbar ist. Darüber hinaus kann NDP auch den Router für eine spezielle Verbindung, oder den Default-Router für den lokalen Link ermitteln.
NDP unterstützt die angeschlossenen Systeme außerdem bei der Autokonfiguration der Netzwerkeinstellungen. Leider wurden hierbei aber keinerlei Sicherheitsmerkmale integriert, weshalb NDP eine Spielwiese für Angreifer mit Zugang zum lokalen Netz, den „Insidern“, ist.
Angriffe, die auf den „Schwachstellen“ von NDP aufsetzen, lassen sich generell in zwei Kategorien einteilen: Angriffe, die sich mit gefälschten „Redirects“ beschäftigen, also zum Beispiel auf einen falschen Default Router verweisen und mit denen ein Angreifer dann alle Pakete über sein eigenes Gerät umleiten kann sowie DoS-Angriffe, die auf gefälschten „Redirects“ oder gefälschten DAD-Antworten basieren.
Gesetzt den Fall, Gerät A sendet eine „Neighbor Solicitation Message“, um für den Datenaustausch die „Link Layer Address“ von Gerät B zu ermitteln. Wie bei der Verwendung von IPv4 kann ein Angreifer dann eine gefälschte Antwort zurück senden und damit den Datenverkehr zwischen Gerät A und Gerät B blockieren oder den gesamten Datenverkehr völlig unbemerkt über sein eigenes Gerät umleiten. Dabei ist besonders kritisch, dass sich, wie unter IPv4, der „Neighbor Cache“ regelmäßig aus Gründen der Performanz aktualisiert.
„Secure Neighbor Discovery“ („SEND“) heißt die Erweiterung, die die Sicherheitsproblematik von NDP durch Anwendung von kryptographischen Verfahren lösen sollte. Es ergänzt NDP um eine „Cryptographically Generated Address“ („CGA“), um Address Spoofing zu verhindern. Außerdem wird eine „RSA Option“ bereitgestellt, die einen Hash des verwendeten Server Keys und ein digitales Zertifikat enthält.
Damit kann ein Gerät nun die Quelle von ankommenden Paketen verifizieren und damit Vertrauensbeziehungen aufbauen. Die beiden ICMPv6-Nachrichtentypen „Certification Path Solicitation Message“ (RFC 3971; Type 148) und „Certification Path Advertisement Message“ (RFC 3971; Type 149) lassen sich so von einem Gerät dazu benutzen, einen Router nach einem Vertrauensanker zu befragen, mit dem dann die Authentizität von anderen Routern verifiziert werden kann.
Offen bleibt jedoch die Frage, wie die zugehörige Public Key Infrastruktur (PKI) aufgebaut werden soll. Das ist eine Frage, deren Lösung sich in der Vergangenheit als durchaus anspruchvoll herausgestellt hat.
Die Verfügbarkeit des Netzes unter den Gesichtspunkten mobiler Anwendungen und Szenarien war ebenfalls einer der Beweggründe bei der Spezifikation von IPv6. Allgemein erlaubt der „Mobility Support in IPv6“ („MIPv6“; RFC 3775) Geräten, sich unter Aufrechterhaltung der aktuellen Verbindung zwischen Netzwerken zu bewegen.
MIPv6 nutzt dazu die Funktion eines „Home Agent“, der den zentralen Kommunikationspunkt zwischen „Mobile Node“ – dem mobilen Gerät – und dem „Correspondent Node“ – also dem Gerät, mit dem das mobile Gerät kommunizieren will – bildet. Wenn das mobile Gerät von einem Netzwerk in ein anderes wechselt, werden der „Home Agent“ und die „Correspondent Node“ über den Wechsel informiert, dieser Vorgang wird auch als „Binding Update“ bezeichnet.
Unter Sicherheitsaspekten ist das „Binding Update“ der kritische Faktor. Denn wenn Angreifer diese Nachricht abändern können, sind sie in der Lage, das mobile Gerät in beliebige Netzwerke zu verschieben und dann entweder den gesamten Datenverkehr zu belauschen und/oder einen DoS-Angriff auszuführen.
Um diesem Szenario vorzubeugen, empfiehlt RFC 3775 die Nutzung von IPsec bei der Übertragung von „Binding Updates“, während die „Bindind Updates“ zum „Correspondent Node“ durch einen Mechanismus mit Namen „Return Routability Procedure“ abgesichert werden sollen.
Leider zeigt aber eine aktuelle Untersuchung von van Hauser (siehe Link), dass viele Implementierungen zurzeit die Verwendung von IPsec optional komplett abschalten können – ein Umstand, der auch Angreifer sicher erfreut.
Eine ausgefeiltere Form mobiler Anbindung stellt das Konzept der „Network Mobility“ („NEMO“; RFC 3963) dar. Bei diesem Ansatz sind nicht einzelne Geräte, sondern ganze Netze „mobil“. Dieses Szenario kann sinnvoll sein, zum Beispiel bei Access Points, die sich etwa in einem Zug oder Flugzeug befinden und sich somit von (Provider-)Netzwerk zu (Provider-)Netzwerk bewegen.
Generell sind hier die gleichen Angriffe denkbar, die im vorherigen Abschnitt beschrieben wurden. Allerdings kommt verschärfend hinzu, dass der Angreifer hier die Integrität kompletter Netzwerke mit einem einzigen gefälschten „Binding Update“ angreifen kann.
Christoph Wegener, promovierter Physiker und CObIT Basic Practitioner, ist seit 1999 mit der wecon.it-consulting freiberuflich in den Themen IT-Sicherheit und Open Source / Linux aktiv. Er ist Autor zahlreicher Fachbeiträge, Fachgutachter für verschiedene Verlage und Mitglied in mehreren Programmkomitees. Seit Anfang 2005 ist er zudem am europäischen Kompetenzzentrum für Sicherheit in der Informationstechnik (eurobits) tätig. Darüber hinaus ist er Gründungsmitglied der Arbeitsgruppe Identitätsschutz im Internet (a-i3) e.V. und dort, sowie in der German Unix User Group (GUUG), Mitglied des Vorstands.
Wilhelm Dolle ist Senior Security Consultant bei der HiSolutions AG in Berlin. Er hat unter anderem als Abteilungsleiter und Mitglied der Geschäftsleitung eines mittelständischen Unternehmens und freiberuflicher Berater mehr als 15 Jahre Erfahrung im IT-Sicherheitsmanagement, in Risiko- und Sicherheitsanalysen, in der Computer-Forensik sowie im Incident Management sammeln können. Wilhelm Dolle ist lizenzierter ISO 27001 / BSI IT-Grundschutzauditor, CISA, CISSP, Autor zahlreicher Artikel in Fachzeitschriften und hat Lehraufträge an einer Universität und an einer Berufsakademie inne.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2009408)
