Explanation of DNS cache poisoning attacks

The DNS Cache vulnerability is a security system that is vulnerable to the Internet in our applications. The root cause of poor security lies in design defects. By exploiting this vulnerability, users may not be able to open the webpage. The most important is phishing and financial fraud, which can cause huge losses to victims.

DNS Cache vulnerabilities to learn about cache poisoning attacks

Cache Poisoning attackers inject illegal network domain name addresses to the DNS server. If the Server accepts this illegal address, the cache is attacked, in addition, in the future, domain name requests will be controlled by hackers. When these illegal addresses enter the server cache, your browser or email server will automatically jump to the address specified by DNS.

This type of attack is often classified as a domain spoofing attack (pharmingattack), which causes many serious problems. First, users often think that they are logging on to websites they are familiar with, but they are not. Unlike phishing attacks that use illegal URLs, these attacks use valid URLs.

Another problem is that hundreds of thousands of users are redirected to a trap site set up by hackers by embedding a server with a cache poisoning attack. The severity of this issue is related to the number of users who use domain name requests. In this case, hackers who do not have a variety of technologies can cause a lot of trouble. In this case, users can tell others their online banking account passwords and online game account passwords in a confused manner.

With this similar technique, the email system will also be attacked by hackers. It is not for the Web server, but for the illegal address of the mail server, so that the system directs to the controlled mail server.

Then, how does a hacker make the Cache Server Accept illegal addresses? When a DNS cache server receives a domain name request from a user, the server will find the address in the cache. If it does not, the higher-level DNS server sends a request.

Before such a vulnerability occurs, it is difficult for attackers to attack the DNS server: they must send a forged query response, obtain the correct query parameters to access the cache server, and then control the legal DNS server. This process usually lasts for less than one second, making it difficult for hackers to succeed.

However, some security personnel have found the vulnerability, making the process shift toward an attacker. This is because the attacker was informed that the server cannot respond to the requests from the cache server for continuous queries. For example, a hacker may send a request like 1q2w3e.google.com, and he also knows that the domain name cannot exist on the cache server. This will cause the cache server to send more query requests, and there will be many opportunities for spoofing responses.

Of course, this does not mean that attackers have many opportunities to guess the correct value of the query parameter. In fact, the publication of this open source DNS Server vulnerability will expose it to dangerous attacks within 10 seconds.

You must know that even if 1q2w3e.google.com is attacked by the cache DNS poisoning, no one will send such a domain name request, but this is where the attacker can exert its power. By spoofing the response, hackers can also direct the cache server to an Invalid server domain name address, which is generally controlled by hackers. Generally, the information cache servers in these two aspects are stored.

Respond to vulnerabilities

As attackers can now control the Domain Name Server, each query request is redirected to the server specified by the hacker. This means that hackers can control the subdomain URLs under all domain names: www.bigbank.com, mail.bigbank.com, ftp.bigbank.com, and so on. This is very powerful. Any query involving subdomain URLs can be directed to any server specified by hackers.

How can this problem be solved?

To solve these problems, the UDP port used for query should not be the default 53, but should be randomly selected within the UDP port range (excluding the reserved port)

However, many enterprises find that their DNS servers are far behind the various devices that provide network address translation (networkaddresstranslation, Nat. Most NAT devices randomly select the UDP port used by the NDS server, which results in the loss of new security patches. The IT manager will not open all-round UDP ports in the firewall. More seriously, some security researchers have proved that even if the protection is randomly selected from the 64000udp port, the DNS server may still be infected with viruses.

Now it is time to consider other DNS protection solutions. UDP source port randomization is a useful protection measure, but this will break the protection of UDP source port Randomization to the DNS server, this balances the risks faced by all-round open ports or reduces firewall performance. Another effective protection measure is to enable the DNS server to switch to the TCP connection when detecting potential attack risks.

If the attacker guesses the necessary parameters to fool the query response, additional defense measures are required. This means that the DNS server needs to be more intelligent and can accurately analyze each query response to eliminate harmful information in the illegal response sent by attackers.