Stabsstelle Informationssicherheit der
Universität Stuttgart (RUS-CERT)
https://cert.uni-stuttgart.de 		logo
Meldung Nr: RUS-CERT-1476

[Generic/DNS] Schwachstelle im DNS-Protokoll vereinfacht cache poisoning (UPDATE)
(2008-07-08 17:06:50.469252+00)

Quelle: http://archive.cert.uni-stuttgart.de/bugtraq/2008/07/msg00055.html

Eine Entwurfsschwachstelle im DNS-Protokoll ermöglicht das sehr viel leichtere Implantieren beliebiger Daten in den Cache von DNS-Resolvern (sog. cache poisoning) als bisher gedacht. DNS-Resolver, die die sogenannte source port randomization implementieren, sind über diese Schwachstelle sehr viel schwieriger anzugreifen, weshalb deren Konfiguration dringend empfohlen wird. Für BIND 9 werden Patches bereitgestellt, die dies ermöglichen. Statische Firewalls, die solchermaßen umkonfigurierte Resolver schützen, müssen ebenfalls entsprechend umkonfiguriert werden. UPDATE: Mittlerweile sind Details zur Schwachstelle durchgesickert.

Inhalt

Betroffene Systeme

DNS-Resolver, die keine source port randomization durchführen. Dies sind z.B.

Nicht betroffene Systeme

Hinweis!
Die Schwachstelle ist in diesen Applikationen nicht behoben, bzw. nicht abwesend! Die Applikationen sind lediglich in der Lage, ohne zusätzlichen Patch source port randomization zu verwenden.

Einfallstor

Angriffsvoraussetzung

Angriffsvektorklasse

Auswirkung

Typ der Verwundbarkeit

Gefahrenpotential


(Hinweise zur Einstufung des Gefahrenpotentials.)

Kontext

DNS cache poisoning (z.T. auch "DNS cache pollution") ist eine seit den 1990er Jahren bekannte Angriffsmethode und wurde durch verschiedene Maßnahmen der Hersteller von DNS-Server- und -Resolversoftware erschwert, so dass sie Anfang des Jahrtausends außer Mode gekommen war. Der Aufwand im Vergleich zum Nutzen war einfach zu hoch geworden.

Eine der wichtigsten Maßnahmen der Hersteller war die Einführung einer 16 Bit langen Transaktionsnummer, die mittels eines Zufallszahlengenerators erzeugt wird. Um sie zu fälschen, bzw. zu erraten und über eine mit dieser Nummer versehenen gefälschten Antwort den Cache des Opfers zu manipulieren, benötigt ein Angreifer im statistischen Mittel 32.768 Versuche, sofern ein ordnungsgemäß arbeitender Zufallszahlengenerator verwendet wird. Dies ist in den meisten Angriffsszenarien zu aufwendig, bzw. leicht feststellbar, und in sofern unattraktiv als dass es z.B. für Phisher meist leichtere Möglichkeiten gibt, massenhaft Angriffe durchzuführen.

Allerdings ist der Angriff nicht undurchführbar und in speziellen Fällen sicherlich praktikabel. Das Protokoll weiterhin als unsicher anzusehen. Das Abflauen der Angriffstätigkeit hatte den negativen Effekt, dass die Hersteller und die Betreiber offenbar nicht den nötigen Druck verspürt haben, sichere Alternativen, etwa DNSSEC zu implemetieren.

Eine weitere Angriffsmethode ist das Senden nicht angefragter Ergebnisse in sogenannten resouce records (RRs). Wenn ein Resolver einen Name Server nach der IP Adresse eines DNS-Namens fragt, dann kann dieser neben den angefragten Daten im sogenannten (nach der Definition des Protokolls vollkommen zulässigen) glue record zusätzlich die Auflösungsdaten gar nicht angefragter Namen senden und sie so im Cache des anfragenden Resolvers platzieren. Diese Daten im glue record können natürlich nach Belieben des Name-Server-Betreibers gestaltet und selbstverständlich auch gefälscht sein. Die auslösende Anfrage des Opfers kann z.B. über eine Webseite erfolgen, die entsprechende Elemente enthält, die von einem Server der Domäne des angreifenden Name Servers stammen, etwa (unsichtbare) Bilder. Um diese durch einen URI mit DNS-Namen identifizierten Elemente laden zu können, muss der Browser bei seinem Resolver um die Auflösung des Namens bitten, der dann den Name Server fragt und sie von diesem zusammen mit den gefälschten Daten in den glue records erhält.

Um auch diese Methode zu erschweren, akzeptieren aktuelle Resolver-Implementierungen keine RRs mehr, die nicht in Zusammenhang mit ihrer ursprünglichen Anfrage stehen. Die resource records die in Zusammenhang mit der gestellten Anfrage stehen, werden als in-bailiwick records bezeichnet.

Beschreibung

Jüngste Untersuchungen haben eine Entwurfsschwachstelle im DNS-Protokoll (Domain Name System) offenbart, die das Implantieren beliebiger Daten in den Cache von DNS-Resolvern (sog. cache poisoning) sehr viel leichter ermöglicht, als bislang gedacht. Damit werden solche Angriffe wieder attraktiv, da sie wirtschaftlicher sind.

Das beschriebene Angriffsszenario beinhaltet die Kombination der oben beschriebenen Angriffsszenarien und ermöglicht das Platzieren eigener Daten im Cache eines angegriffenen Resolvers.

Wie oben erwähnt, ist es relativ leicht, einen Resolver dazu zu bringen, bestimmte Anfragen an einen Name Server zu senden. Das Erraten der Transaktionsnummer ist bei einzelnen Anfragen sehr schwierig und mit statistisch sehr geringer Erfolgsquote beschieden. Anders sieht es aus, wenn ein Opfer dazu gebracht wird, sehr viele Anfragen an einen Name Server zu stellen. Nach dem Geburtstagsparadoxon steigt die Wahrscheinlichkeit einen Treffer zu erhalten mit der Zahl der Anfragen drastisch. Ein Angriff, der diese Tatsache ausnutzt, wird als Geburtstagsangriff bezeichnet.

Soll beispielsweise der Cache mit einer falschen IP-Adresse für www.denwillichfaelschen.de gefüttert werden, so wird ein Benutzer des anzugreifenden Resolvers z.B. durch eine entsprechende Webseite dazu gebracht, sehr viele Anfragen an den Name Server der Domain denwillichfaelschen.de zu stellen. Diese haben jedoch nicht www.denwillichfaelschen.de zum Thema sondern z.B. aaaaa.denwillichfaelschen.de, aaaab.denwillichfaelschen.de, ... und so weiter. Dies kann z.B. durch das Platzieren tausender Ein-Pixel-Bilder in der Seite geschehen, die alle durch URIs referenziert werden, die diese (ausgedachten) Servernamen enthalten. Selbstverständlich kann der Angreifer auch selbst die Anfragen an den anzugreifendenden Resolver stellen und dabei z.B. gefälschte IP-Adressen als Absender verwenden.

Existiert der entsprechende DNS-Name nicht, antwortet der zuständige Name Server ns1.denwillichfaelschen.de mit der Fehlermeldung NXDOMAIN. Falls er existiert, wird die für den Angriff irrelevante IP-Adresse ebendieser Maschine zurückgeliefert (jedoch nicht der für www.denwillichfaelschen.de). Im Cache sind nun die Auflösungsdaten für diesen einen (ausgedachten) DNS-Namen enthalten, jedoch nicht für das eigentliche Ziel. Zufällige Treffer beenden den Angriff also nicht vorzeitig.

Der Angreifer wird jedesmal versuchen, dem Resolver seine eigene Antwort mit einer geratenen Transaktionsnummer unterzuschieben. Bei ausreichend vielen Anfragen, wird es dem Angreifer irgendwann gelingen, einen Treffer zu erzielen und die eigenen Daten in den Cache zu platzieren. Die dabei gelieferte Auflösung, z.B. für cxpny.denwillichfaelschen.de ist jedoch nebensächlich, im mitgelieferten glue record ist nämlich die gefälschte Auflösung für www.denwillichfaelschen.de enthalten. Da sie sich auf dieselbe Domain denwillichfaelschen.de bezieht, ist sie in-bailiwick und wird daher vom Resolver akzeptiert. Der Cache des angegriffenen Resolvers ist damit erfolgreich mit eigenen Daten beschickt.

In einer leichten Abwandlung des Angriffs kann dem angegriffenen Resolver auch der A record des autoritativen Name Servers der Domain denwillichfaelschen.de untergeschoben werden, so dass er in Zukunft gar nicht mehr auf die Idee kommt, den tatsächlich zuständigen Name Sever zu fragen, sondern einen beliebigen anderen, vom Angreifer gewählten. Hat er diesen unter Kontrolle (z.B. ein anderweitig geknacktes System) so kann er dem angegriffenen Resolver und den diesen benutzenden Clients jeden beliebigen DNS-Namen aus der Domain denwillichfaelschen.de mit einer von ihm gewählten IP-Adresse beantworten.

Insbesondere DNS-Resolver, die statisch den Port 53/udp verwenden, können leicht Ziel solcher Angriffe werden und liefern dann bei Anfragen von Clients die durch den Angreifer gewählten IP-Adressen für einen bestimmten DNS-Namen von Servern zurück, anstatt die korrekten. DNS cache poisoning ist das Dorado für Phisher (bzw. Pharmer), die so leicht z.B. Anfragen an Bank-Server auf die eigenen Server umleiten können, um Zugangs- und Transaktionsdaten abzufangen. Auch können zahlreiche andere Angriffstechniken dadurch unterstützt werden (s.u.).

Zur Abmilderung des Problems sollte in aktuellen Implementierungen die sog. source port randomization eingesetzt werden, die einen Angriff deutlich erschwert, jedoch nicht unmöglich macht. Sie erweitert den Raum der durch den Angreifer zu erratenden Daten -- bislang nur die Transaktionsnummer -- um den verwendeten Port (zwischen 1024 und 65535), so dass er statistisch runde 1 Milliarde Versuche benötigt um die Kombination aus Transaktionsnummer und Port zu erraten und erfolgreich DNS-Antworten zu fälschen, mit denen der Cache eines Resolvers manipuliert werden kann.

Wird für o.g. Angriffsszenario zum Erraten der Transaktionsnummer ein Geburtstagsangriff durchgeführt, fällt jedoch die Zahl der statistisch notwendigen Versuche signifikant auf ca. 320 (!) bei reiner Verwendung von Transaktionsnummern und runde 56.000 bei zusätzlicher Verwendung von source port randomization!

Die Einführung der source port randomization ist also zwingend notwendig, um wenigstens den Status Quo zu halten!

DNS-Resolver/Server, für die eine Firewall den Zugriff statisch auf Port 53/udp beschränkt, müssen entsprechend umkonfiguriert werden, um Anfragen auch weiterhin zuzulassen. Entweder müssen dabei alle Ports ab 1024/udp geöffnet werden oder es muß eine Firewall eingesetzt werden, die in der Lage ist, Zugriffe auf dynamisch verwendeten UDP-Ports nachzuvollziehen.

Anwendungen des Angriffs

Betroffen sind Resolvers. Diese führen für Clients die notwendige Übersetzung eines DNS-Namens in eine für einen Rechner verwendbare IP-Adresse durch. So wird z.B. beim Zugriff auf die Webseiten des RUS-CERT der DNS-Name cert.uni-stuttgart.de im URL http://cert.uni-stuttgart.de/ in die IP-Adresse 141.58.89.3 übersetzt, so dass der Browser (bzw. der beherbergende Rechner) die eigentliche Anfrage an http://141.58.89.3/ stellt.

Der Angriff erlaubt es, Resolvers so zu manipulieren, dass sie einen vom Angreifer gewählten DNS-Namen in eine vom Angreifer gewählte IP-Adresse übersetzen.

Die beschriebene Schwachstelle kann in verschiedenen Szenarien, die den größten Teil der Internetnutzung betreffen, ausgenutzt werden:

Neben den offensichtlichen Angriffsszenarien, wie dem Phishing, kann die Schwachstelle in zahlreichen komplexeren Angriffsszenarien eingesetzt werden, in denen z.B. die Unterdrückung oder das Umleiten von E-Mail erforderlich ist, oder Systeme durch die Installation von Malware kompromittiert werden sollen.

Workaround

Da die Schwachstelle das DNS-Protokoll selbst betrifft, ist sie mit Patches in der Resolver-Software nicht zu beheben, sondern nur für Angreifer schwieriger ausnutzbar zu machen. Im Folgenden werden mehrere Methoden vorgestellt, dies zu bewerkstelligen, die möglichst alle angewandt werden sollten, um die Sicherheit einer Installation zu erhöhen. Insbesondere die Verwendung vertrauenswürdiger Forwarders sollte in komplexeren Umgebungen vorgenommen werden, um die Angriffsfläche zu minimieren.
  1. Patches
    Ertüchtigung von Resolver-Installationen zur source port randomization.
    Sofern die Resolver-Software diese bereits beherrscht, sollte diese umgehend eingeschaltet werden, andernfalls sollte ein entsprechender Patch, bzw. ein entsprechendes Paket installiert werden:
    Um die source port randomization einzuschalten, bzw. zu überprüfen, ob sie eingeschaltet ist, muss in BIND 9-Installationen (praktisch alle, außer die unter Microsoft, die über die Systemsteuerung graphisch konfiguriert wird) die Konfigurationsdatei /etc/named.conf geöffnet und ggf. geändert werden.
    Dazu sind die folgenden Schritte durchzuführen:
    1. werden Sie zum administrativen Benutzer root: 
          $ su
    Password:
    #
      2. öffnen Sie die Konfigurationsdatei /etc/named.conf 
          # vim /etc/named.conf
    2. Suchen Sie die folgende Stelle 
          options {
    [...]
    # The next three statements may be needed if a firewall 
    # stands between the local server and the internet.

          query-source address * port 53;
    [...]
    }
      und ändern Sie sie wie folgt: 
          options {
    [...]
         query-source address * port *;
    [...]
    }
      Sofern möglich, d.h. sofern der Resolver innerhalb eines geschlossenen, durch eine Firewall vom Internet abgetrennten Netzes steht (wie dies z.B. an der Universität Stuttgart der der Fall ist), sollte in jedem Fall zusätzlich die Angriffsfläche reduziert werden, indem Forwarders konfiguriert werden
      In diesem Falle, ist hier fortzufahren.
      Sofern keine Forwarders eingesetzt werden können, muss mit den hier folgenden Schritten fortzufahren.
    3. Schreiben Sie die Datei und verlassen Sie den Editor mit dem Kommando :wq!
    4. Senden Sie dem Name Server bzw. Resolver ein HUP-Signal, das ihn veranlasst, seine Konfigurationsdatei neu zu lesen.
      Dies geschieht unter Linux mit dem killall-Befehl: 
          # killall -HUP named
      Während unter anderen Unix-Derivaten der kill-Befehl verwendet und dem als Argument die ProzessID des named-Prozesses übergeben werden muss: 
          # kill -HUP `ps -ef | grep named | awk -F \  '{print $2}'`
    5. Geben Sie die root-Privilegien wieder auf: 
          # exit
    $
  2. Verwendung von Forwarders
    DNS-Resolver, die nicht in der Lage sind, source port randomization einzusetzen, können innerhalb eines geschützten Netzwerkes weiterbetrieben werden, in dem sie so konfiguriert werden, dass sie alle Anfragen an einen Resolver innerhalb desselben geschützten Netzwerkes weitersenden, der in der Lage ist source port randomization einzusetzen.

    Diese Maßnahme sollte zusätzlich für alle gepatchten DNS-Resolver getroffen werden, die innerhalb eines geschlossenen Netzwerkes stehen und die Möglichkeit haben, einen oder mehrere zentrale Resolver als forwarder zu nutzen.

    Es bleibt jedoch festzuhalten, dass ein erfolgreicher Angriff auf den konfigurierten Forwarder sich ebenfalls auf ein diese Maßnahme implementierendes System auswirkt.

    Zur Konfiguration einer BIND-Installation sind hier die verschiedene Zeilen in der Datei /etc/named.conf zu ändern, bzw. einzufügen.

    1. werden Sie zum administrativen Benutzer root: 
          $ su
    Password:
    #
      2. öffnen Sie die Konfigurationsdatei /etc/named.conf 
          # vim /etc/named.conf
    2. fügen Sie ein, bzw. ändern Sie die folgenden Zeilen: 
          options {
    [...]
      forwarders { 1.2.3.4; 1.2.3.5; };
    [...]
    # Enable the next entry to prefer usage of the name server 
    # declared in the forwarders section.
      forward only;
    }
      wobei in diesem Beispiel die IP-Adressen 1.2.3.4 und 1.2.3.5 die Adressen der Resolver sind, die die tatsächlichen Anfragen an fremde Name Server versenden und die Ergebnisse an die anfragenden Resolver zurücksenden. Sie agieren quasi als Proxies und müssen natürlich durch die tatsächlich in einer konkreten Umgebung vorhandenenen IP-Adressen ersetzt werden. Natürlich kann hier eine beliebige Anzahl von IP-Adressen von Forwarders eingetragen werden.

      Innerhalb des Netzes der Universität Stuttgart sind dies z.B. die zwei zentralen DNS-Server/Resolver:

      • 129.69.1.28 (artemis.rus.uni-stuttgart.de)
      • 141.58.231.9 (skylla.rus.uni-stuttgart.de)
      sodass die entsprechenden Zeile für Systeme innerhalb der Netze der Universität Stuttgart wie folgt aussehen sollten: 
          options {
    [...]
      forwarders { 129.69.1.28; 141.58.231.9; };
    [...]
    # Enable the next entry to prefer usage of the name server declared in
    # the forwarders section.
      forward only;
    [...]
    }

    3. Schreiben Sie die Datei und verlassen Sie den Editor mit dem Kommando :wq!
    4. Senden Sie dem Name Server bzw. Resolver ein HUP-Signal, das ihn veranlasst, seine Konfigurationsdatei neu zu lesen.
      Dies geschieht unter Linux mit dem killall-Befehl: 
          # killall -HUP named
      Während unter anderen Unix-Derivaten der kill-Befehl verwendet und dem als Argument die ProzessID des named-Prozesses übergeben werden muss: 
          # kill -HUP `ps -ef | grep named | awk -F \  '{print $2}'`
    5. Geben Sie die root-Privilegien wieder auf: 
          # exit
    $

    Eventuell noch aktive DNS-Resolver-Freischaltungen sollten nun deaktiviert werden. Wenden Sie sich dazu bitte an die Stabsstelle DV-Sicherheit (RUS-CERT) der Universität Stuttgart.

    Es bleibt festzustellen, dass innerhalb der Netze der Universität Stuttgart weiterhin Angriffe auf verwundbare DNS-Resolver möglich sind. Alternativ können die Clients selbst so konfiguriert werden, dass sie ihre Anfragen an diese beiden Resolver senden.

Hinweis: Dieser Workaround behebt das Problem nicht, sondern erschwert nur dessen Ausnutzung. Weiterhin ist zu beachten, dass Resolver, die mit einer Firewall geschützt sind, die statisch den Port 53/udp geöffnet hält, nicht mit source port randomization weiterbetrieben werden können. Entweder muss die Firwall alle Ports zwischen 1024/udp und 65535/udp freigeben (was natürlich mit einem erheblichen Sicherheitsverlust verbunden ist) oder sie muss in der Lage sein, dynamisch vewendete Ports zu erkennen und mit den entsprechenden Antworten zu korrellieren.

Gegenmaßnahmen

Die einzig wirksame Gegenmaßnahme ist der Einsatz von Für einen flächendeckenden Einsatz ist jedoch die erforderliche Infrastruktur noch nicht etabliert.

Angriffssignaturen und Detektion

Das beschriebene Angriffsszenario eröffnet Detektionsmöglichkeiten für Angriffsversuche. Angriffe werden mit hoher Wahrscheinlichkeit viele NXDOMAIN Fehlermeldung provozieren, auf die der Netzverkehr überwacht werden sollte. Sofern die Resolver innerhalb einer Infrastruktur bekannt sind, kann die Überwachung ggf. auf diese eingeschränkt werden.

Nutzer von Resolvern, die kein DNSSEC verwenden (in Deutschland der größte Teil der Infrastruktur) können Opfer von Angriffen auf diese Resolver werden. Sie können bei Zugriff auf Server über DNS-Namen, z.B. auf Webseiten (etwa Seiten zum Online-Banking) über Webbrowser, auf andere durch den Angreifer kontrollierte IP-Adressen umgeleitet werden.

In diesem Zusammenhang sollte insbesondere auf Fehlermeldungen des Browsers bei Problemen mit Zertifikaten dieser Seiten geachtet werden und ggf. ein Fortsetzen des Zugriffs unterbleiben. Insbesondere sollten keinerlei Zugriffsdaten an Server gesandt werden, bei denen solche Probleme auftreten.

Vulnerability ID

Weitere Information zu diesem Thema

Exploit Status

Revisionen dieser Meldung

(og)

Weitere Artikel zu diesem Thema:

Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der Universität Stuttgart recherchiert und zusammengestellt. Die Universität Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel darf ausschließlich in unveränderter Form und nur zusammen mit diesem Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine Veröffentlichung unter diesen Bedingungen an anderer Stelle ist ausdrücklich gestattet.

Copyright © 2022 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/

https://cert.uni-stuttgart.de/ticker/article.php?mid=1476