User:ReverseEngineered/DNS Forgery

DNS forgery consists of an attacker pretending to be the authoritative server for a domain. When the victim requests a DNS record from the authoritative server, the attacker responds before the authoritative server in such a way that the victim believes they have received an authoritative response. The attacker typically uses this to trick the victim into believing the address for that domain is one of his own, enabling attacks such as pharming.

A Typical DNS Request

See Domain Name System for a complete description.

When a user wishes to resolve the IP for a given hostname, their client sends a request to a DNS server. The request includes:

• A 16-bit unique transaction identifier, used to match up responses with outstanding queries.
• A question, including the hostname and the type of record required -- typically an A record; the IP address of the host.

The DNS server will respond with a similar message that includes:

• The same transaction identifier used in the request.
• The question that was sent in the request.
• An answer to the question (the address of the host), if it is known.
• An authority, indicating what other DNS server would be able to answer the question.
• Any additional records which may be required. This typically includes the address of the DNS server given in the authority section.

The client believes that this came from the same server that the request was sent to because the response comes from the same IP address, is received on the same port that the client sent from, and contains the same unique identifier.

Forging a DNS Response

In order to forge a response, an attacker's response must contain the same unique identifier and question, appear to come from the same IP that the request was sent to (see IP spoofing), and be received on the same port that the request was sent from. Most importantly, it must be received before the legitimate response from the real DNS server.

How many of these pieces the attacker knows depends on the way the attack is made. If the attacker can sniff the original request, he will know all of the above information and can immediately send a forged response. This isn't always possible, but it also isn't necessary -- the attacker can use what information is available to him and attempt to guess the remainder.

For example, say the attacker had the ability to cause the victim to make DNS requests. This may be possible if the victim is a public DNS resolver (see DNS cache poisoning) or if the attacker can lure the victim into visiting a webpage which contains links to domains of the attacker's choosing. Since the attacker knows which domain names will be looked up, he can predict what questions the victim will send and what DNS server the requests will be made to. If the attacker makes the requests himself, he knows when the requests are made and can send the forged responses immediately. If he can't control when the requests are made, he may be able to detect them. In the example of the webpage containing links, the attacker may assume that the links will be resolved in a specific order. If a link points to a server he controls, he can detect this lookup and predict what lookup the victim will make next.

The attacker doesn't generally know which source port the request was made from, but for many clients this can be easily predicted.

Once the request is made, the attacker has a limited amount of time to send the forged response. The client will accept the first valid response that it receives, ignoring all others. Since the original request has been sent out to the real DNS server, the attacker has to create a valid forged response before the real response from the DNS server is received. The attacker can send multiple forged responses during this time, including guesses for any information that he doesn't know. The number of guesses he can make depends on the amount of bandwidth the attacker and victim have and the latency between the victim and the real DNS server. A decrease in the amount of information the attacker needs to guess, or an increase in the latency of the DNS server's reply, increases the chances that the attacker will send a valid forged response to the victim before the real response is received from DNS server.

Uses

The result of DNS forgery is to trick the victim into believing that the IP address of the host is something other than what it really is. This can be used to make the attacker appear to be a trusted host or a trusted third party. This would allow the attacker to do things that any other system would not be allowed to. For example, if an attacker could trick the victim into believing that windowsupdate.microsoft.com pointed to the attacker's IP, the attacker could trick the victim into downloading and installing malicious code.

A common application of DNS forgery is combined with DNS cache poisoning, resulting in a DNS amplification attack. By convincing a public DNS cache (one used by many people) to accept and cache the forged DNS record, the attacker can effectively trick many people at once through a single attack. This is commonly used in pharming.

Other uses include:

• Redirecting a popular search engine to a pop-up ad site
• Redirecting a bank website to gain access to account passwords
• Redirecting news sites to inject false stories and manipulate stocks

Other Factors

The probability of successfully forging a DNS response can be increased by several factors:

• Some DNS resolvers will send several multiple requests for the same domain name if asked to. In this case, they will accept the first valid response to any of these requests and use it for all of the outstanding requests for the same domain name. Using a birthday attack, the attacker can make several similar requests and send several responses. Assuming the unknown parts of the client's request (the transaction ID and the source port) are different for each request, the birthday paradox means that, instead of $N$ responses, the attacker only needs to send approximately $1.25\cdot {\sqrt {N}}$ requests and responses to maintain the same probability of success. Assuming the attacker can make a fixed number of guesses, this greatly increases his probability of success.
• Even in cases where the transaction ID and/or the source port are random, they are chosen by a pseudo-random number generator (PRNG). Flaws in the PRNG may allow the attacker to narrow down the possibile values of the random numbers, greatly increasing his chance of guessing them correctly.
• The number of guesses that the attacker can make depends heavily on the time it takes for the real DNS server to respond. If the attacker can affect the latency of the DNS server, such as using a denial-of-service attack, he can increase the time it takes for the real DNS server to respond, allowing him more guesses and giving him a greater chance of succeeding.

Prevention

The practicality of this attack depends on the ability of the attacker to masquerade as the real DNS server. This includes spoofing the response to look like it came from the real DNS server and guessing any unknown information in the original request.

The more information that is unknown to the attacker, the more guesses the attacker must make and the less likely he is to guess correctly. Using random transaction IDs and source ports leaves more information unknown and increases the number of guesses the attacker must make, decreasing the probability that he will correctly guess before the real DNS server responds.

DNSSEC attempts to solve the problem of authenticating that the response actually came from the real DNS server. Utilizing public-key cryptography, the DNS server would sign the response using its private key. The requester could verify the authenticity of the response using the DNS server's public key, which it would obtain through a public key infrastructure.

References

• Mockapetris, P.: RFC1035 - Domain names - implementation and specification. 1997. http://www.faqs.org/rfcs/rfc1035.html
• Schuba, Christoph: Addressing Weaknesses in the Domain Name System Protocol. August 1993. http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf
• Klein, Amit.: BIND 9 DNS Cache Poisoning. March 2007. http://www.trusteer.com/bind9dns
• http://www.isotf.org/news/DNS-Amplification-Attacks.pdf
• http://www.kb.cert.org/vuls/id/800113