{"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":"In July 2008, a DNS flaw let attackers plant false addresses for any domain within seconds. How it worked and how vendors fixed it on a single day.","language":"en","latest_measurement":"2026-11-01","method":"latency-v3","method_page":"https://crackthe.net/data/method/","source":"https://crackthe.net/","text":"On July 8, 2008, makers of DNS software around the world published fixes on the same day. They closed a flaw that the security researcher Dan Kaminsky had found. The DNS, the Domain Name System, is the internet\u0026rsquo;s address book. It translates names such as example.com into the numeric addresses that computers use. The flaw let attackers plant false addresses for any domain in the memory of the servers that look up these names for users. According to CERT.at, Austria\u0026rsquo;s national computer emergency team, almost all DNS servers on the internet were vulnerable.\nHow it worked When you open a website, your device asks a resolver for the address. A resolver is a DNS server that looks up names on behalf of users, usually run by your internet provider or your company. It asks the name servers responsible for the domain and keeps their answer in its cache, a temporary memory, for a while. That way, it can answer the next user at once. Whoever gets a forged answer into this cache sends every user of the resolver to the wrong server. This is called cache poisoning.\nA resolver accepted an answer if it matched its question, above all through a query ID, a number between 0 and 65,535. Most resolvers sent all their questions from the same network port. So this number was the only secret an attacker had to guess: each forged answer had a chance of 1 in 65,536. Poisoning was still hard, because the real answer usually arrived within about 100 milliseconds. Once it was in the cache, the attacker had to wait until it expired, often for days.\nKaminsky\u0026rsquo;s idea removed the waiting. The attacker makes the resolver look up names that do not exist, such as random1.example.com, then random2.example.com, and so on. Such names are never in the cache, so each one is a new chance. The forged answers carry an extra entry. It claims that a server of the attacker is now the name server for all of example.com. As soon as one guess fits, the resolver stores this claim and from then on asks the attacker about every name in the domain. According to a 2009 study presented at NDSS, a security research conference, the technique cut the time an attack took from weeks to seconds.\nAttackermakes the resolver look up a random name that does not exist Forged answersrace the real one, each with a guessed query ID One guess fitsthe resolver accepts the forged answer Cachenow names the attacker\u0026#39;s server for the whole domain Usersare sent to servers of the attacker\u0026#39;s choice If the real answer arrives first, the attacker simply asks for the next random name. The US-CERT, the US government\u0026rsquo;s computer emergency team, warned that web traffic, email and other important network data could be redirected to systems under the attacker\u0026rsquo;s control.\nReach and attacks The weakness lay in the DNS protocol itself, not in a single product, wrote ISC, the maker of the widely used DNS software BIND. The CERT/CC, the US coordination center for security flaws, listed 91 vendors, 37 of them affected, from Microsoft and Cisco to Linux distributions.\nCERT.at, which is run by the registry of Austria\u0026rsquo;s .at domains, measured how fast Austrian resolvers were fixed. A patched resolver changes its port with every query. CERT.at could see this in the logs of one of the registry\u0026rsquo;s name servers. Before the fixes, only about 15 % of the resolvers did so. Two weeks after the fixes, 66 % of the busy resolvers, those seen on almost every day, were still unpatched:\nUnpatched resolvers in Austria, July 2008 Busy resolvers, data until July 2166 % Busy resolvers, data until July 2762 % Weighted by queries, until July 2150 % Weighted by queries, until July 2742 % Weighted by queries, resolvers that send many queries count more than small ones. Source: CERT.at (2008).\nStudies of resolvers worldwide came to different results. Months after the fixes, researchers at the Georgia Institute of Technology probed 0.9 million open resolvers, which answer queries from anyone. About 57 % still sent every query from the same port. A survey by The Measurement Factory, commissioned by the DNS vendor Infoblox, estimated 4.3 million open resolvers in October 2008. It found poor port randomization in 24 % of those it tested.\nHow 0.9 million open resolvers chose their port, months after the fixes Always the same port57 % Ports in a fixed rotation2 % No pattern found, counted as fixed41 % Source: Recursive DNS Architectures and Vulnerability Implications (NDSS 2009).\nThe details of the attack were to stay secret until a talk at the Black Hat security conference in early August. But on July 21, they leaked. On July 23, working attack code appeared, according to DNS-OARC, an association of DNS operators. A week later, the press reported that a DNS server of the provider AT\u0026amp;T in Texas had been poisoned. Users of that server who called up google.com landed on a fake page that clicked on ads. The SANS Internet Storm Center also reported the poisoned server. In the first two weeks of August 2008, the researchers from Georgia found poisoned answers for the domains of banks and large websites. For the US bank Washington Mutual alone, they found 11,050. The number rose after the attack tools came out, but the researchers could not prove which technique had been used. No source puts a figure on the damage.\nThe fix and the response Kaminsky had warned the vendors months before. On March 31, 2008, makers of DNS software met at Microsoft to discuss the problem. Their common fix is called source port randomization. A patched resolver sends each query from a randomly chosen port and accepts only answers that arrive at exactly that port. According to CERT.at, this adds up to 16 more bits of randomness that an attacker has to guess. After Microsoft\u0026rsquo;s update, for example, Windows DNS servers picked their ports from 16,384 possible ones. Together with the query ID, that makes about a billion combinations instead of 65,536. The idea was not new. CERT/CC credits it to the developer of djbdns, a resolver that already chose random ports.\nCERT/CC arranged for almost all vendors to publish their fixes on the same day, July 8, 2008. Among them were Microsoft with update MS08-037 and ISC with new versions of BIND. CERT.at called this coordination almost unprecedented. Apple followed on July 31 with an update for the BIND server built into Mac OS X. CERT/CC also warned that routers and firewalls that translate addresses and ports could undo the protection.\nRandom ports only raise the bar. DNSSEC, the DNS Security Extensions, lets resolvers check digital signatures on answers. Without such changes to the protocol, the fixes “cannot completely prevent cache poisoning”, CERT/CC wrote. ISC called DNSSEC “the only definitive solution”. In October 2008, the US Department of Commerce asked for comments on signing the root zone, the top of the DNS, with DNSSEC. Its request cited this flaw. Since July 15, 2010, resolvers have been able to check the signed root zone.\nThe National Vulnerability Database rates the flaw 6.8 out of 10 on CVSS 3.1, “medium”. An attacker can falsify answers but cannot read data or shut down a server. The attack also counts as hard to carry out.","title":"Kaminsky DNS flaw: the trick that could hijack any domain","url":"https://crackthe.net/security/vulnerabilities/kaminsky-dns/"}