Decryption: Internet DNS Structure Vulnerability Analysis

One of the most popular vulnerabilities recently discovered by the DNS protocol itself is a serious problem (cert vu #800113 ). Most of the domestic media reports are vague, so I want to talk about the vulnerability.

First, we need to clarify the first question: how is DNS query performed? For most desktop systems, DNS queries are not completed by their own machines. DNS queries are submitted to another DNS server (which is usually provided by an ISP or company ), then the server performs the real query operation. The advantage of doing so is that the DNS query results can be saved by this machine, which improves the query efficiency and reduces the traffic overhead caused by DNS (of course, such overhead is negligible today ).

One thing we can see is that a cache DNS server (compared with authoritative DNS, provided by such systems) the following desktop systems may have hundreds, thousands, tens of thousands, or even hundreds of thousands. In terms of the effectiveness of attacks, if this server can be affected, compared to the desktop system under attack, the cost is much lower. This type of attack is generally called a leveraged attack.

Leverage attacks against cache DNS servers have been studied for a long time. In addition to hackers who wish to hijack website traffic for profit, there are also some who use this method for other purposes, for example, shielding websites with security problems and purifying Internet content in some countries.

This VU #800113 is a problem that attracts people's attention. Although it still uses the "Cache poisoning oning" method, however, this method uses some new techniques to make it more effective. Specifically, the DNS query process is sent from a client (either a desktop computer or a query initiated by the cache DNS server) to an authoritative DNS server (possibly the root DNS, it may also be the authoritative DNS of a specific domain name) a udp request, and then wait for its response.

UDP is a connectionless protocol. To identify responses from different servers, the DNS protocol uses ports and a txt id Identifier (similar to TCP serial numbers) to distinguish them. In fact, early DNS implementations even use fixed ports to initiate DNS requests. In this way, TXID becomes the unique identifier of the response. Because the DNS protocol was designed in the 1970s S, the TXID number is only 16 bits in width, it is easy to forge the source address of a UDP packet (because UDP does not provide a built-in mechanism similar to TCP to prevent such attacks). Therefore, attackers can simply try to convince the DNS Cache Server that the response from authoritative DNS is authentic.

Specifically, this attack includes two parts. One is to try to make the cache DNS server initiate a new DNS query request (there are many methods ), the second is to issue a large number of counterfeit packets and expect them to hit, that is, before the real authoritative DNS response, send the forged UDP response that matches both the port and TXID to the cache DNS server.

For some DNS clients that generate TXID in a linearly increasing manner, attackers can set up a DNS server on their own to trick the other party into sending DNS requests, thus greatly improving the attack efficiency. For a DNS Client that uses a fixed port, attackers can use similar methods to obtain information about the client. Attackers can achieve this in various ways, including phishing emails and direct queries.

The problem described in VU #800113 this time is that most DNS Cache servers have one or all of these two vulnerabilities.

After talking about the attack principle, I think more people will be concerned about the following: what can we do?

If you are a desktop user, the best way is to wait for the company or ISP staff to correct the problem. By installing appropriate patches, you can eliminate the above two vulnerabilities. For FreeBSD users, the way to mitigate the impact of such problems is in/etc/rc. add named_enable = "YES" to the conf file and run/etc/rc. d/named restart and in/etc/resolv. in conf, 127.0.0.1 is configured as a Domain Name Server. This way, attacking the Cache Server becomes an attack on all desktop systems, greatly increasing the attack cost, however, this means that the cache of the upstream DNS cannot be used.

If you are the administrator of the cache DNS server, you must consider deploying DNSsec in addition to patching (if this vulnerability exists in your system. DNS protocol vulnerabilities can only be partially mitigated by randomizing the query port and TXID, while DNSsec is the root solution.

If you are the administrator of an authoritative DNS server, you can't do anything because the cache DNS server is not under your control. The only thing that can be done is to configure DNSsec for your authoritative domain name. Unfortunately, not all top-level domain names and domain name registration service providers currently support DNSsec.

Some common misunderstandings:

Misunderstanding A: It's the broken BIND vulnerability. I don't need BIND, so it's okay.

Error. In addition to BIND, there are also many other DNS servers that encounter the same problems when used as cache DNS.

Misunderstanding B: My Ubuntu system immediately fixed this problem, so I am not affected.

Error. Unless you run the DNS Cache service locally and only use it as the DNS.

Misunderstanding C: I am using soy sauce. It doesn't matter if my DNS is attacked. At most, I only need to add traffic to others.

Error. Through DNS Cache poisoning attacks, you can direct yourself to some fake phishing sites to defraud sensitive data.

Misunderstanding D: My authoritative DNS server is configured with DNSsec, so the customer will definitely access the correct website.

Error. The fact is that many early DNSsec implementations have introduced other security vulnerabilities. On the other hand, most cache DNS servers do not perform DNSsec verification, so you still need other measures to mitigate the impact of this problem.

A DNSsec push-on is required for the global DNS system.