Hackercombat.com Presents: A Crash Course of DNS Cache Poisoning

After many years of patching and fixing of DNS name servers, it is unfortunate that there are still DNS services that are still vulnerable to DNS cache poisoning attack. This highly technical issue is very complex for a common Joe and Jill to understand, hence here in Hackercombat.com, we will give you a sort-of crash course of what is really happening. Of course, with a complex topic, there is a need to explain the basics. How does the client (browser or any internet-facing app) obtain the domain name info? Below are the steps done in the background to make it happen:

• Request a query from a client using DNS such as end user’s PC to the name server that makes inquiries.
• Based on the contents of the inquiry, the requested name server inquires from the root server in order while delegating, and obtains the result from the authoritative server with the desired domain name information.
• After receiving the request, the name server returns the inquiry result to the client.

A name server that processes inquiries can temporarily store the information of the domain name obtained during processing temporarily locally. This process is called caching and temporarily saved information is called cache. When making the same inquiries as to the contents that you did in the past, you will reply to the client using the information held as a cache without querying other name servers. The authority server can specify data for each data during the period when data is stored in the cache, which is called TTL AKA Time-To-Live.

This mechanism of caching has the effect of reducing the number of inquiries to other servers, reducing DNS load and network bandwidth, and shortening the time required for inquiries. A name server receiving a request from a client for inquiries is also called “cache server” because it often implements this cache mechanism.

In DNS, as described above, we are reducing the load and speeding up by using a cache mechanism. There is an attack called “DNS cache poisoning” that exploits this function and causes the cache server to accumulate fake DNS information as a cache. Although the impact of DNS cache poisoning varies, it is possible to have the following influence on users who use the attacked cache server.

• Change correspondence between hostname and IP address and guide it to harmful site
• Tap, tamper with contents of Web, mail
• Send spam
• Disable DNS and disable various services and applications (DoS)

DNS cache poisoning has an attack that aims at malfunctioning of DNS server software, misconfiguration, etc. In the following, we explain how to attack weak points of DNS protocol. In DNS, a 16-bit identifier “ID” is prepared in the DNS message. This is used to determine which query message it is for when it receives a response message. The cache server specifies the ID in the inquiry message and transmits it. When it receives the DNS message at a later time, the cache server checks the ID in the message and processes the same as the inquiry ID as the corresponding response message. If the ID specified during inquiry does not match the ID included in the response packet, it is discarded as an illegal DNS message.

However, if the ID specified in the inquiry matches the ID in the received packet, the cache server judged that the received packet was sent from the correct authoritative server, and the caching server was disguised Even DNS messages are handled as the result of inquiries. DNS inquiries and responses are mainly communicated using UDP. Although UDP costs less for communication than TCP, it is relatively easy to impersonate a communication packet, so it is possible to disguise DNS messages by modifying the IP address, port number, and ID in the packet.

In particular, since it is only 16 bits (= 65536 ways) to be taken by the ID, it has been pointed out that it is not impossible to make a match by guess or round-robin, so we have to exploit this DNS protocol vulnerability The caching poisoning attack method used has been known for a long time.

1. The attacker sends an inquiry to the target cache server for the domain name to which fake information is to be sent
2. The cache server which received the inquiry inquires the external authority server
3. The attacker sends a fake response packet to the cache server before the correct response is returned from the authority server
4. If the ID of the inquiry message sent by the cache server in 2. and the ID of the fake message sent by the attacker in 3. match, the attack succeeded

However, the cache poisoning attack needs to impersonate the response packet of the inquiry of the cache server. Also, while the cache is in effect (TTL), the cache server does not query external authoritative servers. That is, since the opportunity to send a spoof response packet is once every expiration (the length of TTL), even if matching the ID itself is not difficult, the TTL can be set long enough If so, the success rate of cash poisoning could be kept low.

• Requirements for conventional attack methods
• The attacker matches the ID used by the cache server in the inquiry with the ID of the spoofed response packet
• The attacker sends a fake response packet earlier than the response from the authority server
• It does not exist in the cache, or the cache has expired

However, in August 2008, a security researcher, Dan Kaminsky, announced a new caching poisoning attack method. As mentioned above, until now, if the TTL is sufficiently long, it has been thought that the success rate can be lowered. However, since the attack method by Mr. Kaminsky is able to attack irrespective of the length of the TTL. In this attack method, by querying the cache server for a random domain name, it is possible to forcibly make an inquiry to the outside, even if the attack fails due to ID mismatch, etc., change the domain name and immediately From being able to rechallenge, cache poisoning attacks can be done more efficiently than the methods considered so far. This method takes the name of Mr. Kaminsky and is called “Kaminsky attack”.

Even in the traditional attack method and Kaminsky attack method, as a precondition, it is decided whether the response packet in DNS is spoofed by ID, and the ID can take only the value of 16 bits and the total We are aiming to be vulnerable that we can hit each other. Therefore, as a countermeasure, for example, if the bit length of ID is increased to 32 bits, 64 bits, etc., it becomes difficult to guess the ID and it becomes difficult to attack. However, to increase the bit length, it is almost impossible to realize it because the DNS protocol itself must be changed.

Therefore, as another method of making it difficult to generate spoofed response packets, a method called Source port randomization was considered. This is because the UDP port number used when making inquiries from the cache server to the authority server is not selected in a fixed or narrow range. It is however is selected randomly from a wide range number and used for communication, thereby disguising a reply packet It is a way to make it difficult. The difficulty level of camouflage becomes difficult in proportion to the use range of port numbers.

This Source port randomization is released by each DNS vendor. However, as for Source port randomization, attention ports are fixed and limited in some cases depending on cache server setting, NAT, a firewall device, etc., so the effect may decrease, so be careful. Cache poisoning attacks are performed by an attacker by disguising a DNS response packet and sending it to the cache server.

Therefore, it is necessary for attackers not to be able to attack freely. In other words, you can reduce the risk by limiting clients that can query the cache server, blocking spoofed packets at the source address, and so on. Furthermore, since the attack method mainly predicts the ID on a round-robin basis, when an abnormal DNS packet (there is a response of an ID which is not used for the inquiry or a response from the authority server is inquired more than the number of times the response from the authority server is inquired It is observed in large quantities). By detecting and defending these, it is possible to protect the cache server.