securing and monitoring the domain name system

33
Securing & Monitoring the Domain Name System Paul Roberts, CTO tuscany networks

Upload: ipexpo-online

Post on 21-Aug-2015

508 views

Category:

Technology


0 download

TRANSCRIPT

Securing & Monitoring theDomain Name System

Paul Roberts, CTOtuscany networks

© 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

Why is it so deadly?

Forgot your password?

Slide 20

© 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

[email protected]

Slide 33