Diese Woche im "Standpunkt Sicherheit": Viele Kommentare zur DNS-Schwachstelle und einer zur Datensicherheit in Großbritannien.

DNS - Patch, Details, Exploits und... Attacke!

Eigentlich war das ja zu erwarten: Erst kamen die Patches für die Design-Schwachstelle im DNS-Protokoll, dann wurden erste Details bekannt, kurz darauf gab es die ersten Beispiel-Exploits - und jetzt werden die ersten Angriffe gemeldet. Wobei ich da noch etwas skeptisch bin, denn ich konnte keine bestätigten Angriffe auf irgendeinen Nameserver finden. Dafür aber etliche Meldungen, die aus "Exploitcode veröffentlicht" "Angriffe laufen" machten. Ob wirklich schon Nameserver gezielt angegriffen wurden oder ob da nur jemand etwas falsch verstanden hat ist also noch nicht geklärt. Abgesehen von "So schnell wie möglich patchen" kann man dagegen zurzeit sowieso nicht viel machen. Wenn man denn überhaupt patchen kann, denn z.B. Apple war bisher nicht in der Lage, die mit Mac OS X mitgelieferte BIND-Version zu aktualisieren. Peinlich, peinlich, schließlich gibt es von BIND schon seit dem 8.7. Patches.

Vergiftet oder nicht vergiftet?

Ein erfolgreiches Cache-Poisoning lässt sich nachträglich im Prinzip nicht mehr nachweisen. Wenn die gefälschten Daten aus dem Cache gelöscht oder mit den korrekten Daten überschrieben wurden, sind sie unwiederbringlich verloren. Um einen Cache-Poisoning-Angriff zu erkennen, gibt es nur eine einzige Möglichkeit: Der Cache-Inhalt muss regelmäßig in einer Datei gesichert und dann die Angaben darin mit den vom authoritiven Nameserver gelieferten korrekten Daten verglichen werden. Das kann bei einem stark ausgelasteten Server ziemlich aufwändig werden. Wer es probieren möchte, kann dafür ein Tool von ONZRA verwenden: CacheAudit, eine Sammlung von Python-Skripten, mit denen sich der Cache eines rekursiven DNS-Servers überwachen lässt. Da deren Seite rein auf Flash basiert, sollte man sie eigentlich komplett ignorieren, schließlich lässt sich kein vernünftiger Link setzen. Da das Tool aber für einige Leser nützlich sein könnte, verweise ich hier trotzdem darauf. Die Beschreibung ist irgendwo auf der Seite versteckt, zumindest das Programmarchiv lässt sich aber direkt verlinken: CacheAudit-Latest.tgz.

Patching Isn't Enough

Bruce Schneier hat sich ein paar Gedanken zur Schwachstelle und den Vorgängen drumherum gemacht und kommt zu dem Schluss "Patching Isn't Enough". Da hat er Recht. Nur wenn Sicherheit bereits von Anfang an Bestandteil des Entwicklungsprozesses ist, kommt man aus der "Patch-Tretmühle" heraus. Denn wie läuft das Ganze denn zurzeit meist ab? Jemand schreibt ein Programm, meist ohne besonders auf dessen Sicherheit zu achten. Jemand anders findet eine Schwachstelle. Die wird gepatcht (oder auch nicht). Dann wird wieder eine Schwachstelle gefunden usw. Dass das eine ziemlich ineffektive Herangehensweise ist, wenn man sichere Systeme haben möchte, wird jedem einleuchten.

Sicherheit gehört ins Design!

Ein Entwickler und erst recht ein Programmierer im Sinne eines "Coders" sieht nur ein Problem, das er möglichst effektiv lösen möchte. Ein Sicherheitstechniker betrachtet das aus einem ganz anderen Blickwinkel. Da interessiert nicht primär, wie das Problem schnell und einfach gelöst wird, sondern wie es sicher gelöst wird. Was könnte ein Angreifer damit Böses anstellen und wie kann man das verhindern? Ein gutes Beispiel dafür liefert Bruce Schneier in seinem Artikel:

"Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack."

DNSSEC tut not

Was DNS betrifft: Da ist mit der Installation der Patches noch nicht alles ausgestanden. Die einzige Möglichkeit, das System wirklich sicher zu machen, ist die Umstellung auf DNSSEC. Dabei sorgen digitale Signaturen dafür, dass die Authentizität der gelieferten Daten geprüft werden können: Stammen die Informationen vom zuständigen (authoritiven) Nameserver und sind sie unverändert? Die Internet Corporation for Assigned Names and Numbers ICANN hat ein Paper veröffentlicht, wie bis Ende 2008 die Root-Server auf DNSSEC umgestellt werden können. Das ist allerdings noch keine Roadmap, sondern nur eine erste Überlegung. Trotzdem kann schon das ein weiterer Anreiz sein, weitere Nameserver auf DNSSEC umzustellen.

Da war doch noch was?

Da war sogar noch einiges, was einen Kommentar wert wäre. Eigentlich möchte ich ja noch gerne den neuen elektronischen Personalausweis ein bisschen durch den Kakao ziehen, aber das muss etwas warten. Der hat mehr als ein paar Zeilen zum Schluss verdient. Eigentlich gilt das auch für die aktuelle Daten-Inkontinenz in Großbritannien. Ich vermute, jeder von Ihnen kennt eine von diesen Personen, denen man nur etwas "streng Vertrauliches" anvertrauen muss, um sicher zu sein, dass es kurz darauf jeder weiss. Die Briten sind da weiter, die haben das institutionalisiert, da übernimmt das Tratschen das Verteidigungsministerium. Nach "NSA - wir haben ein Backup aller ihrer Daten" in den USA nun also "MoD - wir verbreiten alle ihre Geheimnisse" in Großbritannien. Was da unsere Innenpolitiker wohl drauflegen werden? Schlimmer geht schließlich immer...

Carsten Eilers