Unterthema: iX-TRACT
Unterthema: Blind Spoofing
Unterthema: DNS_SPOOFING
Wenn sich in der Wüste plötzlich ein Riesenrad dreht, kennt jeder den Grund - eine Fata Morgana. Wenn sich auf der Homepage von Mercedes nackte Frauen tummeln, schrillen bei den Verantwortlichen die Alarmglocken. Ähnlich einer Fata Morgana erscheinen immer häufiger falsche Bilder auf Web-Seiten und verschwinden sofort wieder (nach einem `Reload'). Das Phänomen ist bekannt, doch die Ursachen sind noch immer nicht hundertprozentig geklärt. Es gibt mehrere Möglichkeiten, wie die Irrläufer auf die Seiten kommen. Dabei muß es sich nicht immer um den Einbruch eines Hackers in den WWW-Server handeln.
Mitten in die Vorstellung der V-Klasse hat sich ein fremdes Bild eingeschlichen (Abb. 1).
Am Nachmittag des 3. Juni erschienen im Bereich des XLink-Proxy und in der Universität Karlsruhe beim Abrufen der Seiten www.mercedes.de plötzlich statt des Sterns zwei spielende, nackte Frauen. Etwa 10 Minuten später - nach wiederholtem Neuladen der Seite - verschwand das falsche Bild wieder. Beim Web-Team von Mercedes begann eine akribische Analyse der Logfiles, nichts deutete auf einen Einbruch eines Hackers hin. Das Sternlogo lag unberührt dort, wo es hingehört.
Immer wieder wird von ähnlichen Beobachtungen im Internet berichtet. Das betrifft nicht nur die spektakulären Pornobilder. So entdeckte ein Nutzer des Rechenzentrums der Uni Stuttgart falsche Buttons auf der Homepage von Nestlé. Die Buttonleiste von AltaVista war jüngst genauso von Irrläufern durchsetzt wie die Homepage von Microsoft. Die Suche nach dem Ursprung der `Fata-Morgana-Bilder' führt zu den zahlreichen Proxies im Internet: zu Rechnern, die für andere Rechner dezentral Informationen vorhalten. Da die Browser, auf denen die falschen Bilder beobachtet wurden - soweit bekannt - ihre Informationen aus dem Cache eines Proxy bekamen, läßt sich die Spur anhand der Logfile-Daten zurückverfolgen. Das Bild mit den zwei Frauen auf der Mercedes-Seite etwa kam zunächst aus dem Proxy von XLink, der diese aus dem bundesweit verteilten Harvest-Proxy-Verband (siehe [1]) über die Universität Karlsruhe bezog.
Je mehr Cache-Rechner miteinander zu einem Verband zusammengeschlossen werden, desto größer wird die Gefahr, daß ein fehlerhafter Proxy seine falschen Daten an einen anderen weiterreicht. `Wir raten Netzwerkbetreibern, ihren Proxy nur mit solchen zusammenzuschließen, denen sie vertrauen können und über deren verwendete Software sie genau Bescheid wissen', empfiehlt Stefan Kelm vom DFN-CERT.
Warum aber in eigens zum Thema `Fata-Morgana-Bilder' eingerichteten Diskussionsgruppen im Usenet vor allem von pornographischen Bildern auf Web-Seiten großer Unternehmen berichtet wird, kann zwei Gründe haben. Einerseits die selektive Wahrnehmung der Benutzer: Wem fällt schon auf, wenn eine Markierung auf einer Web-Seite grün statt blau ist - auch solche kleinen Fehler gibt es. Andererseits liegen in den Proxy-Caches viele erotische und pornographische Bilder, da diese sehr häufig von den Benutzern abgefragt werden. So ist die Chance verhältnismäßig groß, daß der Proxy, wenn er durcheinandergerät, ein solches Bild aus seinem Cache liefert.
DNS Spoofing richtet sich gegen Nameserver, also die Rechner, die den Proxies mitteilen, wo unter einem bestimmten Namen gesuchte Informationen im Internet zu finden sind. Dabei wird den Nameservern (NS) zusammen mit richtigen Informationen als `additional information' eine falsche IP-Adresse für einen Web-Server untergeschoben. Der NS speichert die. Fordert etwa ein Proxy Bilder von www.microsoft.com an und fragt, woher er sie bekommen kann, liefert der manipulierte NS die falsche Adresse. Nun muß ein Hacker nur als falsche Adresse die seines eigenen Rechners angeben, und schon kann er dem Proxy statt des Win95-Logos ein Apple-Logo unterschieben.
Kaum ist das geschehen, sorgt der Hacker dafür, daß der gefälschte Eintrag im NS wieder verschwindet. Im Nameserver-Cache tragen alle Einträge ein Expiry Date (Verfallsdatum), danach werden die Daten neu überprüft. Wann diese Frist abläuft, kann dem NS zusammen mit den (gefälschten) Angaben über die IP-Adresse mitgegeben werden. Ein Hacker nutzt diese sinnvolle Option und gibt ein Expiry Date an, das nur wenige Minuten später liegt. So verschwindet der Eintrag wieder. Ein andere Möglichkeit ist, ein zweites Mal eine Zusatzinformation mitzugeben, dieses Mal mit der richtigen IP-Adresse.
Jeder kann einen NS manipulieren. Werkzeuge dazu sind frei aus dem Internet erhältlich. Auf einigen Seiten liegen sogar detaillierte Anleitungen für Spoofing-Angriffe. Bei einem Angriff muß der Hacker zunächst beim Nameserver, den er manipulieren möchte, eine IP-Adresse aus der eigenen Domain abfragen. Der attackierte Nameserver versucht, diese Adresse beim zuständigen Nameserver zu erfragen. Diese Anfrage beantwortet der Angreifer dann selbst und gibt dabei als `additional Information' eine falsche IP-Namenszuordnung mit.
Es gibt inzwischen viele Abarten des DNS Spoofing. Die Auswirkungen eines solchen Hacks haben vor wenigen Wochen zahlreiche Internet-Benutzer in ganz Europa zu spüren bekommen, als für kurze Zeit nach einem `Angriff' die Web-Seiten der Firma Microsoft fehlgeleitet wurden. So berichtete etwa ein Mitarbeiter der Firma Siemens aus den Niederlanden, daß bei ihm am 6. Juni auf die Anfrage `www.microsoft.com' die Homepage von www.grid9.net erschien.
Mit DNS-Spoofing ist es bis heute möglich, Teile des Internet durcheinanderzubringen. Auch wenn die Entwickler von Nameserver-Software heftig an Korrekturen ihrer Programme arbeiten, sind zur Zeit noch viele für solche Angriffe anfällig. Ob ein NS angegriffen werden kann, zeigt ein Besuch auf der Web-Seite von `Els Apostols' (siehe Kasten `DNS Spoofing' und Abb. 2). Sun bietet für den dort vorgeführten Bug inzwischen einen Patch an, und für die Nameserver-Software bind 4.9.x sowie 8.x existieren entsprechende Updates im Netz. Es gibt jedoch keine vollständige DNS-Sicherheit; die soll später der sogenannte `secure DNS' bieten.
DNS-Verwundbarkeitstest: das Ergebnis läßt schon beim Domain-Namen ein Stirnrunzeln aufkommen (Abb. 2).
Das DFN-CERT weist in seiner Mailingliste win-sec-ssc@cert.dfn.de auf derlei hin. Über www.cert.dfn.de/infoserv/dml.html kann man sich in eine Liste eintragen. Weitere Informationen zum DNS Spoofing enthält der genannte Kasten.
Wenn der Nameserver Opfer eines erfolgreichen Spoofing-Angriffs wird, bleibt nur noch das Zurückverfolgen, um den Hacker wenigstens nachträglich dingfest zu machen. Dazu rät das CERT, zuerst einmal den Cache von alten Einträgen zu säubern (kill -INT <pid des named>). Wenn ein neuer gefälschter Eintrag kommt, ist es möglich, in der Datei /var/tmp/named_dump.db (Default; Pfad ist aber wählbar) nachzusehen, welche Daten es sind und woher er diese bekommen hat. Natürlich stehen auch dort wieder nur (fälschbare) IP-Adressen, allerdings ist es (zum Beispiel mit einem Blind Spoofing, siehe gleichnamigen Kasten) nicht einfach, diese zu fälschen. Da immer mehr Unternehmen auch ihre Web-Server mit Firewalls schützen, ist es für den Hacker viel einfacher, vor dem Firewall im offenen Internet die zentralen DNS-Caches anzugreifen, sofern diese nicht auch entsprechend geschützt sind. Das Ergebnis für den Benutzer am anderen Ende des Internet ist aber dasselbe. Durch die Proxy-Verbände wird das Problem immer bedeutender. Denn es reicht nun aus, nur einem geschickt ausgewähltem Proxy eine falsche Information unterzuschieben, dieser sorgt für die Verbreitung.
Wer bei einer Autofirma anruft und den Beate-Uhse-Versand am Telefon hat, der vermutet sofort, daß er sich verwählt hat und ruft noch einmal an. Im WWW ist es aber für viele nicht so selbstverständlich, daß `unterwegs' Irrtümer und Fehler passieren können. Auch bei Informationen aus dem Internet ist daher ein gesundes Mißtrauen und damit ein Neuladen einer `verdächtig' erscheinenden Seite oder aber ein kurzzeitiges Abschalten des Proxy ratsam. Auch im Internet gilt: Vertrauen ist gut, Kontrolle besser. (hb)
ist Webmaster des dpunkt-Verlags und Web-Beauftragter der Fakultät fuer Chemie, Universität Heidelberg.
Sich auf diese Weise eine Tarnkappe aufzuziehen, ist aber nicht einfach. Denn die meisten Nameserver geben ihrer Anfrage nach einem neuen Namen eine Query-ID mit, die der Angreifer bei der Antwort benutzen muß.
Hat der Hacker nun eine falsche IP-Adresse angegeben, wird diese ID nicht zu seinem Rechner gesendet. In diesem Fall benötigt er entweder genaue Informationen über den NS, oder er muß das Netzwerk, über das die ID läuft, abhören und die ID abfangen. Allerdings ist es mit einfachem IP-Spoofing nur möglich, Daten abzufangen, die auch physikalisch durch die eigene Leitung fließen.
Frei aus dem Internet Informationen abzufangen ist zwar schwierig, aber etwa durch Manipulation von Routern möglich. Wenn es einem Hacker gelingt, die Routing-Tabelle eines zentralen Internet-Routers zu verändern, kann er die Anfrage an sich selbst weiterleiten.
Eine andere Möglichkeit ist, durch geschicktes Abschätzen die ID `blind' zu erraten. `Blind Spoofing' heißt diese Art des DNS-Angriffs, bei der es nicht nötig ist, an einem Rechner zu sitzen, an dem die Daten physikalisch (per Kabel) vorbeikommen. Der Hacker generiert einfach und ungefragt selbst die Antwort.
Zwei Schwierigkeiten bestehen hier für den Hacker: zum einen muß er die genannte Antwort innerhalb eines limitierten Zeit`fensters' liefern, sonst nimmt der Nameserver sie nicht mehr an. Zum anderen gilt es, die unbekannte ID herauszubekommen. Im Vorfeld des eigentlichen Angriffs veranlaßt der Hacker durch eine geschickte Anfrage an den anvisierten Nameserver, eine IP-Adresse vom eigenen Rechner (mit Nameserver) zu holen. Dadurch erhält der Hacker eine aktuelle ID des anzugreifenden NS. Auf der Basis dieses ID versucht er nun, die der nächsten abzuschätzen.
| Dokumentation von bind | ftp://ftp.cert.dfn.de/pub/tools/net/bnind/src/8.1/bind-doc.tar.gz |
| Requests for Comment (RFCs) | http://www.dns.net/dnsrd/docs/rfc.html |
| Cheswicks und Bellovins Artikel von der Usenix Security Conference 1996 | http://www.usenix.org/publications/libary/proceedings/sec96/cheswick.html |
| Test der DNS-Verwundbarkeit | http://apostols.org/toolz/dnshack.cgi |