DNS poisoning also referred to as DNS spoofing, is a type of network security hacking in which the Domain Name System data is corrupted. False data is put into the cache of the DNS resolver, causing the DNS server to return bad records. This results in traffic being deflected from the intended destination.
A DNS poisoning attack is usually done via URLs delivered through spam emails. These emails want to trick users into clicking the received URL.
How DNS works
A DNS server translates a domain name or URL like google.com into an IP address, which machines use to make connections.
To increase the performance of the server, it typically caches the translation for a period of time. If a request is received for an already saved translation, the reply will be given without asking a server.
When a false translation is received and cached by the DNS, it becomes poisoned. It then sends wrong information to the client.
The Internet does not have just one DNS server, as that would be very inefficient. Internet Service Providers (ISP) run their very own DNS servers, which caches information from other trusted DNS servers.
Your home router also serves as a DNS server, that caches the information from your ISP’s DNS servers. Your system has a local DNS cache so that it can refer to DNS lookups quickly, which it has already performed instead of performing a new DNS lookup every time.
Read more about what is a DNS cache and how does it work
DNS cache poisoning
It is possible for a DNS cache to be poisoned when it contains an incorrect cache entry. For instance, when an attacker steals the control of a DNS server and makes changes to some of the information on it.
Let’s say they make google.com actually point to a different IP address owned by the attacker. That DNS server would make its users look for google.com at the wrong address. The attacker’s IP address might be for some malicious phishing website that can harm your system.
This type of DNS poisoning is also very contagious. For example, if many Internet Service Providers are getting the same tainted DNS information from this compromised server, the poisoned DNS entry can completely spread across these Internet Service Providers and get cached there.
This compromised DNS information will then spread to various home routers, and the DNS server will then cache it on computers as they try to look up the DNS entry. They will receive the incorrect responses and save them on the system.
How DNS poisoning works
DNS cache poisoning is done through the code usually found in URLs sent through spam emails. These emails try to make sure the users click on the received URL, which will definitely affect their computers.
Images and banner ads found in spam emails and untrustworthy websites can also be used to redirect users to this code. Once the computer is poisoned, it will take users to fake websites, spoofed to look like the real thing. This will expose them to different risks like keyloggers, spyware or worms.
DNS cache poisoning attacks
Usually, ISPs or user organizations provide DNS servers to networked computers. To increase resolution response, performer organization networks use DNS servers to catch previously obtained information. Users that get hosted by compromised servers get affected when a single DNS is poisoned.
Before a DNS poisoning attack can be done, there must be a loophole in the DNS application. A server must validate that DNS responses are gained from the authentic source because the server may cache bad entries locally and give them to the users that made that exact request.
An example is when an attacker parodies an IP address entry for a particular website and changes it to a new IP address that they control. Therefore, the attacker creates documents on a server they control with similar names to that particular server.
The files created mostly contain harmful contents, like computer viruses or worms. Any user whose system has used the compromised DNS server can get deceived into accepting the compromised materials coming from the non-genuine server and accidentally download the harmful content.
DNS Poisoning Risks
DNS poisoning causes many risks. It is easy to spoof IP addresses of banking and retail websites. This means that sensitive information like credit card details, passwords and so on can easily be stolen. If ISP sites are spoofed, a user’s computer can get compromised.
Finally, it is difficult to eliminate DNS cache poisoning, since mere cleaning of the infected server does not remove the problem, and clean systems connecting to a compromised server will definitely get compromised again. Flushing your DNS cache can resolve this issue.
Preventing DNS poisoning
For starters, to prevent DNS poisoning IT personnel need to configure DNS servers to depend on trusted relationships with other DNS servers as little as possible. Reducing trust relationships among servers makes it very hard for attackers to make use of their own DNS servers to poison targeted servers.
Other than limiting trust relationships among DNS servers, IT personnel need to ensure that the most recent DNS version is being used. DNS’ that use BIND version 9.5.0 or later include features like cryptographically-encrypted transaction IDs and port randomization.
Cryptographically-encrypted transaction IDs and port randomization help in preventing DNS poisoning attacks. To further prevent DNS poisoning attacks, IT personnel need to configure their DNS servers to limit recursive queries and store only data associated with the requested domain.
They should also limit query responses to provide only information of the requested domain. The DNS server needs to be maintained to make sure that services that are not needed are removed. To further prevent DNS poisoning, IT personnel can implement the DNSSEC technique on the DNS server.
DNSSEC was created for caching resolvers serving the applications and to protect applications from using manipulated or forged DNS data, like the one created by DNS cache poisoning. All responses from DNSSEC protected zones are signed digitally.
By looking at the digital signature, a DNS resolver will be able to see if the information provided is identical — that is unmodified and complete — to the information provided by the zone owner and distributed on an authoritative DNS server. IP address protection is the primary concern of many users.
DNSSEC can protect all data published on the DNS server, including the text records (TXT) and the mail exchange records (MX). DNSSEC can be used to combine other security systems that provide feedback about cryptographic certificates kept in the DNS like certificate records, IPSec public keys, SSH fingerprints, and TLS Trust Anchors.
DNSSEC does not provide data confidentiality. To be precise, not all DNSSEC responses are encrypted but they are authenticated. DNSSEC doesn’t directly protect against DoS attacks, though it provides some indirect benefits.
The DNS lookup procedure for DNSSEC
From a DNS lookup result, a security-conscious DNS resolver can dictate whether the authorized name server for that domain supports DNSSEC, whether the response is secure, and whether there is any form of error. The lookup procedure varies for recursive name servers like ISP name servers, and for stub resolvers like those integrated by default in mainstream operating systems (like the Windows stub resolver). Microsoft Windows makes use of a stub resolver and Windows 7 uses a non-validating — but DNSSEC-aware — stub resolver in particular.
Cryptographically, to know if a domain is absent there is a need to label the answer to every query of a non-existent domain. Though this is not an issue for online signing servers, for which keys are available online.
Moreover, DNSSEC was created to use offline computers to sign records so that the zone-signing keys can be stored in cold storage. This can create an issue when trying to authenticate answers.
To query non-existent domains, it is not possible to pre-generate an answer for every hostname query possible. The first solution to this issue was to design NSEC records for all pairs of domains in a particular zone.
Therefore, if a client requests for a record that is non-existent such as k.example.com, the server would answer with an NSEC record that states that nothing exists among a.example.com and z.example.com. However, this technique leaks more information about that zone than the traditional, unauthenticated NXDOMAIN errors since it shows real domain existence.
Prevention and Mitigation of DNS Poisoning
Many DNS poisoning attacks can easily be prevented by the reduction of trust in the information received from external DNS servers.
Another tactic is to ignore DNS records received that are not very applicable to the query. DNS poisoning attacks can also be reduced on the application layer or transport layer when point-to-point validation is performed on the systems once the connection has been established. A typical example of this type of procedure is the use of digital signatures and Transport Layer Security (TLS).
For example, by using the secured HTTP version which is HTTPs, users can check if the digital certificate of the server is valid and that it belongs to the website’s presumed owner.
Likewise, the remote login programme, which is known as secure shell (SSH), inspects at the endpoints the digital certificates before it proceeds with the spell.
For software that automatically downloads updates, the software can locally include a duplicate of the signed certificate and authenticate the signature kept in the application update with that of the certificate embedded.
Since we are all going digital, DNS poisoning poses a very big threat to our information and day-to-day activities. DNS poisoning has given attackers the ability to compromise systems remotely without having physical access to that system.
Preventing DNS poisoning and cache poisoning is very important, therefore administrators need to implement a less trusting approach towards other servers.
They also need to implement techniques like DNSSEC or updating their servers to the latest versions, with features like cryptographically-encrypted transaction IDs, and port randomization.