Falsch verbunden

Gefahr durch DNS-Spoofing

Wissen | Know-how

Der Domain Name Service, kurz DNS, ist die (de)zentrale Auskunft des Internet. Wer ihre Informationen fälschen kann, lenkt Datenströme in beliebige Bahnen: dem Mißbrauch stehen Tür und Tor offen.

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, daß 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 gethostbyname() 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 unterminieren.

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.


Der Angreifer stellt eine rekursive Anfrage nach seinem eigenen Rechner, um die aktuelle Query-ID zu ermitteln.


Der Angreifer fragt nach www.company.com und schickt sofort gefälschte Antworten auf den Weg.


Die Anfrage wird an den zuständigen Nameserver weitergereicht und sofort durch die gefälschten Pakete beantwortet.


Die echte Antwort kommt zu spät und wird verworfen. Der Provider-Nameserver antwortet mit den gefälschten Informationen.


Ein Anwender will auf 'www.company.com' zugreifen und wird aufgrund der gefälschten Daten umgelenkt.

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. Vor 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 Absender 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 Query-IDs 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. (nl)

Secure Networks Inc. Security Advisory

[2] Articon Newsletter DNS-Risiken (http://www.articon.de/security/dns.html)

[3] Paul Albitz, Cricket Liu, DNS and Bind in a Nutshell, O'Reilly, ISBN 1-56592-010-4

[4] Welcome to www.company.com

[#anfang Seitenanfang]


Kaum eine Anwendung schreit so sehr nach Sicherheit wie das Homebanking. Fast alle großen deutschen Banken bieten inzwischen Transaktionen per Internet an. Die meisten benutzen Java-Krypto-Applets, die über einen SSL-Kanal (Secure Socket Layer) bezogen werden. Was uns die Werbung nicht verrät: bis diese Sicherheit zieht, ist es schon zu spät!

Wenn es einem Verbrecher gelingt, seinen Rechner als SSL-Banking-Server auszugeben, kann er dem Browser des nichtsahnenden Kunden ein selbstgebasteltes Java-Applet übermitteln, das optisch von dem echten nicht zu unterscheiden ist. Der Kunde würde wie gewohnt seine PINs und TANs eingeben und keinen Unterschied bemerken. Daß diese Übertragung nur vergleichsweise schwach geschützt über das Netz geht, ist praktisch bedeutungslos, da die Daten bereits unmittelbar an kriminelle Hände adressiert sind.

Da solche Angriffe völlig automatisierbar sind, ist leicht vorstellbar, daß jemand nach längerer Vorbereitungphase (PIN/TAN sammeln) innerhalb weniger Tage viele Tausend falsche Überweisungen tätigt. Die meisten davon könnten reine Ablenkung sein, um die wahren Zielkonten zu verschleiern, bis der elektronische Bankräuber sich mit dem Geld von einem Bruchteil der benutzten Konten aus dem Staub macht. Die Prüfung all dieser Vorgänge durch die Banken dauerte vermutlich so lange, daß der Übeltäter längst über alle Berge ist, bis man ihm auf die Schliche kommt.

Noch schöner ist das Gedankenspiel mit Wertpapieren. Bringt der Verbrecher Tausende Depots dazu, bestimmte Aktien zu verkaufen oder zu kaufen, kann er bestimmt erstklassige Geschäfte machen. Das übliche Tageslimit von Online-Wertpapiertransaktionen liegt bei 100 000 DM pro Depot. Da es, im Gegensatz zu Überweisungen, keine 1:1-Verbindung gibt, dürften solche Vorgänge sehr schwer nachzuvollziehen sein. Und Wertpapiergeschäfte rückgängig zu machen ist wahrscheinlich ziemlich teuer bis unmöglich.

Um unauffällig eine SSL-Verbindung zum falschen Banking-Server zu öffnen, müssen zwei Voraussetzungen erfüllt sein: Der Client-Rechner muß nach Eingabe der URL 'https://banking.meinebank.de' die falsche numerische Internet-Adresse erhalten - DNS-Spoofing, kein Problem. Darüber hinaus muß der Browser des Kunden das SSL-Zertifikat, das ihm der falsche 'Secure' Webserver zeigt, als echt und gültig akzeptieren. Dazu ist das Zertifikat einer 'vertrauenswürdigen' Stelle (Certification Authority, CA) erforderlich.

Es ist mit frei im Internet verfügbaren Tools völlig trivial, einen SSL-CA-Zertifizierungsschlüssel zu erstellen, der dem Schlüssel einer echten Certification Authority extrem ähnlich sieht. Damit unterschreibt man das hausgemachte SSL-Banking-Zertifikat. Bleibt lediglich, dem Browser des Banking-Kunden den gefälschten CA-Schlüssel unterzuschieben. Bei Netscape Browsern gelten (bis zum Widerruf durch den Benutzer) alle Schlüssel als vertrauenswürdig, die in der Datei cert7.db stehen - der Internet Explorer benutzt die Windows-95-Registry 'HKEY_LOCAL_ MACHINE\System\CurrentControlSet\control\SecurityProviders\SCHANNEL\CertificationAuthorities\'.

Diese Einträge sind in keiner Weise vor Veränderungen durch Browser-Sicherheitslücken, ActiveX, Viren, Makros, unberechtigten oder schlecht informierten Kunden geschützt. Und ein solcher Eingriff muß nur ein einziges Mal stattfinden, ohne zeitlichen Zusammenhang zu den Banking-Transaktionen.

Es gäbe allerdings einfache Möglichkeiten, die Anwender gegen solche Angriffe zu schützen: Am wichtigsten wäre die Umstellung sämtlicher SSL-Zertifikate von DNS-Namen auf IP-Adressen. Damit wird dem Angreifer extrem erschwert, den SSL-Zugriff umzuleiten. Da im SSL-Zertifikat die URL (etwa 'https://banking.meinebank.de') steht, für die es gilt, kann man bislang keine numerische IP-Adresse eingeben. Der Browser beschwert sich sonst, daß die URL nicht zum Zertifikat paßt.

Weiterhin benötigten die Homebanking-Kunden eine kurze, gedruckte Checkliste, in der die Seriennummer und ein kryptographischer Fingerabdruck des SSL-Zertifikats stehen. Diese Informationen müßten über einen sicheren Kanal, beispielsweise per Post, ankommen. Nach aufmerksamer Kontrolle der Schlüsseldaten ließen sich dann Angriffe durch gefälschte SSL-Zertifikate wirksam verhindern.

Letztlich müßten die Browser-Hersteller durch öffentlichen Druck dazu gebracht werden, ihre Software und die mitgelieferten Zertifikate so zu schützen, daß Manipulationen an den Programmdateien und ein 'Abhören' von Tastatureingaben unmöglich sind - gleiches gilt für proprietäre Banking-Applikationen. Das sollte man von jeder sicherheitsrelevanten Software erwarten können - technisch ist es schon lange möglich. Hardwareunterstützte Lösungen böten weitere Möglichkeiten, die Sicherheit zu erhöhen: möglicherweise ESDs MeChip oder der Einsatz von SmartCard-Lesern. Einige wenige Änderungen könnten elektronischen Handel und Banking heute schon deutlich sicherer machen; eigentlich sollte jeder sehen, daß solcher Mehraufwand eine Investition in die Zukunft wäre. (nl)
Viktor Mraz

Anzeige