Thursday, July 6, 2006

Uses for a DNS Cache Poison

A short-lived targeted attack (black hat):

  • Identify a vulnerable DNS server upstram from your target.
  • Poison the target's upstream DNS server for a common web service they access. Broad scope (e.g. tsp.gov, google.com) or narrow scope (e.g. some.project.page.contractor.com).
  • Throw up a web server that looks reasonably like the original. Have some nasty links/exploits in tehre. Entice the user to click or enter information like logins for the original site. Collect data. Hack clients. This is the 'pharming' concept.
  • Natural end: simply stop poisoning the upstram server. The attack will end when the caches refresh the old data.
  • Quicker end: re-poison (or un-poison) the upsteam cache with the correct address.

Ideas for defense (white hat):

Determine the scope of impact

  • Create s script to do non-recursive lookups of all DNS cache servers for the suspect domain all the way to the network border (and maybe beyond into the upstream if possible). Aggregate the data for analysis.
  • Parse the data and identify cache servers that do not resolve to the expected set of IP addresses.

What's poisoned?

  • Reverse-DNS the suspected poisoned IP. Discovering what its PTR record is may reveal useful information.
  • Use an independent source (not the targeted network) to resolve the suspect domain for "real" IP addresses. Compare this to the data set.
  • Identify cache servers that do not resolve correctly.

Remediation

  • Determine the root of the poison through TTL and DNS forwarder analysis of the cache servers. Get as close to the top as possible.
  • Clear caches, starting at the border, and working inward. As cache requests are made during the flush process, the remediation will be helped along by pulling the now-correct data from the upstream caches. Conversely, starting at the bottom leaves caches vulnerable to reinfection from upstream servers.
  • If you cannot determine the poison's root, or determine that it is upstream in or beyond your ISP, consider redirecting to other upstream DNS forwarders until the main feeds are fixed. Ask the ISP for assistance if necessary.

Long term

  • Consider shifting the border (top level) DNS cache forwarders from time to time or even at regular intervals in rotation. It may change the dynamics of your network infrastructure enough to make poisoning more difficult for the attacker.
  • Ensure DNS engine patches are up-to-date. Demand the same of your upstream feeders.