DNS-Sicherheit bröckelt

An der Sicherheitskonferenz Blackhat erläuterte Sicherheitsspezialist Dan Kaminsky erstmals das von ihm entdeckte Sicherheitsproblem des Domain Name System (DNS). Bekannt ist das Problem seit Juli, als CERTs und die Hersteller von DNS-Software wie ISC (Bind), Microsoft oder Cisco in einer koordinierten Aktion Advisories und Patches für ihre Produkte veröffentlichten. Wie sich nun zeigt, ist es Kaminsky gelungen, bekannte «Konstruktionsfehler» des DNS in einer neuen Weise auszunutzen.


Normalerweise wird mit 16-bittigen, zufälligen Transaktions-IDs verhindert, dass Angreifer einem DNS-Resolver mittels Spoofing falsche Antworten unterjubeln können. In Kombination mit Caching der gültigen Antworten führt dies dazu, dass eine erfolgreiche Cache-Poison­ing-Attacke Jahre dauert. Nun
hat Kaminsky aber herausgefunden, dass sich mit Anfragen für nicht existerende Domains wie aaaa.example.com, aaab.example.com und so weiter das Caching aushebeln und innerhalb von Sekunden eine Transaktions-ID erraten lässt. Mittels Additional Ressource Records können dem Resolver dann falsche IP-Adressen für einzelne Domains oder gleich andere Nameserver für komplette Zonen wie example.com untergeschoben werden. Die Folgen sind fatal: Es lassen sich nicht nur die Nutzer eines Resolvers unbemerkt auf andere Webseiten umleiten. Auch könnten E-Mails abgefangen oder Auto-Update-Mechanismen zum Verteilen von Schadcode missbraucht werden.

Da das Angriffsszenario auf den Prinzipien des DNS aufbaut, ist es schwierig, Gegenmittel zu ent­wickeln. Momentan beschränken sich die Hersteller auf Source Port Randomization. Dabei wird jede Anfrage von einem anderen Port aus gestartet und erwartet, dass die Antwort auf demselben Port eintrifft. Dies bringt aber maximal weitere 16 Bits an Zufall, sodass eine ID in Stunden oder Tagen erraten werden kann.


Eine definitive Lösung ist nicht abzusehen, da Massnahmen wie DNSSEC technisch wie politisch umstritten und nicht über Nacht einzuführen sind. Bis dahin bleibt einem nur, Patches einzuspielen und die Resolver zu überwachen. Dies gilt auch für private Netze hinter Firewalls, die laut Kaminsky nicht immun sind. Wie ein Resolver auf Patch-Bedarf überprüft werden kann, erklärt www.dns-oarc.net/oarc/services/porttest.