#pragma section-numbers off DNS/FCP/2について、ここに記述してください。 <> <> = 2 Attacks Requirements = In this section we describe the requirements of the different attacks that we introduce in this work. See Table 1 forthe requirements of each attack. Below, we dedicate one subsection to the ‘Fragmentable zone’ and ‘Poisonable zone’ requirements, and another one to the ‘Permissive or Island’ requirement. We initiate with a brief description of three technical requirements: IP-ID, NSEC3 optout and RFC 4697. == 2.1 Technical Requirements == The IP-ID requirementis that attackers have ‘reasonable’ probability of success in guessing the IP-ID in the responses from the name servers. In IPv4, the IP-ID field consists of only 16 bits; considering that fragment reassembly can usually hold a significant number of fragments for specific senders, typically at least 64, this implies a good success probability even if attacker just guesses the IP-ID values. Furthermore, many systems, and in particular most name servers, authoritative for major TLD zones, e.g.,mil, use operating systems where IP-ID is generated sequentially, either globally (for all destinations) or with per-destination counters. In both cases, we can significantly improve the probability for a correct match. We optimised the IP-ID prediction, in the per destination case, by adapting the technique of [12] to be used with resolver. Note that in IPv6, it is harder to predict the IP-ID, since it is 32 bits and is sent only in fragmented traffic; however, IPv6 specifically recommends the use of sequential IP-ID, and hence can be guessed with good chance of success. {{{ The bottom line is that the IP-ID requirement is almost always satisfied. }}} ---- The NSEC3 opt-out requirement is that the zone uses NSEC3 DNSSEC record with opt-out option [26]. This allows attackers to create fake (non-existing) sub- domains, and thereby facilitate XSS, phishing and cookie stealing attacks. Sub-domain injection attack was proposed in [5], that carried it out by a MitM attacker. Infact, [5], also suggested that the attack could be carried out by an off-path attacker, assuming that only the transaction ID in DNS packets is randomised. However, this assumption does not hold for most DNS resolvers, as they (at the very least) support source port randomisation. In Section 4.2 we show that such an attack can be effectively carried out by an off-path attacker, that does not intercept and inspect packets, and against patched DNS resolvers, i.e., supporting source port randomisation, IP randomisation and DNS query randomisation. In spite of the publication of this potential abuse by MitM [5], NSEC3 opt-out is still widely used, and often even recommended, since it improves performance (esp. as long as DNSSEC is deployed only in small fraction of the domains). ---- The RFC 4697 requirement is that resolvers adhere to (one of) the recommendations in RFC 4697 [25, 36], specifically, that a resolver will refrain from sending queries to a name server after (few) failures, i.e., timeout queries, within a predefined time interval, and to lame name servers, i.e., those that provide DNS responses where (some of) the DNSSEC records, e.g., signatures, are missing or corrupted. We show in Section 3.2 that this allows an attacker to cause resolvers to stop using specific name server(s), facilitating poisoning attacks, as well as other attacks, including off-path traffic analysis and covert channel attacks. We validated this behaviour in popular and standard DNS resolvers, see Section 3.2. == 2.2 Fragmentable Zone and Poisonable Zone Requirements == We now describe our two fragmentation requirements: ‘Fragmentable zone’ and ‘Poisonable zone’. === The‘Fragmentable zone’ === requirement is necesssary to all of our attacks, and essentially amounts to the ability of the attacker to cause fragmentation of a response from a name server. As can be seen in Figure 2, long second fragments are rather common, and responses are fragmented from most top level domains (which deploy DNSSEC), e.g., in the gov top-level domain, which is the top-level domain with maximal adoption of DNSSEC so far. Note that fragmentation can also occur even if the resolver does not deploy DNSSEC, e.g., it relays a query for a DNSKEY from the client, or due to other types of records which can be long, e.g., different TXT records, and/or when fragmentation occurs at relatively low packet length l, due to success in sending fake ICMP fragmentation-required alerts (see Section 2.2). === The ‘Poisonable zone’ === requirement is necessary for our poisoning attacks, and requires that at least one complete record is present in the second fragment so that the attacker can modify the second fragment and replace the authentic resource record with a spoofed one, which gets accepted and cached by the resolver. Details follow. The ability to cause the required fragmentation depends both on the records in the zone file, as well as on the properties of the name server (including the route from the name server to the resolver). In particular, fragmentation typically depends on the smallest MTU enroute on the path from the name server to the resolver; packets larger than 1500 bytes will normally be fragmented. The attacker may also sometimes be able to‘trick’ the name server into fragmenting (even) shorter packets before sending them. The attacker can inflict fragmentation by sending a spoofed ICMP ‘fragmentation needed’ packet, similar to attacks in [13]. Let l denote the size of packets, above which attacker can cause fragmentation - the minimal MTU along the path, or the minimal length that the attacker can ‘force’ the name server to use by issuing fake ICMP fragmentation-needed alerts. In principle, name servers could be configured to never allow fragmentation of responses, by sending response packets of length up to (some bound of) l bytes with the DF (do not fragment) bit set, and send longer responses only via TCP, relying on TCP’s path MTU discovery mechanism. However, the use of TCP for DNS requests and responses has significant performance penalty, in addition to the overhead and complexity of handling fragmentation-required ICMP alerts received due to sending packets with the DF set, which reach a network whose MTU is smaller than the packet size. Hence, we do not expect name servers to send packets with DF bit set (and indeed have not seen this behavior, e.g., com, edu ). Note that for the ‘Fragmentable zone’ requirement to hold, any fragmentation suffices, e.g., of 1 byte, and there is no requirement on the contents or length of the second fragments. Hence, we only require existence of a response whose length is greater than l. A ‘Poisonable zone’ requirement is a stronger assumption, since it also implies that the attacker is able to include a (fake) resource record in the response, such that the response - and in particular the fake record - would pass validation at the resolver and get cached. {{{ This requires that the second fragment is predictable [1] (to allow attacker to avoid corrupting the checksum), and that it contains at least one modifiable record - typically, an NS record in the authority section, or an A (‘glue’) record in the additional section. The challenge here is mainly to find queries which will result in second fragments containing the necessary record(s) which the attacker will replace with its own. }}} [1] The (off-path) attacker can query the victim name server itself to select the query whose response it will poison. CACHING AND TIME TO LIVE (TTL). The DNS resolvers will not issue queries at all, if there is a corresponding cached response. The TTL field of each DNS resource record indicates how long it may be cached by resolvers. The majority of TTLs of DNS records range between　one hour to one day, [20]. However, many records have very low or even zero TTLs, e.g., records of content distribution networks (CDNs). Furthermore, some queries, most notably for non-existent domain, always or usually would not be in cache. In fact issuing queries for non-existent domain is similar to Kaminsky style attack, and allows to initiate the attack as frequently as required since the attacker simply prepends a new random string to the query. We demonstrated attacks exploiting fragmented non-existent domain 2 or no-data 3, [1], DNSSECenabled responses. We also found that often DNSSEC public verification key (DNSKEY) records, which typically exceed MTU and get fragmented, have relatively short TTL e.g., 15 minutes in org domain; they also often indicate short expiration time in the signatures. Hence, caching would usually not prevent the attack, and the expiration time of some record from the cache can be anticipated by the attacker; there may be some impact on length of attack and possibly on its commu- nication costs too, but this would not make the attack infeasible. Usually, successful poisoning happens within reasonable time == 2.3 ‘Permissive or Island’ requirement == The ‘Permissive or Island’ requirement is that DNSSEC validation is either not used or is not correctly used, and thus ignored by the resolver; ‘Island’ means that not all the zones from the root to the target zone deploy DNSSEC correctly, and ‘Permissive’ means that resolver does not fail even DNSSEC-enabled responses do not validate. In either of this cases, DNSSEC does not of- fer protection, although deployed === Permissive Resolvers. === A permissive resolver is one that supports DNSSEC, however, ignores DNSSEC validation failures, e.g., if the signatures are missing or invalid; Unbound DNS resolver has an explicit ‘permissive’ mode to support such operation. Obviously, for such resolvers, DNSSEC does not provide added security; yet, there appears to be a significant number of such resolvers [8,16], apparently due to concerns about loss of connectivity due to interoperability and other problems upon enforcing DNSSEC. Such implementors deploy DNSSEC incorrectly or possibly via an ‘incremental deployment’, aiming to preserve DNS functionality with intermediate Internet devices, e.g., firewalls, and legacy resolvers which may discard DNSSEC enabled DNS responses or strip DNSSEC signatures. This approach apparently assumes that permissive use of DNSSEC can provide evidence on whether the network can deploy DNSSEC fully without problems or not, while not harming their security; unfortunately, this is not the case and such resolvers are open to poisoning. === Island of Security. === When the parent zone returns an NSEC or NSEC3 (indicating that the child does not sup- port DNSSEC), while the child does, the resolver can- not establish a ‘chain-of-trust’ to the target zone and thus cannot validate the DNSKEY of the zone. This holds for many second level domains, e.g., children of gov TLD (Figure 3), and even for some TLDs, e.g., mil. As a result, the resolver falls back to non-validating mode, and ignores the signatures in a DNS response.