Nieuws
image

Details zeer ernstig DNS-lek op straat

dinsdag 22 juli 2008, 10:07 door Redactie, 12 reacties

Uitgebreide informatie over het DNS-lek dat vele miljoenen mensen in gevaar had kunnen brengen, en door Microsoft, Sun en Cisco begin juli werd gepatcht, is uitgelekt. Beveiligingsonderzoeker Dan Kaminsky wilde de kwetsbaarheid in het Domain Name System (DNS) pas volgende maand tijdens de Black Hat conferentie onthullen. Op deze manier zouden beheerders van kwetsbare DNS servers een maand te tijd krijgen om hun software te patchen.

En dat is nodig, want via de kwetsbaarheid kan een aanvaller iemand z'n websessie kapen en het slachtoffer naar een kwaadaardige server doorsturen om zo malware te verspreiden of vertrouwelijke informatie te stelen. Zo zou het mogelijk zijn om iemand naar een banksite door te sturen, terwijl dit niet de legitieme site van de bank is. Het slachtoffer zou niets doorhebben omdat zij netjes in de adresbalk het adres van de bank typt.

Een andere beveiligingsonderzoeker was het niet met de mening van Kaminsky eens dat het embargo systeembeheerders meer tijd geeft en besloot de patches te reverse engineeren om zo achter de details van het lek te komen, en dat is hem gelukt. Volgens Halvar Flake is het juist belangrijk om de kwetsbaarheid te bespreken, want de aanpak van Kaminsky geeft mensen alleen een "warm en veilig" gevoel.'

Flake's veronderstelling

Flake deed de volgende veronderstelling en die is volgens Kaminsky juist. De onderzoeker roept tevens iedereen op om NU te patchen.

"Mallory wil de DNS lookups van de server ns.polya.com voor het domein www.gmx.net vergiftigen. De nameserver voor gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. Mallory stuurt nep requests voor www.ulam00001.com, www.ulam00002.com ... naar ns.polya.com. Ns.polya.com heeft deze requests niet gecached, dus vraagt aan een root server "waar kan ik de .com nameserver vinden?" Dan ontvangt het een verwijzing naar de .com nameserver en vraagt die waar het de nameserver voor ulam00001.com, ulam00002.com etc kan vinden.

Mallory spooft de verwijzingen naar ns.poly.com die afkomstig van de .com nameserver lijken. In deze verwijzingen laat het weten dat de nameserver voor ulamYYYYY.com een server met de naam ns.gmx.net is en dat die server zich bevindt op het IP-adres 244.244.244.244. Tevens is de time to live (TTL) van deze verwijzing lang. Uiteindelijk zal Mallory het lukken om de verwijzing te spoofen, bijvoorbeeld door de TXID te raden. Ns.polya.com zal dan cachen dat ns.gmx.net op 244.244.244.244 te vinden is."

Reacties (12)
22-07-2008, 10:13 door spatieman
nouja..
GMX.NET staat er samen met WEB.DE naar mijn meening om
bekend dat zij vooral veel spam krijgen.1 op de 100 zal
legetiem zijn....

maar opzicht ,een griezelig spoof verhaal
22-07-2008, 10:23 door Anoniem
@ spatieman: het is slechts een hypothetisch voorbeeld, dus je kan GMX.NET
vervangen door ieder ander willekeurig domein.
22-07-2008, 10:33 door Anoniem
Deze techniek was toch al lang bekend?

De oplossing is toch secure DNS?
22-07-2008, 10:38 door Nomen Nescio
Door spatieman
nouja..
GMX.NET staat er samen met WEB.DE naar mijn meening om
bekend dat zij vooral veel spam krijgen.1 op de 100 zal
legetiem zijn....

maar opzicht ,een griezelig spoof verhaal
Leer eens schrijven, want dit doet pijn aan mijn ogen.
22-07-2008, 11:10 door Anoniem
Het mechanisme van DNS poisening zoals hierboven beschreven
was al jaren bekend, dus wat is er nu uitgelekt ?
De patch bestaat uit het random genereren van de source poort
en dat koppelen aan de txid om de kans om het correct gespoofde
antwoord te verkleinen.
Je kunt ook je eigen private recursive DNS server gebruiken
zonder forwarders om dit soort truuks te voorkomen.
22-07-2008, 11:33 door SirDice
Door Anoniem
Deze techniek was toch al lang bekend?

De oplossing is toch secure DNS?
Enig idee hoe je secure DNS zou kunnen implementeren op de
root DNS servers (of het ritsje .com)? Enig idee wat de load
op die machines nu is? Wat denk je dat de load zal worden
als er ook nog allerhande crypto spul moet gaan draaien?
22-07-2008, 11:43 door Anoniem
Door Nomen Nescio
Leer eens schrijven, want dit doet pijn aan mijn ogen.
Ga eens naar nl.taal, want dit gezeur hoort niet thuis op
een forum dat primair door techneuten bezocht wordt. Reageer
inhoudelijk of reageer niet.
22-07-2008, 12:38 door Anoniem
Door Anoniem
Door Nomen Nescio
Leer eens schrijven, want dit doet pijn aan mijn ogen.
Ga eens naar nl.taal, want dit gezeur hoort niet thuis op
een forum dat primair door techneuten bezocht wordt. Reageer
inhoudelijk of reageer niet.
Ook techneuten maken het moeilijk voor zichzelf en anderen als hun bijdrage
niet nagenoeg foutloos is.
Er is toch niets op tegen om even je tekst na te lezen en fouten te verbeteren!

Tevens is Security.nl natuurlijk niet het domein van alleen techneuten,
maar ook anderen. Voor Techies onder elkaar ga je bijvoorbeeld naar
usenet.
22-07-2008, 13:14 door Anoniem
Als techneut is het belangrijk om, duidelijk, accuuraat en
voelleedig te zijn. Darom is het belangerijk da je goet kan
spelle ook. Grammateca en zinsopbouw en konsiestensie is ook
belangenrijk.

Ik ben ervoor om andere te verbeteren omdat het je scherp hou.
22-07-2008, 19:50 door Anoniem
Door Anoniem
Je kunt ook je eigen private recursive DNS server gebruiken
zonder forwarders om dit soort truuks te voorkomen.
Inderdaad, zie http://www.kb.cert.org/vuls/id/800113
III. Solution.
Run a local DNS cache
In lieu of strong port randomization characteristics in a stub resolver,
administrators can protect their systems by using local caching full-service
resolvers both on the client systems and on servers that are topologically
close (on the network) to the client systems. These resolvers should be used
in conjunction with the network segmentation and filtering strategies
mentioned above.
22-07-2008, 19:52 door Anoniem
wat een geneuzel!

Wanneer gaan we het weer over security hebben???
23-07-2008, 02:15 door Rene V
*zucht*

Niemand hier ooit van dyslexie gehoord?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search