[English translation] Detection and prevention of DNS spoofing attacks (Computer Engineering 2006)

[wkrp]

This research paper, originally published in Chinese in 2006, has not been available in English before. It is a bit unusual in that it describes how to mitigate a class of DNS attacks that is done by the Great Firewall of China, even though one of the authors, 方滨兴 (Fang Binxing), is known to have helped create the Great Firewall.

---

Detection and prevention of DNS spoofing attacks
闫伯儒 (Yan Boru), 方滨兴 (Fang Binxing), 李斌 (Li Bin), 王垚 (Wang Yao)
Journal homepage
Original Chinese PDF
Online English HTML
English PDF

The paper is, facially, about detecting and preventing DNS response injection attacks—exactly the kind of attack that has long been one of the GFW's primary tools for censorship. It presents three way to detect that DNS response injection is occurring, and three ways to distinguish injected responses from legitimate one and thereby foil the attack.

Section 1.2 is a straightforward description of a DNS response injection attack. The DNS client sends a query, and the attacker sends a response containing a fake IP address (spoofing the source address so it appears to come from the real resolver). The real resolver sends its response too, but because the attacker's response arrives first, that is the one honored by the client.

Figure 2: DNS spoofing attack

The paper unambiguously calls DNS response injection "harmful" and an "attack". Table 1 compares response injection with other DNS attacks: cache poisoning, server compromise, and denial of service. They emphasize that the attack is only possible because of design flaws in the DNS protocol.

The three techniques for detecting that DNS injection is happening come in both passive and active varieties:

1. After sending a DNS query, wait for a certain amount of time and count the responses. (Similar to "Hold-On", 2012.) Real resolvers send only one response per query, so receiving more than one response is a sign of injection.
2. Actively send DNS queries to non-resolvers. If any response is received, it must have been from DNS injection.
3. Cross-checking: After receiving a DNS response containing an IP address, do a reverse lookup on the IP address to get a hostname, and check whether the hostname matches the hostname that was initially queried for. A mismatch indicates DNS injection.

There are an additional three techniques for distinguishing injected DNS responses from legitimate ones. The first two are based in the observation that injected responses tend to be simpler in structure than real responses, having fewer sections and resource records.

1. Assign a weight (which may be positive or negative) to each of the possible section in a DNS message (Question, Answer, Authority, and Additional), and compute a weighted sum over the number of resource records in each section. Classify as injection any responses whose score is above or below some threshold.
2. Use a Bayes classifier. The paper devotes considerable space to deriving a Bayes classifier over a single feature, the number of resource records in the Authority section. The distribution of the number of authoritative servers in legitimate responses is empirically estimated using the top 100 websites in China in Figure 3. The authors stress that this is only a proof of concept, and that a realistic classifier would take more features into account. (Though they do try out the single-feature classifier later, in the evaluation section.)
3. Cross-checking: Just as with detection technique (3) above, check that forward and reverse lookups are consistent. The extra step that makes it prevention is to ignore any inconsistent responses.

The evaluation uses ADMid as a DNS spoofing attack tool. The authors enhanced ADMid to, with 10% probability, add a non-empty Authority section to responses, to make them more realistic. They try prevention technique (1) with two different weight vectors, and prevention technique (2) (the single-feature Bayes classifier). Sending 1000 queries in total for the top 100 websites in China (thereby provoking 1000 injected and 1000 legitimate responses), they get true positive rates of 97% or 98%, and true negative rates of 72% to 97%. The best prevention technique is (1), the weighted sum of section sizes, with weight 1 for each of the Answer, Authority, and Additional sections.

In two places the paper says that the attacker is constrained to send an injected response as quickly as possible, and therefore cannot spend much time on packet construction. This is what makes detection technique (2) work: the attacker could check that the destination IP address in a DNS query is actually a resolver, but it would take too much time.

[wkrp]

This paper is cited in "Splinternet Behind the Great Firewall of China" (2012), in the context of explaining how the GFW's DNS injection works:

If the GFW sees any sensitive query, such as "www.facebook.com," it will inject a faked DNS reply with an invalid IP address. In most cases, the faked reply arrives much earlier than the legitimate one, and the DNS server will accept the first one and forward it to the user. Because GFW spoofs the IP addresses of the legitimate DNS name servers outside China, the DNS server in China cannot distinguish the faked answers from the legitimate ones.²⁷

It is also mentioned in "Finding contributors to Great Firewall by their papers" ("通过分析论文挖掘防火长城(GFW)的技术人员") from 2013, an attempt to map out the network of researchers contributing to the Great Firewall, starting from 方滨兴 (Fang Binxing):

检测到不良信息接下来就是网络管控和阻断技术，比如利用协议欺骗[14]、DNS污染[15]、路由控制[16]等，相比之下，这些论文的水平不高。

Once undesirable information is detected, it requires network control and blocking techniques, such as the use of protocol spoofing [14], DNS pollution [15], routing control [16], etc., These papers are comparatively of not very high quality.

[wkrp]

The earliest documentation of DNS response injection in China that I know of comes from 2002, which is 4 years before this paper, and 10 years before "Splinternet". There were two reports, one by Bill Dong and DynaWeb, and one by Jonathan Zittrain and Benjamin Edelman. The beginning of DNS response injection in China appears to have been September 2002.

A report about national DNS spoofing in China on Sept. 28th
Dynamic Internet Technology Inc.
2002-10-02

On Sept. 28th, reports came from China that visits to dissident websitess were being redirected to different IPs. Analysis shows that this is an unprecedented large-scale domain name hi-jacking in China achieved through DNS record spoofing. This effort is the result of an escalated level of Internet censorship in China.

On Sept. 30th when testing was performed on the top ten forbidden websites and the DNS server list we have, all of these ten sites resolved to the same IP address on all DNS servers on the list, except in Hong Kong and Macau. The IP is 64.33.88.161, or http://falundafa.ca - a Canadian registered non-profit organization aimed at promoting the practice of Falun Gong.

Many DynaWeb domains were pointed to 64.33.88.161 by the DNS servers. In fact, all DNS servers that were tested, except the ones from Hong Kong and Macau, pointed to this IP address when they queried DynaWeb domains.

It is interesting that the injected IP address was one belonging to a web site that was already blocked. The DNS injection system returns a blocked IP address, and relies on the IP address blocking system (cf. #434, #435) to actually block access to the site.

These days, the DNS injection system in China uses not just 1, but hundreds or thousands of fake IP addresses; see #47, https://censorbib.nymity.ch/#Hoang2021a.

Internet Filtering in China
Jonathan Zittrain, Benjamin Edelman
2003-04

DNS servers in China have been found to offer seemingly intentionally incorrect answers to the IP addresses of certain domain names. For 1,043 tested sites, we confirmed that DNS servers in China report a Web server other than the official Web server actually designated via each site’s authoritative name servers.

When a user in China requests a site affected by DNS redirection, for example, the user’s computer is told that the site’s domain name is associated with the IP address 64.33.88.161. That IP address is associated with the host www.falundafa.ca, the site of a Canadian organization that promotes the practice of Falun Gong. However, that address is blocked by Chinese border routers, preventing such requests from reaching either the falundafa server or any other.

This report also says that HTTP request keyword blocking and HTTP response body keyword blocking both also began in September 2002.

URL Keyword Filtering

Beginning in September 2002, our data reflects that a subscriber to a Chinese ISP would receive no response when seeking a URL that contained certain words or phrases. This effect was particularly notable at Google, where names of key political figures are apparently off-limits, as are certain other words used to invoke particular Google features (among them the caching feature that can provide a method of circumventing the filtering implementations described above). In some instances, we have also observed that these keyword blocks apply equally to requests from other sites. From at least certain locations in China, attempts to retrieve any URL containing the character string “jiang+zemin” triggers a distinct kind of temporary filtering (even if the result of that request would only be a “404 — Not Found” error page).

Subsequent to a request for a URL with a prohibited term, we have confirmed “timeout” periods of 5 to 30 minutes during which either the target site or even all sites (including otherwise-unfiltered sites) became inaccessible.

HTML Response-Keyword Filtering

Beginning in September 2002, we observed that certain keywords within Web page data being transmitted to a Chinese Internet user triggered filtering of that data. In particular, even when a page came from a server not otherwise filtered, and even when the page featured a URL without controversial search terms, it might nonetheless be inaccessible if the page itself contained particular controversial terms. Such pages were often – but not always – truncated, that is, interrupted midway through their display.