URL dieser Newsmeldung:

Diesmal geht es vor allem um die von Dan Kaminsky gefundene Schwachstelle in der DNS-Spezifikation, außerdem gibt es einen Hinweis auf einen Patch, dessen Installation einen Fehler behebt, der die Installation von Patches verhindert.

Identische DNS-Schwachstellen bei verschiedenen Herstellern

Microsofts Security-Bulletin zu den DNS-Schwachstellen sah eigentlich ganz harmlos aus. Um Cache-Poisoning zu erschweren, wurden zusätzlich zufällig wechselnde Quellports für die DNS-Abfragen implementiert. Okay, kann man machen, warum auch nicht? Dass da eine komplett neue Schwachstelle dahinter steckt, habe ich da noch nicht gewusst und auch nicht erwartet. Kurz darauf folgten dann Security-Advisories von Cisco und ISC: Auch in verschiedenen Cisco-Produkten und den ISC-Nameserver BIND wurde dieselbe Schwachstelle wie in Windows behoben. So verschiedene Produkte, und dann dieselbe Schwachstelle, das ist doch ziemlich ungewöhnlich.

Design-Fehler in der DNS-Spezifikation

Einige wenige Details dazu verrät eine Vulnerability Note des US-CERT: Bisher war Cache-Poisoning immer dann möglich, wenn durch eine Schwachstelle die Transaction-IDs der DNS-Abfragen erraten oder berechnet werden konnten. Dan Kaminsky hat eine neue Methode entdeckt, um ohne weitere Schwachstelle Cache-Poisoning durchzuführen. Details sollen erst auf der Sicherheitskonferenz Blackhat im August vorgestellt werden, bisher ist nur bekannt, dass es sich um einen Design-Fehler in der DNS-Spezifikation handelt. Aufgrund der wenigen Informationen kann man die wirkliche Gefährdung durch diesen bisher unveröffentlichten Angriff nicht einschätzen, aber wenn Microsoft, Cisco und ISC sich zu einer koordinierten Veröffentlichung ihrer Patches entschließen, sollte einem das schon zu denken geben.

Gute Arbeit!

Dan Kaminsky hat in seinem Blog über die Koordinierung der Veröffentlichung berichtet. Das ist wirklich eine Leistung, auf die die Beteiligten stolz sein können. Bravo, sehr gut gemacht! Einen Fehler hat Dan Kaminsky allerdings gemacht: Er hat die Schwachstelle den Betroffenen, d.h. den Entwicklern von DNS-Servern, vorgeführt, aber niemandem aus der Security-Community. Er war sich sicher, dass sein Angriff funktioniert und die Schwachstelle wirklich existiert, und hielt jede Veröffentlichung, selbst in kleinstem Kreis, für zu gefährlich. In so einem Fall auf jeden Peer-Review zu verzichten, ist in meinen Augen sehr mutig, andere haben für diese "Geheimniskrämerei" weniger schmeichelhafte Worte benutzt. Nachdem Dan Kaminsky seinen Fehler als solchen erkannt hatte, hat er Thomas Ptacek und Dino Dai Zovi Details über die Schwachstelle genannt, und sowohl Thomas Ptacek als auch Dino Dai Zovi haben seine Ergebnisse bestätigt und waren nach eigenen Aussagen beeindruckt. Das klingt für mich gar nicht gut.

Multimedia

Um die Schwachstelle möglichst weit bekannt zu machen, hat Dan Kaminsky keine Mühen gescheut: Außer der Security Advisories der betroffenen Hersteller, der Vulnerability Note des US-CERT und der Blogeinträge gibt es ein Interview mit ihm im Network Security Podcast, und für 'Non-Geeks' erklärt seine Nichte das Problem in einem Video.

Zu Risiken und Nebenwirkungen fragen Sie ...

... ja, wen denn? Das ist eine gute Frage. Sofern Hersteller bereits Advisories veröffentlicht haben und/oder die Vulnerability Note des US-CERT Informationen enthält, kann man sich danach richten. Was ist aber mit Produkten, deren Hersteller sich noch nicht zu der Schwachstelle geäußert haben? Und wie sieht es mit der Bedrohung von DNS-Servern in DSL-Routern und den Rechnern hinter NAT-Routern aus? Von z.B. D-Link und Zyxel gibt es bisher keine Informationen, ob Produkte betroffen sind oder nicht und ob es ggf. Updates oder Patches gibt. Über NAT-Router hat Tom Cross von IBM X-Force einen Blogeintrag veröffentlicht, den er auch auf der Mailingliste Full-Disclosure veröffentlicht hat. Je nach Implementierung kann ein NAT-Router anscheinend die Zufälligkeit der Quellports zunichte machen, wenn er eigene Quellports der Reihe nach vergibt. Damit wird ein Client hinter dem NAT-Router wieder angreifbar, da die Sicherheit wieder auf die Zufälligkeit der Transaction-ID reduziert wird.

Du kommst hier nicht durch!

Ein weiteres Problem sind Firewalls, die mit den sich nach der Installation der Patches ändernden Quellports nicht klar kommen. Nach der Installation des Microsoft-Patches kamen Nutzer von ZoneAlarm auf Windows XP und 2000 nicht mehr ins Internet. Inzwischen wurden von ZoneAlarm Updates bereit gestellt, und Microsoft hat das Security-Advisory um Hinweise zu den Problemen ergänzt. Dumm nur, dass die Betroffenen das ja eigentlich gar nicht lesen können, schließlich kommen sie ja nicht ins Internet. ZoneAlarm schlägt als Workaround vor, den Patch zu deinstallieren oder die Sicherheitseinstellung der ZoneAlarm-Firewall auf 'Mittel' zu stellen. Ich vermute, viele Betroffene haben das erst gelesen, nachdem sie ZoneAlarm deaktiviert oder sogar deinstalliert hatten. Schließlich ist das doch einer der ersten Schritte bei Problemen mit der Internetverbindung: Weg mit der Firewall, besonders mit einer Personal.

Testmöglichkeiten

Wer wissen möchte, ob sein DNS-Server betroffen ist, kann dazu einen webbasierten Test in Dan Kaminskys Blog starten. Möchten Sie einen bestimmten Server testen, können Sie einen Test des "DNS Operations, Analysis and Research Center" nutzen:

Der DNS-Server wird mit

# dig @DNS-Server +short porttest.dns-oarc.net TXT

getestet. Ein gepatchter Server antwortet darauf z.B. mit

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. 
"IP-Adresse is GOOD: 26 queries in 4.0 seconds from 26 ports ..."

Ein verwundbarer Server liefert dagegen z.B.

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"IP-Adresse is POOR: 26 queries in 4.1 seconds from 1 ports ..."

Für DNS-Server müssen Sie den zu testenden Server einsetzen, IP-Adresse ist die IP-Adresse des getesteten Servers.

Patch me, if you can

Ein Patch, dessen Installation einen Fehler behebt, der die Installation von Patches verhindert - das klingt merkwürdig, oder? Das ist aber die Lösung für das im Standpunkt der vorigen Woche beschriebene Problem mit dem Windows Server Update Services (WSUS) und Office 2003. Microsoft ist mit der Analyse des Problems fertig und hat Patches zum Download bereit gestellt, die das Problem beheben. Nach deren Installation steht dann auch der Installation der Patches vom letzten Patchday nichts mehr im Wege. Na, dann mal los...

Carsten Eilers

 "About Security": Die wöchentliche Serie von Carsten Eilers (http://entwickler.de/zonen/portale/psecom,id,234,nodeid,.html)