DNS spoofing and cache poisoning are IT security attacks on the Domain Name System to forge the mapping between a domain name and its IP address. The purpose is to steer traffic to another computer unnoticed, for example, to carry out a phishing or pharming attack. If traffic is directed to an unreachable destination, it can be used to carry out a denial-of-service attack.
The terms DNS spoofing and cache poisoning come from different attack methods, but they have the same purpose. Cache poisoning refers to attacks in which forged resource records are injected into the victim’s DNS cache. DNS spoofing refers to attacks in which fake resource records are sent using IP spoofing. A related attack is DNS hijacking, in which a DNS resolver returns false responses.
A historical cache poisoning attack method is the addition of additional, spoofed DNS records to legitimate DNS responses. If the requester takes over resource records from the response without checking them, fake resource records for any domain name can be fed into the DNS cache.
---
How it works
In public DNS, individual DNS servers are authoritative only for parts of the entire DNS. If a DNS server receives a request for an area where it is not authoritative, it can forward the request to the next DNS server. To avoid unnecessary load, DNS servers can cache other servers’ responses to requests locally. In this case, the above request could be forwarded to another server and a response could be sent immediately. A DNS participant who sends a request to a name server carries the received response into its cache for a predetermined amount of time without checking it. In addition to the actual response, additional (legitimate) data (glue records) are often transmitted, which are also stored in the cache. Cache poisoning relies on hiding one or more fake resource records in this additional data.
More precisely, in the authority section of the response packet, the name to be redirected (for example, thecustomizewindows.com) is entered as the alleged DNS server, and in the Additional section, the IP address (for example, 1.2.3.4) of a server controlled by the attacker.
Example of Sequence
An attacker takes control of the name server XX. It manipulates it in such a way that every time a name from the domain example.com is requested, the fake record thecustomizewindows.com 192.0.2.1 is supplied without being asked.
The public nameserver YY wants to resolve the name test.example.com. It sends a corresponding request to the responsible name server XX (controlled by the attacker). This manipulated name server responds with the correct IP address, but also provides the fake record of thecustomizewindows.com at 192.0.2.1. This is copied into the cache by the requesting server YY unchecked.
At a later point in time, a user tries to resolve the name thecustomizewindows.com and turns to the public nameserver YY. The name server finds the (fake) record in its cache and sends the IP address 192.0.2.1 back to the user in good faith.
The user wants to access thecustomizewindows.com, but is redirected to a wrong web page with the IP address 192.0.2.1.
Troubleshooting
The vulnerability in the BIND name server was fixed in June 1997 by ignoring unsolicited resource records. Only resource records from the domain actually requested (in-bailiwick ‘in the administrative district’) will be accepted. All name servers in use today perform this check before being cached.
DNS spoofing
In DNS spoofing, the attacker sends fake DNS responses that allegedly originate from the responsible name server using IP spoofing. For the attack to be successful, the spoofed response must either arrive at the attacked resolver before the legitimate response, or the responsible name server is prevented from sending a response by a denial-of-service attack. Furthermore, the parameters of the response must match the request, including the 16-bit transaction number. The attacker can send multiple fake responses at the same time to increase the probability of success in an attack attempt, but this increases the amount of resources required.
Various vulnerabilities make it easier to guess the transaction number. In BIND 8, the pseudo-random number generator was insecure, so that the transaction number could be predicted with little effort. If the attacked resolver sends an identical DNS request multiple times with different transaction numbers, the probability of success increases significantly due to the birthday paradox.
If the attack was unsuccessful, the correct resource record is cached, so the attacker cannot attempt again until the time to live has expired.
Tagged With nothing42a