How To Deal With DNS Vulnerabilities?
Believe it or not, in the early days of the Internet, all the domain names (nodes) it had been listed in just one file, the host file. Today, the host file has been demoted to just a way to redirect an IP address to a specific domain name, which the operating system checks first before querying the DNS servers. In Windows operating systems, the host file is stored under \Windows\System32\Drivers\etc\hosts, while in Unix-like operating systems it is under the /etc/hosts.
As the Internet matures and entered the World Wide Web era, the domain names in use have increased exponentially, that made the host file no longer feasible for listing all the existing domain names and its corresponding IP address. DNS is created in order to solve the need of many nodes to identify domain names to its corresponding IP addresses, as the Internet-facing apps only know how to fetch info from an IP address, not from the domain name itself.
Applications that access the Internet, such as Web browsers, pass the destination hostname to a server called a resolver that resides in the company or Internet provider. The resolver returns the corresponding IP address if the hostname exists in its cache. If it does not exist in the cache, it queries a server called authoritative DNS server, which has a table of correspondence between domains and IP addresses in the world. Some resolvers do not have caches and only query the authoritative DNS server, but many resolvers have caches to improve response and reduce unnecessary packet transmission. A resolver with a cache is called a “cache DNS server”.
Just like any part of a working system, DNS (Domain Name Service) has its fair share of vulnerabilities. However, we still use it since it is an efficient way to reach the rest of the Internet, without maintaining a huge host file. Maintaining DNS servers is a cost to Internet Service Providers (ISP), that is why it is the last aspect of their service that they usually take care of.
Here are the three most common attacks against a vulnerable DNS system:
Kaminski attack
As long as the cache server does not query the authoritative DNS server as long as DNS information exists in the cache, setting a long cache time-to-live (TTL) was an effective countermeasure. However, security researcher Dan Kaminski announced a new cache poisoning attack method in 2008. This is an attack method in which the cache server is forced to inquire the authoritative DNS server by querying the cache server with a hostname that exists but does not exist in the domain name, like hackercombat.com. Even if the cache TTL is increased, queries are generated forcibly, so repeated attacks will increase the probability of successful impersonation. This attack method is called, “Kaminski attack” after the name of the presenter.
DNS cache poisoning attack
The method of security attacks that exploit the mechanism of DNS is called DNS cache poisoning. Malicious attackers can send attackers fake DNS information to access the attacker’s server or cause the cache server to stop functioning. First, an attacker queries the IP address of a host that is impersonating a cache server. If the cache server does not have that hostname in the cache, it will query the authoritative DNS server. Before the response comes back, the attacker sends the fake DNS information that appeared to be the response from the authoritative DNS server to the same cache server. If successful, trying to access that host will gain access to the attacker’s server, or it will not be able to find that host.
Zone transfer request attack
In addition to DNS cache poisoning and DoS attacks and DDoS attacks derived from it, there are also security attacks that exploit the mechanism of the zone transfer. Although multiple DNS servers can be installed in the same zone (one of the divided domains or the same as the domain if not split) for load balancing, it is possible to set DNS information in the zone at that time. It needs to be synchronized. The zone transfer request is issued for that purpose. If a zone transfer request can be sent from the outside, it will be possible to see the response and understand the internal configuration and to subsequently send in invalid DNS information.
Security professionals recommend that users change their DNS servers of choice, from the default ISP-supplied to a known reliable DNS provider. This is to cover the vulnerability of DNS, as the ISP-supplied one is the least maintained of all available DNS servers compared to a full-time DNS provider.We can recommend a handful: Quad 9, Cisco OpenDNS, Cloudflare DNS, and Google DNS.
Related Sources:
What Do We Need to Know About the 2018 Global DNS Threat Report?
Faster Internet with Privacy-Focused 1.1.1.1 DNS Service
0 Comments