Sie sind hier: Home » Aktuelle Meldungen » Meldung
Meldung Nr: RUS-CERT-1476

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

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.
  • ISC:
    • BIND 9 ohne entsprechende Patches
    • BIND 8
    • alle früheren Versionen
    siehe: ISC: CERT VU#800113 DNS Cache Poisoning Issue
  • Debian GNU/Linux:
    siehe: [SECURITY] [DSA 1603-1] New bind9 packages fix cache poisoning
  • GNU libc stub resolver
  • Ubuntu:
    • Ubuntu 6.06 LTS
    • Ubuntu 7.04
    • Ubuntu 7.10
    • Ubuntu 8.04 LTS
    • alle früheren Versionen
  • OpenSUSE:
    • openSUSE 10.2
    • openSUSE 10.3
    • openSUSE 11.0
    • SUSE SLES 9
    • Novell Linux Desktop 9
    • Open Enterprise Server
    • Novell Linux POS 9
    • SUSE Linux Enterprise Desktop 10 SP1
    • SLE SDK 10 SP1
    • SLE SDK 10 SP2
    • SUSE Linux Enterprise Server 10 SP1
    • SUSE Linux Enterprise Desktop 10 SP2
    • SUSE Linux Enterprise Server 10 SP2
    • alle früheren Versionen
    siehe: [security-announce] SUSE Security Announcement: bind (SUSE-SA:2008:033)
  • Mandriva:
    • Mandriva Linux 2007.1
    • Mandriva Linux 2007.1/X86_64
    • Mandriva Linux 2008.0
    • Mandriva Linux 2008.0/X86_64
    • Mandriva Linux 2008.1
    • Mandriva Linux 2008.1/X86_64
    • Corporate 3.0
    • Corporate 3.0/X86_64
    • Corporate 4.0
    • Corporate 4.0/X86_64
    • Multi Network Firewall 2.0
    • alle früheren Versionen
    siehe [ MDVSA-2008:139 ] - Updated BIND packages fix critical DNS vulnerability
  • FreeBSD:
    • FreeBSD 6
    • FreeBSD 6.3
    • FreeBSD 7.0
    • alle früheren Versionen
    siehe: FreeBSD Security Advisory FreeBSD-SA-08:06.bind
  • Cisco Inc.:
    siehe Cisco Document ID: 107064
  • Juniper Network, Inc.:
    • Firewalls unter ScreenOS
    • J-series Routers unter JUNOS Enhanced Services Software (junos-jsr) der Versionen vor 2008-05-23
    • Juniper Switches unter JUNOS Enhanced Switching Software (junos-ex) der Versionen vor 2008-05-23
  • SUN Microsystems, Inc.:
    • Solaris 8 BIND 8.2.4
    • Solaris 9 BIND 8.3.3
    • Solaris 10 BIND 9.3.4-P1
    • alle früheren Versionen
  • Apple
    • Mac OS X v10.4.11
    • Mac OS X Server v10.4.11
    • Mac OS X v10.5.4
    • Mac OS X Server v10.5.4
    • alle früheren Versionen
  • Microsoft:
    • DNS-Client unter Microsoft Windows 2000 SP4
    • DNS-Server unter Microsoft Windows 2000 SP4
    • DNS-Client unter Windows XP SP2 und Windows XP SP3
    • DNS-Client unter Windows XP Professional x64 Edition und Windows XP Professional x64 Edition SP2
    • DNS-Client unter Windows Server 2003 SP1 und Windows Server 2003 SP2
    • DNS-Server unter Windows Server 2003 SP1 und Windows Server 2003 SP2
    • DNS-Client unter Windows Server 2003 x64 Edition und Windows Server 2003 x64 Edition SP2
    • DNS-Server unter Windows Server 2003 x64 Edition und Windows Server 2003 x64 Edition SP2
    • DNS-Client unter Windows Server 2003 SP1 für Itanium-basierte Systeme und Windows Server 2003 SP2 für Itanium-basierte Systeme
    • DNS-Server unter Windows Server 2003 SP1 für Itanium-basierte Systeme und Windows Server 2003 SP2 für Itanium-basierte Systeme
    • DNS-Server unter Windows Server 2008 für 32-Bit-Systeme
    • DNS-Server unter Windows Server 2008 für x64-basierte Systeme
    siehe RUS-CERT#1477: [Microsoft/Windows] Microsoft stellt Patches für insgesamt neun Schwachstellen bereit
  • ...

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.
  • PowerDNS, sofern source port randomization aktiviert ist
  • MaraDNS, sofern source port randomization aktiviert ist
  • Unbound, sofern source port randomization aktiviert ist
  • ..., sofern source port randomization aktiviert ist

Einfallstor

  • DNS-Transaction

Angriffsvoraussetzung

  • Möglichkeit, einem entsprechenden Resolver eine entsprechende Transaktion zu schicken
    (network)

Angriffsvektorklasse

  • über eine Netzwerkverbindung
    (remote)

Auswirkung

Typ der Verwundbarkeit

  • Designfehler im DNS-Protokoll
    (design flaw)

Gefahrenpotential

  • hoch bis sehr hoch

(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:

  • Umleiten beliebiger Webseiten auf vom Angreifer gewählte Seiten
    Dies ist inbesondere im Rahmen des Phishings bzw. Pharmings interessant, da der Angreifer das Opfer nicht dazu bringen muss, einen gefälschtem URL, der etwa in einer entsprechenden E-Mail-Nachricht enthalten ist, zu öffnen. Sobald das Opfer den gewünschten DNS-Namen öffnet, egal ob manuell eingegeben oder in den Bookmarks angeklickt, wird des zum Server des Angreifers umgeleitet. Ein direkter Angriff oder eine Interaktion mit dem Opfer ist nicht erforderlich, er erfolgt vollkommen unbemerkt, da stets der korrekte URL verwendet wird. Besonders interessante Ziele hierbei sind:
    • Online-Banking-Seiten
    • Online-Auktionshäuser, wie z.B. Ebay
    • Generell Server, auf denen für Angreifer interessante Benutzerdaten eingegeben werden
    • ...
    Im Rahmen dieser Ausnutzung der Schwachstelle kann der Angreifer z.B. Authentifizierungsdaten für Benutzerkonten, PINs, TANs usw. stehlen.
  • Umleiten von Servern, die Software bereitstellen
    Der Angreifer kann die Zugriffe auf diese Systeme umleiten und so ggf. die Installation von Malware auf den betroffenen Systemen initiieren, wenn keine weiteren Maßnahmen zur Absicherung implementiert wurden.
  • Umleiten von Updateservern, die zur Bereitstellung von Patches und Updates genutzt werden auf vom Angreifer kontrollierte Systeme
    Viele Betriebssystem- und Applikationshersteller verwenden Update-Server zur Bereitstellung von sicherheitsrelevanten Patches bzw. Updates. Der Angreifer kann die Zugriffe auf diese Systeme umleiten und so ggf. die Installation von Malware auf den betroffenen Systemen initiieren, wenn keine weiteren Maßnahmen zur Absicherung implementiert wurden.
  • Umleiten von Mail
    Durch das Unterschieben von MX Records können Mailserver dazu veranlasst werden, Nachrichten an eine bestimmte Domain an einen Mailserver zu senden, der unter der Kontrolle des Angreifers steht. So können z.B. alle Nachrichten. die von einem so angegriffenen Mailserver etwa an Mail-Adressen der Domain @denwillichfaelschen.de an einen Server der Wahl den Angreifers geleitet werden und erreichen nie ihr eigentliches Ziel oder erst, nachdem sie kopiert wurden.
  • Unterdrückung von Netzwerkverkehr, der auf DNS basiert (HTTP, SMTP, FTP,...), an eine Domain (denial of service)
    Durch das Ausnutzen der Schwachstelle kann der Angreifer auch sämtlichen Verkehr an die angegriffene Domain an einen Server senden, der schlicht nicht antwortet.
  • Umleiten von Netzverkehr an Systeme zum Zwecke der Überlastung (denial of service)
    Die Ausnutzung der Schwachstelle kann auch dazu ausgenutzt werden, beliebigen Netzverkehr besonders vieler Systeme an ein bestimmtes Ziel umzuleiten und es so durch Überlastung außer Gefecht zu setzen.
  • ...
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
          
    3. 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.
    4. Schreiben Sie die Datei und verlassen Sie den Editor mit dem Kommando :wq!
    5. 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}'`
          
    6. 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
          
    3. 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;
          [...]
          }
          

    4. Schreiben Sie die Datei und verlassen Sie den Editor mit dem Kommando :wq!
    5. 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}'`
          
    6. 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

  • Exploit Code, der die Schwachstelle ausnutzt und demonstriert wurde auf der Mailingliste Bugtraq veröffentlicht.
    (proof of concept)

Revisionen dieser Meldung

  • V 1.0 (2008-07-08)
  • V 1.1 (2008-07-08)
  • V 1.2 (2008-07-09)
  • V 1.3 (2008-07-11)
    • Liste der Patches in "Workaround" ergänzt.
    • Beschreibung für die Konfiguration einer BIND-Installation in der Sektion Workaround eingefügt.
  • V 1.4 (2008-07-15)
  • V 1.5 (2008-07-22)
  • V 1.6 (2008-07-24)
  • V 1.7 (2008-07-28)
  • V 1.8 (2008-08-01)
    • Liste der Patches in "Workaround" erweitert (Apple Mac OS X, Patches sind nun verfügbar).
  • V 1.9 (2008-08-09)
    • Konfigurationsanweisungen in "Workaround" überarbeitet
(og)

Weitere Artikel zu diesem Thema:

  • [MS/Windows] Microsoft stellt Patches für insgesamt neun Schwachstellen bereit (2008-07-08)
    Microsoft stellt im Rahmen seines Security Bulletin Summary for June 2008 Patches bzw. Updates zur Behebung von insgesamt neun Schwachstellen bereit. Die Schwachstellen betreffen die Betriebssystme Windows 2000, Windows XP, Server 2003, Vista und Server 2008, die Microsoft SQL Server 2000 Desktop Engine, die Windows Internal Database sowie den Exchange Server 2003 und 2007 und ermöglichen die Erweiterung der Privilegien unprivilegierter Benutzer, DNS cache poisoning sowie die Ausführung beliebigen Programmcodes auf dem beherbergenden Rechnersystem. Es wird dringend empfohlen, die Updates zu installieren.

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 © 2014 RUS-CERT, Universität Stuttgart, http://cert.uni-stuttgart.de/

Vorherige Meldung Weitere Meldungen... Nächste Meldung

Bitte lesen Sie auch die Grundsätze, nach denen das RUS-CERT Tickermeldungen veröffentlicht. Der regelmäßige Bezug von Tickermeldungen über E-Mail und RSS-Feed ist ebenfalls möglich.