Sunday | 5 July, 2009
CSO
Slideshow: How DNS cache poisoning works
Tips to thwart DNS cache-poisoning attacks
Bob Halley (Network World) 21/10/2008 09:34:00
  • 1 of 8

There has been a long history of attackson the DNS ranging from brute-force denial-of-service attacks to targeted attacks requiring specialized software. In July 2008 a new DNS cache-poisoning attack was unveiled that is considered especially dangerous because it does not require substantial bandwidth or processor resources nor does it require sophisticated techniques. Let
There has been a long history of attackson the DNS ranging from brute-force denial-of-service attacks to targeted attacks requiring specialized software. In July 2008 a new DNS cache-poisoning attack was unveiled that is considered especially dangerous because it does not require substantial bandwidth or processor resources nor does it require sophisticated techniques. Let's take a look at how DNS cache poisoning works and what can be done to prevent it.
There has been a long history of attackson the DNS ranging from brute-force denial-of-service attacks to targeted attacks requiring specialized software. In July 2008 a new DNS cache-poisoning attack was unveiled that is considered especially dangerous because it does not require substantial bandwidth or processor resources nor does it require sophisticated techniques. Let's take a look at how DNS cache poisoning works and what can be done to prevent it.Caching server critical: The primary function of DNS is to return an IP address for a given domain name. Virtually every contemporary Internet application depends on DNS -– browsing, email, SIP etc. 
1. User inputs www.bigbank.com 
2. If the domain isn’t cached, the server consults with an Authoritative DNS server. 
3. The address is cached and forwarded to the end user, who is then connected.Expiration of domain entry opens door: With cache poisoning an attacker tries to insert a fake address entry into a DNS server. In the past an attacker could only attack a DNS server when it was refreshing a cache entry.

1. Attacker figures out when a domain entry will expire on a caching server using readily available tools.
2. Attacker "races" the legitimate DNS server, trying to get the caching server to accept a fake response.
3. In order to be accepted the fake response must match query parameters of the actual response.Attacker tries to beat authoritative DNS: If the attacker's fake answer arrives before the "real" Authoritative server's answer, and the attacker has guessed the query parameters correctly, most caching servers will accept the response and then use the address provided by the attacker to respond to queries for the domain being attacked.

1. Attacker gets DNS to accept fake response (matches query parameters): www.bigbank.com Is at 6.7.8.9 (an address controlled by the attacker).
2. DNS Server responds to user queries with fake address.Surfers never see the diversion: Subsequent traffic intended for a legitimate domain is redirected to the server controlled by the attacker. This happens without the subscriber knowing, which is why this attack is so dangerous.Flooding the cache server makes it vulnerable: Until recently, an attacker could only poison a caching server entry when the Time to Live (TTL) of the entry expired. Now the door has been thrown wide open.

1. Attacker sends numerous fake questions to the caching DNS server, knowing the server can not answer: Q) Where is 123xyz.bigbank.com? This forces the caching server to keep making requests of the Authoritative DNS server, greatly increasing the chances for the attacker to slip in fake answers.
2. The fake answers the attacker feeds to the caching DNS can also further comprise the server by pointing to other fake resources like name servers: A) I don't know where 123xyz.bigbank.com is. But FAKEnameserver.bigbank.com knows, and they can be reached at 6.7.8.9.Attacks come from multiple pointsAre these tips and insights helpful? Have best practices of your own to share?

Comments

Post new comment

Login or register to link comments to your user profile, or you may also post a comment without being logged in.
The content of this field is kept private and will not be shown publicly.
Enter the fully qualified URL, eg. http://www.example.com/
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

 
Whitepaper

IDC Report: Managed Communications - Delivering on a Holistic ICT Vision

IDC believes that advances in technology combined with convergence, consolidation, centralisation and consumerisation drivers are set to change communications business models and the ICT landscape. Read on and enable your business to do more with less.

Sponsored Links