Seite 2: Wie können andere helfen?

Inhaltsverzeichnis

Wie können andere helfen?

Wir benötigen immer noch Unterstützung aus der Community. Sie können uns helfen, indem Sie folgende Informationen bereit stellen:

1. Wir könnten noch Reports über aktives Cache Poisoning gebrauchen. Solche Berichte sollten die verwendete Version der DNS-Server-Software enthalten und ob Forwarder eingerichtet sind. Eine gute Beschreibung wäre: "Windows 2000 Server (mit Registry-Schlüssel gegen Cache Pollution), der Anfragen an einen BIND 8.4.6 Server in einer DMZ weiterleitet, der seinerseits keine Weiterleitung durchführt." Versuchen Sie Paket-Mitschnitte des Verkehrs auf UDP-Port 53 mit zu liefern, die erstellt wurden, nachdem der Cache vergiftet wurde. Außerdem sollten Sie versuchen, uns eine Kopie des aktuellen DNS Cache zu schicken.
   Anscheinend gibt es keine Möglichkeit, den Cache eines laufenden DNS Servers auf Windows-Systemen zu exportieren. Das ginge nur über die Log-Dateien im Debug-Modus, was nicht wirklich praktikabel ist. Manche haben uns deshalb Screenshots des DNS Managers/Console geschickt, was wohl die beste Alternative ist (zumindest bis uns jemand eine bessere verrät).
   Bei BIND kann man den aktuellen DNS-Cache mit dem Tool "ndc" (BIND 8) oder "rndc" (BIND 9) auf dem Server als root exportieren. Der Befehl "dumpdb" schreibt den aktuellen Cache-Inhalt in das Verzeichnis, das die "directory"-Option in named.conf angibt; typischerweise ist es "/var/cache/bind".
2. Setzen Sie die Snort-Regeln am Ende dieses Textes ein und senden Sie uns dadurch erzeugte Alarmmeldungen einschließlich der vollen Paket-Traces.
3. Wenn Ihr Sniffer groß genug ist, können Sie den gesamten Verkehr auf Port 53 von und zu Ihrer Site protokollieren. Wenn wir weitere bösartige DNS-Server entdecken, könnte es passieren, dass wir DNS-Verkehr von oder zu einem bestimmten DNS-Server benötigen. Mit Hilfe von solchen Aufzeichnungen könnte man unter Umständen bestimmen, wann ein Angriff begann und welche Poisoning-Methode er einsetzte. Vergessen Sie aber dabei nicht, die Dump-Dateien zu rotieren, damit sie nicht den gesamten Festplattenplatz des Sniffers auffressen.
   

Was muss ich als Betroffener tun?

1. Sie müssen zunächst absolut sicherstellen, dass Sie nicht mit Spyware infiziert sind. Viele Spy/Adware-Programme verändern die DNS-Einstellungen oder die lokale hosts-datei auf Windows-Rechnern. Sie sollten also zunächst Ihr bevorzugtes Spyware-Suchprogramm laufen lassen.
2. Versuchen Sie, die IP-Adresse des bösartigen DNS-Servers herauszufinden und überprüfen Sie auf unserer Webseite, ob der schon registriert wurde. Wenn nicht, senden Sie uns eine kurze Nachricht über die folgende URL: http://isc.sans.org/contact.php
3. Es ist sinnvoll, die IP-Adresse des bösartigen DNS-Servers auf den äußeren Routern/Firewalls zu blockieren, um sicherzustellen, dass Ihr Cache nicht erneut vergiftet wird.
4. In einem großen Firmennetz kann es erforderlich sein, die Caches aller internen DNS-Server zu leeren, beginnend mit denen, die den direktesten Außenkontakt haben.
5. Unter Windows leert das Anhalten und Starten des DNS-Service den Cache. Alternativ erledigt das auch das Tool dnscmd.exe aus dem Resource Kit:
   dnscmd.exe /ClearCache
6. Auf Windows 2000, XP und 2003 Clients können Sie den Cache mit "ipconfig /flushdns" leeren. (Beachten Sie, dass das einen vergifteten DNS-Caching-Server im Upstream nicht säubert.)
7. Bei BIND 9 können Sie den Cache mit dem Befehl "flush" des Tools "rdnc" leeren. Bei BIND 8 müssen Sie wohl den Server anhalten und neu starten.

Welche Software ist angreifbar?

Folgende Produkte wurden als verwundbar bestätigt:

1. DNS-Server von Windows NT4 und 2000
   Die Default-Konfiguration der DNS-Server von Windows NT 4 und 2000 ist durch DNS Cache Poisoning VERWUNDBAR. Per default schützt der DNS-Server NICHT gegen DNS Cache Poisoning. Wenn Sie auf Windows NT 4 oder Windows 2000 (2003 ist sicher konfiguriert) einen Nameserver betreiben, der Namensauflösung macht, raten wir DRINGEND, den Anweisungen in http://support.microsoft.com/default.aspx?scid=kb;en-us;241352
   zu folgen, um sich zu schützen.
2. Symantecs Gateway-Produkte.
   Es gab einen bestätigten Fehler in diversen Symantec-Produkten, der DNS Cache Poisoning ermöglichte. Am 15. März 2005 wurde ein Patch für die folgenden Produkte herausgegeben:
   Symantec Gateway Security 5400 Series, v2.x
Symantec Gateway Security 5300 Series, v1.0
Symantec Enterprise Firewall, v7.0.x (Windows and Solaris)
Symantec Enterprise Firewall v8.0 (Windows and Solaris)
Symantec VelociRaptor, Model 1100/1200/1300 v1.5
   Weitere Informationen finden Sie unter:http://securityresponse.symantec.com/avcenter/
   security/Content/2005.03.15.htmlhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0817
   Am 21. Juni 2004 wurde ein ähnlicher Fehler in denselben Produkten beseitigt:http://securityresponse.symantec.com/avcenter/
   security/Content/2004.06.21.html
   

Uns liegen Berichte vor, nach denen Windows 2003 und NT4/2000 trotz korrekter Registry-Schüssel immer noch anfällig sind. Wir arbeiten derzeit mit Microsoft zusammen, um herauszufinden, ob das ein Fehler oder ein Architekturproblem in deren DNS-Software ist.

Mögliche Theorie #1: Windows-DNS-Server die Anfragen an BIND-Nameserver weiterreichen ignorieren die zusätzlichen Authority Records in den DNS-Antworten nicht. Eventuell werden in diesem Szenario die Registry-Schlüssel "secure cache against poisoning" ignoriert.

Mögliche Theorie #2: Der bösartige DNS-Server antwortet derzeit mit .COM-Einträgen mit einer TTL von 99999 Sekunden; das entspricht 1 Tag, 3 Stunden, 46 Minuten, 39 Sekunden. Möglicherweise gibt es einen Fehler, der bewirkt, dass der Server den .COM-Eintrag übernimmt, weil er eine größere TTL hat, als der bereits vorhandene Eintrag im Cache?

Des weiteren haben wir verlässliche Berichte erhalten, dass ganze Sites vergiftet wurden, obwohl sie ausschließlich BIND-Server einsetzen. In der Standardkonfiguration sind die diversen Unix-Server für solche Angriffe nicht anfällig. Man könnte sie jedoch vielleicht durch schlechte Einstellungen verwundbar machen.