DNS Cache Security

About Cache
How can this problem be solved?
DNSSnoopy
About Cache
 
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. For example, evilgrade attacks
 
These attacks are often classified as domain spoofing attacks, which can cause 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, so that users can tell others their online banking account passwords and online game account passwords in a confused manner.
 
In this way, 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.
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.
 
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)
 
How can this problem be solved?
However, many enterprises find that their DNS servers are far behind the various devices that provide network address translation (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. Www.2cto.com
 
 
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.
 
DNSSnoopy
 
There is a simple automated tool DNSSnoopy to exploit this vulnerability,
 
The author introduces the running process:
 
Primero obtiene los servidores DNS del dominio solicitado.
Comprueba si alguno de ellos es vulnerable al ataque de snooping, para ello se solicita un listado de los dominios más comunes hasta que se encuentra alguno cacheado o ADO se acaba la lista.
Si se ha obtenido uno o más servidores vulnerables se procede a probar una lista de dominios que se indique para encontrar los cacheados con anterioridad.
Trata de calcular el tiempo que hace que se cache óen el servidor vulnerable, para ello compara el TTL obtenido del servidor cacheado el TTL original.


Author: dis9.com