Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Securing and Monitoring the Domain Name System


Published on

In 2008, security researcher Dan Kaminsky highlighted a long-standing bug that could allow attackers to
compromise the integrity of the Domain Name System with relative ease. In this session, Paul Roberts will
explain the bug and why it is still prevalent 2 years later. He will then introduce the DNS Security Extensions,
which can be used to mitigate the problem, and discuss ways of monitoring the DNS environment to help
identify potential attacks.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Securing and Monitoring the Domain Name System

  1. 1. Securing & Monitoring the<br />Domain Name System<br />Paul Roberts, CTO<br />tuscany networks<br />
  2. 2. Who are we?<br />The UK’s Leading IP Address Management and DNS Specialists<br />Domain Name System (DNS)<br />Dynamic Host Configuration Protocol (DHCP) <br />IP Address Management (IPAM)<br />14+ years experience in the “DDI” market<br />Recognised by Gartner in 2009 DDI MarketScope report<br />Over 100 large corporate customers including many global deployments<br />Finance, telcos, retail, manufacturing, service providers, transport, government, education<br />© 2010 tuscany networks<br />Slide 2<br />
  3. 3. What is DNS?<br />Pretty much everything that connects to the network uses an IP address<br />Humans are not very good at remembering numbers,so we give everything a name<br />A bigger problem with IPv6<br />DNS, at its most basic, provides the translation fromname to number (IP addresses)<br />It's basically a telephone directory for networks<br />Slide 3<br />© 2010 tuscany networks<br />
  4. 4. What is DNS?<br />Imagine TV adverts that used IP addresses instead of names...<br /> =<br /> = <br /> =<br />Slide 4<br />© 2010 tuscany networks<br />
  5. 5. What is DNS?<br />DNS = Domain Name System<br />Specific servers run the DNS service<br />These are known as DNS servers or name servers<br />Multiple servers can be deployed to provide resilience<br />Clients query these servers in order to resolve names and addresses<br />e.g. your PC typically talks to DNS when you browse a web page or access an internal system/service<br />What is the IP address<br />of<br />DNS Server<br /> =<br /><br />Slide 5<br />© 2010 tuscany networks<br />
  6. 6. DNS Security problems<br />DNS has traditionally had very little security<br />It was designed in an era when the Internet was still relatively small, and people trusted each other<br />DNS messages are sent in plain text with no authentication<br />The protocol is simple and easy to spoof<br />Over the years, various attacks have been publicised, e.g.<br />Denial of Service<br />WPAD spoofing<br />Cache poisoning<br />© 2010 tuscany networks<br />Slide 6<br />
  7. 7. What is cache poisoning?<br />The process of inserting data into a name server’s cache to deliberately redirect people to an illegitimate web site<br />In the 90s, this was very easy to do as the name server trusted (and cached) all data it received<br />It was very easy to redirect users to a malicious web site via spoofed DNS responses<br />Way before Web 2.0, this vulnerability was fixed, but can still be achieved using different, more complex techniques<br />© 2010 tuscany networks<br />Slide 7<br />Maliciousupdates<br />DNS Server<br />DNSQuery<br />Maliciousresponse<br />Web traffic<br />Malicious web server<br />
  8. 8. Transaction Identifiers<br />Every DNS query has a transaction id (TXID) comprising a 16 bit number<br />16 bits = 65536 possible values<br />This 16 bit number is generated by the client or name server and inserted into every query<br />The DNS response has to have the same TXID as the query for it to be accepted<br />This allows the client to match the response to the query (as there could be multiple outstanding queries)<br />If you can predict the next TXID the name server will use, you can potentially poison the cache by spoofing a response with a matching TXID<br />© 2010 tuscany networks<br />Slide 8<br />
  9. 9. Transaction IDs (TXIDs) in use<br />© 2010 tuscany networks<br />Slide 9<br />I don't know, talk to bigbank's DNS servers(TXID=13423)<br />ISP or corporateDNS Server<br />What is the IP address<br />of<br />(TXID=13423)<br />root/GTLD servers<br />What is the IP address<br />of<br />(TXID=28736)<br />Cache<br />What is the IPaddress<br />(TXID=36452)<br /> =<br /><br />(TXID=28736)<br /> =<br /><br />(TXID=36452)<br />bigbank's DNS Server(<br />Response TXID matches query TXID<br />User<br />
  10. 10. TXID Prediction<br />Amit Klein of Trusteerfound that BIND and MS-DNS didn't generate a suitably random TXID<br />BIND<br />If the current TXID is even, the next one would be one of only 10 possible values<br />Also possible, with 13-15 queries, to predict all successive TXIDs<br />Older versions just used a sequentially increasing number<br />MS-DNS<br />Could predict the next TXID after sniffing 8 queries<br />Other DNS server implementations also suffered similar problems<br />If you could sniff a few DNS packets you could predict the next TXID<br />Inducing a lookup to your name server is easy, just send an email<br />© 2010 tuscany networks<br />Slide 10<br />
  11. 11. Monitoring the TXID by inducing a name server to query yours<br />© 2010 tuscany networks<br />Slide 11<br />root/GTLD servers<br />What is the IP address<br />of<br />Victim's DNS Server<br />Victim's mail Server (<br />I don't know, talk to badguy's DNS servers<br />Send a reply with 0 TTL so it doesn't get cached. This allows us to send another mail and check the next TXID<br />What is the IP address<br />of<br />(TXID=some number)<br />Victim's mail server reports: "No such user" and needs to bounce email back....What is the IP address<br />Badguy's DNSServer (<br />Log the TXID<br />... and repeat!<br />HELO:<br />MAIL FROM:<br />RCPT TO:<br />DATA: Hi, this mail will bounceback and cause you to look upmy mail server using DNS.<br />Badguy's mail server (<br />Badguy<br />
  12. 12. Monitoring the TXID by directly querying the victim name server<br />© 2010 tuscany networks<br />Slide 12<br />What is the IP address<br /><br />(TXID=some number)<br />root/GTLD servers<br />Victim's DNS Server (e.g. ISP or corporate DNS server)<br />I don't know, talk to badguy's DNS servers<br />What is the IP address<br />of<br />(TXID=some number)<br />What is the IP address<br />of<br />(TXID=some number)<br />What is the IP address<br />of<br />(TXID=some number)<br />What is the IPaddress<br />Badguy's DNSServer (<br /><br /><br />Log the TXID<br />... and repeat!<br />Badguy<br />
  13. 13. Cache poisoning<br />If you monitor the TXID and find a pattern it is very easy to spoof a reply<br />We use a long TTL to ensure our fake reply stays in cache as long as possible<br />Even if you don't find a pattern, you just need to reply with enough packets before the "real" answer arrives<br />But you only have a short round-trip time to do it (RTT typically < 100ms)<br />However, the "Birthday Paradox" can increase our probability of being successful...<br />© 2010 tuscany networks<br />Slide 13<br />
  14. 14. The birthday paradox<br />The probability of us guessing the correct TXID increases as we send more queries<br />Although the TXID is a 16-bit number with 65536 possible values, we can achieve 90% probability with only 600 guesses<br />© 2010 tuscany networks<br />Slide 14<br />
  15. 15. Poisoning a single entry<br />© 2010 tuscany networks<br />Slide 15<br />What is the IP address<br />of<br />(TXID=1000)<br />root/GTLD servers<br />Victim's DNS Server (e.g. ISP or corporate DNS server)<br />I don't know, talk to bigbank's DNS servers<br />What is the IP address<br />of<br />(TXID=1001)<br /> =<br /><br />(TXID=1001)Response is ignored if spoofed TXID matched!<br />Cache<br />What is the IPaddress<br />bigbank DNS server (<br />Spoofed response<br /> =<br /><br />(TXID=1000)<br />mismatches<br />Spoofed response<br /> =<br /><br />(TXID=1001)<br />success!<br />Spoofed response<br /> =<br /><br />(TXID=1002)<br />mismatches<br />What is the IP address<br />of<br /> =<br /><br />Unsuspecting userenters password/credit card details<br />Badguy's fakebigbank web site @ <br />Badguy<br />
  16. 16. That's a lot of effort!<br />True, we have only poisoned one entry<br />And we have to inject the bogus response before the real response comes back<br />i.e. it's a race and we may only get 1 shot at it<br />Once the real response has been cached, we are out<br />Unless we can guess the TXID, or send enough responses during the real response RTT, we will probably fail<br />Average RTT for DNS <= 100ms<br />However, there's a way that is much more deadly!<br />© 2010 tuscany networks<br />Slide 16<br />
  17. 17. The "Kaminsky" Exploit<br />Security Researcher Dan Kaminsky discovered a way to use theTXID weakness to hijack a whole domain<br /> poisoning name server "glue"<br />...and get multiple goes at the race!<br />This makes it almost certain that the cache can be poisoned<br />If you can hijack the whole domain, you can hijack all thetraffic...<br />SMTP, HTTP, SSL, VPN, FTP... EVERYTHING!<br />© 2010 tuscany networks<br />Slide 17<br />Photo credit: "Dave Bullock / eecue"<br />
  18. 18. Hijacking a whole domain<br />© 2010 tuscany networks<br />Slide 18<br />What is the IP address<br />of<br />(TXID=1000)<br />root/GTLD servers<br />Victim's DNS Server (e.g. ISP or corporate DNS server)<br />I don't know, talk to<br />bigbank DNS server (<br />What is the IP address<br />of<br />(TXID=1001)<br />Real response =<br />name server=ns1.bigbank.comns1 glue record=<br />(TXID=1001)<br />Response is ignored ifspoofedTXID matched!<br />Cache<br />What is the IP address<br />What is the IP address etc.<br />Spoofed response<br />name server=ns1.bigbank.comns1 glue record=<br />(TXID=1000) mismatches<br />Spoofed response<br />name ns1 glue record= success!<br />Spoofed response<br />name server=ns1.bigbank.comns1 glue record=<br />(TXID=1002) mismatches<br />...keep repeating withdifferent random hostnames until we win!<br />Badguy's DNSserver<br />Badguy<br />
  19. 19. What's with the random host names?<br />Using multiple random host names allows us multiple goes at the race because it's the random name that gets cached (negatively)<br />Which we don't care about<br />Once that is cached, we just try again with a different name<br />The REAL name server and glue data will be cached from the real response...<br />But our fake glue can override what's in the cache, so we just keep on going until we match the TXID, poison the name server glue, and hijack the whole domain!<br />© 2010 tuscany networks<br />Slide 19<br />
  20. 20. Why is it so deadly?<br />Forgot your password?<br />© 2010 tuscany networks<br />Slide 20<br />
  21. 21. Email should not be used to identify you<br />Search for "forgot your password" on Google<br />Only a few sites then! <br />If you can hijack the domain you can intercept all the email<br />Just have an MX record pointing to your server<br />So many sites uses email to identify you, but since when has email been secure?<br />Insecure email on an insecure DNS platform? Hmmm!<br />© 2010 tuscany networks<br />Slide 21<br />
  22. 22. Email hijack in action<br />© 2010 tuscany networks<br />Slide 22<br />bigbank's DNS server<br />(Cache poisoned by badguy)<br />ISP DNS server(<br />Cache<br />Recursive lookup for<br />Web server needs tosend email: What is the IP address of<br />badguy stores and forwardsa copy of all emails received<br /><br /><br />Dear Joe, please click onthe link below to resetyour password...<br />Mail is sent viabadguy's mailserver!<br />ISP mail server<br />(<br />Damn! I forgotmy password<br />Badguy's mail & DNS server @ <br />bigbank's web server<br />(<br />email arrives inuser's inbox – theyhave no idea it has<br />been intercepted<br />Normal web traffic<br />Unsuspecting user clicks "I forgot my password" on bigbank's web site. User enters his email address as:<br />
  23. 23. What's the fix?<br />There isn't one really, it's a fundamental protocol problem<br />Dan Kaminsky found that with existing DNS server implementations, you could hijack a domain in under 10 seconds<br />So he worked quietly with various vendors until a co-ordinated patch could be released<br />Implement better TXID randomisation<br />Add source port randomisation<br />This only makes the attack harder, it does not "fix" it<br />© 2010 tuscany networks<br />Slide 23<br />
  24. 24. Source port randomisation<br />One problem was that nearly every DNS implementation was sending DNS queries from the same UDP source port<br />Even though there are nearly 65000 available ports!<br />So a hacker only had to guess the TXID<br />Vendors added source port randomisation so that a hacker has to guess both the source port AND the TXID<br />Some implementations are better than others though<br />BIND uses a range of 16,384 ports<br />MS-DNS uses approx. 2,500 ports<br />Regardless, true randomisation is very hard to achieve with computer systems<br />© 2010 tuscany networks<br />Slide 24<br />
  25. 25. Still not a fix<br />Although many people have upgraded, it is still not a complete fix<br />With enough bandwidth, or a botnet, it is still possible to perform cache poisoning<br />Russian researcher EvgeniyPolyakov demonstrated an attack against fully patched servers that was successful after approx. 10 hours<br />Firewalls doing NAT can also "de-randomise" the source port thus rendering the fixes useless<br />Typically all queries will go out from the same NAT source port even if the DNS server is randomising it<br />© 2010 tuscany networks<br />Slide 25<br />
  26. 26. Is there a permanent solution?<br />The only real way to fix this is to deploy the DNS Security Extensions (DNSSEC)<br />DNSSEC adds cryptographic checksums to DNS responses that authenticate the data<br />If someone poisons a cache, the checksum will not validate and the response will be discarded<br />But DNSSEC is hard to do, and requires widespread adoption<br />© 2010 tuscany networks<br />Slide 26<br />
  27. 27. DNSSEC Basics - Signing<br />www IN A<br />secure hashfunction<br />digital signature(RRSIG record)<br />hash value<br />signed record<br />www IN A<br />encrypt withmy private key(kept secret)<br />www IN A RRSIG ....<br />© 2010 tuscany networks<br />Slide 27<br />
  28. 28. DNSSEC Basics - Validation<br />signed record<br />www IN A<br />www IN A RRSIG ....<br />www IN A<br />digital signature(RRSIG record)<br />hash value 1<br />secure hashfunction<br />decrypt withmy public key(published in DNSKEY record)<br />hash value 2<br />hash value 1<br />hash value 2<br />=<br />Data validates<br />hash value 1<br />hash value 2<br />!=<br />Data does not validate<br />© 2010 tuscany networks<br />Slide 28<br />
  29. 29. DNSSEC Basics – Chain of trust<br />How do you know that I am legitimate?<br />A chain of trust ensures you have been validated<br />Your parent validates you<br />Their parent validates them<br />All the way up to the root<br />Although the root is now signed, not all TLDs are<br />Still waiting for .COM and .NET for instance<br />.UK is signed, but not .CO.UK (yet!)<br />© 2010 tuscany networks<br />Slide 29<br />Not yet signed!<br />
  30. 30. DNSSEC is an enabler for better security<br />DNSSEC provides the underlying infrastructure for DNS authentication, but is difficult to manage<br />For instance, MS-DNS server DNSSEC management is all done on the command line<br />In time, the tools and processes will be developed to automate and simplify it<br />Some IPAM systems like Infoblox already do it<br />It's still early days, the root domain was only signed 3 months ago<br />.COM and .NET are due Q1 2011<br /> we may see widescale adoption next year<br />© 2010 tuscany networks<br />Slide 30<br />
  31. 31. What can you do?<br />Get DNSSEC running in your lab, be ready<br />When your parent domain offers it, you have the option<br />Deploy on your external DNS, don't worry about the internal DNS yet<br />Desktop OS vendors need to do some catching up<br />Windows 7 does not do DNSSEC validation yet, so the upstream DNS server has to do it on the client's behalf<br />© 2010 tuscany networks<br />Slide 31<br />
  32. 32. If you can't implement DNSSEC...<br />Monitor your name servers<br />Processing querylogs is hard work but tuscany networks have a tool that can automate this<br />...and give you a nice GUI too!<br />Keep an eye on your query load<br />You are looking for a large increase in "NXDOMAIN" type responses<br />Especially if the host name being looked up is changing between each query<br />Or you may be able to detect queries utilising that are using sequential TXID's<br />Remember, all your DNS servers are vulnerable!<br />© 2010 tuscany networks<br />Slide 32<br />
  33. 33. Thank you<br />Come visit us on stand 222:<br />Discover more about DNS<br />Have you deployed DNSSEC? What has been your experience?<br />Get more info on DNS & DHCP Activity Monitor<br />Discuss any issues you may have<br />Find out more about the IP Address Management solutions we can offer<br /><br />© 2010 tuscany networks<br />Slide 33<br />