Microsoft hat am April-Patchday vier Schwachstellen in Exchange und dem Windows SMTP Service behoben, aber nur zwei davon im Security Bulletin aufgeführt. Dieser Standpunkt Sicherheit bohrt in der Wunde.

Es war einmal ...

Erinnert sich noch jemand von Ihnen an die Design-Schwachstelle in der DNS-Spezifikation, die 2008 von Dan Kaminsky entdeckt wurde und die DNS-Cache-Poisoning-Angriffe erlaubt? Ja? Prima. Nein? Macht eigentlich nichts. Jedenfalls solange Sie nicht versuchen, ein Programm zu schreiben, das selbst DNS-Abfragen stellt. Aber wenn sie das versuchen, müssen sie sich sowieso mit der DNS-Spezifikation beschäftigen, und in RFC 5452, "Measures for Making DNS More Resilient against Forged Answers", einer Ergänzung zum DNS-Standard, wird die Schwachstelle samt Gegenmaßnahmen beschrieben.

Damals ...

Die Schwachstelle wurde von Microsoft vor ihrer Veröffentlichung in Windows behoben (MS08-037), und auch fast alle anderen betroffenen Hersteller patchten ihre Software zügig, ebenso wie die betroffenen ISP etc. diese Patches installierten. Allgemein sorgte die Schwachstelle 2008 für einige Aufregung, angefangen von der Veröffentlichung der Vulnerability Note des US-CERT im Juni über das Durchsickern erster Details, der Veröffentlichung der ersten Exploits und ersten Angriffen bis zur Veröffentlichung der Details durch Dan Kaminsky auf der Sicherheitskonferenz Black Hat im August - wer irgend etwas mit DNS zu tun hat, kann das eigentlich gar nicht nicht bemerkt haben. Vor allem, weil es danach noch weiter ging, z.B. mit Angriffen auf gepatchte Server oder einem Angriff auf einen chinesischen DNS.

... und heute?

Falls Sie sich jetzt fragen, warum ich diese ollen Kamellen ausgrabe, die heutzutage doch gar keinen mehr interessieren, kann ich darauf nur antworten: Das frage ich mich auch. D.h., ich weiß zwar, warum ich dass alles geschrieben habe, frage mich aber selbst, warum das notwendig ist. Die Ursache ist eigentlich ziemlich traurig. Würden Sie es für möglich halten, dass es 2010, fast 2 Jahre nach der Veröffentlichung der Schwachstelle, noch Programme gibt, die eine DNS-Spoofing- bzw. -Poisoning-Schwachstelle enthalten? Ich hätte nicht mehr damit gerechnet, jedenfalls nicht, wenn es um aktuelle, noch unterstützte Programme geht. Es gibt sicher noch Programme, die DNS-Abfragen machen und die seit 2008 oder noch früher nicht mehr unterstützt werden und dementsprechend auch die Schwachstelle noch nicht berücksichtigen. Aber dass ein aktuelles Programm betroffen ist, hätte ich nicht für möglich gehalten. Aber es gibt so ein Programm, genauer: Sogar zwei davon. Die wurden vor einigen Wochen gepatched, aber der Hersteller hat es nicht mal für nötig gehalten, auf die behobene Schwachstelle hin zu weisen. Sollte man das für möglich halten? Und wer jetzt schreit "Hah, bestimmt Adobe, die melden ja öfter mal Schwachstellen nach", den muss ich enttäuschen. Es war nicht Adobe (was nicht ausschließt, dass die auch noch eine DNS-Leiche im Keller haben, Adobe traue ich eigentlich alles zu), sondern... Microsoft. Ja, genau, Microsoft, das Unternehmen, das in letzter Zeit eigentlich schon zu einem sicherheitsbewussten Musterknaben geworden war.

Microsoft patcht ...

Am April-Patchday hat Microsoft zwei DoS-Schwachstellen in Exchange und dem Windows SMTP Service behoben. Im Security Bulletin MS10-024 wird DNS-Poisoning bzw. -Spoofing nur in der FAQ erwähnt, und das auch nur indirekt:

"This update also includes a defense-in-depth change for Microsoft Exchange 2007 and Microsoft Exchange 2010 that adds additional source port entropy to DNS transactions initiated by the SMTP service."

... mehr Schwachstellen als sie zugeben

In der vorigen Woche wurde dann von Core Security ein Security Advisory veröffentlicht (Kopie auf der Mailingliste Full-Disclosure). Nicolás Economou hat bei der Untersuchung der behobenen DoS-Schwachstellen zwei weitere Schwachstellen entdeckt, die ebenfalls mit dem Updates zu MS10-024 behoben wurden. Die Schwachstellen werden weder im Bulletin erwähnt noch gab es CVE-IDs dafür (die wurden von Core Security inzwischen angefordert, vergeben wurden CVE-2010-1689 und CVE-2010-1690). Zum einen verwendete der Windows SMTP Service für DNS-Queries vorhersagbare Transaction-IDs, die wurden einfach nur inkrementiert. Hallo? Transaction-IDs hochzählen - schon mal was von Spoofing gehört? Dass man sowas nicht machen darf, war schon einige Jahre vor der Entdeckung der Design-Schwachstelle bekannt - wie kommt so eine uralte Schwachstelle in eine aktuelle Implementierung (schließlich ist auch Exchange 2010 betroffen)?

Und als wenn das nicht schon schlimm genug wäre, wurde das ID-Feld in der DNS-Response gar nicht mit dem ID-Feld der gesendeten DNS-Query verglichen (womit man sich die ID auch sparen könnte). Der Vergleich der ID aus der DNS-Response mit der ID aus der zugehörigen DNS-Query ist eigentlich eine Basisanforderung an einen DNS-Resolver, die außerdem in Punkt 9.1 von RFC 5452 zwingend verlangt wird. Wie will der Server sonst eigentlich zuverlässig erkennen, zu welcher Anfrage eine Antwort gehört? Nur anhand der zufällig gewählten Ports?

Im Endeffekt bedeutet das, dass ein Angreifer vor der Installation der Updates zum Bulletin MS10-024 aus der Beobachtung weniger DNS-Queries den Wert der künftigen Transaction-IDs bestimmen konnte, was für ein erfolgreiches Spoofen einer DNS-Response aber gar nicht nötig war, da die ID sowieso nicht geprüft wurde. Der Angreifer musste also nur den Source-Port der DNS-Query raten.

Keine behobene Schwachstelle, sondern "Defense-in-Depth"

Aus der "Report Timeline" des Core-Advisories geht hervor, dass Microsoft die Änderungen als "defense-in-depth change" betrachtet und nicht als Korrektur eine Schwachstelle, so dass auch keine CVE-ID notwendig sei. Natürlich ist es peinlich, wenn man so einen uralten Fehler in einem aktuellen Programm hat, vor allem nach der ganzen Aufregung 2008. Aber ist es nicht noch peinlicher, wenn einem dieser Fehler samt des Vertuschungsversuchs nun von einem unabhängigen Forscher unter die Nase gerieben wird?

Hätte Microsoft die Schwachstellen ganz normal als solche behoben, hätte es z.B. diesen Text gar nicht gegeben. Vielleicht hätte ich dann allgemein über alte Schwachstellen in neuen Programmen geschrieben, mit dem Rat "Gucken Sie doch mal, ob sie nicht auch noch irgend wo so einen alten Bug in ihren Programmen mit sich rumschleppen", aber ansonsten wäre das Thema doch ziemlich uninteressant, oder? Aber jetzt, mit dem Vertuschungsversuch, sieht die Sache natürlich ganz anders aus. Übrigens ist diese "Defense-in-Depth"-Argumentation sehr interessant. Damit lassen sich doch bestimmt noch mehr Schwachstellen wegmogeln. Wie wäre es mit einer Defense-in-Depth-Maßnahme, die einen Pufferüberlauf verhindert, statt eines Patches für eine Pufferüberlauf-Schwachstelle? Patches gegen DoS-Schwachstellen könnte man dann als Maßnahmen zur Stabilitätsverbesserung bezeichnen, und der Marketingabteilung fallen sicher auch für alle anderen Schwachstellen schöne Umschreibungen ein.

Gefährdung einschätzen, ohne genug zu wissen

Mal abgesehen davon, dass ich mich frage, welche uralten Schwachstellen denn in den Programmen und Systemen sonst noch so stecken und wie viele Schwachstellen denn üblicherweise pro Bulletin heimlich behoben werden, gibt es einen viel schwerwiegenderen Kritikpunkt: Microsoft stuft das Advisory als wichtig ein, es hat einen Exploitability- und Deployment-Index von 3, also besteht für die Admins kein Grund, die Updates schnell einzuspielen, schlimmstenfalls ist der Mailserver eben nach einem Angriff einige Zeit nicht erreichbar, bis er neu gestartet ist. Das ist kein größeres Problem, sowie es bemerkt wird, sorgt ein Neustart dafür, dass er wieder läuft, und Mails gehen dadurch wohl kaum verloren. Eine DNS-Poisoning-Schwachstelle ist dagegen deutlich schwerwiegender, denn damit lässt sich dem Server z.B. ein falscher Mailserver für eine Domain unterschieben, an die der dann alle Mails für diese Domain schickt.

"Wer einmal nicht die Wahrheit sagt ..."

Ach, und noch etwas: Wenn Microsoft im Bulletin

"The updates for Microsoft Exchange 2007 and Microsoft Exchange 2010 only include the defense-in-depth change that adds additional source port entropy to DNS transactions initiated by the SMTP service."

schreibt, in Wirklichkeit aber die Transaction-IDs zufällig erzeugt werden und ein Vergleich der Transaction-IDs von Response und Query eingeführt wird - wie genau nehmen die es dann bei den anderen Beschreibungen? Darf man den Angaben in Microsofts Security Bulletins dann überhaupt vertrauen?

Denen von Adobe vertraue ich schon lange nicht mehr, allerdings ist das ziemlich egal - ob im Reader nun 5, 10, 15 oder was weiß ich wie viele kritische Schwachstellen behoben werden, bei mir kommt das Programm sowieso nicht auf die Platte, und allen anderen rate ich grundsätzlich, sofort die Updates zu installieren, bevor sie ihren Rechern im Rahmen einer Drive-by-Infektion einem Botnet spenden. Aber bei Microsoft konnte man sich eigentlich auf die Informationen in den Security Bulletins verlassen und daraufhin entscheiden, welche Patches man zuerst installiert und welche warten können. Gilt das immer noch?