Die Katze ist endgültig aus dem Sack, Details zur Design-Schwachstelle im DNS öffentlich bekannt.
Kleine Ursache...
Halvar Flake hat in seinem Blog über die Ursache der Schwachstelle spekuliert und dabei ziemlich nah ans Schwarze getroffen. Im Blog von Matasano wurden daraufhin Details zur Schwachstelle veröffentlicht, aber sehr schnell wieder gelöscht. Hallo? Löschen? Im Internet veröffentlichte Daten? Na, das hätten die von Matasano aber besser wissen müssen. Die Katze ist aus dem Sack, die Information öffentlich und bereits an etlichen Stellen im Netz verfügbar.
... große Wirkung
Thomas Ptacek hat kurz darauf eine Entschuldigung veröffentlicht: Nachdem Dan Kaminsky ihm die Schwachstelle erläutert hatte, wurde ein entsprechender Text vorbereitet und auf dem Server gespeichert:
"We chose to have a story locked and loaded for that presentation, or for any other confirmed public disclosure."
Eigentlich sollte inzwischen jeder wissen, dass nicht zur Veröffentlichung bestimmte Daten nichts auf einem Webserver zu suchen haben. Das ist ein extrem peinlicher Anfängerfehler, vor allem für ein Sicherheitsunternehmen. Quasi sowas wie ein durch ein weggeworfenes brennendes Streichholz ausgelöstes Feuer bei der Feuerwehr. Dass dieser vorbereitete Text dann aber allen Anschein nach automatisch veröffentlicht wurde, ist dann das Tüpfelchen auf dem i:
"[...] a post appeared on our blog about that hypothesis. It was posted in error. We regret that it ran. We removed it from the blog as soon as we saw it." [Hervorhebung von mir]
OK, Shit happens. Was passiert ist, ist passiert und lässt sich nicht mehr ändern. Die Katze ist aus dem Sack, bringt die Mäuse in Sicherheit.
Katerstrophe?
Teilweise herrscht jetzt Katerstimmung: Was nun? Panik? Untergang des Internets? Erst einmal: Ruhig durchatmen. Dann: Halvar Flakes Blogeintrag lesen, besonders auch den ersten Teil. Eigentlich ist nichts passiert, was die Gefährdung wirklich erhöht. Wer wirklich an Angriffen interessiert ist, wer damit Geld ergaunern will und ein bisschen Aufwand nicht scheut, der konnte Dan Kaminskys Angriff auch schon vorher selbst nachvollziehen. Zumal erste Hinweise auf die Art der Schwachstelle schon in den verschiedenen Advisories enthalten waren. Die Nicht-Veröffentlichung von Details wiegt nur in falscher Sicherheit. Wie Halvar Flake geschrieben hat: Alle denken, sie haben fürs Patchen Zeit bis zur Konferenz im August, tatsächlich sind die Angreifer aber womöglich schon viel früher startbereit. Und die warten nicht auf irgendeinen Startschuss, die legen sofort los.
Butter bei die Fische
Die von Matasano veröffentlichten Details können an vielen Orten nachgelesen werden, z.B. hier, hier oder hier. Im Folgenden eine kurze Zusammenfassung:
Eine Methode, einen DNS-Cache zu vergiften, besteht im Liefern einer
gefälschten Antwort, wie es im Artikel zur Design-Schwachstelle beschrieben wurde. Eine weitere
Methode besteht darin, in einer DNS-Antwort zusätzlich gefälschte
Informationen, so genannte Additional Resource Records (RR), für eine andere
Domain mitzuliefern (siehe About Security #62). Damit ein cachender Nameserver
keine RRs für andere Domains in einer Antwort akzeptiert, wird das
so genannte 'Bailiwick Checking' eingesetzt: Zusätzliche Informationen werden
immer nur für die abgefragte Domain akzeptiert ('in-bailiwick'). Damit
wird verhindert, dass dem Server bei der Anfrage nach
www.server.example in der Antwort zusätzlich noch
Informationen über www.anderer-server.example
untergeschoben werden - diese RRs sind 'out-bailiwick'.
Um nun den Eintrag in Alices DNS-Server für
www.opfer.example mit der IP-Adresse 1.2.3.4 zu vergiften,
geht der Angreifer vereinfacht folgendermaßen vor: Er lässt
Alice z.B. durch eine präparierte E-Mail nach vielen unsinnigen Namen
fragen: aaaa.opfer.example, aaab.opfer.example,
aaac.opfer.example, ... . Der für
opfer.example zuständige DNS-Server antwortet mit
NXDOMAIN - diese Domain existiert nicht. Der Angreifer liefert
für jeden Namen eine gültige Antwort. Zusätzlich
enthält diese Antwort jedes Mal einen Additional Resource Record, laut
dem die IP-Adresse von www.opfer.example 1.2.3.4 ist. Dieser
RR ist 'in-bailiwick', da er wie der angefragte Server zur Domain
opfer.example gehört, und wird daher akzeptiert.
Alices DNS-Server erhält nun auf jede Anfrage zwei Antworten - und akzeptiert die erste mit der richtigen Transaktions-ID. Je mehr dieser IDs verbraucht werden, desto größer ist die Chance für den Angreifer, eine gültige ID zu erraten. Und dann muss er nur noch schneller antworten als der zuständige DNS-Server. Den könnte er bei Bedarf aber durch einen DoS-Angriff am Antworten hindern.
Und nun?
Der Angriff ist eigentlich erschreckend einfach. Ich frage mich, wieso er nicht schon viel früher entdeckt wurde. Oder wurde er bereits früher entdeckt, aber nur von Leuten, die ihn lieber für Phishing und andere Verbrechen eingesetzt haben, anstatt ihn zu veröffentlichen? Immerhin ist ein erfolgreiches DNS-Cache-Poisoning nach Ablauf der Gültigkeitsdauer des vergifteten Eintrags kaum noch nachzuweisen. Dieser Angriff ist auf jedem Fall sehr gefährlich, daher bleibt nur noch, Dan Kaminskys Aufforderung zu wiederholen:
"Patch. Today. Now."
Carsten Eilers
