4 DNS Response Poisoning

The main idea behind our DNS cache poisoning attacks is to apply Second-fragment Overwriting technique to change the content of a DNS response by replacing authentic resource records (RRs) with spoofed A or NS RRs either for the existing domain or for a new subdomain.

Specifically, the off-path attacker triggers a DNS request to some victim domain, e.g., using a puppet (malicious script confined in a browser), and then spoofs the second fragment. Depending on the section (of the DNS response) which the second fragment contains, i.e., authority or additional, the attacker replaces authentic records with his fake records 8.

The main difference between the attacks is related to the two intertwined issues:

 (1) frequency at which theattack can be repeated, and 
 (2) the queries which the attacker can request.

Both these issues depend on the freedom of the attacker over the (suitable) queries which it can request.

NXDOMAIN or No-Data Responses.

To evade caching of the resolver the attacker can issue DNS requests for ‘non-existing domain names’, i.e., responses containing an RCODE with name error, or responses in dicating that the domain name exists but with a different type, i.e., with‘no data no error’responses.

Such responses exist in every domain.

We found that domains that use NSEC3 (which is currently the majority of the domains) to indicate nxdomain (and no data) responses, to be most suitable for our attacks as those responses get fragmented in the authority section, such that the second fragment contains at least one complete RR (not including the EDNS RR).

This technique is similar to Kamisky attack, as it allows the attacker to repeat the attack as frequently as required, by selecting a different random name

(prepended to the real domain name) in each query.

However, nxdomain responses may not always get fragmented, e.g., if the zone does not use NSEC3.

‘Existing Domain’ Responses.

If the attacker triggers the attack with queries for existing domain names (with a non-zero TTL) that get fragmented, e.g., responses to DNSKEY, then it can trigger the attack only if the record is not in cache.

If the attack fails the first time,  it has to wait 
till the record expires from cache, i.e., the TTL reaches 0 or sinature expires.

Records with zero TTL, e.g., used for CDN networks, can be requested repeatedly, thus allowing to launch the attack as frequently as required, since they are not cached.

Such DNS responses with (zero TTL) records in the answer section also contain (among others) NS and A records (in authority and additional sections respectively) with a cache-able TTL, which the attacker can replace.

However, the zero TTL records may not exist in every domain, and in particular, may not exist in a domain which the attacker wishes to poison.

Thus the typically query choice of the attacker is between ‘nxdomain/no-data’ or ‘exiting domain’ (with a non-zero TTL).

Poisoning the Cache.

Inserting spoofed records into the cache is not straight forward, and merely changing the records in a DNS response will not necessarily result in resolver accepting and (then) caching them.

In particular, the forged DNS response must comply with the caching (and other) conditions which the resolvers impose on DNS responses:

the forged packet p′ must be a valid DNS response; the ‘poisonous’ resource record r′must be valid for the specific response and section of the response; and the resolver must cache r′.

The choice of forged DNS records, which we apply when modifying the DNS response, and semantics and values of each field in a DNS record, essentially follow the known rules for DNS cache poisoning and were investigated and studied (most notably) by Kaminsky [22] and Son and Shmatikov [33], and by Bau and Mitchell [5] for DNSSEC enabled DNS responses.

[十分検討されたという状況ではない。-- ToshinoriMaeno 2018-11-20 23:35:34]

[22] ] D. Kaminsky. It’s The End Of The Cache As We Know It.

In Black Hat conference 2009

[33] S. Son and V. Shmatikov. The hitchhikers guide to dns cache poisoning.

Security and Privacy in Communication Networks, pages 466–483, 2010

[5] 5] J. Bau and J. C. Mitchell. A security evaluation of DNSSEC with NSEC3.

In Network and Distributed Systems Security (NDSS) Symposium . The Internet Society, 2010.