DNS/FCP/3について、ここに記述してください。

3 Fragment Overwriting and NS-Blocking

In this section, we present the Name Server blocking (NS-blocking) attack,

allowing attackers to cause resolvers to avoid querying a name server. 

This attack requires much weaker assumptions than the poisoning attacks, Section 4, and only assumes that the responses get fragmented.

Both NS-blocking and the poisoning attacks, rely on Fragment Overwriting.

Fragment Overwriting, explained next, allows attackers to modify fragmented packets.

In Section 3.2 we explain how fragment overwriting allows an attacker to cause standard-conforming resolvers to avoid a particular name server, i.e., to perform NS-blocking.

Then, in Section 3.3, we discuss potential exploits of NS-blocking.

3.1 Fragment Overwriting

We now present a simple technique, allowing an attacker to replace (overwrite) second fragments of
(fragmented) IP packets,  in particular,  of DNS responses sent to the resolver; 
this basic technique is applied in all of our attacks.

Suppose the original packet has payload x, and, after fragmentation, it is sent as two IP packets y1, y2.

Then,the defragmentation process, running at the resolver on inputs < y1, y2> reproduces x.

To overwrite the second fragment, the attacker sends a fake second fragment y'2 so that it arrives at the defragmentation module before the authentic fragments y1, y2 of the DNS response.

The defragmentation mechanism in the IP layer will cache y′2, in anticipation of the rest of the packet.

By default, an unmatched fragment is kept in the cache for 30 seconds or so, hence, ‘planting’ such fake fragments is easy; we now explain how the attacker can ensure a match with the original packet.

Note that it is easy to adjust this technique for the (less common) case where fragments are sent in a reverse order: attacker removes the authentic second fragment y2 from the reassembly buffer by sending an arbitrary y′1 (whose validation fields match those of the y2), and the rest is the same as above.

According to [18, 31] the fragments of a datagram are associated with each other by their protocol number, the value in their IP-ID field, and by the source/destination IP address pair.

Thus both the first authentic fragment y1 and the second spoofed fragment y′2 must have the same destination IP address (of the resolver that sent the query), the same source IP address (of the responding DNS server), the same protocol field (UDP) and the same fragment identifier (IP-ID).

In addition, the spoofed second fragment should have the correct offset (as in the authentic second fragment). The fragment reassembly process, applied to the pair < y1, y′2>, returns either a failure or a different packet x′6=x.

Matching most of these parameters is not difficult.

In particular, path MTU changes infrequently, and can be found by attacker easily, e.g., by trace-route.

In many scenarios, the resolver has a single, known IP address; zones typically have 6 IP addresses on average.

The attacker may sometimes also have some knowledge on the likely name servers since the server selection algorithms of many resolvers can be predicted [36], e.g., based on latency, and may even use our attacks to disable some name servers; in the worst case, the attacker can launch the attack for each name server in parallel.

In this work we show techniques which often allow the attacker to simply block the name servers of its choice.

It remains to ensure a match between the value of the fragment identifier (IP-ID) field in the fake fragment y ′ 2 , and the IP-ID in the authentic fragment y 1 of the original response x.

There are several possible options for IP-ID prediction, 
depending on the version of the IP protocol (IPv4 or IPv6),
the method that the name server’s OS uses to select IP-IDs, and on the receiver implementation.

In the most common case the communication is over IPv4, where the IP-ID field is 16 bits; and the host performing the defragmentation process, i.e., the resolver or firewall, has cache of 64 (or more) fragments per particular <source IP, destination IP, protocol> combination; note that when more than 64 fragments (for the same tuple) arrive, the oldest fragment is evicted from cache and is replaced with the new one.

Assuming that the attacker has no knowledge on the process according to which the IP-ID is incremented, and assuming the IP-ID in the packet and in the fake fragment are selected independently, it suffices for the attacker to send 64 spoofed second fragments, to ensure success probability of roughly 1/1000 of replacing the second fragment of a packet in a single attempt.

A much better probability of success (as we discuss next) can typically be achieved, however, even this attack can be sufficiently efficient for many scenarios.

Most systems select the IP-ID sequentially.

Of these, many use a single counter for all destinations (globally- sequential), as in Windows and by default in FreeBSD. Other systems, e.g., Linux, use per-destination IP-ID counters.

In both of these cases, the attacker can efficiently predict the IP-ID, achieving high probability of success (certainly compared to 1/1000).

In particular, for globally-incrementing IP-ID, which appears to be more widely used, e.g., mil, the attacker can simply learn the current value, and the rate of propagation, by querying the name server directly.

The technique we use to achieve improved success probability in the case of per-destination IP-ID, is an improvement of the methods of [12].

These techniques ensure feasibility of the attack even for most implementations of IPv6, in spite of its use of 32-bits IP-ID field.

3.2 Name-Server Blocking

In this subsection, we present the NS-blocking attack, allowing an off-path attacker to dissuade resolvers from querying particular name server(s); this can have multiple goals, including denial/degradation of service, traffic analysis and more (see next subsection).

As indicated in Table 1, the NS-blocking attack has two main requirements:

• the ability of the attacker to generate a DNS query from the resolver, that will result in

fragmented response from the ‘victim’ name server;

• and that the resolver follows a behaviour recommended in

RFC 4697 [25, 36], namely, of avoiding a name server if there are two or more failures within some time interval (the time interval depends on the resolver implementation).

We first describe how the attacker is able to block responses to a particular query, which does not rely on the behaviour recommended in [25].

To block responses to a query from a particular name server to the resolver, the attacker needs to send an ar- bitrary fake second fragment y ′ 2 with the anticipated IP-ID and other parameters, to match a legitimate response, as described above.

The reassembly process using the legitimate first packet and the fake second fragment usu- ally fails, and both fragments are silently dropped, by the UDP layer or by the DNS resolver itself, due to incorrect checksum.

The resolver will resend the query after a timeout, but the timeout periods are known to the attacker, who can easily send appropriate fake fragments to cause loss of each of the responses, until the resolver gives up.

The number of attempted retransmissions depends on the number of name servers that the zone uses; if the zone uses one name server, the resolver gives up in about 5 to 7 retransmissions, e.g., Bind9 after 7 timeouts, and Unbound 1.4.10 after 5 timeouts, if the zone uses more name servers then after one to two timeouts the resolver queries the next name server.

We show how to apply this technique, in order to perform NS-blocking, i.e., block a specific name server, instead of blocking just one particular packet.

For this, we need the assumption that the resolver avoids querying unresponsive name servers, as per the recommendations in [25, 36].

We exploit the fact that when the target name server is not responsive, i.e., two or few queries timesout, the resolver does not send 5 any more queries to it.

The attack is illustrated in Figure 4. The idea is for the attacker to send a spoofed fragment, e.g., one byte long, which ruins the DNS response from the specific IP address.

After repeating the attack few times (depending on the resolver software), e.g., twice in every 15 minute interval for Unbound, the resolver marks the name server (or rather the IP of the name server) as non-responsive and does not send queries to it for the specified interval of time which depends on the resolver implementation.

It is important to notice, that with most resolvers, NS-blocking is effective against a specific name server IP, and not limited to a specific domain.

Namely, we can use NS-blocking to dissuade a resolver from using a specific name server, e.g., at IP address 38.103.2.1, using queries (with fragmented responses) to one domain isi-sns.info, and as a result the resolver will also avoid this name server for all the other domains which that server serves, e.g., paypal.com.

This can be very useful, as name servers often host multiple domains, and some of these may use DNSSEC (and have fragmented responses), or be owned (or corrupted) by the attacker (who can put some other record with fragmented response), while oth- ers may only have short (unfragmented) responses, in ad- dition, some domains are much less frequently queried,

e.g., info, than popular domains, e.g., paypal.com, that use the same name server, allowing to match the IP-ID with little effort; e.g., [32] show that a typical domain name depends on 46 name servers on average which also serve other domains.

As illustrated in Figure 4, we performed the attack against a 404.gov domain, whose non-existing domain responses exceed 1500 bytes and thus get fragmented enroute.

This phase, of forcing the resolver to use a specific IP, requires a puppet, i.e., a script confined in a browser, which issues DNS requests via the local caching DNS resolver, at IP 1.2.3.4 in Figure 4.

In steps 1 and 2 the puppet coordinates with the attacker and issues a DNS request for $123.404.gov (where $123 is a random prefix).

In steps 3 and 4, the spoofer sends a forged second fragment, for all the possible name servers (i.e., a total of 2 spoofed fragments) except one which the attacker wants the resolver to use for its queries during the poisoning phase; the 404.gov domain has three name servers.

This ensures that only one IP address will result in a valid response, and the other two result in a malformed DNS packets.

The spoofed second fragment is incorrect, and contains a single arbitrary byte (in addition to headers).

In step 5, the spoofed second fragment is reconstructed with the authentic first fragment resulting in a malformed DNS packet which leaves the fragments reassembly buffer.

This malformed DNS response is then discarded by the resolver, and the IP of the name server is marked 6 as ‘non-responsive’.

When the authentic second fragment arrives, it does not have a match and is discarded after a timeout.

As a result the resolver does not receive the response, and after a timeout it resends the DNS request to the next DNS server, step 6.

The same procedure applies here, and the response is discarded.

In step 9 a valid response arrives from IP 162.138.183.11. This way, by wrecking the re- sponses from all name servers except one, we forced the resolver to direct all its queries for 404.gov domain to 162.138.183.11.

The IP-ID allocation algorithm does not have a signif- icant impact on our attacks against such resolvers (e.g., Unbound), since ‘misses’, i.e., valid responses arriving to the resolver from some IP, do not prevent the attack; e.g., two failed (timed-out) queries suffice for Unbound to mark the server as non-responsive for 15 minute inter- val.

The Wireshark capture, in Figure 5, that was run on the resolver, demonstrates the experimental evalutation, i.e., the DNS packets entering/leaving the network card of the resolver. During the course of the experiment the puppet issued 6000 queries 7 to the resolver.

The spoofer initiates the attack by sending three spoofed fragments to each IP address except 162.138.183.11.

For simplicity, the capture presents only the packets exchanged between the re- solver and the name server of 404.gov at 162.138.191.23 (by adjusting a corresponding filter in wireshark); the complete capture contains queries/responses from other name servers too.

Packets numbered 18-20 are the forged fragments sent by the spoofer, with sequentially incre- menting IP-IDs. Then puppet triggers a DNS request, packet 29. The response from the name server contains two fragments, packets 33 and 34. The first fragment is reassembled with spoofed fragment 18, resulting in a malformed packet which is discarded by the resolver.

The second fragment is discarded after a timeout. In packet 48 the resolver requests a public verification key of the 404.gov zone. The response contains three frag- ments 49-51; the first fragment is reconstructed with the spoofed fragment in packet 20, which also results in a malformed DNS response and is discarded.

Note that this request, in packet 48, was sent at 19:28.

Based on our tests it can be seen that when Unbound encoun- ters a timeout twice for the same destination IP, it stops sending further packets to that destination for 15 minutes.

Indeed, the next packet that is sent to that IP is packet number 6848, at time 19:43. The same scenario was observed with IP 162.138.191.11. The queries be- tween 19:28 and 19:43 were sent only to 162.138.183.11, avoiding 162.138.191.11 and 162.183.191.23.

Note that even if some of the responses (between packets 33 and 49) were valid and accepted by resolver, e.g., if they were not fragmented, it did not make a difference, and two timed-out responses in a 15 minute interval were suffi- cient for Unbound to stop querying those IP addresses; this fact shows that the success probability of the attack does not depend on the IP-ID selection mechanism.

3.3 NS-Blocking: Applications

NS-blocking is rarely a goal by itself; more often, it can serve as a mechanism for other goals. We discuss three such goals:

• facilitation of DNS poisoning; degradation of service, and traffic analysis.

Facilitate DNS poisoning

In [32], Ramasubramanian and Sirer conducted a survey showing that a typical do- main name depends on 46 servers on average, and names belonging to countries depend on a few hundred servers.

They note that compromising a server can lead to domain hijacks and postulate that it is possible to hijack 30% of the domains in Yahoo and DMOZ.org directories; DNS servers are known to have vulnerabilities [11, 24].

However, [32] did not suggest a technique which can be used to force a resolver to query a specific name server.

NS-blocking can provide exactly the necessary mechanism.

Also note that NS-blocking can assist in other DNS cache poisoning attacks, including these in the next sec- tion of this paper, as it allows the attacker to reduce the number of servers that the resolver can query, possibly to only one.

Off-path Degradation of Service

By blocking ‘good’name servers, an attacker can cause resolvers to send their traffic to specific, ‘bad’ name servers.

In particular, resolvers may resort to name servers with very high latency, causing unnecessary delays. Note that the zone administrators often deploy techniques to distribute the load between several physical servers sharing the same IP, e.g., using load balancing or Anycast [17].

Typically not all the name servers of a domain deploy such optimi- sations, e.g., 6 out of 13 root servers, [27]. Our technique allows the attacker to block those servers and to ‘force’ the resolver to query a name server which does not support such load balancing.

Off-path Traffic Analysis and Covert Channel

Many names servers provide side-channels allowing an attacker to learn or estimate the rate of requests handled by the server. In particular, one simple and effective sidechannel is the IP-ID used by the name server.

We next show how an off-path attacker can use this side channel, in conjunction with NS-blocking, to estimate (analyse) the rate of requests from some resolver r, to a particular domain foo.bar. NS-blocking can facilitate such off-path traffic analysis in several ways; as we later explain, this side-channel can even allow covert communication (between a bot using the resolver, and an attacker which is not controlling the name server). First consider the case that one (or more) of the name servers of foo.bar , say ns.foo.bar , is using globally- incrementing IP-IDs (this is common). By using NS- blocking, we can direct all or most of the DNS re- quests from r to ns.foo.bar ; by periodically querying ns.foo.bar , the attacker can measure the rate of progress of the IP-ID (and hence of responses sent by ns.foo.bar ). To further improve the measurement, the adversary may use NS-blocking to cause other major resolvers to avoid using ns.foo.bar.

This mechanism also allows off-path covert channel, between an agent, say a bot b , which can use the resolver r , and an off-path attacker o , which can make queries to the name server ns.foo.bar. The bot can, e.g., encode in- formation by signaling via the queries to ns.foo.bar (or possibly, signaling using distinct queries to several do- mains, each mapped to a specific, distinct name server).

The attacker can communicate to the bot by signaling via loss of DNS responses. The traffic analysis attack is applicable also if none of the name servers of foo.bar use globally-incrementing IP-ID, provided at least one of them, say ns.foo.bar , uses per-destination incrementing IP-ID . In this case, the at- tacker will also need the ability to use the resolver r , e.g., via a puppet (malware such as script, in a sandbox). At- tacker will use the puppet to keep track of the IP-ID used by ns.foo.bar to send packets to r