Securing and Monitoring the Domain Name System
 

Securing and Monitoring the Domain Name System

on

  • 599 views

In 2008, security researcher Dan Kaminsky highlighted a long-standing bug that could allow attackers to ...

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.

Statistics

Views

Total Views
599
Views on SlideShare
599
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Securing and Monitoring the Domain Name System Securing and Monitoring the Domain Name System Presentation Transcript

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