zurück zum Artikel

Vergiftetes DNS

Kyle Haugsness

Das Internet Storm Center analysiert drei Angriffe auf DNS-Server im MĂ€rz 2005. Tausende von Anwendern -- darunter viele in Firmen -- wurden dabei auf Web-Seiten umgeleitet, die versuchten, Spyware zu installieren.

Dies ist eine Analyse von Kyle Haugsness und dem Internet Storm Center [1]. heise Security veröffentlicht die deutsche Übersetzung mit freundlicher Genehmigung des ISC. Das Original finden Sie hier [2].

Anmerkung: Am 3. April ist dieser Vorgang noch nicht vollstĂ€ndig geklĂ€rt. Wir werden diesen Text aktualisieren, sobald mehr Details verfĂŒgbar sind.

Am 3. MĂ€rz 2005 gegen 22:30 GMT gingen beim SANS Internet Storm Center Berichte von mehreren Sites ein, dass Anwender durch Vergiften des DNS-Caches auf Web-Seiten umgeleitet wurden, die Schadsoftware enthalten. Als der Diensthabende fĂŒr den 4. MĂ€rz habe ich diese VorgĂ€nge im Lauf der nĂ€chsten Stunden und Tage untersucht. Dieser Report soll einige meiner Ergebnisse fĂŒr die Internet-Gemeinde dokumentieren.

Die ursprĂŒnglichen Berichte enthielten starke Hinweise auf DNS Cache Poisoning, allerdings schien auch irgendwie Spyware/Adware/Malware involviert zu sein. Nach einer vollstĂ€ndigten Analyse stellte sich heraus, dass eine ganze Reihe von Aspekten bei dem Angriff eine Rolle spielten: dynamisches DNS, DNS Cache Poisoning, ein Fehler in Symantecs Firewall/Gateway-Produkten, Standardeinstellungen in Windows NT/2000, Spy/Adware und mindestens fĂŒnf kompromittierte Unix Web-Server. Hinweisen zufolge könnte der Angriff bereits am 22. Februar begonnen haben, betraf da aber zunĂ€chst nur wenige Anwender.

Am 24. MĂ€rz erhielten wir Berichte ĂŒber einen anderen DNS-Poisoning-Angriff, der sich allerdings nur auf wenige Leute auswirkte. Er wird im weiteren als der "zweite Angriff" referenziert.

Nachdem wir die Situation nun ĂŒber mehrere Wochen beoabachtet haben, wird klar, dass der oder die Angreifer ihre Methoden und Werkzeuge weiter Ă€ndern, um Web-Seiten-Abrufe auf andere kompromittierte Server umzuleiten. Daraus wurde der "dritte Angriff", der am 1. April immer noch andauert.

An dieser Stelle ist ein Dank an all diejenigen angebracht, die uns Berichte eingeschickt, bei der Analyse geholfen und Log-Dateien bereit gestellt haben. Das Internet Storm Center ist eine Initiative von Freiwilligen und je besser die Informationen sind, die wir aus der Community erhalten, desto bessere Analysen können wir erstellen und an die Community zurĂŒckgeben.

  1. Wie können andere helfen?
  2. Was muss ich als Betroffener tun?
  3. Welche Software ist angreifbar?
  4. Ich bin ein Modem/ISDN/DSL-Nutzer -- bin ich angreifbar?
  5. Wo kann ich testen, ob meine Site angreifbar ist?
  6. Was ist DNS Cache Poisoning ĂŒberhaupt?
  7. Warum machen die das?
  8. Wurden DNS Cache Poisoning Angriffe nicht schon vor 8 Jahren unmöglich gemacht?
  9. Was war der Auslöser der Angriffe?
  10. Wie haben diese Angriffe genau funktioniert?
  11. Welche Domain-Namen wurden umgeleitet?
  12. Welche Sites waren betroffen?
  13. Welche SchÀdlinge wurden auf meinem System installiert, wenn ich die bösartigen Server besucht habe?
  14. Gibt es Pakete?
  15. Wie siehts mit Snort-Regeln aus?

Wie können andere helfen?

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 [3]
    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.html [4]    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0817 [5]
    Am 21. Juni 2004 wurde ein Àhnlicher Fehler in denselben Produkten beseitigt:http://securityresponse.symantec.com/avcenter/
    security/Content/2004.06.21.html [6]

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.

Bin ich angreifbar?

Ich bin ein Modem/ISDN/DSL-Nutzer -- bin ich angreifbar?

Ziemlich sicher nicht. Die großen Internet Provider setzen DNS-Server unter Unix ein, die derzeit nicht anfĂ€llig sind. Es gibt jedoch einige Provider, die DNS-Server unter Windows NT4 oder 2000 einsetzen und diese nicht gesichert haben könnten.

Wo kann ich testen, ob meine Site angreifbar ist?

FĂŒr einen Test haben wir ein Tool entwickelt, das versucht, den .COM-Cache-Eintrag zu vergiften (oder den fĂŒr jede andere Domain). Leider haben wir bisher keinen Weg gefunden, das fĂŒr einen sicheren Selbsttest bereit zu stellen. Es besteht die Gefahr, dass ein Endanwender diesen Test bei seinem Internet Provider oder seiner Firma erfolgreich durchfĂŒhrt und damit alle anderen Anwender beeintrĂ€chtigt, die auf denselben DNS-Server zugreifen. Wir versuchen derzeit eine weniger gefĂ€hrlichen Testmethode zu entwickeln.

Bitte fragen Sie nicht nach dem Tool. Wir geben es derzeit an niemanden heraus.

Was ist DNS Cache Poisoning ĂŒberhaupt?

Im Grunde ist es eine Methode fĂŒr einen Angreifer, die IP-Adresse zu verĂ€ndern, in die ein Hostname aufgelöst wird. www.cisco.com verweist beispielsweise auf die IP-Adresse 198.133.219.25. Mit einem DNS Cache Poisoning Angriff kann der Angreifer diesen Hostnamen auf eine andere IP-Adresse zeigen lassen.

Wenn der obige Absatz fĂŒr Sie keinen Sinn ergibt, helfen vielleicht die folgenden ErklĂ€rungen. Das Domain Name System (DNS) löst einen verstĂ€ndlichen Namen wie www.google.com in eine IP-Adresse auf. Dies ist die Adresse unter der ein Computer im Internet zu finden ist. Ein gute ErklĂ€rung wie DNS funktioniert liefert (in Englisch):

http://computer.howstuffworks.com/dns.htm/printable [7]

Die meisten Endanwender benutzen DNS-Server in ihrer NĂ€he -- bei ihrem Internet Provider oder in der Firma -- um Namen nachzuschlagen. Damit sie die nĂ€chste Anfrage fĂŒr denselben Namen schneller beantworten können, speichern diese Server ihre Antworten in einem Cache. Weist die Software des DNS-Servers Fehler auf oder ist sie falsch konfiguriert, kann dies Cache Poisoning Angriffe ermöglichen (Poison englisch fĂŒr Gift). Wird der Cache eines Opfers vergiftet betrifft das ALLE weiteren Nachfragen fĂŒr den vergiftete Domain-Namen fĂŒr ALLE Nutzer dieses DNS-Servers. Damit kann dieser Angriff tausende von Anwendern betreffen, ohne dass ein einziger irgendwas Falsches gemacht hĂ€tte.

Und so funktioniert der Angriff: ZunĂ€chst muss ein Auslöser dafĂŒr sorgen, dass der DNS-Server des Opfers den bösartigen DNS-Server befragt. Das lĂ€sst sich auf verschiedene Arten bewerkstelligen. Zum Beispiel durch eine E-Mail an eine ungĂŒltige Mail-Adresse, die eine Non-Delivery-Nachricht an die Absenderadresse erzeugt, Spam-Mail mit einem externen Bild, Anzeigen von einem anderen Server oder vielleicht sogar ĂŒber bereits installierte Spyware.

Durch diesen Auslöser fragt also der DNS-Server des Opfers beim bösartigen DNS-Server nach einer IP-Adresse. In die Antwort baut der dann einige Zusatzinformationen ein. Bei den Angriffen enthielten die Antworten zusĂ€tzliche Root-EintrĂ€ge fĂŒr die gesamte .COM-Domain. Ist Ihr DNS-Server nicht gesichert, akzeptiert er den neuen Eintrag fĂŒr .COM und löscht den Verweis auf die Verisign-Server (die tatsĂ€chlich fĂŒr die .COM-Domain zustĂ€ndig sind). Ab dann fragt der DNS-Server fĂŒr jede .COM-Adresse bei dem bösartigen Server nach und der antwortet womit er will. In diesem Fall wurden fĂŒr alle Hostnamen IP-Adressen von Web-Servern zurĂŒckgeliefert, die Schwachstellen des Internet Explorer ausnutzten, um Spyware zu installieren.

Es ist wichtig, festzuhalten, dass auf diese Art und Weise alle Top-Level-Domains wie .NET, .ORG oder .DE entfĂŒhrt werden könnten. Der Angreifer könnte auch alle entfĂŒhren. Ein gerissener Angreifer wĂŒrde sich jedoch auf einige Hostnamen beschrĂ€nken und fĂŒr den Rest richtige Adressen zurĂŒck liefern. Dies wĂ€re nicht so auffĂ€llig und könnte betrĂ€chtlichen Schaden anrichten.

Warum machen die das?

Die Motivation fĂŒr diese Angriffe ist sehr einfach: Geld. Das Ziel des ersten Angriffs war, Spy/Adware auf so vielen Windows-Systemen wie möglich zu installieren. Ein gutes Spy/Adware-Programm bringt dem Angreifer betrĂ€chtliche Einnahmen.

Die Leute by LURHQ haben eine gute Zusammenfassung erstellt, die das Pay-Per-Click-Konzept fĂŒr Anzeigen beschreibt, das wahrscheinlich hinter der ersten und dritten Attacke steht: http://www.lurhq.com/ppc-hijack.html [8].

Der zweite Angriff wurde wahrscheinlich von einem bekannten Spammer initiiert. Da dies fĂŒr einen Spammer jedoch ein recht komplexer Angriff ist, vermute ich im Moment, dass die eigentlichen Angreifer ihre Dienste fĂŒr Geld feil bieten. Unser Beweggrund fĂŒr diese detaillierte Analyse war die Tatsache, dass Angriffe mit DNS Cache Poisoning Millionen von Internet-Nutzern betreffen können und sehr gefĂ€hrliche Folgeangriffe ermöglichen. Nachdem wir ein paar verlĂ€ssliche Berichte erhalten hatten, war uns klar, dass wir dieser Sache auf der Grund gehen mussten,

DNS Cache Poisoning Angriffe

Wurden DNS Cache Poisoning Angriffe nicht schon vor 8 Jahren unmöglich gemacht?

Ein kleiner Ausflug in die Vergangenheit... Cache-Poisoning ist seit geraumer Zeit bekannt. Damals tauchten einige sehr heftige Fehler in BIND und auch einige Designfehler auf. DJB-Fans stellen fest, dass auch djbdns seit langem vor Cache-Poisoning geschĂŒtzt ist. Im Grunde ist die Unix-basierte Software bereits seit einiger Zeit vor Cache-Poisoning geschĂŒtzt, aber da könnte natĂŒrlich immer noch irgendwo ein Design-Fehler oder ein Bug entdeckt werden. Uns ist nicht klar, warum Microsoft die Standardeinstellung von Windows NT4 und 2000 unsicher belassen hat (Sie können hier gerne ihren Lieblingsspruch oder -witz zu Microsoft und Sicherheit einfĂŒgen -- aber bitte behalten Sie ihn fĂŒr sich).

Was war der Auslöser der Angriffe?

Es ist uns nicht gelungen, den genauen Auslöser fĂŒr die Angriffe herauszufinden. Es gibt auch so viele Möglichkeiten, eine DNS-Anfrage zu einem bösartigen DNS-Server auszulösen, dass es eigentlich keine Rolle spielt. Es geht ganz einfach. Also statt sich auf den Auslöser zu konzentrieren, sollten Administratoren lieber ihre DNS-Software absichern.

Wie haben diese Angriffe genau funktioniert?

WĂ€hrend des ersten Angriffs (von circa 22.2. bis 12.3.2005) wurden die Opfer auf einen der folgenden drei Server umgeleitet: 217.160.169.87, 207.44.240.79, 216.127.88.131. Deren Domain-Namen waren www.7sir7.com, 123xxl.com und abx4.com. Sie wurden kurz vor dem Angriff erworben. Alle drei Adressen zeigten auf kompromittierte Unix-Web-Server bei Web-Hostern. Den meisten Anwendern fiel die Umleitung beim Surfen auf, wir haben aber auch Berichte ĂŒber fehlgeschlagene E-Mail-Zustellungsversuche erhalten und Untersuchungen der Log-Dateien der Server zeigten, dass auch FTP-, IMAP/POP und SSH-Logins umgeleitet wurden. Die Angreifer haben auf den Web-Servern zwei Internet-Explorer-Exploits installiert, die beim Abruf der Web-Seite ausgefĂŒhrt wurden und bei Erfolg ein Spyware-Programm installierten.

WĂ€hrend des zweiten Angriffs (25.3.) leiteten zwei bösartige Web-Server die Leute um: 222.47.183.18 und 222.47.122.203. Sie leiteten alle Anfragen auf sich selbst, wo eine Web-Seite Medikamente anpries. Sie enthielt jedoch keine Schad-Software. Das war eher das Werk eines Spammers. Untersuchungen zu den IP-Adressen und der darauf registrierten Domain-Namen ergaben, dass sie vermutlich einem Spammer gehören, der ĂŒber 300 weitere Domain-Namen registriert hat. Die Web-Seiten zeigten den Namen "megapowerpills.com" an, der jedoch als echte Web-Site auf einer anderen IP-Adresse existiert.

Der dritte Angriff (25.3. bis 1.4.2005) ist eine direkte Fortsetzung des ersten; ebenfalls mit dem Ziel Spyware zu installieren. Einer der drei Server aus dem ersten Angriff wurde nie richtig gesĂ€ubert, der Angreifer kam zurĂŒck und setzte ein neues Poisoning-Tool ein. Diesmal gab der DNS-Server folgende IP-Adressen aus: 209.123.63.168, 64.21.61.5, 205.162.201.11. Sie alle beherbergen die gleiche einfache Webseite, die Anwender auf die beiden URLs

vparivalka .org /G7 /anticheatsys.php?id=36381
find-it .web-search .la

umgeleitet hat (sie wurden durch uns stillgelegt).

Welche Domain-Namen wurden umgeleitet?

Welche Domain-Namen wurden umgeleitet?

Wir haben einige Log-Dateien von zwei der Server des ersten Angriffs erhalten, die am 4.3. entdeckt wurde. Beachten Sie jedoch, dass die Maschinen kompromittiert waren, die Daten also nicht verlĂ€sslich sind. Diese Log-Dateien ergeben die folgende Statistik fĂŒr drei Tage (2.-5.3.)

Ein Administrator hatte uns am 4.3. eine Kopie seines vergifteten DNS-Caches geschickt. Allein fĂŒr seine Site wurden 665 Hostnamen vergiftet. Da die gesamte .COM-Domain vergiftet war, wĂ€re jeder Zugriff seiner Anwender auf einen Namen, der auf .COM endet, auf einen der feindlichen Server geleitet worden.

Die folgende Übersicht zeigt, welch weitreichende Konsequenzen ein solcher Angriff haben kann. Wichtig ist, dass auch E-Mail, FTP-Logins, HTTPS-Sitzungen und anderer Verkehr auf die bösartigen Server umgeleitet wurden. Es gibt zwar keine Anzeichen, dass der Angreifer E-Mails gelesen oder Passwörter gesammelt hat -- sicher kann man sich da jedoch nicht sein.

Bitte beachten Sie, dass die aufgefĂŒhrten Firmen nicht von dem Angriff betroffen waren. Es ist jedoch durchaus möglich, dass ihre Kunden unwissentlich Login-Daten oder persönliche Informationen an die bösartigen Server ĂŒbermittelt haben. Und eine letzte Anmerkung: Dies ist nur eine Liste der Domainnamen, die in einem einzigen Netz vergiftet wurden -- es hĂ€tte auch jeden anderen erwischen können.

Finanzen:
--------
americanexpress.com (credit cards)
citicards.com (credit cards)
billpay.quickbooks.com (financial software/services)
adp.com (data processing)
hrblockemail.com (financial services)
 
Firmen-PrÀsenzen
----------------
dhl-usa.com (global shipping)
fedex.com (global shipping)
walmart.com (retail)
samsclub.com (retail)
kraftfoods.com (food products)
averydennison.com (paper products, labels)
ppg.com (worlwide commercial products)
nortelnetworks.com (telecommunications)
potterybarn.com (retail)
weightwatchers.com (retail)
dressbarn.com (retail)
moviefone.com (online movie listings/purchase)
nascar.com (car racing)
officemax.com (retail office supplies)
verizonwireless.com (wireless telephone service)
qvc.com (retail)
 
Unterhaltung/Medien/News
------------------------
cnn.com
nbc.com
abc.com
fox.com
foxnews.com
espn.com
yahoofs.com
starwave.com (part of go.com)
hotjobs.com (job search)
chicagotribune.com
tribune.com
suntimes.com
wgnradio.com
businessweek.com
wired.com
randomhouse.com
imdb.com (online music database)
napster.com (online music)
musicmatch.com (online music)
allofmp3.com (online music)
audible.com (online music)
modblog.com (mobile blogging site)
entertainment.com
courttv.com
 
Hardware/Software
-----------------
trendmicro.com (anti-virus)
redhat.com (linux vendor)
msoffice.com
microsoftoffice.com
officeupdate.com
giantcompany.com (microsoft's new anti-spyware)
autodesk.com (AutoCAD)
realone.com
realplayer.com
emc.com (enterprise storage)
creative.com (consumer electronics)
lavasoftusa.com (personal firewalls)
tomshardware.com (pc hardware)
 
ISP/Hosting/Suche
------------------
msn.com
compuserve.com
realpages.com
geocities.com
hotbot.com
switchboard.com
cleanmail.com
webex.com
catalog.com
about.com
 
Gesundheit
----------
webmd.com (online medical advice)
lilly.com (pharmaceuticals)
questdiagnostics.com (medical testing)
 
Reisen
------
orbitz.com
sabre.com
tickets.com

Welche Web-Sites waren betroffen?

Ohne ausdrĂŒckliche Genehmigung veröffentlichen wir keine Namen von Betroffenen. Wir stellen lediglich allgemeine Informationen zusammen. Aufgrund der eingegangenen Berichte und der ausgewerteten Log-Dateien schĂ€tze ich vorsichtig, dass circa 500-1000 mittlere bis große Unternehmen betroffen waren.

Etwa zehn Firmen, die uns kontaktierten, hatten ĂŒber 1000 Angestellte. Sie kommen aus unterschiedlichen Branchen (Banken, Industrie, Versicherungen, Telekommunikation). Interessanterweise sind die meisten Opfer in Nord- und SĂŒdamerika zu finden.

Welche SchÀdlinge wurden auf meinem System installiert, wenn ich die bösartigen Server besucht habe?

Die Web-Server des ersten und dritten Angriffs versuchten ein Spyware-Programm auf dem Rechner der Opfer zu installieren, indem sie eine SicherheitslĂŒcke des Internet Explorer bei der Behandlung von Dateien mit animiertem Cursor ausnutzten. Diese Schwachstelle wurde am 11. Januar 2005 veröffentlicht, weitere Informationen dazu liefert:

http://www.microsoft.com/technet/security/Bulletin/MS05-002.mspx [9]

Kurze Zeit nach Bekanntgabe der Schwachstelle wurde ein Proof-of-Concept-Exploit veröffentlicht. Der Angriff verwendete die Dateinamen aby.ani und abx22.ani. Virustotal identifiziert die ANI-Dateien als:

Kaspersky:   Trojan-Downloader.Win32.Ani.d
McAfee:      Exploit-ANIfile
BitDefender: Exploit.Win32.MS05-002.Gen

Diese ANI-Exploits versuchten eine der beiden Dateien abx_search.exe oder mhh.exe zu installieren, die gleich waren. Sie werden gemeldet als:

Kaspersky: AdWare.ToolBar.SearchIt.h
Panda: Adware/AbxSearch

Wenn Sie sich mit dieser Toolbar infiziert haben, sollten Sie sie mit Ihrem bevorzugten Anti-Spy/Adware-Programm aufspĂŒren und entfernen.

Gibt es Pakete?

Gibt es Pakete?

Die folgenden Paketbeschreibungen zeigen DNS-Anfragen und die Antworten der bösartigen DNS-Server. Die aufgezeichneten Pakete wurden mit tethereal dekodiert, am Ende findet sich jeweils ein Hex-Dump. Das zweite Paket des Dumps enthĂ€lt den zusĂ€tzlichen RR-Eintrag fĂŒr "com", der die regulĂ€ren "com"-EintrĂ€ge ĂŒberschrieben hat. Letztere zeigen auf die offiziellen 13 Root-Nameserver.

Der erste Dump wurde einige Tage nach dem 4. MÀrz aufgezeichnet. Es zeigt, dass der Angreifer jede Adresse verbogen hat. Im Beispiel frage ich nach www.cisco.com und der bösartige DNS-Server antwortet mit 209.135.140.198, was definitiv nicht die richtige Adresse ist (198.133.219.25).

Frame 1 (2 on wire, 2 captured)
    Packet Length: 73 bytes
    Capture Length: 73 bytes
Ethernet II
    Destination:
    Source:
    Type: IP (0x0800)
Internet Protocol, Src Addr: 10.11.12.13 (10.11.12.13), Dst Addr:
    216.127.88.131 (216.127.88.131)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 59
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0xf397 (correct)
    Source: 10.11.12.13 (10.11.12.13)
    Destination: 216.127.88.131 (216.127.88.131)
User Datagram Protocol, Src Port: 34899 (34899), Dst Port: 53 (53)
    Source port: 34899 (34899)
    Destination port: 53 (53)
    Length: 39
    Checksum: 0x9801 (correct)
Domain Name System (query)
    Transaction ID: 0xd4f5
    Flags: 0x0100 (Standard query)
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... ...0 .... = Non-authenticated data OK:
    Non-authenticated data is unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        www.cisco.com: type A, class inet
            Name: www.cisco.com
            Type: Host address
            Class: inet
 
0x0000   4500 003b 0000 4000 4011 f397 0a0b 0c0d        E..;..@.@.......
0x0010   d87f 5883 8853 0035 0027 9801 d4f5 0100        ..X..S.5.'......
0x0020   0001 0000 0000 0000 0377 7777 0563 6973        .........www.cis
0x0030   636f 0363 6f6d 0000 0100 01                    co.com.....

Frame 2 (2 on wire, 2 captured)
    Frame Number: 2
    Packet Length: 119 bytes
    Capture Length: 119 bytes
Ethernet II
    Destination:
    Source:
    Type: IP (0x0800)
Internet Protocol, Src Addr: 216.127.88.131 (216.127.88.131), Dst Addr:
    10.11.12.13 (10.11.12.13)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 105
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 51
    Protocol: UDP (0x11)
    Header checksum: 0x006a (correct)
    Source: 216.127.88.131 (216.127.88.131)
    Destination: 10.11.12.13 (10.11.12.13)
User Datagram Protocol, Src Port: 53 (53), Dst Port: 34899 (34899)
    Source port: 53 (53)
    Destination port: 34899 (34899)
    Length: 85
    Checksum: 0x036c (correct)
Domain Name System (response)
    Transaction ID: 0xd4f5
    Flags: 0x8580 (Standard query response, No error)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for
                                domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 1... .... = Recursion available: Server can do
                                recursive queries
        .... .... ..0. .... = Answer authenticated: Answer/authority
                                portion was not authenticated by the
                                server
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 1
    Additional RRs: 0
    Queries
        www.cisco.com: type A, class inet
            Name: www.cisco.com
            Type: Host address
            Class: inet
    Answers
        www.cisco.com: type A, class inet, addr 209.135.140.198
            Name: www.cisco.com
            Type: Host address
            Class: inet
            Time to live: 1 day, 3 hours, 46 minutes, 39 seconds
            Data length: 4
            Addr: 209.135.140.198
    Authoritative nameservers
        com: type NS, class inet, ns 3sistersmassage.com
            Name: com
            Type: Authoritative name server
            Class: inet
            Time to live: 1 day, 3 hours, 46 minutes, 39 seconds
            Data length: 18
            Name server: 3sistersmassage.com
 
0x0000   4500 0069 0000 4000 3311 006a d87f 5883        E..i..@.3..j..X.
0x0010   0a0b 0c0d 0035 8853 0055 036c d4f5 8580        .....5.S.U.l....
0x0020   0001 0001 0001 0000 0377 7777 0563 6973        .........www.cis
0x0030   636f 0363 6f6d 0000 0100 01c0 0c00 0100        co.com..........
0x0040   0100 0186 9f00 04d1 878c c6c0 1600 0200        ................
0x0050   0100 0186 9f00 120f 3373 6973 7465 7273        ........3sisters
0x0060   6d61 7373 6167 65c0 16                         massage..

Zum Zeitpunkt der Aufzeichnung ergab 3sistersmassage.com 216.127.88.131 -- die Adresse des Servers, der die Anfrage erhalten hatte.

Das nĂ€chste ist ein Dump aus dem zweiten Angriff. Er zeigt mehrere Hostnamen (mit derselben IP-Adresse) als Root-Nameserver fĂŒr .com. Das Paket ist die Antwort auf eine Anfrage nach einem obskuren Namen (www.leroysprings.com). Der Server antwortet mit 222.47.183.18 als IP-Adresse und nennt die gleiche IP-Adresse als Root-Nameserver fĂŒr .com.

Frame 1
    Packet Length: 260 bytes
    Capture Length: 260 bytes
Ethernet II
    Destination:
    Source:
    Type: IP (0x0800)
Internet Protocol, Src Addr: 222.47.183.18 (222.47.183.18), Dst Addr:
    10.11.12.13 (10.11.12.13)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 246
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 50
    Protocol: UDP (0x11)
    Header checksum: 0x9c9d (correct)
    Source: 222.47.183.18 (222.47.183.18)
    Destination: 10.11.12.13 (10.11.12.13)
User Datagram Protocol, Src Port: 53 (53), Dst Port: 32792 (32792)
    Source port: 53 (53)
    Destination port: 32792 (32792)
    Length: 226
    Checksum: 0xfa49 (correct)
Domain Name System (response)
    Transaction ID: 0x5494
    Flags: 0x8500 (Standard query response, No error)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for
    domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 0... .... = Recursion available: Server can't do
    recursive queries
        .... .... ..0. .... = Answer authenticated: Answer/authority
    portion was not authenticated by the server
    .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 2
    Authority RRs: 4
    Additional RRs: 4
    Queries
        www.leroysprings.com: type A, class inet
            Name: www.leroysprings.com
            Type: Host address
            Class: inet
    Answers
        www.leroysprings.com: type A, class inet, addr 222.47.183.18
            Name: www.leroysprings.com
            Type: Host address
            Class: inet
            Time to live: 1 minute
            Data length: 4
            Addr: 222.47.183.18
        www.leroysprings.com: type A, class inet, addr 222.47.183.18
            Name: www.leroysprings.com
            Type: Host address
            Class: inet
            Time to live: 1 minute
            Data length: 4
            Addr: 222.47.183.18
    Authoritative nameservers
        com: type NS, class inet, ns ns1.m-dns.us
            Name: com
            Type: Authoritative name server
            Class: inet
            Time to live: 1 minute
            Data length: 14
            Name server: ns1.m-dns.us
        com: type NS, class inet, ns ns2.com
            Name: com
            Type: Authoritative name server
            Class: inet
            Time to live: 1 minute
            Data length: 6
            Name server: ns2.com
        com: type NS, class inet, ns ns1.bizwebb.us
            Name: com
            Type: Authoritative name server
            Class: inet
            Time to live: 1 minute
            Data length: 14
            Name server: ns1.bizwebb.us
        com: type NS, class inet, ns ns2.com
            Name: com
            Type: Authoritative name server
            Class: inet
            Time to live: 1 minute
            Data length: 2
            Name server: ns2.com
    Additional records
        ns1.m-dns.us: type A, class inet, addr 222.47.183.18
            Name: ns1.m-dns.us
            Type: Host address
            Class: inet
            Time to live: 1 minute
            Data length: 4
            Addr: 222.47.183.18
        ns2.com: type A, class inet, addr 222.47.183.18
            Name: ns2.com
            Type: Host address
 
0x0000   4500 00f6 0000 4000 3211 9c9d de2f b712        E.....@.2..../..
0x0010   0a0b 0c0d 0035 8018 00e2 fa49 5494 8500        .....5.....IT...
0x0020   0001 0002 0004 0004 0377 7777 0c6c 6572        .........www.ler
0x0030   6f79 7370 7269 6e67 7303 636f 6d00 0001        oysprings.com...
0x0040   0001 c00c 0001 0001 0000 003c 0004 de2f        ...........<.../
0x0050   b712 c00c 0001 0001 0000 003c 0004 de2f        ...........<.../
0x0060   b712 c01d 0002 0001 0000 003c 000e 036e        ...........<...n
0x0070   7331 056d 2d64 6e73 0275 7300 c01d 0002        s1.m-dns.us.....
0x0080   0001 0000 003c 0006 036e 7332 c01d c01d        .....<...ns2....
0x0090   0002 0001 0000 003c 000e 036e 7331 0762        .......<...ns1.b
0x00a0   697a 7765 6262 c05c c01d 0002 0001 0000        izwebb.\........
0x00b0   003c 0002 c06c c052 0001 0001 0000 003c        .<...l.R.......<
0x00c0   0004 de2f b712 c06c 0001 0001 0000 003c        .../...l.......<
0x00d0   0004 de2f b712 c06c 0001 0001 0000 003c        .../...l.......<
0x00e0   0004 de2f b712 c07e 0001 0001 0000 003c        .../...~.......<
0x00f0   0004 de2f b712                                 .../..

Wie siehts mit Snort-Regeln aus?

Die folgenden Snort-Regeln sollten Poisoning-Angriffe auf die .COM-Domain erkennen. Neue Signaturen veröffentlichen wir auf der ISC-Site, nachdem wir sie getestet haben. Aktuelle Signaturen finden Sie auch auf: http://bleedingsnort.com/ [10]

alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"com DNS cache poison";
content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|";
content:"|00 02|"; distance:1; within:2;
byte_jump:1,-3,relative,from_beginning; content:"|03|com|00|"; nocase;
within:5; classtype:misc-attack; sid:1600; rev:3;)


(ju [11])

URL dieses Artikels:
https://www.heise.de/-270662

Links in diesem Artikel:
[1] http://isc.incidents.org/
[2] http://isc.sans.org/presentations/dnspoisoning.php
[3] http://support.microsoft.com/default.aspx?scid=kb;en-us;241352
[4] http://securityresponse.symantec.com/avcenter/security/Content/2005.03.15.html
[5] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0817
[6] http://securityresponse.symantec.com/avcenter/security/Content/2004.06.21.html
[7] http://computer.howstuffworks.com/dns.htm/printable
[8] http://www.lurhq.com/ppc-hijack.html
[9] http://www.microsoft.com/technet/security/Bulletin/MS05-002.mspx
[10] http://bleedingsnort.com/
[11] mailto:ju@ct.de

Copyright © 2005 Heise Medien