Netwerkbeveiliging dns cache poisoning

11 www.kdg.be DNS cache poisoning11
NetwerkbeveiligingNetwerkbeveiliging
DNS 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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Netwerkbeveiliging dns cache poisoning