Stellen Sie sich vor, Sie surfen im Internet wie an vielen anderen Tagen. Sie wählen aus der Bookmark-Liste die Seite Ihrer Bank mit den Börsenkursen, anhand der unerwartet günstigen Kurse entschließen Sie sich zum Kauf. Anschließend holen Sie sich per FTP ein halbfertiges Manuskript vom Firmen-Server, um zu Hause daran zu arbeiten. Und die Web-Seite eines großen Softwareherstellers liefert ein langersehntes Software-Update.

Ein ganz normaler Tag im Internet? Heute nicht. Die Börsendaten waren gefälscht, die Optionsscheine bereichern nun eine zwielichtige Firma. Die Konkurrenz hat Ihre FTP-Verbindung übernommen und ist soeben dabei, Ihre Kundendatenbank abzugreifen. Und das vermeintliche Software-Update ist eine Zeitbombe, die in Kürze die Kontrolle über Ihren Rechner übernehmen wird. Alle diese Angriffe lassen sich durch Manipulationen des DNS (Domain Name Service) verwirklichen. Die Kunstgriffe dafür sind im Internet-Untergrund allgemein bekannt, erfolgreiche Angriffe bereits ohne großen Aufwand durchgeführt worden.

Der DNS entspricht einem Telefonbuch für die Rechneradressen im Internet. Sobald ein Übeltäter es schafft, Ihnen seine "Telefonnummer" anstatt der echten unterzuschieben, geht alles andere wie von selbst. Stellen Sie sich die Mißbrauchsmöglichkeiten vor, die sich ergäben, wenn jemand in den Gelben Seiten beliebige Änderungen vornehmen könnte. Zum Beispiel wäre es möglich, Sie in eine 0190er-Verbindung zu locken, das Gespräch automatisch zum tatsächlichen Anschluß durchzuverbinden und noch dazu mitzuhören. Im Internet ist die Situation noch brisanter, da sich dort praktisch niemand die Anschlußnummern merkt, sondern diese immer wieder automatisch und für den Benutzer unsichtbar im DNS nachgeschlagen werden.

Die Rechner im Internet kommunizieren an sich über numerische IP-Adressen (32-Bit-Zahlen). Da diese Zahlen für Menschen nur schwer zu merken sind, wurden die Rechnernamen eingeführt. Um beispielsweise www.harmlos.de in die numerische IP-Adresse 192.168.42.11 umzuwandeln, kommt der DNS ins Spiel: nach Art einer weltweit verteilten, dezentralen Datenbank. Normalerweise funktioniert das auch sehr zuverlässig – alle Daten sind auf mindestens zwei unabhängigen Servern gespeichert. Diese Redundanz sorgt dafür, daß auch bei teilweisen Ausfällen im Internet immer noch eine Auskunft möglich ist.

Gegen mutwillige Störungen ist DNS jedoch nur schlecht gesichert. Und da die Kompatibilität zu allen weltweit eingesetzten Versionen gewährleistet sein muß, lassen sich neue Sicherungsmaßnahmen nur schwer durchsetzen. Einer der Hauptgründe für die Anfälligkeit ist, dal3 Antworten von legitimen Servern leicht vorzutäuschen sind und der Empfänger keine Möglichkeit hat, ihre Authentizität zu prüfen.

Besonders gefährlich macht die Angriffe, daß sie nur schwer zu entdecken sind. DNS-Aktivitäten werden aufgrund ihrer Vielzahl normalerweise nie protokolliert – pro Web-Zugriff oder geladenem Bild fällt mindestens ein DNS-Aufruf an, also bei typischen größeren Nameservern viele Tausend pro Sekunde. Die wenigsten Anwender schöpfen bei Problemen Verdacht, da die meisten DNS-Fehler zu einem völligen Ausfall des Dienstes und nicht zu falschen Antworten führen. Außerdem funktioniert zunächst alles scheinbar perfekt; nur die zurückgegebenen Daten sind gefälscht.

Die Auflösung eines Namens erfolgt in mehreren Schritten. Am Anfang steht die Zeichenkette, entweder direkt vom Anwender eingetippt oder aber aus einer Datei gelesen, etwa den WWW-Bookmarks. Das Programm ruft dann die vom Betriebssystem bereitgestellte Bibliotheksfunktion gethost-byname() auf, um die Adresse zu ermitteln. Diese Funktion konstruiert ein DNS-Anfragepaket und schickt es an den "domain"-Port 53 des vordefinierten Nameservers.

Clientprogramme stellen immer "rekursive" Anfragen, das heißt, der Client will die endgültige Antwort wissen und nicht, wie unter Bürokraten üblich, an einen anderen, zuständigen Nameserver verwiesen werden. Untereinander kommunizieren Nameserver hingegen "nichtrekursiv": jeder Server gibt nur Antworten, die er selber kennt. Sonstige Fragen werden mit einem Hinweis auf andere Nameserver abgehandelt, die die Antwort wissen sollten. Die Kommunikation im DNS erfolgt aus Effizienzgründen nicht über TCP, sondern verbindungslos über das paketorientierte UDP (User Datagram Protocol). Da UDP-Pakete unterwegs verlorengehen können, beinhalten die Server und Clients spezielle Logik zum Wiederholen unbeantworteter Anfragen; unerwartete Antwortpakete werden stillschweigend ignoriert. Während TCP-Pakete durch 32-Bit-Sequenznummern recht brauchbar gegen Fälscher geschützt sind, die nicht auf der Leitung mitlesen können, fehlt dem UDP-Protokoll jegliche Sicherung gegen eingestreute Pakete.

Der "reverse lookup spoof" profitiert davon, daß mitunter Rechnernamen zur Berechtigungsprüfung eingesetzt werden. Ein Beispiel sind die ".rhosts"-Dateien unter Unix: Listen mit Rechnernamen, von denen aus eine Anmeldung ohne Paßwortprüfung möglich ist. Sobald eine Verbindung zustande kommt, wird nach dem zur Absenderadresse gehörigen Namen gefragt. Es ist eine sehr schlechte Idee, den erhaltenen Namen einfach in der Liste der berechtigten Systeme zu suchen. Der Angreifer kann in der Regel ja selber entscheiden, was für Namen seine eigenen Adressen tragen. Nirgends wird technisch dafür gesorgt, daß diese Namen überhaupt in seiner Domain liegen müssen. Ein böswilliger Mensch definiert also einfach für die IP-Adresse seines Rechners den Namen eines berechtigten Systems und baut die Verbindung auf.

Der Schutz gegen diesen Angriff ist naheliegend: eine zweite DNS-Anfrage nach den Adressen, die zu den zurückgegebenen Namen gehören – ein "Double Reverse Lookup". Wenn die Absenderadresse der offenen Verbindung hierin nicht enthalten ist, liegt eine Fälschung vor. Die meisten modernen Systeme machen diese Prüfung richtig, doch Ausnahmen bestätigen wie immer die Regel. Und die unten beschriebenen Methoden zur DNS-Fälschung können auch diese zweistufige Prüfung untermmieren.

Trickreicher funktioniert die "Cache Pollution". Hier nutzt der Angreifer aus, daß manche Nameserver erhaltene Daten gutgläubig im Cache verstauen und nachfolgende Anfragen mit den zwischengespeicherten Daten beantworten. Dieses Caching wurde aus Effizienzgründen eingerichtet. Wenn jemand wissen will, wer der "Mail Exchanger" (MX) einer Domain ist, wird er sich oft auch für den Namen und die numerische IP-Adresse interessieren. Um eine unnötige Anfrage einzusparen, wird diese Information gleich als Anhang mitgeschickt.

Findige Leute kamen auf die Idee, einfach ganz andere Daten mitzuschicken, die mit der Anfrage eigentlich gar nichts zu tun haben. Ein Cracker könnte also im Internet einen ganz normalen Web-Server einrichten und seine Adresse publik machen. Uor jedem Zugriff darauf fragt das potentielle Opfer den Nameserver des Angreifers nach der IP-Nummer. Der schickt nun aber im Antwortpaket neben den angeforderten Daten zusätzlich ungefragt eine gefälschte Adresse für einen fremden Rechner, etwa www.company.com [4]. Der Nameserver des Opfers verstaut diese Information dankbar im Cache, und wenn später jemand tatsächlich auf www. company.com zugreift, landet er bei der falschen Adresse.

Die aktuellen Nameserver Versionen bieten jedoch einen Schutz gegen diese Angriffe, indem sie die Glaubwürdigkeit zusätzlicher Daten heuristisch überprüfen: Informationen, die mit der Anfrage nichts zu tun haben und für die der gefragte Nameserver auch nicht zuständig ist, werden ignoriert.

Der zur Zeit gefährlichste Angriff besteht im Erraten der Query-IDs von Anfragen. Diese IDs sind 16-Bit-Zahlen, die der Ahsender frei wählt. Sie dienen der Zuordnung von Antwortpaketen parallel laufender Anfragen. Nebenbei sollen sie vor gefälschten Antworten schützen, doch für diese Aufgabe sind sie nur schlecht geeignet.

Wenn ein böser Mensch weiß, daß ein (Provider-)Nameserver soeben eine Anfrage nach www. company. com gestellt hat, und er die Query-ID dieser Anfrage kennt, kann er versuchen, dem company.com-Nameserver zuvorzukommen und die Anfrage mit gefälschtem Inhalt, aber echter Query-ID zu beantworten. Der Provider-Nameserver wird ihm diese Antwort glauben und sie für zukünftige Anfragen speichern.

Dazu bedarf es einiger Vorbereitungen: Der Cracker benötigt eine eigene Domain, z. B. harmlos.de, dessen Namespace er selbst verwaltet. Seinen Nameserver ersetzt er durch ein spezielles Programm, das die Pakete auf Port 53/UDP entgegennimmt. Der Angreifer ermittelt die echten Nameserver, deren Antworten er fälschen will, über eine einfache nslookup-Anfrage mit dem Anfragetyp "query=NS" (zuständige Nameserver). Er bekommt daraufhin eine Liste, zum Beispiel ns.company.com und ns.secondary.com.

Die Query-ID zu erhalten ist für den Angreifer sehr einfach: Alle zur Zeit üblichen Nameserver numerieren die Anfragen sequentiell durch, sie besitzen einen internen Zähler, den sie nach jeder eigenen Anfrage um eins erhöhen. Der Angreifer fragt den angegriffenen Nameserver zunächst nach einem eigenen Rechner (ichbin.harmlos.de). Der Server stellt nun eigene nichtrekursive Anfragen, um die Frage zu beantworten, und kurz danach bekommt der Missetäter ein entsprechendes Paket an seinen Nameserver geschickt. Er merkt sich die Query-ID dieses Pakets und kennt damit die IDs der nächsten Anfragen seines Opfers.

Anschließend stellt der Angreifer eine rekursive Anfrage nach www.company.com und schickt sofort danach die passenden gefälschten Antworten an den Opfer-Nameserver (ns.provider.de). Er verwendet sicherheitshalber mehrere Pakete, mit schrittweise größer werdenden Query-IDs ab der erhaltenen. Als Absender-IP-Adresse der UDP-Pakete werden die wirklich zuständigen Nameserver eingesetzt. Die darin enthaltene Antwort auf die IP-Anfrage kann der Cracker beliebig wählen.

Inzwischen hat der Opfer-Nameserver begonnen, über nichtrekursive Anfragen nach www.company.com zu suchen. Die Pakete bekommen fortlaufende Query-IDs, und einer der für company.com zuständigen Nameserver wird gefragt. Noch bevor der echte Nameserver antwortet, kommen die gefälschten Antwortpakete an. Das Opfer übernimmt die Antwort mit der passenden Query-ID und (anscheinend) vom richtigen Server, die überzähligen Pakete landen stillschweigend im Datennirvana.

Von da an beantwortet der angegriffene Nameserver alle Anfragen nach www.company.com mit den gefälschten Daten. Insbesondere wird auch die ursprüngliche Anfrage des Angreifers beantwortet – der sieht also sofort, ob das Manöver erfolgreich war. Falls nicht, waren wohl noch echte Daten im Cache. Dann sagt das TTL-Feld (Time To Live) dem Angreifer auf die Sekunde genau, wie lange diese noch gültig sind. Der Bösewicht muß nur abwarten und kann dann einen neuen Versuch unternehmen, der mit höchster Wahrscheinlichkeit erfolgreich ist.

Die Reichweite der Fälschung kann der Angreifer in weiten Grenzen frei wählen: das Ziel kann ein kleiner Nameserver innerhalb einer Firma sein oder aber der Nameserver eines großen Providers, der Zehntausende von Anwendern mit den gefälschten Daten versorgt. Kein Firewall bietet davor Schutz, da die Pakete bis aufs letzte Bit mit der echten Anfrage übereinstimmen und auch über dieselbe Leitung beim Opfer ankommen. Der tatsächliche Besitzer des gefälschten Namens (www.company.com) merkt zudem nichts von dem Angriff. Die DNS-Anfrage verläuft für ihn völlig normal, und den Zugriff auf die gefälschte Adresse sieht er vermutlich überhaupt nicht.

Ein effektiver Schutz vor diesem Angriff wäre, die QueryIDs nicht sequentiell zu verwenden. Eine zufällige Permutation macht die Attacke viel schwieriger. Aber es ist äußerst schwierig, von einem Computersystem taugliche Zufallszahlen zu erhalten. Die üblichen Pseudozufallszahlengeneratoren lassen sich viel zu leicht knacken. Und selbst bei guten Zufallszahlen ist es durchaus denkbar, alle 65 536 möglichen Query-IDs durchzuprobieren. Die Erfolgschancen eines solchen Brute-Force-Angriffs hängen von der verfügbaren Zeit für die Antwort ab. Dabei hilft natürlich, wenn die echten Nameserver nicht antworten können, weil sie mit einer Unmenge sinnloser Anfragen oder anderen Denial-of-Service-Angriffen beschäftigt sind.

Wenn man von circa 100 Byte pro DNS-Query ausgeht, umfaßt ein Brute-Force-Angriff mit 65 536 Paketen insgesamt etwa 6,5 MByte. Bei einer 1-MBit-Internetleitung sind etwa 60 Sekunden zum Übertragen der Daten notwendig, bei einer ISDN-Leitung etwa 20 Minuten. Für den Angreifer ist es jedoch nicht notwendig, die komplette Zeit abzuwarten. Wenn er den Angriff jeden Tag wiederholt, hat er gute Chancen, irgendwann erfolgreich zu sein – letztlich läßt sich das Verfahren leicht automatisieren.

Leichtes Spiel hat der Angreifer, wenn er die Leitung des Opfers abhören kann. Dann bekommt er die Query-IDs im Klartext geliefert und kann sofort die gefälschte Antwort schicken. An dieser Stelle hilft eine Absicherung des DNS ohnehin wenig, da ein Abhören der Leitung auch viele andere Angriffe, wie das Ausspähen von Paßworten und das Übernehmen von Verbindungen (Session Hijacking) ermöglicht (siehe Seite 142).

Im Internet werden seit längerer Zeit Sicherungsmaßnahmen diskutiert. Die verbreitetste Nameserver-Implementation, die BIND-Distribution (Berkeley Internet Name Domain), verwendet aber auch in der neuesten Version 8.1.1 immer noch sequentielle Query-IDs, wenn auch mit einen zufälligen Anfangswert. Andere Versionen, wie sie etwa Microsoft bei Windows NT ab 4.0 mitliefert, sind in dieser Hinsicht auch nicht besser. Zudem werden bei BIND neu bekanntwerdende Lücken meist schneller gestopft als bei den Nachbauten.

Die Kompatibilität zu Internet-Firewalls und bisherigen Versionen schränkt Verbesserungsmöglichkeiten deutlich ein. Zum Beispiel würde sich der Suchraum für blinde Attacken stark vergrößern, wenn der Nameserver eigene Anfragen von zufälligen Source-Ports aus abschicken würde, anstatt immer Port 53 zu verwenden. Doch viele Firewalls würden solche Pakete blockieren. Bei einer Erweiterung der Query-IDs auf 32 Bit müßten hingegen weltweit alle Clients und Server getauscht werden.

Auch die Reaktion auf verdächtige Paketeingänge ist weiterhin mangelhaft. Eine Protokollierung wäre zumindest dann wünschenswert, wenn Antwortpakete mit unerwarteten Query-IDs ankommen. Es wurde auch schon vorgeschlagen, bei einem vermuteten Angriff weitere Maßnahmen zu treffen, etwa die Anfrage über TCP statt über UDP zu wiederholen oder einen anderen Nameserver zu fragen. Implementiert wurden solche Vorschläge jedoch bisher nicht.

Der Query-ID-Angriff ist nur mit "IP Spoofing" durchführbar, dem Versenden von IP-Paketen mit gefälschten Absenderadressen. Dagegen existiert zur Zeit kein allgemein wirksamer Schutz. Das Verschicken "gespoofter" Pakete ist sehr einfach, da die Router im Internet normalerweise den Absender ignorieren und die Weiterleitung alleine anhand der Zieladresse vornehmen. Eine Analogie ist die

Briefpost: die Absenderadresse wird von der Post nicht geprüft, nur der endgültige Empfänger ist daran interessiert. Und dann ist es zu spät, den Weg festzustellen. Im Gegensatz zur Briefpost gibt es im Internet noch nicht einmal einen Poststempel, der zumindest den ungefähren Ort des Absenders festlegen könnte.

Ein Provider kann gefälschte Absenderadressen nur verhindern, indem er bei jedem Einwahlpunkt prüft, ob seine Kunden auch tatsächlich ihnen zugewiesene Adressen verwenden. Das ist im Prinzip mit einer einfachen Paketfilter-Regel im Router möglich. Dies schützt aber die Kunden nicht vor dem Empfang gefälschter Pakete, da der Provider die Absenderdaten eingehender Pakete nicht sinnvoll prüfen kann. Solange es auch nur einen einzigen Provider gibt, der keine Maßnahmen gegen Spoofing einsetzt, können Cracker von dort aus ihre Angriffe starten.

Die Kryptographie verspricht auch Lösungen für diese Probleme. Statt die Adressen zu prüfen, können sich Rechner und Benutzer untereinander durch kryptographische Schlüssel authentisieren. Für Electronic Mail existieren bereits mehrere Verfahren, allen voran PGP (Pretty Good Privacy). Als Ersatz für Telnet, rlogin und FTP bietet sich die Secure Shell (SSH) an, bei der Server und Anwender eigene, eindeutige Schlüssel besitzen, die sich automatisch prüfen lassen. Das Umlenken einer Verbindung über einen gefälschten DNS-Eintrag ist also sinnlos, da der Client sofort merkt, wenn der angebliche Server sich nicht entsprechend authentisiert und damit nicht echt sein kann.

Eine Erweiterung des DNS-Protokolls um digitale Unterschriften ist bereits in Arbeit. Jeder Server bekommt einen kryptographischen Schlüssel, und der Client kann damit die Echtheit der erhaltenen Antworten prüfen. Es ist jedoch unklar, wann diese neue Version sich allgemein durchsetzen wird. Zunächst will man damit die Kommunikation der Nameserver untereinander, stärker sichern.

Verschlüsselte Kommunikation auf IP-Ebene über IPSEC (offener Standard für verschlüsselte IP-Kommunikation) oder SKIP (ein von SUN Microsystems entworfenes Protokoll) bietet nur dann Schutz, wenn ein sinnvolles weltweites Protokoll zum vertrauenswürdigen Schlüsselaustausch existiert. Verschlüsselung ohne Authentisierung der Kommunikationspartner hilft hingegen wenig. Und zur Zeit ist es nicht realistisch, daß ein Nameserver die Host-Schlüssel aller weltweiten Nameserver auf Echtheit prüfen könnte. Die Performance wäre ebenfalls ein Problem, da die Nameserver der großen Provider bereits jetzt an ihren Leistungsgrenzen arbeiten.

Für den Endanwender bleiben vorerst nur wenig Möglichkeiten: Ein gesundes Mißtrauen ist nie falsch – wenn nach der Verbindung mit einem Internetserver unerwartete Daten präsentiert werden, könnte etwas faul sein. Krypto-basierte Clients und Protokolle können bei sorgsamem Einsatz hohe Sicherheit gewährleisten – essentiell ist hierbei die sorgfältige Schlüsselverwaltung. Falls SSL-Verbindungen im WWW Schutz bieten sollen, kontrollieren Sie möglichst die Fingerprints der Server-Schlüssel.

Zur Zeit ist die einfachste Hilfe auch die effektivste: für sicherheitsrelevante Dienste die numerische IP-Adresse verwenden. Lassen Sie sich diese schriftlich oder am Telefon durchgeben und verwenden Sie beispielsweise "http://194.122. 76.131" statt "http://www.heise.de". Von den Providern muß man verlangen, daß sie ihre Nameserver absichern und Maßnahmen gegen IP Spoofing treffen, um auch in Zukunft ein unbeschwertes Arbeiten im Internet zu ermöglichen.