securing and monitoring the domain name system
TRANSCRIPT
© 2010 tuscany networks
Who are we?
The UK’s Leading IP Address Management and DNS SpecialistsDomain Name System (DNS)Dynamic Host Configuration Protocol (DHCP) IP Address Management (IPAM)
14+ years experience in the “DDI” marketRecognised by Gartner in 2009 DDI MarketScope report
Over 100 large corporate customers including many global deploymentsFinance, telcos, retail, manufacturing, service providers, transport, government, education
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 serviceThese are known as DNS servers or name serversMultiple servers can be deployed to provide resilienceClients 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
DNS Server
What is the IP addressof news.bbc.co.uk?
news.bbc.co.uk =212.58.244.56
Slide 5 © 2010 tuscany networks
© 2010 tuscany networks
DNS Security problems
DNS has traditionally had very little securityIt was designed in an era when the Internet was still relatively small, and people trusted each otherDNS messages are sent in plain text with no authenticationThe protocol is simple and easy to spoof
Over the years, various attacks have been publicised, e.g.Denial of ServiceWPAD spoofingCache poisoning
Slide 6
© 2010 tuscany networks
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
Slide 7
DNS Server
Maliciousupdates
DNSQuery
Web traffic
Malicious web server
Maliciousresponse
© 2010 tuscany networks
Transaction Identifiers
Every DNS query has a transaction id (TXID) comprising a 16 bit number16 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 acceptedThis 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
Slide 8
© 2010 tuscany networks
Transaction IDs (TXIDs) in use
Slide 9
bigbank's DNS Server(ns1.bigbank.com)
User
What is the IPaddress ofwww.bigbank.com?(TXID=36452)
What is the IP addressof www.bigbank.com?(TXID=28736)
www.bigbank.com =212.140.250.23(TXID=28736)
www.bigbank.com =212.140.250.23(TXID=36452)
Cache
ISP or corporateDNS Server
Response TXID matches query TXID
What is the IP addressof www.bigbank.com?(TXID=13423)
root/GTLD servers
I don't know, talk to bigbank's DNS servers(TXID=13423)
© 2010 tuscany networks
TXID Prediction
Amit Klein of Trusteer found that BIND and MS-DNS didn't generate a suitably random TXID
BINDIf the current TXID is even, the next one would be one of only 10 possible valuesAlso possible, with 13-15 queries, to predict all successive TXIDsOlder versions just used a sequentially increasing number
MS-DNSCould 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 TXIDInducing a lookup to your name server is easy, just send an email
Slide 10
© 2010 tuscany networks
Monitoring the TXID by inducing a name server to query yours
Slide 11
Victim's DNS Server
Badguy
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 addressof 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?
Log the TXID
What is the IP addressof smtp.badguy.com?
root/GTLD servers
I don't know, talk to badguy's DNS servers
Badguy's mail server (smtp.badguy.com)
Victim's mail Server (bigbank.com)
HELO: smtp.badguy.com.MAIL FROM: [email protected] TO: [email protected]: Hi, this mail will bounceback and cause you to look upmy mail server using DNS.
... and repeat!
Badguy's DNSServer (badguy.com)
© 2010 tuscany networks
Monitoring the TXID by directly querying the victim name server
Slide 12
Victim's DNS Server (e.g. ISP or corporate DNS server)
Badguy's DNSServer (badguy.com)
Badguy
What is the IP addressof nohost2.badguy.com?(TXID=some number)
What is the IP addressof nohost1.badguy.com?(TXID=some number)
What is the IP addressof nohost3.badguy.com?(TXID=some number)
What is the IPaddress ofnohost1.badguy.com?nohost2.badguy.com?nohost3.badguy.com?
Log the TXID... and repeat!
What is the IP addressof nohost1.badguy.com?(TXID=some number)
root/GTLD servers
I don't know, talk to badguy's DNS servers
© 2010 tuscany networks
Cache poisoning
If you monitor the TXID and find a pattern it is very easy to spoof a replyWe 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...
Slide 13
© 2010 tuscany networks
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
Slide 14
People Chances of two or more people having the same birthday
10 12%
20 41%
23 50.7%
30 70%
50 97%
100 99.99996%
Number of reply messages
Chances of guessing the right message ID
200 ~20%
300 ~40%
500 ~80%
600 ~90%
© 2010 tuscany networks
Poisoning a single entry
Slide 15
Victim's DNS Server (e.g. ISP or corporate DNS server)
bigbank DNS server (ns1.bigbank.com)
Badguy
What is the IP addressof www.bigbank.com?(TXID=1001)What is the IP
address ofwww.bigbank.com?
www.bigbank.com =212.140.250.23(TXID=1001)Response is ignored if spoofed TXID matched!
Spoofed responsewww.bigbank.com =66.66.66.66(TXID=1000)mismatches
Spoofed responsewww.bigbank.com =66.66.66.66(TXID=1001)success!
Spoofed responsewww.bigbank.com =66.66.66.66(TXID=1002)mismatches
Cache
Badguy's fakebigbank web site @ 66.66.66.66
What is the IP addressof www.bigbank.com?
www.bigbank.com =66.66.66.66
Unsuspecting userenters password/credit card details
What is the IP addressof www.bigbank.com?(TXID=1000)
root/GTLD servers
I don't know, talk to bigbank's DNS servers
© 2010 tuscany networks
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 backi.e. it's a race and we may only get 1 shot at itOnce 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!
Slide 16
© 2010 tuscany networks
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!
Slide 17
Photo credit: "Dave Bullock / eecue" http://eecue.com
© 2010 tuscany networks
Hijacking a whole domain
Slide 18
Victim's DNS Server (e.g. ISP or corporate DNS server)
bigbank DNS server (ns1.bigbank.com)
Badguy
What is the IP addressof www123456.bigbank.com?(TXID=1000)
What is the IP address ofwww123456.bigbank.com? Spoofed response
name server=ns1.bigbank.comns1 glue record=66.66.66.66(TXID=1000) mismatches
Spoofed responsename server=ns1.bigbank.com ns1 glue record=66.66.66.66(TXID=1001) success!
Spoofed responsename server=ns1.bigbank.comns1 glue record=66.66.66.66(TXID=1002) mismatches
Cache
Badguy's DNSserver
root/GTLD servers
I don't know, talk to ns1.bigbank.com
What is the IP addressof www123456.bigbank.com?(TXID=1001)
...keep repeating withdifferent random hostnames until we win!
Real response =name server=ns1.bigbank.comns1 glue record=212.140.250.22(TXID=1001)Response is ignored ifspoofedTXID matched!
What is the IP address ofwww123457.bigbank.com?etc. etc.
© 2010 tuscany networks
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!
Slide 19
© 2010 tuscany networks
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 emailJust 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!
Slide 21
© 2010 tuscany networks
Email hijack in action
Slide 22
ISP DNS server(bigisp.net)
Cache
Badguy's mail & DNS server @ 66.66.66.66
Unsuspecting user clicks "I forgot my password" on bigbank's web site. User enters his email address as: [email protected]
bigbank's DNS server(Cache poisoned by badguy)
ISP mail server(smtp.bigisp.net)
bigbank's web server(www.bigbank.com)
Normal web traffic
Web server needs tosend email: What is the IP address of smtp.bigisp.net?
Recursive lookup for smtp.bigisp.net
smtp.bigisp.net=66.66.66.66
badguy stores and forwardsa copy of all emails received
Dear Joe, please click onthe link below to resetyour password...
email arrives inuser's inbox – theyhave no idea it hasbeen intercepted
Damn! I forgotmy password
Mail is sent viabadguy's mailserver!
© 2010 tuscany networks
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 randomisationAdd source port randomisation
This only makes the attack harder, it does not "fix" it
Slide 23
© 2010 tuscany networks
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 thoughBIND uses a range of 16,384 portsMS-DNS uses approx. 2,500 ports
Regardless, true randomisation is very hard to achieve with computer systems
Slide 24
© 2010 tuscany networks
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 poisoningRussian researcher Evgeniy Polyakov 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
Slide 25
© 2010 tuscany networks
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
Slide 26
DNSSEC Basics - Signing
www IN A 194.72.65.34
hash value digital signature(RRSIG record)
www IN A 194.72.65.34
www IN A RRSIG ....
encrypt withmy private key(kept secret)
signed record
secure hashfunction
© 2010 tuscany networksSlide 27
DNSSEC Basics - Validation
www IN A 194.72.65.34
hash value 2
digital signature(RRSIG record)
www IN A 194.72.65.34
www IN A RRSIG ....
decrypt withmy public key(published in DNSKEY record)
signed record
hash value 1
hash value 1 hash value 2
hash value 1 hash value 2
=
!=
Data validates
Data does not validate
secure hashfunction
© 2010 tuscany networksSlide 28
© 2010 tuscany networks
DNSSEC Basics – Chain of trust
How do you know that I am legitimate?
A chain of trust ensures you have been validatedYour parent validates youTheir parent validates themAll the way up to the root
Although the root is now signed, not all TLDs areStill waiting for .COM and .NET for instance.UK is signed, but not .CO.UK (yet!)
Slide 29
Not yet signed!
© 2010 tuscany networks
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 itSome 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
Slide 30
© 2010 tuscany networks
What can you do?
Get DNSSEC running in your lab, be readyWhen your parent domain offers it, you have the option
Deploy on your external DNS, don't worry about the internal DNS yetDesktop OS vendors need to do some catching upWindows 7 does not do DNSSEC validation yet, so the upstream DNS server has to do it on the client's behalf
Slide 31
© 2010 tuscany networks
If you can't implement DNSSEC...
Monitor your name serversProcessing 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 loadYou are looking for a large increase in "NXDOMAIN" type responses
Especially if the host name being looked up is changing between each queryOr you may be able to detect queries utilising that are using sequential TXID's
Remember, all your DNS servers are vulnerable!
Slide 32
© 2010 tuscany networks
Thank you
Come visit us on stand 222:Discover more about DNSHave you deployed DNSSEC? What has been your experience?Get more info on DNS & DHCP Activity MonitorDiscuss any issues you may haveFind out more about the IP Address Management solutions we can offer
Slide 33