Netwerkbeveiliging dns cache poisoning

11 www.kdg.be DNS cache poisoning11

NetwerkbeveiligingNetwerkbeveiligingDNS cache Poisoning


Wat is DNS?Wat is DNS?

Systeem dat namen (waar mensen mee werken) mapt op internet adressen (waar Internet mee werkt) Nummers veranderen zo vaak, dat we ze steeds opnieuw

moeten opzoeken Bijna ALLES op internet werkt eerst via DNS

- Mail, http, proxies,...


DNS is gedistribueerdDNS is gedistribueerd

Op de vraag “waar is www.whitehats.com” zijn er 3 mogelijke antwoorden: Hier is het IP adres dat bij de naam hoort Maak dat je wegkomt, ik bedien je niet Ik weet het niet, vraag eens aan die andere server

- Dat is delegatie, je vraagt iets en je vraagt wordt doorgestuurd door heel het netwerk

1)Doorsturen naar 13 root servers: www.whitehats.com? Geen idee, vraag eens aan de .COM server op 1.2.3.4

2).COM server: www.whitehats.com, geen idee, vraag aan whitehats.com op 2.3.4.5

3)whitehats.com server: www.whitehats.com heeft IP adres 3.4.5.6

http://www.whitehats.com/

http://www.whitehats.com/


Twee soorten DNS serversTwee soorten DNS servers

Authoritative nameserver Deze server voert vertalingen uit voor alle servers in zijn

zone (bv. ns.kdg.be kent mail.kdg.be en www.kdg.be). Caching nameserver

Deze server neemt enkel DNS- informatie over van autoritative servers. Een caching nameserver slaat al deze informatie op in een lokale, tijdelijke kopie (cache), om sneller te kunnen antwoorden op toekomstige DNS verzoeken.


Cache poisoningCache poisoning

Cache poisoning De cache van de caching nameserver kan gemanipuleerd

worden zodat deze de verkeerde informatie doorgeeft aan gebruikers


Kwetsbaarheid 1 DNS serverKwetsbaarheid 1 DNS server

Het moment dat een caching nameserver een vraag stelt aan een authoritative nameserver Een attacker moet zien dat hij het antwoord op de vraag

sneller geeft dan de echte authoritative server Moeilijkheid

- Gokken Transactie ID- Gokken Poortnummer


Kwetsbaarheid 2 DNS serverKwetsbaarheid 2 DNS server

Naast het antwoord op de vraag kan je bij DNS extra informatie meegeven bij je antwoord. Iemand vraagt bijvoorbeeld www.kdg.be In het antwoord zet je extra een nieuw ip voor mail.kdg.be

- Een bug in 1997 was dat je van eender welk domein kon toevoegen. Je gaf dus buiten het antwoord op www.kdg.be OOK www.google.com door


En nu de slechterikken ...En nu de slechterikken ...

Een attacker wil maar al te graag dat zijn IP adres wordt doorgegeven in plaats van een echt IP adres

Hoe wordt er verhinderd dat iemand de DNS servers een verkeerd IP adres doorgeeft? Transaction ID – Een “random” nummer tussen 0 en

65535. De echte nameserver kent de nummer, want deze zit in de vraag (de DNS request).

De attacker kent de nummer niet, tenzij hij de verbinding afluistert of de nummer gokt.


Oude bug: Sequentiële TX ID'sOude bug: Sequentiële TX ID's

In 1997 waren Transactie ID's (TX ID's) sequentieel, waardoor eenvoudig volgende nummers konden gekozen worden om valse reply's te maken

Ref BIND 1997, http://www.cert.org/advisories/CA-1997-22.html


Oude bug 1997 → kwetsbaarheid 2Oude bug 1997 → kwetsbaarheid 2

Misbruikt door Eugene Kashpureff Echte DNS servers stellen

vragen aan valse servers Bij de reply worden extra valse naam-ip

mappings doorgegeven. Deze naam -ip mappings mochten EENDER welk domein zijn

Eugene Kashpureff kon dus eender welk domein kapen en gratis nieuwe aanmaken Misbruikte dit om adressen te stelen van zijn concurrent

InterNIC. De klanten van InterNIC werden dan doorgestuurd naar servers van AlterNIC

Dit kostte hem 5 jaar cel en 250.000$


Oude bug: Birthday ParadoxOude bug: Birthday Paradox

Birthday Paradox Bij een groep van 23 random gekozen mensen is er meer

dan 50% kans dat er 2 mensen op dezelfde dag geboren zijn.

In cryptografie kan zo een hash functie dezelfde resultaten geven op verschillende data

Door een zwakheid in het genereren van de transactie ID's was de kans niet 0,0015% maar 100% bij het versturen van 700 pakketten.

Ref: BIND 2002, zie : http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html


De gokkans vergrotenDe gokkans vergroten

De gok op een juist antwoordpakket is een kans van 1 op 65535 (TX ID)

Om de kans te vergroten moeten we zorgen dat de caching nameserver VEEL vragen stellen aan authoritative nameserver.

Het antwoord van de authoritative server doet er niet toe. We gaan immers het antwoord zelf proberen te geven aan de caching nameserver met de gegokte TX ID.

De vragen moeten gesteld worden over de zone die we willen aanpassen. Dus om www.kdg.be aan te passen vraag je: aaaaaaa.kdg.be,aaaaaab.kdg.be,aaaaaac.kdg.be, ...


Werking Kaminsky codeWerking Kaminsky code

De code vuurt dus vragen af op een caching nameserver en vuurt dus ook antwoorden naar de caching nameserver (met een gegokte TXID), zogezegd komende van de authoritative server

Je kan een aantal antwoorden sturen, zolang de echte authoritatieve server nog niet geantwoord heeft. Sommige DNS servers antwoorden niet als ze een domein

niet kennen.


Als alles goed gaatAls alles goed gaat

Het antwoord van een goede DNS server heeft een TTL Time to Live

- 1 minuut / meerdere minuten- 1 uur / meerdere uren- 1 dag / meerdere dagen

De mapping naam-ip wordt zo lang bijgehouden of geblokkeerd als de TTL


De kaminsky code zelfDe kaminsky code zelf

zie Milw0rm, metasploit, ...


““Voorlopige” oplossingVoorlopige” oplossing

Source Port Randomization Als de source port van de DNS request random is, dan

heeft de attacker niet 1 op 65536 kansen maar 1 op 4 miljard (65536 x (65536 – 1024))

Bovendien moet de aanvaller binnen de dag een juiste gok doen. ( maximum TTL)

Dat is echter NIET ONMOGELIJK- Testen op een DNS server via een Gigabit LAN leveren binnen de

10 uur een positief resultaat- Opm: Er kunnen, voor dat de echte autoritatieve server antwoord

kan geven 40000 tot 50000 valse replies gestuurd worden• Ref http://www.milw0rm.com/exploits/6236


Lange TTL waardeLange TTL waarde

De TTL geeft aan hoe lang een record niet mag veranderen Google heeft bijvoorbeeld een TTL van 95 dagen Microsoft heeft een TTL van 39 dagen

Nadeel Stel dat er iets foutloopt met de webservers, en alle caching

nameservers veranderen hun records niet, dan ligt google in het slechtste geval 95 dagen plat

- In praktijk zal in het geval van google wel alles sneller geregeld worden door ISP's


Alternatieve oplossingenAlternatieve oplossingen

Een DNS server zelf kan gemakkelijk detecteren dat er een aanval bezig is. Veel pakketten met foute TX ID Veel pakketten met foute poort … Maar wat dan?

Blokkeren of limiteren van een bepaalde IP is slecht Een aanvaller kan zo gemakkelijk een DoS veroorzaken

Overschakelen op TCP in plaats van UDP op poort 53 DNS server Nominum schakelt bij een foute TXID over op

TCP voor die query. Het voornaamste voordeel hierbij is dat de Nominum server dan zelf de snelheid bepaald (vertraagd) van de queries


DNSSECDNSSEC

Secure DNS Digitale handtekening op elke DNS Resource Record Verzekering van de data (integriteit) Ook een verzekerde “denial of existence”.

Het “onbekend” verklaren van een naam verloopt ook met authenticatie.

DNSsec zorgt NIET voor confidentialiteit van de data DNSsec verhindert geen DDOS


Tools of the tradeTools of the trade

Kaminsky gebruikte “scapy” Tool waarmee je interactief pakketten aanmaakt. Gebaseerd op Python In tegenstelling tot andere tools niet enkel geschreven voor

bepaalde protocollen met bepaalde instellingen. Je mag dus afwijken van eender welk protocol

Toont ook de respons op jou pakket


Patching DNS serversPatching DNS servers

Bron: Clarified Networks


ReferentiesReferenties

DNS cache poisoning redirects Internic customers http://www.secure64.com/ddos-news/internic-alternic-dns-poisoning.html

Black Ops 2008: It’s The End Of The Cache As We Know It http://www.doxpara.com/DMK_BO2K8.ppt

‘De Kaminsky Code’: Kwetsbaarheden in DNS http://www.govcert.nl/download.html?f=118

Scapy, Interactieve Packet Manipulation Tool http://www.secdev.org/projects/scapy/

Secret Geek A-Team Hacks Back, Defends Worldwide Web http://www.wired.com/techbiz/people/magazine/16-12/ff_kaminsky?

DNS Security Introduction and Requirements , RFC 4033 http://www.ietf.org/rfc/rfc4033.txt


ReferentiesReferenties

CERT® Advisory CA-1997-22 BIND - the Berkeley Internet Name Daemon http://www.cert.org/advisories/CA-1997-22.html

Birthday Paradox (Alertas do CAIS ALR-19112002a) http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html

DNS Cache Poisoning, The Next Generation http://www.lurhq.com/dnscache.pdf

Netwerkbeveiliging dns cache poisoning

Lifestyle

Transcript of Netwerkbeveiliging dns cache poisoning