image

Geïllustreerde uitleg Dan Kaminsky's DNS-lek

woensdag 13 augustus 2008, 11:25 door Redactie, 7 reacties

Inmiddels is duidelijk dat de patch voor het door Dan Kaminsky ontdekte DNS-lek geen lange termijn oplossing is. Toch zijn er nog altijd voldoende bedrijven en providers die hun nameserver niet gepatcht hebben en zijn ook veel internetgebruikers niet op de hoogte van de ernst van de situatie. Voor die laatste groep heeft Steve Friedl een geïllustreerde uitleg gemaakt waarin de werking van het DNS en de kwetsbaarheid zelf aan bod komen.

Kaminsky zelf is blij met de door de IT-industrie genomen moeite. "Dit kostte veel uren van veel IT'ers. Ik weet zeker dat er heel veel blije pizzabakkers zijn. Maar laten we duidelijk zijn, er zijn aanvallers en ze gebruiken deze aanval op interessante manieren. Mensen die gepatcht zijn, zijn veel veiliger dan mensen die dat niet zijn."

DNSSec?

Sinds de bekendmaking door Kaminsky vraagt iedereen zich af hoe DNS gerepareerd moet worden. De onderzoeker ziet een mogelijkheid voor DNSSec, maar kijkt ook verder. "De werkelijke vraag is 'waarom maakt DNS zoveel uit?'. De onderliggende problematiek is de aanname dat er een verschil is tussen kwaadaardige en veilige netwerken. DNS is een fantastische manier om die waanvoorstelling onderuit te halen, zeker achter firewalls. Zelfs als we van 32 bits naar 128 bits entropy gaan, als we DNSSec gebruiken, dan leveren we nog steeds mail op een onveilige manier af."

De problemen met het internet gaan veel verder, ook al wordt DNS gerepareerd, aldus Kaminsky: "We hebben dan nog steeds te maken met een bijna compleet ongeauthenticeerd web. We gaan nog steeds SSL-certificaat foutmeldingen negeren en we hebben nog steeds applicaties die op een onveilige manier zichzelf updaten. Dat is aan het eind van de dag een veel groter probleem dan dit specifieke DNS geval."

Reacties (7)
13-08-2008, 13:10 door Anoniem
<quote>
Just for the sake of discussion, let's assume that the bad guy can generate
50
forged replies for each random name query before the real reply arrives from
the real nameserver.
</quote>

50 keer een reply binnen een fractie van een seconde elke met een ander
Query ID, maar wel voor dezelfde domeinnaam. Een beetje filter moet dat toch
herkennen als een hackaanval en dat tegen kunnen houden.

De PC/Server van de bad guy moet door de filter op een openbare blacklist
worden gezet. Is ook maar een lapmiddel, ik weet het....

"People, we have a problem!"
13-08-2008, 13:58 door Anoniem
je snapt wel dat het een udp pakket is dat van de juiste
server afkomstig lijkt?
13-08-2008, 15:37 door Anoniem
Door Anoniem
je snapt wel dat het een udp pakket is dat van de juiste
server afkomstig lijkt?

En dat valt niet op in een filter, 50 keer een udp packet die met dezelfde
answer-data komt?
13-08-2008, 15:59 door Anoniem
Door Anoniem
Door Anoniem
je snapt wel dat het een udp pakket is dat van de juiste
server afkomstig lijkt?

En dat valt niet op in een filter, 50 keer een udp packet
die met dezelfde
answer-data komt?

jawel, maar als je dat blokkeert blokkeer je ook het echte
antwoord, en dan stel je jezelf bloot aan een wel hele
makkelijke dos attack
13-08-2008, 20:14 door Anoniem
Door Anoniem
Door Anoniem
Door Anoniem
je snapt wel dat het een udp pakket is dat van de juiste
server afkomstig lijkt?

En dat valt niet op in een filter, 50 keer een udp packet
die met dezelfde
answer-data komt?

jawel, maar als je dat blokkeert blokkeer je ook het echte
antwoord, en dan stel je jezelf bloot aan een wel hele
makkelijke dos attack

Als ik in mijn filter instel dat ipnummers geblokkeerd moeten worden die me
meer dan x keer binnen y milliseconden dezelfde data sturen, dan kan de
echte DNS server nog gewoon data afleveren... of zie ik nog iets over het
hoofd?
14-08-2008, 11:02 door Anoniem
Door Anoniem
Als ik in mijn filter instel dat ipnummers geblokkeerd
moeten worden die me
meer dan x keer binnen y milliseconden dezelfde data sturen,
dan kan de
echte DNS server nog gewoon data afleveren... of zie ik nog
iets over het
hoofd?

ja, omdat de adressen gespoofd worden, komt de nep-data,
voorzover jouw filter dat weet, van het adres van de echte
dns server.
14-08-2008, 11:43 door Anoniem
Nee, je hebt dan dus de echte dns server geblokkeerd omdat
het nepverkeer en het echte verkeer van hetzelfde ipadres
afkomstig lijken. Je kunt dus ook niet bij voorbaat al
alleen dns verkeer van het ip van je dns server toelaten en
al het andere dns verkeer droppen. Dat zou anders een
makkelijke oplossing zijn he? :)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.