Off-Path Attacking the Web Yossi Gilad and Amir Herzberg Department of Computer Science Bar Ilan University Abstract sends spoofed packets, i.e., packets with fake (spoofed) We show how an off-path (spoofing-only) attacker can sender IP address. Due to ingress filtering [24, 15, 5] and perform cross-site scripting (XSS), cross-site request other anti-spoofing measures, IP spoofing is less com- forgery (CSRF) and site spoofing/defacement attacks, monly available than before, but still feasible, see [2, 14]. without requiring vulnerabilities in either web-browser Apparently, there is still a significant number of ISPs that or server and circumventing known defenses. Attacker do not perform ingress filtering for their clients (espe- can also launch devastating denial of service (DoS) at- cially to multihomed customers). Furthermore, with the tacks, even when the connection between the client and growing concern of cyberwarfare and cybercrime, some the server is secured with SSL/TLS. The attacks are prac- ISPs may intentionally support spoofing. Hence, it is still tical and require a puppet (malicious script in browser reasonable to assume spoofing ability. sandbox) running on a the victim client machine, and at- However, there is a widespread belief that an ‘off- tacker capable of IP-spoofing on the Internet. path’ spoofing attacker, cannot inject traffic into a TCP Our attacks use a technique allowing an off-path at- connection. The reasoning is that an incoming TCP tacker to learn the sequence numbers of both client and packet must contain valid sequence number (or be dis- server in a TCP connection. The technique exploits the carded); the sequence number field is 32 bits long and fact that many computers, in particular those running initialized using randomness, therefore, it seems unlikely Windows, use a global IP-ID counter, which provides a that an attacker can efficiently generate a spoofed packet side channel allowing efficient exposure of the connec- which will be accepted by the recipient, i.e., inject data tion sequence numbers. into the TCP stream. We present results of experiments evaluating the learn- This belief is also stated in RFCs and standards, e.g., ing technique and the attacks that exploit it. Finally, we in RFC 4953, discussing on TCP spoofing attacks (see present practical defenses that can be deployed at the fire- [42], Section 2.2). Indeed, since its early days, most In- wall level; no changes to existing TCP/IP stacks are re- ternet traffic uses TCP - and is not cryptographically pro- quired. tected, in spite of warnings, e.g., by Morris [33], Bellovin [8, 10]). arXiv:1204.6623v1 [cs.CR] 30 Apr 2012 1 Introduction Of course, TCP injections are easy, for implementa- tions using predictable initial sequence numbers (ISNs). TCP is the main transport protocol over the Internet, This was observed already by Morris at 1985 [33] and ensuring reliable and efficient connections. TCP was abused by Mitnick [38]. Later, at 2001, Zalewski not designed to be secure against Man-in-the-Middle found that most implementations still used predictable (MitM); in fact, it is trivially vulnerable to MitM attacks. sequence numbers [46]. However, it seems that man-in-the-middle and eaves- However, by now, most or all major implementations dropping attacks are relatively rare in practice, since they ensure sufficiently-unpredictable initial sequence num- require the attacker to control routers or links along the bers, e.g., following [19, 20]. Does this imply that TCP path between the victims. Instead, most practical attacks injections are infeasible? involve malicious hosts, without MitM capabilities, i.e., Zalewski [48] suggested that it may be possible to the attackers are off-path. spoof a non-first fragment of a (fragmented) TCP packet, In our attacks, as well as in many other off-path attacks when the values of the fragment IP-IDs are predictable. (e.g., SYN-flood [42], DNS-poisoning [22]), the attacker In particular, existing implementations of Windows use 1 globally-incrementing IP-ID values, which are easy to New connection formed, C HTTP referrer: mallory.com predict. Zalewski’s attack may also be applicable to S.com Linux, using the IP-ID prediction techniques in [17]. Network However, exploiting such non-first-fragment TCP in- jections seems challenging; furthermore, currently al- XSS, CSRF or clog C-S most all TCP implementations use path MTU discovery link [32, 31] and avoid fragmentation completely. Hence, Za- lewski’s attack (on TCP) will rarely work in practice. mallory.com Yet, we show that TCP injections are still possible. Figure 1: Network Model. C enters www:mallory:com, We present an efficient, practical technique, based on the adversarial web page. A script on that page forms a globally-incrementing IP-ID, allowing an off-path adver- connection with www:s:com. sary, Mallory, to inject data into a TCP connection be- tween two communicating peers: a client C and a server S. The attack is not immediate, and requires a connection lieved that such attacks are impractical and too complex lasting a few dozens of seconds. We present experimen- to be exploited in practice. They confirmed our results tal results, showing that our techniques allow efficient, and agreed that they are feasible; they will address the practical TCP injections. Furthermore, we show, that the problem in new releases. attacks have significant potential for abuse. Specifically, We believe that this response is ‘too little, too late’, we show how our TCP injection techniques, allow both and that it is critical for the community to be aware of the circumvention of the Same Origin Policy [6, 49] and dev- threat and apply mitigations (Section 7). A more contro- astating DoS attacks. Details follow. versial conclusion is the need to apply more prudent ap- Our TCP injection technique is related to a proposal proach to network security vulnerabilities, and respond for TCP injection, by klm [27]. The technique described to early indications of weakness, without waiting for a by klm had some limitations, e.g., it did not work for complete exploit; see discussion in Section 8. clients connected by a firewall. More significantly, klm Much of our work focused on analyzing what are the did not present experimental results; our experiments practical implications of the TCP injection. We study show that their technique, even with some improvements, two approaches to exploit TCP injections: to circumvent results in low injection success rates, unless the attacker address based server authentication, usually referred to has low latency to the victim (as when they are on the as Same Origin Policy (SOP) [6, 49]; and to launch a De- same LAN). Our techniques avoid this limitation. We nial of Service (DoS) attack. We discuss each of these provide a detailed comparison between our technique to briefly in separate subsections below, and in depth in [27] in appendix A. Sections 2 and 3. All attacks are based on the same at- Like [48, 17, 27], our technique is based on the pre- tacker and network assumptions which we now describe. dictability of the IP-ID (e.g., in Windows); however, in- stead of using the predictable IP-ID to intercept or mod- Attacker Capabilities and Network Model ify fragmented packets, as in [48, 17], we use the changes in the IP-ID as a side channel. We use this side-channel All our attacks work in the same settings: an off-path, to allow the attacker to detect difference in responses for IP-spoofing attacker. We also assume that the attacker is crafted probe packets that she sends to the client; our im- able to control some puppets [4], i.e., scripts, applets or plementation uses specific probes, but others may exist. other restricted (sandboxed) programs, running on client Previous works noted that the predictable IP-ID can machines accessing an adversarial web site. This is il- be used as a side channel, allowing an attacker to use one lustrated in Figure 1 where C enters a site controlled by connection to learn about events in another connection, the adversary, Mallory. This allows Mallory to run a ma- which is undesirable. Gont [18] mentions several ways licious script within C’s browser sandbox. The script al- in which the side channel based on globally-incremented lows Mallory to (1) form the connection between C and IP-ID can be abused. However, their impact is modest. S, and (2) probe C’s connection with S and avoid firewall In particular, the side-channel can be used to perform the filtering. The first allows Mallory to choose the victim idle (stealth) scan attack [47, 26, 29], and to count the server (S), we show how the second allows exposure of number of machines behind NAT [9]. the TCP connection’s four tuple. However, vendors continued using globally- As mentioned above, our attacks require that the con- incrementing IP-ID values, even after we presented nection from C and S will not be short; since Mallory our initial TCP injection results to them, and being forms this connection (using the puppet), she can ensure aware of the previous attacks exploiting the globally that it does not terminate by sending periodic requests incrementing IP-IDs. Their justification is that they be- to the server. In persistent HTTP connections, all re- 2 quests are over the same (victim) connection and ensure a server side or browser vulnerability. Moreover, since it does not close. Persistent HTTP connections are the Mallory can choose the server S, any persistent HTTP default configuration of apache servers and are also em- connection between C and a server is vulnerable (see ployed by many large web-servers (e.g., Facebook, Ya- above).