Socket Overloading for Fun and Cache-Poisoning ∗
Amir Herzberg
Department of Computer Science Bar Ilan University Ramat Gan, Israel
Fachbereich Informatik Technische Universität Darmstadt/EC-SPRIDE Darmstadt, Germany
[email protected]
[email protected]
ABSTRACT We present a new technique: socket overloading, which allows to circumvent source port randomisation, implemented in transport layer protocols. Our attacks are launched with an off-path adversary. We show how to apply socket overloading for: (1) UDP port derandomisation against popular and standard port randomisation algorithms [22], and (2) for cache poisoning and degradation/denial of service attacks against DNS. Our socket overloading technique may be of independent interest, and can be of use in other attacks, and applied against other protocols.
Keywords DNS cache-poisoning, socket overloading
1.
†
Haya Shulman
INTRODUCTION
Since 1989 [9], experts have been arguing that Internet security requires cryptographic protocols, ensuring security against Man-in-the-Middle (MitM) attackers. A MitM attacker is located on the path of the communicating parties, and can manipulate the communication between them in any way, i.e., intercept, modify, block and inject spoofed packets. The information security community invested significant efforts in developing cryptographic schemes and protocols, standards and products, providing security against MitM attackers, such as IPsec, SSL/TLS, Secure-BGP and DNSSEC. In spite of all these efforts, and although Internet security is well recognised to be critical, most Internet traffic is still not cryptographically protected. For example, we found that only about 6% of the TCP traffic is cryptographically protected with SSL/TLS (based on CAIDA dataset of 3 million packets [12]); and less than 1% of the DNS resolvers enforce DNSSEC (cryptographic) validation [16]. ∗sites.google.com/site/amirherzberg/ †Corresponding author sites.google.com/site/hayashulman/
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00.
We believe that the main reason for the underutilisation of cryptography, is an illusion of security against networkbased attacks that current, non-cryptographic, Internet protocols already provide sufficient protection against typical, common attackers, and in particular, against off-path attackers. Unlike a MitM attacker, an off-path attacker cannot observe nor modify traffic exchanged between legitimate parties, however, it can transmit packets with a spoofed (fake) source IP address - impersonating some other party; IP spoofing is still possible via many ISPs, see [2, 11]. We show that in fact, current Internet protocols are often vulnerable even to an off-path attacker. More specifically, we show a new technique for port derandomisation, and apply it to DNS poisoning. The new technique, UDP socket overloading, exploits a simple but rarely investigated weakness of UDP, allowing an attacker to cause packet loss, with limited bandwidth. We believe that socket overloading is interesting, and that it has additional applications and implications; in particular, we show that it can also be used for name-server pinning and for DoS attacks on DNS resolvers. The security of most Internet applications, e.g., email, web surfing, and most peer-to-peer applications, relies on challenge-response mechanisms, i.e., a client sends a random challenge with the request, and validates that the correct challenge value is echoed in the response. Since an off-path attacker cannot eavesdrop on packets exchanged between the server and the client, it appears that he would have to guess the challenge; hence, the (sufficiently long, random) challenge allows to prevent off-path attacker from crafting a packet with a valid challenge. Note that, trivially, challenge-response mechanisms are ineffective against MitM attackers, since they are able to eavesdrop on the challenges. The false sense of security is due to the existing challenge-response mechanisms, in particular, in TCP and UDP, that are believed to provide sufficient defenses against the (weaker and common) off-path attackers. To ease deployment, challenge-response defenses mostly or wholly reuse existing fields; i.e., challenges are fields which already exist in requests and are echoed in responses for some other purpose. The use of a randomised (16-bit) source port field, that maps responses to the client process which issued the request, is a widely used ‘best practice’ against off-path attacks; see RFCs 6056, 5452 and [19]. We argue that such dual-use of an existing field for challengeresponse, while conveniently allowing deployment of defenses only on the client side without requiring coordinated adop-
tion by the server, is often vulnerable. In this work we focus on derandomisation of UDP source port for attacks on the Domain Name System (DNS).
1.1
Domain Name System Security
Correct and efficient operation of the Domain Name System (DNS) is essential for the operation of the Internet. However, there is a long history of vulnerabilities and exploits related to DNS, most notably DNS cache poisoning. In a poisoning attempt the attacker causes recursive DNS servers (resolvers) to cache an incorrect, fake DNS record, e.g., mapping authentic web page to an IP address controlled by the attacker. DNS poisoning can facilitate many other attacks, such as injection of malware, phishing, website hijacking/defacing, circumventing same origin policy and denial of service. The main technique for DNS poisoning is by generating spoofed responses to DNS requests which were sent by resolvers; as a countermeasure, the resolvers validate that the response echoes some unpredictable (random) values sent with the request, such as the DNS transaction ID (TXID) field, the source port selected by the resolver, e.g., see RFC 5452 [18] for more details. Obviously, such mechanisms are insecure against a Man-in-the-Middle (MitM) attacker, who can read the randomness from the request and send a fake response with the valid identifiers. Furthermore, even a weaker - and more common - off-path, spoofing attackers, may be able to generate valid DNS responses when the validated values are predictable or limited. For example, some DNS implementations use predictable identifiers, e.g., in [21], Klein shows how to predict the identifier for the thencurrent version of Bind 9, a widely-used DNS server, and how this can be exploited for highly-efficient DNS poisoning by off-path attackers. Indeed, as pointed out by Vixie [30], already in 1995, the identifier field alone is simply too short (16 bits) to provide sufficient defense against a determined spoofing attacker, who can foil it by sending (not too) many fake responses.
Cryptographic Defense Against Poisoning To improve DNS security, the IETF standardised the DNSSEC [6, 8, 7], an extension to DNS, using cryptography (signatures and hashing) to ensure security (even) against MitM adversaries. However, in spite of the publication of DNSSEC more than a decade ago, in 1997 [1], and the wide awareness to its existence, deployment is still limited - e.g., less than 2% of the domains are signed, as reported in [15]. Worse, only about 0.3% of the resolvers, properly validate DNSSEC [16]. One potential factor for slow adoption of DNSSEC is due to the recent improvements (‘patches’) to non-cryptographic defenses, causing the ‘if it ain’t broke, don’t fix it’ response. These patches are mainly by deploying new sources of ‘unpredictability’ in DNS requests (and validating them in responses) most notably selecting random source ports [18, 22].
can add a significant amount of entropy1 . To prevent birthday attack, where attacker causes resolver to issue multiple requests for the same domain in order to increase the probability of a match with one of the multiple fake responses, Bernstein [10] and others suggest to limit the maximal number of concurrent requests for the same resource record. Many implementations did not integrate support for these suggestions till the Kaminsky attack, [19], which showed that DNS cache poisoning was a practical threat. Kaminsky introduced two critical improvements, allowing devastating attacks on many Internet applications. The first improvement was to control the time at which the resolver sends queries by prepending a random or sequential prefix to the domain name; see details in Figure 9. The second improvement was to spoof a type NS DNS record (specifying a new name for the domain name server) and/or a type A ‘glue’ DNS record (specifying an IP address of that domain’s name server). These records poison the resolver’s entries for the victim name server. Hence, if the attack succeeds once (for one record), the adversary controls the entire name space of the victim. As a result of Kaminsky’s attack, it became obvious that changes were needed to prevent DNS poisoning. Indeed, major DNS resolvers were quickly patched. The most basic patches were known measures - source port randomisation and birthday protection (see above). The patches are summarised in RFC 5452 [18], and recently, [22] standardised a number of ephemeral port selection algorithms to enhance security against off-path attackers. One of the popular and widely deployed source port randomisation is per-destination incrementing ports. A perdestination incrementing port is believed to be secure, since different ports’ sequences are assigned by the resolver to different destinations; in particular learning the port value to one destination does not leak the port value to some other destination. Per-destination ports’ assignment is believed to be secure by experts, e.g., recommended in [22, 28] and supported in popular operating systems, e.g., Linux kernel 3.2. We also checked the predictability rate assigned by the popular DNS checker services, e.g., OARC [14], to resolvers that send DNS requests with per-destination incrementing port, and many tools report (the highest) great score to a perdestination incrementing port; see Table 1. All these indicate that a per-destination ports’ assignment is believed to be secure by the security experts. Furthemore, a perdestination incrementing ports’ assignment also seems to be supported by many resolvers. We performed statistics on the traces of two CAIDA datasets from 2012 [12] and found that more than 54% of the requests are sent from incrementing ports; in our statistics we focused on DNS requests sent over UDP. In this work we present a socket overloading technique that allows to predict the per-destination incrementing ports by off-path attackers.
1.2
Challenge-Response Defenses Against Poisoning Many researchers have identified vulnerabilities and suggested improvements in the approach of relying on an ‘unpredictability’ of some fields in a DNS request and proposed patches; we next review some of the main results. Bernstein, [10], suggested to improve DNS’s defense against spoofed responses by sending DNS requests from random ports, which
Off-Path (Ephemeral) Ports Derandomisation Attacks
In our attacks, we assume an off-path, spoofing adversary connected to the Internet and an internal host, running a puppet, [5], (a script confined by a browser); the attacker 1
The exact amount of entropy added depends on the number of available ports, which may be below 216 .
DNS Resolver
Puppet
Figure 1:
Off-path Attacker
DNS Server
Internet
Attack scenario and network configuration. We
assume an off-path spoofing attacker on the Internet and a puppet (running on a client) that can trigger DNS requests at the resolver.
model is depicted in Figure 1. Our off-path attacks rely on attacker’s ability to predict the five-tuple (protocol, source IP address, destination IP address, source port, destination port) that identifies the transport protocol instance. The addresses are typically known and services are located at known ports. Clients connect to services by specifying server IP address and destination port. The ports of the client are chosen automatically by the network TCP/IP stack, and are called emphemeral ports. The attacker may be able to learn the IP address of the server, and the service port, and the IP address of the client. But should not be able to guess the ephemeral port. We next present a high level idea of the socket overloading technique and its applications for port derandomisation.
1.3
Contributions: Socket Overloading and Applications
Operating systems use interrupts to receive notifications of I/O events. To handle the interrupt the CPU suspends its activity and executes the interrupt handler routine, since the operating systems assign high priority to interrupts. However, if traffic rate increases the CPU spends more of its time processing interrupts for incoming packets. As a result, the input queue fills up and the arriving packets are discarded. We use packet loss as a side-channel, indicating correct guess of an ephemeral port. We show how to apply socket overloading for port derandomisation against algorithms recommended in [22] and evaluate against a port randomisation algorithm deployed in Linux Kernel 3.2 (Section 3). We also show that socket overloading for port derandomisation, allows to circumvent the birthday protection. Port derandomisation can facilitate DNS poisoning (Section ??), by exposing resolvers to Kaminsky style cache poisoning attacks. Furthermore, we use socket overloading for low-rate degradation of service attacks against name servers (Section 4.2) and resolvers (Section 4.1), e.g., for name server pinning.
1.4
Organisation
In Section 2 we introduce our basic technique of socket overload. Then, in Section 3, we show how to apply socket overloading for port derandomisation of algorithms recommended in [22] and evaluate it against a Linux kernel 3.2 OS. Finally, in Section 4, we use socket overloading for low rate attacks on name servers and resolvers, allowing name server pinning, and for DNS cache poisoning attacks. We conclude with countermeasures against our attacks in Section 5.
2.
INTERRUPT-DRIVEN SOCKET OVERLOADING
In this section we introduce the basic technique which allows to discover the ephemeral port, used by the victim resolver, for communication to some destination. We use this technique as a building block in our attacks throughout this work. The idea is based on a packet loss inflicted by the attacker via socket overloading: to sample some port p, an off-path attacker sends a short burst of packets to a port p, causing socket overloading between kernel interrupts; this results in packets’ loss. If the resolver used p to send its request to some name server, then the response from the name server to port p is also discarded. The attacker uses this loss of response from the name server as an indication of hitting the correct port. Notice that a packet loss is caused only when the burst of packets is sent to the same port on which the resolver excepts to receive a response. If a burst is sent to a different port, than the one from which the resolver sent its request, no loss will be incurred. We first describe the basic idea of inbound packet handling by the kernel, in Section 2.1. Then, in Section 2.2, we show how to perform socket overloading, of a known port, such that the system starts discarding incoming packets arriving to that socket. We present experimental evaluation in Section 2.3.
2.1
Inbound Packet Handling and Interrupt Driven Scheduling
The kernels in operating systems (OSes), e.g., Unix variants and Microsoft platforms, use hardware interrupts for event notification purposes in communication with input/output hardware components. Network interface cards (NICs) generate interrupts to notify the kernel of arrival of new packets. When a NIC receives a packet it triggers hardware interrupt. Hardware interrupts can impose significant CPU overhead. This is due to the fact that hardware interrupt is associated with context switching of saving and restoring processor state, see details in [20]. After the notification of a new packet arrival the kernel processes the packet, and then invokes TCP/IP protocol processing. However, arrival of a new packet distrupts protocol processing since hardware interrupts have higher priority over other tasks. Thus under a high traffic load, the socket may fill up if the interrupt level is high, and when the socket queue is full the arriving packets will be dropped. Notice that the topic of avoiding socket overloading was studied in the scope of improving web servers efficiency, e.g., [26, 29]. However, prior art did not investigate applications of socket overloading as a side channel for attacks. In contrast, in this work, we apply socket overloading for attacks on applications, specifically DNS, that depend on security in transport layer. Our goal is to apply socket overloading in a most efficient way, i.e., via the shortest possible burst, and use it as a building block in other, more advanced, attacks, e.g., port derandomisation for DNS cache poisoning or low rate degradation attacks.
2.2
Socket Overloading
On the receiving side the network interface determines the destination socket of incoming packets and places them in the corresponding queue. If the queue is full the packet is discarded. For our socket overloading technique we use
DNS DNS Resolver Resolver 1.2.3.4 1.2.3.4
Client Client 1.2.3.6 1.2.3.6
1
Name Name Server Server 5.6.7.8 5.6.7.8
field
source
destination
field
source
destination
IP
1.2.3.6
1.2.3.4
IP
1.2.3.4
8.8.8.8
Port
5555
53
Port
3424
53
Payload A?$1.foo.org
Packet Size (bytes) 100 500 1000 1500 wrong port
0.5
0.4
0.3
0.2
0.1
field
source destination
IP
6.6.6.6 1.2.3.4
Port
ANY
field
source destination
IP
5.6.7.8 1.2.3.4
Port
53
Payload
Timeout and retransmission
10
3
4
source
destination
IP
1.2.3.4
8.8.8.8
Port
3425
53
Burst of N packets to a port that was selected by resolver for its query.
Payload A?$1.foo.com
source destination
field
source destination
IP
1.2.3.4 1.2.3.6
IP
5.6.7.8 1.2.3.4
Port 53 3425 Payload $1.foo.org NXD
50
whether a correct port is found. Since when sending the burst to a wrong destination port no loss is incurred (the lowest line on the graph), but all the connections experience a (similar) additional delay of tens milliseconds; see Figure 4 for results of the additional latency added for different packets’ sizes.
5
Report response time
Figure 2: Basic technique of socket overloading applied to a DNS resolver. The resolver uses sequentially incrementing ports, known to the attacker.
Experimental Evaluation
20 Attack Rate (MByte/sec)
Figure 3: Evaluation of loss probability for different attacker rates and different packets’ sizes. Notice that when packets are sent to wrong port, no loss is incurred and therefore packets’ size does not matter.
$1.foo.org NXD
field
15
2
3424
field
Port 53 5555 Payload $1.foo.org NXD
0
3424
loss
2.3
0.6
Payload A?$1.foo.com
Payload AAAAAAAAAAAAAAAA
6
Off-path Off-path Attacker Attacker 6.6.6.6 6.6.6.6
The setup consisted of three hosts, the resolver, the client (with access to the resolver) and an off-path attacker. The DNS resolver was run on a host equipped with dual core CPU Intel pentium 4 processors, each running at 3GHz with 4GB RAM. The resolver has a single network interface Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection, and runs a linux kernel 3.2.0 OS. The off-path attacker was run on a host with the same description. The resolver and the client were connected via a switch on a university (fast ethernet) 100Mb/sec LAN. The client was used to trigger DNS requests at the resolver, and the attacker’s host was on a different university network segment connected via a router. We tested the effectiveness of the socket overloading technique by triggering a DNS request at the resolver and running an attack sequence that consisted of a burst of 1 second duration per DNS request; we repeated the attack 500 times. The results are reported in Figure 3. Notice that we use a single host to send malicious bursts. This host itself has interrupts when generating packets’ bursts, therefore distributing the task among a number of hosts would achieve better success probability, requiring lower burst volume. Latency however cannot be used for indication of
Packet Loss Probability
the fact that frequent packet arrivals generate interrupts at the receiver and overflow occurs when packet processing is in progress and packets arrive too frequently. Specifically, when a new packet arrives before per-packet processing completes the kernel has to service the newly generated interrupt. As long as new packets are coming in, the kernel cannot execute application code, as a result the socket buffer will eventually overflow. To introduce our basic technique of socket overloading, we assume (for simplicity) that the attacker knows the port of the victim host, e.g., the attacker attempts to overload the socket of a resolver that performs a recursive resolution on a known fixed port; in subsequent sections we show how the attacker can apply this technique to discover the port. Notice that UDP socket is defined by a pair destination IP address, destination port. Therefore, the attacker can send the burst of packets from any source IP address and source port, and they will all be demultiplexed to the same socket according to destination IP address, destination Port specified in packets’ headers. The steps of the attack are illustrated in Figure 2. In step (1) the attacker triggers a DNS request via the client. In step (2) the attacker sends a burst of N packets to the victim host. Notice that the packets can be sent from a spoofed source IP address, e.g., to evade detection. The attacker’s goal is to send the packets at a sufficiently high rate, such that the victim host is overwhelmed with interrupts due to incoming packets, and as a result cannot deplete the buffer, to allocate space for subsequently arriving packets. As a result, the packet fill the buffer and eventually the system starts discarding incoming packets.
3.
PORT DERANDOMISATION VIA SOCKET OVERLOADING
In this section we describe port randomisation methods, standardised and deployed in popular systems, and show how to apply our socket overloading technique for port derandomisation and discovery. Port derandomisation attacks were proposed in ([17]), however, they require a zombie (unpriviledged malware) on the LAN and a DNS resolver be-
100 90 80
CDF %
70 60 50 40 30 Packet Size (port) 500 (wrong) 100 (wrong) 500 (correct) 100 (correct)
20 10 0 16
32
64
128
256 512 1024 Latency (ms)
2048
4096
8192 16384
Figure 4: Evaluation of additional latency due to attack when sending packets’ burst to incorrect vs correct destination port for different packets’ sizes (500 and 100 bytes).
hind a network address translator. In contrast, the techniques proposed in this work only require the ability to trigger queries at the DNS resolver, i.e., the basic requirement of the Kaminsky cache poisoning attack [19] (Figure 9). We show how to apply port overloading technique for port discovery against a number of popular port randomisation methods. Specifically, we focus on the recently proposed algorithms, [22], aimed at randomising the ports selected by clients, to prevent attacks on application layer protocols. We also apply our technique against a port randomisation method supported by the Linux kernel, and show that it applies to other popular operating systems, we report on the result in Table 1. In each following subsection, we give an abstract presentation of the port allocation method and show how it can be circumvented using the port overloading technique. Our presentation of the algorithms focuses on the property of ‘unpredictability’ and we simplify the algorithms by ignoring issues such as port wrap-around, and instantiations of ports’ ranges; for simplicity we assume that the range of available ports is P. We also report on our findings related to the effectiveness of different DNS checker services and their ability to detect vulnerable port assignment methods, see Table 1. Notice that Algorithms #1 and #2, [22], select random port for each outgoing packet, and thus are not vulnerable to port derandomisation attacks.
3.1
Simple Hash-Based Port Selection Algorithm
Simple hash based port assignment method is described in Algorithm #3, [RFC6056] [22]. The port selection algorithm, at the sender, maintains a different offset to each destination, such that an offset is a pseudorandom function computed over a tuple (source IP address, destination IP address, destination port, secret key), and uses a single counter, that is incremented globally, by one, for each allocation, and added to the offset of the relevant destination. As a result, connections to different destinations will have different sequences of port numbers, and one destination should
not be able to anticipate the ports allocated to the other. This algorithm was supported by Linux OS kernel version 2.6, and was believed to be secure against off-path attackers. Recent Linux versions also use a variation of per-destination incrementing ports, see Section 3.4. In Figure 5 we show how to apply our socket overloading technique to discover the ephemeral port used by a victim resolver to some destination name server. The attacker learns the typical delay δ for a request to some name server (step (1) in Figure 5), i.e., sends Q DNS requests for different records to the target name server2 . The attacker then triggers DNS requests (via a client on the LAN) (step (2)), and generates bursts of N UDP packets to each candidate port (step (3)), starting with the highest port, and decrementing the port during each attempt. The ephemeral port is found if during sampling of a candidate port z the response arrives after τ > δ seconds. Otherwise, the attacker repeats the attack with a new port z − 1; following a descending order of ports sampling as in Figure 6. The attacker learns if the corDNS DNS Resolver Resolver 1.2.3.4 1.2.3.4
Client Client 1.2.3.6 1.2.3.6
Name Name Server Server 5.6.7.8 5.6.7.8
Off-path Off-path Attacker Attacker 6.6.6.6 6.6.6.6
Measure typical response latency δ
1 DNS Request SrcPort: x
2
DNS Request SrcPort: y UDP Packet DstPort: z
t=0 sec DNS Response DstPort: x
DNS Response DstPort: y
3
4 Register response latency t=τ sec
UDP Packet DstPort: z
Burst of N UDP packets sent to port z
Response latency: t=τ sec
5
If τ>δ then z==y Else repeat with port z-1
Figure 5: Socket overloading for ephemeral port discovery: the attacker applies socket overloading to each port, starting with highest port, and then decrementing the candidate ports during each iteration. The ephemeral port is discovered when the response latency is higher than typical response. rect port is hit, via the response latency. Notice that when the correct port is hit, packet loss is incurred. This results in query retransmission by the resolver, and adds tens (and often hundreds) of milliseconds to response time3 . Once the port is discovered, the attacker can use its value for attacks at some later time, without discovering the port again. This is due to the fact that the same counter is used to all destinations, thus the attacker only needs to trigger a DNS request to a server that it controls, to check the current counter value, and adjust the port value accordingly.
3.2
Double-Hash Port Selection Algorithm
Algorithm #4, [RFC6056] [22], builds on Algorithm #3 (Section 3.1), but instead of keeping a globally increment2 If the domain uses a number of name servers, the attacker has to repeat the measurements for each name server of that domain. 3 Typical latency for a DNS request and response is in the order of 100 ms.
Resolver assigns sequentially incrementing ports
1025 1026 1027
Attacker samples ports in sequentially decrementing order
...
16
2 −1 2
16
ports' range
Figure 6: Port sampling in descending order. ing counter for all destinations, it groups the destinations to m sets and uses a separate counter to each set. The recommended value of m is 10, [22, 4], however, as [4] notes, larger m values provide for better port obfuscation, since the same counter is not shared between too many clients. Notice that the special case of m = 1 is supported in Linux kernel 3.2 (Section 3.4). First, the attacker attempts to find an IP address that falls within the same set as the target name server (the goal of the attacker is eventually to discover the port used by the resolver to that name server); for instance, the attacker may try a number of hosts, e.g., bot computers that it controls. The idea is to trigger a request to some host i, and then check, by applying the socket overloading technique, if the current port, allocated to the target server, was incremented; the port sampling attack steps are similar to those presented in Figure 5. If yes, then the host at IP address i falls within the same set as the target name server. This host i can be used to sample port increments. Note, that this phase is only required if the attacker wishes to maintain the port value in a long term, to launch subsequent attacks, e.g., name server pinning (Section 4.1).
3.3
Random-Increments Port Selection Algorithm
Algorithm #5, [RFC6056] [22], maintains a globally incrementing counter to all destinations, which is incremented by (a randomly selected) N at each invocation of the ephemeral port allocation procedure. If N = 1 then this is the globally incrementing algorithm implemented in Windows and FreeBSD operating systems. The attack in Figure 5 apP = getPortsRange() //ports number N = 500 count = P ephemeral = random(P) do{ ephemeral = ephemeral + random(N) + 1; port = 1024 + ephemeral; ephemeral++; return port; } while (count-- > 0); Figure 7: Algorithm #5 in [22]. Global counter, incremented by (a randomly selected) parameter N ; recommended value of N is 500. plies with a slight modification: the attacker has to sample N ports, instead of one, in each attempt. Notice, that although the actual value selected by the port allocation procedure can be less than N but since the attacker does not know its value, it has to sample N ports each time in the worst case. This requires significantly more efforts, since
the attacker has to generate a burst of packets to each of N ports. Furthermore, even when hitting the correct port, the attacker cannot tell which port, out of sampled N ports, it was. To optimise this attack we trigger multiple DNS requests (instead of a single DNS request), which allows us to circumvent the birthday protection. The attacker triggers N DNS request via the client for different resource records within the victim domain, i.e., j.foo.org where (0 ≤ j ≤ N ), and then launches the socket overloading attack. A response with latency above typical, indicates the correct guess; this strategy also allows to learn the ephemeral port value4 . Notice that the attacker cannot trigger the ‘traditional’ birthday paradox, used in Kaminsky attack [19], since resolvers were patched to restrict the number of multiple identical queries. In contrast, in this case the goal is to find the port, and not to match a specific query, therefore, the attacker can trigger queries for different subdomains of the target domain. Once N queries are triggered, the off-path attacker only needs to hit a single port, to ensure success. The success probability, and the number of iterations for success, is proportional to the size of N . Therefore, to reduce the success of port derandomisation attacks, N should be as large as possible. On the other hand, large N increases the chance for port collisions due to ports’ reuse from previous connections, and smaller values of N are required to reduce collisions.
Vendor Linux Netfilter (kernel 3.2) Linux Netfilter (kernel 2.6)
Port Allocation Alg. 4 (m = 1) Alg. 3
Windows 7 (SP 3)
Alg. 5 (N = 1) Alg. 5 (N = 1)
Windows XP ICS (SP 3)
Alg. 4 (m = 1)
FreeBSD 9.1
DNS-checkers scores OARC Provos GRC PDPT [14] [25] [13] [24] great
great
fail
weak
great
great
fail
weak
fail
fail
fail
fail
fail
fail
fail
fail
great
great
fail
weak
Table 1: Summary of port randomisation methods supported by popular operating systems. Right columns are grades assigned by DNS checker services for the port allocation methods supported by these operating systems (normalised: good, weak, fail). Notice that the test by PDPT [24], in contrast to other DNS checkers, depends on the traffic that traverses the gateway.
3.4
Per-Destination Incrementing Ports Algorithm
In Linux OS kernel, the initial port to some destination is selected at random, and subsequent ports to that desti4 At each invocation a random number, between 1 and N , is added to the previous port value to obtain the next port. Thus, maintaining the port knowledge in the long term may be expensive, and the attacker may prefer to launch the attack in tandem with port discovery.
3.4.1
Analysis and Evaluation
The analysis and evaluation of the attack is presented in Figure 8. We next calculate the success probability, the required worst case number of attack iterations and the number of requests by a client and UDP packets by off-path attacker. Probability of hitting the correct port in a single attempt, when triggering Q DNS queries, is: Pr[success] =
Q 216
The success probability during ith iteration of the attack is: Pr[success] =
Q 216 − i · Q
In the worst case the attack has to be repeated at most 15 216 i ≤ 2·Q = 2Q iterations (assuming that at each iteration the attacker sends Q queries). The total number of DNS queries, sent by the client, in the worst case is Q· 5
215 = 215 Q
If resolvers implement decrementing ports, than the attacker should sample ports in ascending order; to check this the attacker needs to trigger a request to a host that it controlls. 6 The ports’ range is typically lower, but we ignores this in this work.
Iterations 1 10 50 100 250
0.25
0.06 0.02
0.0009
Optimisations: Circumventing the Birthday Protection
‘Birthday attack’ is a well-known optimisation for classical DNS cache poisoning attacks, where the attacker not only sends many responses (with different guesses for challenge values), but also generates multiple requests to the same query, to increase the probability of a match between some request and some response. Following Kaminsky’s attack [19], most current resolvers prevent the ‘birthday attack’, by deploying birthday protection: not sending multiple concurrent requests for the same query. We show that this ‘birthday protection’, can be circumvented by applying our socket overloading attacks for port prediction. The attacker can send multiple DNS requests, for different random subdomains of some domain; since these are different domains, birthday protection does not apply. As a result, a burst of N spoofed UDP packets to a single port has a higher chance to hit the currently open port, i.e., instead of targeting 1 port out of 65535 available ports6 the attacker has to match any of the Q currently open ports. As a result the range of ephemeral ports is reduced.
3.4.2
1
Success Probability
nation are incremented sequentially. This method is in fact a special case of Algorithm #3 [RFC6056] in Section 3.1, (Figure ??), except that a distinct counter is maintained per destination (instead of a global counter for all destinations). The same attack of socket overloading for port derandomisation in Figure 5 applies. Notice that the only difference is that the maintenance of the port (e.g., for future exploits) requires more effort. Notice also that when derandomising per-destination ports an efficient strategy is to sample the port in descending order, from the highest to lowest5 .
8
16
32 64 128 Number of Requests [log-scale]
256
512
Figure 8: Socket overloading for ephemeral port discovery against Linux Kernel 3.2. The results are presented for a variable number of iterations of attack. and total number of UDP packets, sent by off-path attacker, is N·
215 Q
Notice that it is not so profitable for the off-path attacker to sample more than one port at each iteration. Assume that the attacker samples a set of P ports, then it has to send a burst of P · N packets, i.e., N packets to each port. However, this is the number of packets it would have to send to sample P ports in i = P iterations anyways, since sampling each port requires N packets. The attacker only saves the number of queries which the client triggers, and instead of triggering P queries (one per iteration) a single query is sent; which does not contitute a significant gain, while exposing to detection, since higher volume of packets is sent.
4.
LOW-RATE DOS ATTACKS USING SOCKETOVERLOADING
In this section we utilise socket overloading for a number of attacks: DNS cache poisoning, name server pinning, and low-rate denial of service attacks. In all our attacks the attacker exploits interrupt based socket overloading, to cause packet loss. In this section we assume that the port of the victim host is known: (1) via port derandomisation attacks in Section 3 or via derandomisation attacks in [17]; (2) the victim host is a server, with a service on a known port, e.g., 53, (this does not require the initial phase of port derandomisation). Applying port-overloading for DNS cache poisoning is a simple extension to the Kaminsky attack: the attacker performs port discovery, and then uses the knowledge of the port to perform cache poisoning by sending 216 responses7 for each possible transaction ID (TXID) value. Once the 7 If the rate of the requests from the resolver to the target name server is high then the attacker may have to repeat the attack for a number P of ports, s.t., P is a function of the requests frequency.
victim port is known, the attacker can launch Kaminsky style, [19], DNS cache poisoning attacks; see Figure 9. DNS DNS Resolver Resolver 1.2.3.4 1.2.3.4
Client Client 1.2.3.6 1.2.3.6
1
Off-path Off-path Attacker Attacker 6.6.6.6 6.6.6.6
field
source
destination
field
source
destination
IP
1.2.3.6
1.2.3.4
IP
1.2.3.4
5.6.7.8
Port
53
53
Port 53 53 TXID 3544 Payload A?$1.foo.com
TXID 127 Payload A?$1.foo.com
2
field
source destination
IP
5.6.7.8 1.2.3.4
Port
53
53
TXID 1 Payload foo.com NS ns.foo.com ns.foo.com A 6.6.6.6
field
source destination
IP
1.2.3.4 1.2.3.6
Port
53
53
TXID 127 Payload $1.foo.com NXD
4 Response with correct TXID is cached and sent to client
Name NameServer Server ns.foo.com ns.foo.com 5.6.7.8 5.6.7.8
field
source destination
IP
5.6.7.8 1.2.3.4
3
Port 53 53 TXID 3544 Payload foo.com NS ns.foo.com ns.foo.com A 6.6.6.6
field
source destination
IP
5.6.7.8 1.2.3.4
Port
53
53
216 spoofed DNS responses, For each TXID value
TXID 65536 Payload foo.com NS ns.foo.com ns.foo.com A 6.6.6.6
Response ignored, since no matching pending request
field
source destination
IP
5.6.7.8 1.2.3.4
Port
53
53
TXID 3544 Payload $1.foo.com NXD
5
Figure 9: Kaminsky DNS cache poisoning attack, whereby the attacker sends 216 spoofed responses (for each value of TXID) to a known port (following the port derandomisation via socket overloading).
4.1
minutes. The idea in this attack is to ‘kill’ few responses, i.e., force the receiving host to discard few responses, within a limited (but not too short) time interval. To optimise the attack, the attacker may send multiple requests during each iteration; this circumvents the birthday protection mechanisms. Only few failed (timed-out) requests suffice to block a name server, and the failures can be for requests to any name server hosted in the given IP address - not necessarily the one being attacked. NS pinning is often effective against a specific name server IP, and not limited to a specific domain. Namely, when a name server serves several domains, by blocking DNS responses to one domain that it serves, we block its IP address in general, for all the domains that it serves. For example, name server at IP 38.103.2.1 serves paypal.com as well as isi-sns.info. By blocking responses to isisns.info, the attacker blocks the name server and dissuades the resolver from querying it also for paypal.com. Blocking response to isi-sns.info may be easy, e.g., since attacker registered a fragmentation-causing subdomain of info. Since name servers often host multiple domains, DNS response blocking is very effective. According to our measurements, 71.53% of the name servers hosting the top 10, 000 domains according to Alexa [3], and 26.28% of the name servers of TLDs, serve more than one domain. To force the DNS resolver to query a specific name server, the attacker can repeat the response blocking technique for all the name servers, except one, which the attacker wishes the resolver to use. DNS DNS Resolver Resolver 1.2.3.4 1.2.3.4
Client Client 1.2.3.6 1.2.3.6
1
field
source
destination
field
source
destination
IP
1.2.3.6
1.2.3.4
IP
1.2.3.4
8.8.8.8
Port
5555
53
Port
3424
53
Payload A?$1.foo.org
field
source destination
IP
6.6.6.6 1.2.3.4
Port
ANY
3424
Payload AAAAAAAAAAAAAAAA field
source destination
IP
5.6.7.8 1.2.3.4
Port
53
Payload
2
3424
$1.foo.org NXD
3
loss
After t seconds timeout and retransmission
Off-path Off-path Attacker Attacker 6.6.6.6 6.6.6.6
Payload A?$1.foo.com
NS Pinning Resolvers by Socket-Overloading
Socket overloading can be applied for name server (NS) pinning, see Figure 10. NS pinning was introduced in [17] (Chapter ??). However, in that work, the attack relies on fragmented DNS packets to block responses from the name server. Notice, though, that most DNS responses do not fragment, since they do not exceed the path MTU. Socket overloading allows to perform NS pinning without requiring fragmentation. NS pinning attack can facilitate many other attacks, e.g., it can improve efficiency of cache poisoning attacks and of attacks exploiting name-server vulnerabilities [27]. This attack can also cause degradation of service, by causing resolvers to use a sub-optimal name server, however, by itself, it cannot cause denial-of-service. The attack works by blocking some name servers, i.e., forcing the resolver to use only a subset of the name servers. The NS blocking attack is applicable (mostly) to DNS resolvers that follow a behaviour recommended in [RFC4697] [23] and [31]. The recommendation suggests that resolvers should avoid querying non-responsive name servers, if there are two or more failed responses within some time interval. The NS pinning attack applies to standard and popular resolvers, e.g., Unbound 1.4.18 resolver, which sets the interval to 15
Name Name Server Server 5.6.7.8 5.6.7.8
4
field
source
destination
IP
1.2.3.4
8.8.8.8
Port
3425
53
Payload A?$1.foo.com
Burst of N packets to a known resolver's port Repeat step (2) after a t seconds
Figure 10: Low rate DoS on DNS resolvers for name server pinning.
4.2
Low-Rate DoS on Name Servers
This attack does not depend on source port allocation supported by the resolvers, and applies also to resolvers that implement random ports, e.g., Algorithms #1 or #2 ([RFC6056]). This is due to the fact that the attacker targets the known service port of the name server, and not that
of the resolver. Therefore, the ephemeral port used by the resolver does not impact the attack. The attack impacts both the victim name server as well as the participating resolvers. The idea of the attack, in Figure 11, is to trigger a DNS request to a target name server, then, to apply socket overloading on the receiving socket of the name server, i.e., port 53. As a result, the DNS request is discarded, the resolver timesout and retransmits the request. To optimise the attacker can force a large number of resolvers, e.g., open resolvers, to participate in the attack, i.e., to send DNS requests simultaneously, which aplifies the impact of port overloading; the attacker also adjusts its burst to the retransmission timeouts of the resolvers, to increase the impact of the attack.
Evaluation Challenges. Real name servers on the Internet are designed to handle large load of requests, all on the same port 53. Therefore, they have specific mechanisms for handling requests on the same port. The name servers typically run on strong hardware, that can handle a large amount of simultaneos DNS requests. As result, testing the impact of our attack on a lab name server will not reflect the impact of the attack on a real name server on the Internet. In addition, many domains deploy load balacing and other techniques, which significantly reduce the impact of the attack. Furthermore, the attack may be complicated by the fact that domains typically use more than one name server. Therefore, resolvers, depending on their server selection algorithm, may select a different server each time, reducing the impact of socket overloading. However, this may be more effective approach than the mere flooding attacks. Furthermore, this approach can be used for name server pinning, even when resolvers use random ports. DNS DNS Resolver Resolver 1.2.3.4 1.2.3.4
Client Client 1.2.3.6 1.2.3.6
2
Name Name Server Server 5.6.7.8 5.6.7.8
Off-path Off-path Attacker Attacker 6.6.6.6 6.6.6.6 field
source
destination
IP
6.6.6.6
5.6.7.8
ANY
53
field
source
destination
Field
source
destination
Port
IP
1.2.3.6
1.2.3.4
IP
1.2.3.4
5.6.7.8
Payload AAAAAAAAAA
Port
5555
53
Port
3424
53
Payload A?$1.foo.org
Timeout and retransmission Of DNS request
Payload A?$1.foo.com
3
field
source
destination
IP
1.2.3.4
5.6.7.8
Port
54525
53
Payload A?$1.foo.com
1
loss
field
source
destination
IP
6.6.6.6
5.6.7.8
Port
ANY
53
Payload AAAAAAAAAA
Burst of N packets
Burst of N packets
loss
Figure 11: Low rate attack on name servers, e.g., can be used for name server pinning against some victim resolver.
5.
CONCLUSIONS AND DEFENSES
We present UDP socket overloading, a new attack tool, which provides a timing side channel for exposing the ephemeral port used by a victim host, and can also be used to launch pinning and DoS attacks against DNS name servers. Exposing the port of the victim host can be utilised for DNS
cache poisoning, when resolvers use per-destination incrementing algorithms for ephemeral ports selection, that were recommended in [22]. The best defense against the poisoning attacks is to properly deploy and validate DNSSEC; DNSSEC provides security not only against off-path attacker but even against MitM attacker. We hope that our results will help motivate administrators to adopt DNSSEC. Until that happens, we recommend to properly randomise the ports, and avoid per-destination sequential port allocation, which we show is predictable.
6.
REFERENCES
[1] D. E. 3rd and C. Kaufman. Domain Name System Security Extensions. RFC 2065 (Proposed Standard), Jan. 1997. Obsoleted by RFC 2535. [2] Advanced Network Architecture Group. ANA Spoofer Project. http://spoofer.csail.mit.edu/summary.php, May 2013. [3] Alexa. The web information company. http://www.alexa.com/. [4] M. Allman. Comments on selecting ephemeral ports. ACM SIGCOMM Computer Communication Review, 39(2):13–19, 2009. [5] S. Antonatos, P. Akritidis, V. T. Lam, and K. G. Anagnostakis. Puppetnets: Misusing Web Browsers as a Distributed Attack Infrastructure. ACM Transactions on Information and System Security, 12(2):12:1–12:15, Dec. 2008. [6] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Introduction and Requirements. RFC 4033 (Proposed Standard), Mar. 2005. [7] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Protocol Modifications for the DNS Security Extensions. RFC 4035 (Proposed Standard), Mar. 2005. [8] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource Records for the DNS Security Extensions. RFC 4034 (Proposed Standard), Mar. 2005. [9] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. Computer Communication Review, 19(2):32–48, apr 1989. [10] D. J. Bernstein. DNS Forgery. Internet publication at http://cr.yp.to/djbdns/forgery.html, November 2002. [11] R. Beverly, A. Berger, Y. Hyun, and K. C. Claffy. Understanding the Efficacy of Deployed Internet Source Address Validation Filtering. In A. Feldmann and L. Mathy, editors, Internet Measurement Conference, pages 356–369. ACM, 2009. [12] CAIDA. Anonymized Internet Traces 2012 Dataset. http://www.caida.org/data/passive/passive_2012_ dataset.xml, 2012. [13] G. R. Corporation. DNS Nameserver Spoofability Test. https://www.grc.com/dns/dns.htm, 2012. [14] DNS-OARC. Domain Name System Operations Analysis and Research Center. https://www.dns-oarc.net/oarc/services/porttest, 2008. [15] L. Eggert. DNSSEC deployment trends. At:http:\\http://eggert.org/meter/dnssec. [16] O. Gudmundsson and S. D. Crocker. Observing DNSSEC Validation in the Wild. In SATIN, March 2011. [17] A. Herzberg and H. Shulman. Security of Patched DNS. In S. Foresti, M. Yung, and F. Martinelli, editors, Computer Security - ESORICS 2012 - 17th European Symposium on Research in Computer Security, Pisa, Italy, September 10-12, 2012. Proceedings, volume 7459 of Lecture Notes in Computer Science, pages 271–288. Springer, 2012. [18] A. Hubert and R. van Mook. Measures for Making DNS More Resilient against Forged Answers. RFC 5452 (Proposed Standard), Jan. 2009.
[19] D. Kaminsky. It’s the End of the Cache As We Know It. In Black Hat conference, August 2008. [20] S. R. Kleiman. Apparatus and method for interrupt handling in a multi-threaded operating system kernel, May 7 1996. US Patent 5,515,538. [21] A. Klein. BIND 9 DNS cache poisoning. Report, Trusteer, Ltd., 3 Hayetzira Street, Ramat Gan 52521, Israel, 2007. [22] M. Larsen and F. Gont. Recommendations for Transport-Protocol Port Randomization. RFC 6056 (Best Current Practice), Jan. 2011. [23] M. Larson and P. Barber. Observed DNS Resolution Misbehavior. RFC 4697 (Best Current Practice), Oct. 2006. [24] J. Oberheide. PDPT: Passive DNS Port Test. http://jon.oberheide.org/blog/2008/07/21/ pdpt-passive-dns-port-test/, July 2008. [25] N. Provos. DNS Testing Image. http://www.provos.org/ index.php?/archives/43-DNS-Testing-Image.html, July 2008. [26] K. Ramakrishnan. Performance considerations in designing network interfaces. Selected Areas in Communications, IEEE Journal on, 11(2):203–219, 1993. [27] V. Ramasubramanian and E. Sirer. Perils of transitive trust in the domain name system. In Proceedings of the 5th ACM SIGCOMM conference on Internet Measurement, pages 35–35. USENIX Association, 2005. [28] M. Rash. NAT and Checking for DNS Cache Poisoning Exploitability. http://www.cipherdyne.org/blog/categories/dns.html, August 2008. [29] K. Salah, K. El-Badawi, and F. Haidari. Performance analysis and comparison of interrupt-handling schemes in gigabit networks. Computer Communications, 30(17):3425–3441, 2007. [30] P. Vixie. DNS and BIND security issues. In Proceedings of the 5th Symposium on UNIX Security, pages 209–216, Berkeley, CA, USA, jun 1995. USENIX Association. [31] Y. Yu, D. Wessels, M. Larson, and L. Zhang. Authority server selection of dns caching resolvers. ACM SIGCOMM Computer Communication Reviews, April 2012.
