{"data":{"case":{"actions":{"de":["Betreibe eine DNS-Server-Version, die noch Updates bekommt: Seit den Fixes vom Juli 2008 wählen Resolver für jede Anfrage einen **zufälligen Quellport**.","Entferne feste Ports aus der Konfiguration des Resolvers, etwa eine Portnummer in der BIND-Option `query-source`: Ein fester Port schaltet die Zufallswahl ab.","Prüfe NAT-Router und Firewalls vor dem Resolver: Manche ersetzen die zufälligen Quellports durch vorhersagbare.","Lass deinen Resolver rekursive Anfragen nur aus deinem eigenen Netz beantworten. Schalte die **DNSSEC-Validierung** ein, die ISC die einzige endgültige Lösung nennt."],"en":["Run a DNS server version that still gets updates: since the fixes of July 2008, resolvers choose a **random source port** for every query.","Remove fixed ports from the resolver's configuration, such as a port number in BIND's `query-source` option: a fixed port switches the random choice off.","Check NAT routers and firewalls in front of the resolver: some replace the random source ports with predictable ones.","Let your resolver answer recursive queries only from your own network. Switch on **DNSSEC validation**, which ISC calls the only definitive solution."]},"criteria":{"damage":{"de":"Keine Quelle nennt eine Zahl zum Schaden. Weder Ausfälle kritischer Dienste noch große Datendiebstähle sind belegt.","en":"No source gives a figure for the damage, and no outage of critical services or large data theft is documented.","met":false},"exploitation":{"de":"Angriffscode war ab dem 23. Juli 2008 öffentlich. Im August 2008 fanden Forscher auf offenen Resolvern vergiftete Antworten für Domains von Banken und Websites, konnten sie dieser Lücke aber nicht zuordnen. Die Quellen belegen keine Massenangriffe (DNS-OARC; Recursive DNS Architectures and Vulnerability Implications, NDSS 2009).","en":"Attack code was public from July 23, 2008. In August 2008, researchers found poisoned answers for bank and web domains on open resolvers, but could not tie them to this flaw. The sources document no mass attacks (DNS-OARC; Recursive DNS Architectures and Vulnerability Implications, NDSS 2009).","met":false},"reach":{"de":"Fast alle DNS-Server im Internet waren verwundbar (CERT.at). Noch Monate nach den Fixes schickten etwa 57 % der 0,9 Millionen getesteten offenen Resolver jede Anfrage vom selben Port ab (Recursive DNS Architectures and Vulnerability Implications, NDSS 2009).","en":"Almost all DNS servers on the internet were vulnerable (CERT.at). Months after the fixes, about 57 % of 0.9 million open resolvers probed still sent every query from the same port (Recursive DNS Architectures and Vulnerability Implications, NDSS 2009).","met":true},"response":{"de":"Auf Betreiben von CERT/CC veröffentlichten fast alle Hersteller von DNS-Software ihre Fixes am selben Tag, dem 8. Juli 2008. Das österreichische CERT nannte das nahezu beispiellos. Später verwies die US-Regierung auf die Lücke, als sie um Stellungnahmen zur Signierung der DNS-Root-Zone mit DNSSEC bat (CERT/CC; CERT.at; NTIA).","en":"CERT/CC arranged for almost all makers of DNS software to publish fixes on the same day, July 8, 2008. The Austrian CERT called this almost unprecedented. The US government later cited the flaw when it asked for comments on signing the DNS root zone with DNSSEC (CERT/CC; CERT.at; NTIA).","met":true}},"cves":["CVE-2008-1447"],"cvss":6.8,"cvss_version":"3.1","cwe":"CWE-331","dates":[{"date":"2008-03-31","de":"Hersteller von DNS-Software treffen sich bei Microsoft, um die Lücke und ihren Fix zu besprechen","en":"Makers of DNS software meet at Microsoft to discuss the flaw and its fix"},{"date":"2008-07-08","key":"disclosed"},{"date":"2008-07-08","key":"patched"},{"date":"2008-07-21","de":"Details des Angriffs sickern vor dem geplanten Vortrag durch","en":"Details of the attack leak before the planned talk"},{"date":"2008-07-23","de":"Funktionierender Angriffscode wird veröffentlicht","en":"Working attack code is published"},{"date":"2008-07-30","de":"Berichte über einen vergifteten DNS-Server beim Provider AT\u0026T in Texas","en":"Reports of a poisoned DNS server at the provider AT\u0026T in Texas"},{"date":"2008-10-09","de":"Die US-Regierung bittet um Stellungnahmen zur Signierung der DNS-Root-Zone mit DNSSEC und verweist auf die Lücke","en":"The US government asks for comments on signing the DNS root zone with DNSSEC and cites the flaw"},{"date":"2010-07-15","de":"Resolver können jetzt die mit DNSSEC signierte Root-Zone prüfen","en":"Resolvers can now check the DNSSEC-signed root zone"}],"de":{"credit":"Dan Kaminsky, Sicherheitsforscher bei IOActive","fixed":"Abgestimmte Updates am 8. Juli 2008, darunter Microsoft MS08-037 und neue BIND-Versionen von ISC; Apple folgte am 31. Juli 2008","product":"DNS-Resolver wie BIND und Windows DNS, die für Nutzer Internetadressen nachschlagen","summary":"Eine Schwachstelle im DNS ließ Angreifer binnen Sekunden falsche Adressen für jede beliebige Domain in den Cache eines Resolvers schleusen. So konnten sie die Nutzer des Resolvers auf Server ihrer Wahl umleiten."},"disclosed":"2008-07-08","en":{"credit":"Dan Kaminsky, security researcher at IOActive","fixed":"Coordinated updates on July 8, 2008, among them Microsoft MS08-037 and new BIND versions from ISC; Apple followed on July 31, 2008","product":"DNS resolvers such as BIND and Windows DNS, which look up internet addresses for users","summary":"A weakness in the DNS let attackers plant false addresses for any domain in a resolver's cache within seconds. They could then send the resolver's users to servers of their choice."},"figures":[{"de":"der 0,9 Millionen getesteten offenen Resolver schickten Monate nach den Fixes noch jede Anfrage vom selben Port ab","en":"of 0.9 million open resolvers still sent every query from the same port months after the fixes","value":"57 %"},{"de":"Herstellern in der Liste von CERT/CC waren betroffen, von Microsoft bis zu Linux-Distributionen","en":"vendors listed by CERT/CC were affected, from Microsoft to Linux distributions","value":"37 of 91","value_de":"37 von 91"},{"de":"mögliche Abfrage-IDs waren vor dem Fix alles, was ein Angreifer erraten musste","en":"possible query IDs were all an attacker had to guess before the fix","value":"65,536"}],"key":"kaminsky-dns","name":"Kaminsky DNS","product":"DNS resolvers","sources":[{"de":"CERT/CC-Schwachstellenhinweis VU#800113","title":"CERT/CC vulnerability note VU#800113","url":"https://www.kb.cert.org/vuls/id/800113"},{"de":"US-CERT-Warnung TA08-190B vom 8. Juli 2008 (Archiv der Mailingliste)","title":"US-CERT alert TA08-190B of July 8, 2008 (mailing list archive)","url":"https://seclists.org/cert/2008/22"},{"de":"Microsoft-Sicherheitsbulletin MS08-037","title":"Microsoft security bulletin MS08-037","url":"https://learn.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-037"},{"de":"ISC: Sicherheitshinweis zu CVE-2008-1447 für BIND","title":"ISC: advisory on CVE-2008-1447 for BIND","url":"https://kb.isc.org/docs/aa-00924"},{"de":"FreeBSD-Sicherheitshinweis FreeBSD-SA-08:06.bind","title":"FreeBSD security advisory FreeBSD-SA-08:06.bind","url":"https://www.freebsd.org/security/advisories/FreeBSD-SA-08:06.bind.asc"},{"de":"Apple: Security Update 2008-005 vom 31. Juli 2008, mit dem Fix für BIND","title":"Apple: Security Update 2008-005 of July 31, 2008, with the BIND fix","url":"https://support.apple.com/en-us/104050"},{"de":"NVD: CVE-2008-1447","title":"NVD: CVE-2008-1447","url":"https://nvd.nist.gov/vuln/detail/CVE-2008-1447"},{"de":"CERT.at: Patching Nameservers, Austria reacts to VU#800113 (24. Juli 2008, mit Update vom 28. Juli)","title":"CERT.at: Patching Nameservers, Austria reacts to VU#800113 (July 24, 2008, with an update of July 28)","url":"https://www.cert.at/en/downloads/papers/papers-0802"},{"de":"Recursive DNS Architectures and Vulnerability Implications, NDSS 2009 (PDF)","title":"Recursive DNS Architectures and Vulnerability Implications, NDSS 2009 (PDF)","url":"https://astrolavos.gatech.edu/articles/recursive_dns_architectures.pdf"},{"de":"The Measurement Factory: DNS-Erhebung vom Oktober 2008 im Auftrag von Infoblox","title":"The Measurement Factory: DNS survey of October 2008, commissioned by Infoblox","url":"http://dns.measurement-factory.com/surveys/200810.html"},{"de":"DNS-OARC: Informationen zu VU#800113, mit Zeitleiste","title":"DNS-OARC: information on VU#800113, with a timeline","url":"https://dns-oarc.net/node/107"},{"de":"SANS Internet Storm Center: Update zum DNS-Cache-Poisoning vom 30. Juli 2008","title":"SANS Internet Storm Center: DNS cache poisoning issue update of July 30, 2008","url":"https://isc.sans.edu/diary/4801"},{"de":"InfoWorld (Presse): der vergiftete DNS-Server von AT\u0026T in Texas","title":"InfoWorld (press): the poisoned AT\u0026T DNS server in Texas","url":"https://www.infoworld.com/article/2172504/dns-attack-writer-a-victim-of-his-own-creation-2.html"},{"de":"NTIA: Konsultation zu DNSSEC für die Root-Zone, Federal Register, 9. Oktober 2008","title":"NTIA: notice of inquiry on DNSSEC for the root zone, Federal Register, October 9, 2008","url":"https://www.govinfo.gov/content/pkg/FR-2008-10-09/html/E8-23974.htm"},{"de":"IANA: Statusmeldungen zur Signierung der Root-Zone (2010)","title":"IANA: status updates on signing the root zone (2010)","url":"https://www.iana.org/archive/root-dnssec-launch/launch-status-updates"}],"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N","year":2008}},"description":"Im Juli 2008 ließ eine DNS-Lücke Angreifer in Sekunden falsche Adressen für jede Domain einschleusen. Wie das ging und wie sie an einem Tag geschlossen wurde.","language":"de","latest_measurement":"2026-11-01","method":"latency-v3","method_page":"https://crackthe.net/de/daten/methode/","source":"https://crackthe.net/","text":"Am 8. Juli 2008 veröffentlichten Hersteller von DNS-Software in aller Welt am selben Tag Fixes für eine Sicherheitslücke. Entdeckt hatte sie der Sicherheitsforscher Dan Kaminsky. Das DNS, das Domain Name System, ist das Adressbuch des Internets. Es übersetzt Namen wie example.com in die numerischen Adressen, die Computer nutzen. Durch die Lücke konnten Angreifer falsche Adressen für jede beliebige Domain im Speicher der Server ablegen, die diese Namen für Nutzer nachschlagen. Laut CERT.at, dem nationalen Computer-Notfallteam Österreichs, waren fast alle DNS-Server im Internet verwundbar.\nSo funktionierte der Angriff Wenn du eine Website öffnest, fragt dein Gerät einen Resolver nach der Adresse. Ein Resolver ist ein DNS-Server, der für Nutzer Namen nachschlägt; meist betreibt ihn dein Internetanbieter oder deine Firma. Er fragt die Nameserver, die für die Domain zuständig sind. Ihre Antwort hebt er eine Weile in seinem Cache auf, einem Zwischenspeicher. So kann er dem nächsten Nutzer sofort antworten. Wer eine gefälschte Antwort in diesen Cache einschleust, schickt jeden Nutzer des Resolvers zum falschen Server. Das nennt man Cache-Poisoning, die Vergiftung des Zwischenspeichers.\nEin Resolver nahm eine Antwort an, wenn sie zu seiner Anfrage passte, vor allem über eine Abfrage-ID, eine Zahl zwischen 0 und 65.535. Die meisten Resolver schickten alle Anfragen vom selben Netzwerkport ab. Damit war diese Zahl das einzige Geheimnis, das ein Angreifer erraten musste: Jede gefälschte Antwort traf mit einer Wahrscheinlichkeit von 1 zu 65.536. Trotzdem war das Vergiften schwierig, denn die echte Antwort kam meist nach etwa 100 Millisekunden an. Lag sie erst im Cache, musste der Angreifer warten, bis sie ablief, oft tagelang.\nKaminskys Idee machte das Warten überflüssig. Der Angreifer lässt den Resolver Namen nachschlagen, die es nicht gibt, etwa random1.example.com, dann random2.example.com und so weiter. Solche Namen liegen nie im Cache, also ist jeder eine neue Chance. Die gefälschten Antworten enthalten einen zusätzlichen Eintrag. Er behauptet, ein Server des Angreifers sei jetzt der Nameserver für ganz example.com. Sobald ein Rateversuch trifft, speichert der Resolver diese Angabe und fragt von da an den Angreifer nach jedem Namen der Domain. Laut einer Studie, die 2009 auf der Sicherheitskonferenz NDSS vorgestellt wurde, verkürzte die Technik die Dauer eines Angriffs von Wochen auf Sekunden.\nAngreiferlässt den Resolver einen zufälligen Namen nachschlagen, den es nicht gibt Gefälschte Antwortenkonkurrieren mit der echten, jede mit einer geratenen Abfrage-ID Ein Trefferder Resolver nimmt die gefälschte Antwort an Cachenennt jetzt den Server des Angreifers als Nameserver der ganzen Domain Nutzerlanden auf Servern nach Wahl des Angreifers Trifft die echte Antwort zuerst ein, fragt der Angreifer einfach nach dem nächsten zufälligen Namen. Das US-CERT, das Computer-Notfallteam der US-Regierung, warnte, dass sich so Webverkehr, E-Mails und andere wichtige Netzwerkdaten auf Systeme umleiten ließen, die der Angreifer kontrolliert.\nReichweite und Angriffe Die Schwachstelle lag im DNS-Protokoll selbst und nicht in einem einzelnen Produkt, schrieb ISC, der Hersteller der weit verbreiteten DNS-Software BIND. Das CERT/CC, die US-Koordinierungsstelle für Sicherheitslücken, führte 91 Hersteller auf; 37 davon waren betroffen, von Microsoft und Cisco bis zu Linux-Distributionen.\nCERT.at wird von der Registrierungsstelle für die österreichischen .at-Domains betrieben und hat gemessen, wie schnell die Resolver in Österreich gepatcht wurden. Ein gepatchter Resolver wechselt mit jeder Anfrage seinen Port. Das konnte CERT.at in den Logdateien eines Nameservers der Registrierungsstelle sehen. Vor den Fixes taten das nur etwa 15 % der Resolver. Zwei Wochen nach den Fixes waren 66 % der aktiven Resolver, also jener, die an fast jedem Tag auftauchten, noch immer ungepatcht:\nUngepatchte Resolver in Österreich, Juli 2008 Aktive Resolver, Daten bis 21. Juli66 % Aktive Resolver, Daten bis 27. Juli62 % Gewichtet nach Anfragen, bis 21. Juli50 % Gewichtet nach Anfragen, bis 27. Juli42 % Bei der Gewichtung nach Anfragen zählen Resolver, die viele Anfragen schicken, stärker als kleine. Quelle: CERT.at (2008).\nStudien zu Resolvern in aller Welt kamen zu unterschiedlichen Ergebnissen. Monate nach den Fixes testeten Forscher des Georgia Institute of Technology 0,9 Millionen offene Resolver, die Anfragen von jedem beantworten. Etwa 57 % schickten noch immer jede Anfrage vom selben Port ab. Eine Erhebung von The Measurement Factory im Auftrag des DNS-Herstellers Infoblox schätzte die Zahl der offenen Resolver im Oktober 2008 auf 4,3 Millionen. Bei 24 % der getesteten Resolver war die Zufallswahl der Ports unzureichend.\nWie 0,9 Millionen offene Resolver Monate nach den Fixes ihren Port wählten Immer derselbe Port57 % Ports in fester Reihenfolge2 % Kein Muster erkennbar, als gepatcht gezählt41 % Quelle: Recursive DNS Architectures and Vulnerability Implications (NDSS 2009).\nDie Einzelheiten des Angriffs sollten bis zu einem Vortrag auf der Sicherheitskonferenz Black Hat Anfang August geheim bleiben. Doch am 21. Juli sickerten sie durch. Am 23. Juli tauchte laut DNS-OARC, einem Verband von DNS-Betreibern, funktionierender Angriffscode auf. Eine Woche später berichtete die Presse, dass ein DNS-Server des Providers AT\u0026amp;T in Texas vergiftet worden war. Wer über ihn google.com aufrief, landete auf einer gefälschten Seite, die automatisch Werbung anklickte. Auch das SANS Internet Storm Center meldete den vergifteten Server. In den ersten beiden Augustwochen 2008 fanden die Forscher aus Georgia vergiftete Antworten für die Domains von Banken und großen Websites. Allein für die US-Bank Washington Mutual waren es 11.050. Ihre Zahl stieg, nachdem die Angriffswerkzeuge erschienen waren. Welche Technik die Angreifer genutzt hatten, konnten die Forscher aber nicht nachweisen. Keine Quelle beziffert den Schaden.\nDer Fix und die Reaktion Kaminsky hatte die Hersteller schon Monate vorher gewarnt. Am 31. März 2008 trafen sich Hersteller von DNS-Software bei Microsoft, um das Problem zu besprechen. Ihr gemeinsamer Fix heißt Source Port Randomization, die zufällige Wahl des Quellports. Ein gepatchter Resolver schickt jede Anfrage von einem zufällig gewählten Port ab und nimmt nur Antworten an, die genau an diesem Port ankommen. Laut CERT.at muss ein Angreifer dadurch bis zu 16 weitere Bits Zufall erraten. Nach dem Update von Microsoft etwa wählten Windows-DNS-Server ihre Ports aus 16.384 möglichen. Zusammen mit der Abfrage-ID ergibt das rund eine Milliarde Kombinationen statt 65.536. Neu war die Idee nicht. CERT/CC schreibt sie dem Entwickler von djbdns zu, einem Resolver, der schon vorher zufällige Ports wählte.\nAuf Betreiben von CERT/CC veröffentlichten fast alle Hersteller ihre Fixes am selben Tag, dem 8. Juli 2008. Darunter waren Microsoft mit dem Update MS08-037 und ISC mit neuen BIND-Versionen. CERT.at nannte diese Abstimmung nahezu beispiellos. Apple folgte am 31. Juli mit einem Update für den BIND-Server, der in Mac OS X steckt. CERT/CC warnte außerdem: Router und Firewalls, die Adressen und Ports umschreiben, könnten den Schutz wieder zunichtemachen.\nZufällige Ports legen die Latte nur höher. Mit DNSSEC, den Sicherheitserweiterungen des DNS, können Resolver digitale Signaturen auf Antworten prüfen. Ohne solche Änderungen am Protokoll können die Fixes „Cache-Poisoning nicht vollständig verhindern“, schrieb CERT/CC. ISC nannte DNSSEC „die einzige endgültige Lösung“. Im Oktober 2008 bat das US-Handelsministerium um Stellungnahmen dazu, die Root-Zone, die oberste Ebene des DNS, mit DNSSEC zu signieren. Dabei verwies es auf diese Sicherheitslücke. Seit dem 15. Juli 2010 können Resolver die signierte Root-Zone prüfen.\nDie National Vulnerability Database bewertet die Lücke auf CVSS 3.1 mit 6,8 von 10, also als „mittel“. Ein Angreifer kann Antworten fälschen, aber weder Daten lesen noch einen Server lahmlegen. Außerdem gilt der Angriff als schwer durchführbar.","title":"Kaminskys DNS-Lücke: Wie sich jede Domain kapern ließ","url":"https://crackthe.net/de/sicherheit/schwachstellen/kaminsky-dns/"}