Vergiftetes DNS

Inhaltsverzeichnis

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

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

Zusammenfassung

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.

Inhalt

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
   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.

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

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.

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.)

• 1.304 Domain-Namen wurden entführt
• 7.973.953 HTTP-Anfragen von 966 verschiedenen IP-Adressen
• 75.529 eingehende E-Mails von 1.863 unterschiedlichen Mail-Servern
• 7.455 fehlgeschlagene FTP-Logins von 635 IP-Adressen (95 Benutzernamen).
• 7.692 versuchte IMAP-Logins (805 User, 411 IP-Adressen).
• 2.027 versuchte Logins auf 82 verschiedenen Web-Mail-Servern.

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

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/

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)