Understanding the basics of DNS spoofing attacks

Last Updated on March 11, 2022

DNS spoofing attacks, also known as DNS cache poisoning, are cyber attacks that have been around for a long time and are still prevalent today. With the evolution of the technology and the apparition of DNSSEC, DNS over HTTPS (DoH), and DNS over TLS (DoT), many people perceive this cyber attack as a very difficult attack to conduct. That would be a correct assumption if these technologies were widely used in the world.

In reality, based on the statistics published by APNIC, in 2021 so far, DNSSEC validation is done only 37% of the time, which means that the traditional DNS system is still predominant today. Therefore, there is no guarantee about the authenticity and integrity of the DNS responses for most of the scenarios. In addition, DoT and DoH adoption rates are not high enough to have a significant impact. For example, according to this study done by RIPE Labs, the adoption rate of DoT is less than 1%.

That being said, let’s look at the technical details of the DNS spoofing attack. In my opinion, the first step toward mitigating an attack is to really understand how it works. From there, you will be able to know how to protect your system against such an attack.

The Domain Name System (DNS)

Before going further, we need to understand the basics of the Domain Name System (DNS).

NB: if you already know what the DNS is, jump ahead to the next section.

The concept

Nowadays, billions of devices can communicate on the Internet by using the Internet Protocol. This protocol requires that each device has at least 1 unique identifier in the network: an IP address. Basically, in order to send a message to a device, you need to know the IP address of that device. That unique identifier is the main information that network components need to route your message to the correct destination.

Actually, there are 2 versions of the internet protocol and each version has its address format (i.e. IP version 4 (IPv4) and IP version 6(IPv6)). IPv4 addresses have a 32-bits size and IPv6 addresses are even longer (128 bits), which makes them impossible to remember. That’s where the domain names come to the rescue.

A domain name is a user-friendly text value identifying a particular website, device or entity. So, instead of using an IP address to access a website, we use the domain name: google.com for example. This way, people don’t need to memorize 32-bit or 128-bit numbers. This convenient solution exists because of the Domain Name System (DNS), which is a global system allowing the translation of domain names to IP addresses.

Created in the ’80s, the DNS is a distributed naming system that keeps a set of records about resources on the Internet. To simplify the concept, you can see the DNS as an address book of computers on the Internet.

In summary, when a user browses to a website like www. siakabaro.com, the first thing that happens behind the scene consists of locating the machine corresponding to www. siakabaro.com. The browser will communicate with a DNS server to get the IP address of the machine hosting www. siakabaro.com. This procedure is called the DNS lookup or DNS resolution procedure. And then, after the DNS lookup procedure, the browser can use the IP address to send the HTTP request to the server hosting the website.

The details of the DNS lookup procedure

There are many servers involved in the DNS lookup procedure and each of them has a specific role. The following diagram shows a series of events that take place when a web browser tries to locate a server through the DNS infrastructure.

In this example, the browser is looking for the domain tools.examplewebsite.com. The top-level domain is .com, and the second-level domain is examplewebsite and the third-level domain or the subdomain is tools. In addition, we supposed that the DNS record is not available in the DNS cache of any of the resolvers. Therefore, they need to send a DNS query for the domain name.

Here are the different steps:

Step 1

The browser checks its DNS cache to see if it already has the IP address of the requested domain. Most modern browsers have their own DNS cache in memory. For example, in Google Chrome, you can flush the browser cache by opening the page chrome://net-internals/#dns. Since the domain name is not in the cache, the browser will forward the DNS query to the stub resolver of the operation system.

Step 2

The stub resolver also checks the operating system DNS cache before sending a query to the recursive DNS resolver (i.e. what we usually call the DNS server). In order to contact the DNS server, the client machine will use the IP address of the DNS setting in its network configuration.  Usually, the DNS service is provided by the Internet Service Provider (ISP).

Step 3-4

The recursive DNS resolver receives the DNS query and then processes it by sending many iterative queries to the appropriate servers. This iterative process starts with the root DNS server. Root DNS servers are critical systems that answer the DNS queries at the root level. Basically, they can return the list of DNS servers that handle top-level domain DNS queries.  Every DNS resolver knows a list of root DNS servers. Therefore, the DNS resolver contacts one of the root servers to request information about the .com top-level domain (TLD). The root DNS server returns the IP addresses of the TLD DNS servers to contact (i.e. DNS NS records).

Step 5-6

The DNS resolver sends a query to the .com TLD for the second level domain named examplewebsite. The TLD server returns the IP Address of the authoritative DNS server (i.e. DNS zone) that knows about the domain examplewebsite.com.

Step 7-8

Then, the DNS resolver sends a query to the examplewebsite.com authoritative server, to get the DNS records for the subdomain tools.examplewebsite.com. The authoritative server returns the list of IP addresses corresponding to the requested domain (i.e. DNS A records)

Step 9-10

The list of IP addresses is sent back to the browser, through the stub resolver.

In addition to these steps, it is important to note that:

1. DNS caches are available at different network nodes during this process.
2. The transport protocol used to exchange DNS messages is the User Datagram Protocol (UDP). The default port used in the DNS protocol is port 53.
3. There are many types of DNS queries and different types of DNS records as well. For example, the A record contains the IPv4 address, the AAAA record contains the IPv6 address and the MX record contains information about the SMTP email server for the domain.

Now that we understand what DNS is and how it works, let’s take a look at the DNS spoofing attack.

DNS spoofing attacks

DNS spoofing attacks are cyber attacks that consist of tampering with the DNS resolution data to redirect the internet traffic to a malicious server. By forging a fake DNS lookup response or by taking over a DNS server directly, the hacker can deceive the client to connect to the wrong IP address. For example, if the DNS query usually returns 10.1.2.3 for the domain name siakabaro.com, the attacker can return 192.1.2.3, and then the browser will send the HTTP request to 192.1.2.3 instead of 10.1.2.3. Moreover, all this redirection happens in the background and is not visible to the user.

The issue is amplified by the fact that DNS resolvers keep the tampered IP address in their cache for a period of time (TTL). Therefore, the affected DNS resolvers will keep returning this IP address until the end of the DNS cache TTL. That explains the origin of the term “DNS cache poisoning”.

Usually, DNS spoofing attacks are used by hackers to get confidential information, such as private data or passwords, or to redirect the user to a malicious website for defacement purposes. These attacks can also be used to install malware or ransomware on users’ machines.

Different types of DNS spoofing attacks

There are many variants of the DNS spoofing attacks. Let’s look at the most popular ones.

Type 1: Poisoning the DNS server cache

By poisoning the DNS server cache, the attacker can potentially impact all machines sending a DNS query to this DNS server. There are 2 well-known examples of this type of DNS spoofing attack: the birthday attack and the malicious authoritative DNS server.

Birthday attack

In the previous picture, we saw that the DNS server sends iterative requests to many servers, from the root DNS to the authoritative DNS server. All these requests and responses are sent through the UDP protocol and are not encrypted. Therefore, the DNS server validates the authenticity of a response by checking the source IP address, the destination port, and the request ID which is a 16-bit number. This verification process is fragile because the request ID is the only variable in the mix.

The Birthday attack is a brute-force attack that leverages this weakness. It consists of sending a large number of queries to the DNS server and then a large number of DNS responses with random request IDs. The goal here is to brute-force the request ID parameter. If a valid forged response arrives before the real response from the authoritative server, then the attack will be successful.

Here is a picture of the birthday attack:

Basically, if the DNS server accepts one of the forged responses, it will save this response in the cache for a period of time (TTL). For subsequent DNS queries about the targeted domain, the DNS server will return the malicious response until the record times out in the cache.

Redirect the DNS queries to a malicious authoritative DNS server

This attack is an evolution of the birthday attack. It consists of sending a large number of forged responses to the DNS server during the iterative name resolution process. Instead of returning DNS A records in the forged DNS response, the attacker just redirects the DNS server to a fake authoritative server that is under his control. This way, he can return whatever IP address he wants for any subdomain of the targeted domain. 

Here is a diagram of this exploit:

Dan Kaminsky revealed the exploit in 2008. At that time, this vulnerability forced many vendors to release patches for this vulnerability (Windows DNS server, BIND,…). 

Type 2: Forging the DNS server’s response

This is similar to the Birthday attack, but instead of targeting the DNS server, the attacker targets directly the user’s computer by sending forged DNS responses to the computer. In this case, the attacker pretends to be the local DNS server of the client. This is usually done in combination with other network attacks since the attacker needs to be in the same network in most cases.

Type 3: Hijacking the local machine settings

In this scenario, the hacker just changes the network configuration of the user’s computer to use a malicious DNS server. In order to achieve that, the hacker needs to have access to the user’s machine. Usually, attackers gain initial access by sending a bunch of spam emails to the user and hope that he clicks on a link in these emails (i.e phishing). Once the Trojan code is executed on the target machine, it will use the user’s permissions to update the DNS settings of the machine. An alternative method simply adds a redirection by updating the good old hosts file of the OS.

Type 4: Hijacking the router

Most ISP keep the IP address of the DNS server in the router that is provided to customers. By having access to router settings, an attacker can set this configuration to his own malicious DNS server. This seems difficult to achieve at first, but in reality, it is easy to do because most people don’t change the admin password of their router: they use the default configuration, which exposes their router to hijacking attacks. Therefore, it is very important to change the password of any device that you acquire.

Type 5: Hijacking the DNS Server

This is the most difficult exploit because it requires taking complete control of the DNS server. In this scenario, the hacker manages to take over the server and then change the configuration of the DNS server as he wish. This is usually the most damaging exploit, but it is difficult to achieve.

Mitigating DNS spoofing attacks

Here are the different ways to reduce the risk of being exposed to DNS spoofing attacks.

Use source port randomization on the DNS server

Many DNS servers were using the traditional port 53 as the source port for sending iterative DNS queries. Therefore, an attacker already knows where to send the forged UDP responses to the DNS server. This forced many vendors to use random ports when sending DNS queries, instead of always using port 53. By using source port randomization, brute-forcing a DNS response requires that the attacker not only guesses the 16-bit request ID but also the response port. That adds another variable to the mix when trying to brute-force the system, which gives a little more work to the attacker (i.e. UDP fragmentation).

Use HTTPS on web servers

After a successful DNS spoofing attack, if the website of the target domain is using HTTPS, end-users who navigate to this website will notice that the certificate is not valid. Usually, the attacker cannot have a real SSL certificate for the hijacked domain. Therefore, the browser will notify end-users about the fact that the website is not secure. This will prevent them from visiting this malicious website and providing their private information to the attacker. So, it’s really a best practice to avoid navigating on non-secure websites when possible (i.e. HTTP websites or HTTPS websites with invalid certificates).

Disable hosts file resolution

It is also recommended to disable the usage of the hosts file on both the clients and the servers. These files were useful in the ’80s but there is no reason to use them nowadays. Disabling hosts file resolution prevents a potential attacker from using these files.

DNSSEC

DNS Security Extensions (DNSSEC) is a standard of the Internet Engineering Task Force (IETF) to address the security concerns that come from exchanging clear text messages over UDP in the DNS protocol. DNSSEC uses asymmetric cryptography to enforce the authenticity and integrity of the DNS response data.

With DNSSEC, every DNS zone has an asymmetric key pair. Therefore, each zone uses its private key to generate a digital signature of the DNS records. When the DNS client receives the DNS resolution response, it can verify the signature of the data by using the zone’s public key.

Moreover, this public key is also signed by the private key of the parent zone. It’s a chain of trust similar to the TLS mechanism with SSL certificates and root certificates from Certificate Authorities (CA). This way, the client receiving a DNS response can verify that the data was not tampered with and that the DNS server who replied to the DNS query is a legitimate server.

Slow adoption of DNSSEC

In order to deploy DNSSEC in a zone, all the parents’ zones in the chain need to have DNSSEC in place, up to the root zone. This makes it overly complex for organizations to deploy DNSSEC and this complexity is a barrier to the full deployment of this technology on the internet. If you are more interested in the statistics, you can look at the DNSSEC validation rate by country, provided by APNIC (i.e around 37% in the world in 2021). For other statistics, you can consult the Internet Society webpage as well.

Encrypting the transport layer for DNS traffic

There are many evolutions of the DNS protocol that rely on other transport protocols. The main ones are DNS over TLS (DoT) and DNS over HTTPS (DoH). These protocols look similar but they are in fact 2 different standards. There is even a debate between adepts of the 2 protocols about which one is the best. However, both protocols allow sending the DNS traffic in an encrypted tunnel by using TLS or HTTPS. These technologies have many benefits for users’ privacy and they also protect against man-in-the-middle attacks and forged DNS responses. In 2020, Mozilla rolled out a version of Firefox that supports DNS over HTTPS. Google did the same thing with Chrome a couple of months later. This option is not enabled by default, so the overall adoption of the technology is not global yet.

In conclusion, with the variety of DNS spoofing attacks that are available, it is difficult to find 1 miraculous solution that mitigates all of them. However, by combining some of the best practices, it’s possible to highly reduce the risk of being exposed to such an attack.