Ccs12 Qian

Download as pdf or txt
Download as pdf or txt
You are on page 1of 12

Collaborative TCP Sequence Number Inference Attack

How to Crack Sequence Number Under A Second

Zhiyun Qian Z. Morley Mao Yinglian Xie


Department of EECS Department of EECS Microsoft Research
University of Michigan University of Michigan Silicon Valley
2260 Hayward Street 2260 Hayward Street 1288 Pear Avenue
Ann Arbor, MI, USA Ann Arbor, MI, USA Mountain View, CA, USA
zhiyunq@umich.edu zmao@umich.edu yxie@microsoft.com

ABSTRACT important one. It was proposed to guard against off-path


In this study, we discover a new class of unknown side chan- spoofing attacks attempting to inject packets with forged
nels sequence-number-dependent host packet counters source addresses (for data injection or reset attacks) [7,
that exist in Linux/Android and BSD/Mac OS to enable 8]. ISN randomization prevents easy prediction of sequence
TCP sequence number inference attacks. It allows a piece numbers; thus arbitrarily injected packets are likely to be
of unprivileged on-device malware to collaborate with an discarded at the receiver due to invalid sequence numbers.
off-path attacker to infer the TCP sequence numbers used The patch has largely rendered most sequence-number-
between a client and a server, leading to TCP injection and guessing-based attacks very hard to succeed. However, in
hijacking attacks. We show that the inference takes, in com- recent years, new attacks are reported. In 2007, a study
mon cases, under a second to complete and is quick enough reported in Phrack magazine [1] has revisited the problem
for attackers to inject malicious Javascripts into live Face- and claimed that TCP sequence number can still be inferred
book sessions and to perform malicious actions on behalf of a based on how a host treats in-window and out-of-window in-
victim user. Since supporting unprivileged access to global coming packets. However, the scope of this attack is rather
packet counters is an intentional design choice, we believe limited, primarily targeting long-lived connections with a
our findings provide important lessons and offer insights on rather low success rate (as shown in 3.3). In 2012, re-
future system and network design. searchers have discovered that the sequence number infer-
ence attack can be more generally applicable, impacting even
short-lived HTTP connections [26]. However, this attack
Categories and Subject Descriptors heavily relies on the presence of sequence-number-checking
D.4.6 [Operating Systems]: Security and Protec- firewall middleboxes deployed in the network. Specifically,
tionInformation flow controls; C.2.5 [Computer- the idea is that if a packet has passed the sequence-number-
Communication Networks]: Local and Wide-Area Net- checking firewall, then it implies that the sequence number
worksInternet (e.g., TCP/IP) of the packet is considered within a legitimate window.
Our work generalizes these attacks by eliminating the
strong requirements imposed on them to enable a broader
General Terms class of attacks. Specifically, we make the following key con-
Security, Experimentation tributions:
Building on the threat model presented in the recent
Keywords work [26], we generalize the sequence number inference at-
tack by demonstrating that it can be reliably carried out
TCP hijacking, TCP sequence number, Network packet without the help of the firewall middleboxes. Our work pro-
counters vides further evidence that relying on TCP sequence number
for security is not an option.
1. INTRODUCTION Distinct from the error counters (e.g., packets rejected
Since TCP was not originally designed for security, for due to old timestamps) used in the previous study [26],
years it has been patched to address various security holes, which serves only as an indication of whether a packet is
among which the randomization of TCPs initial sequence allowed to pass through the sequence-number-checking fire-
number (ISN), introduced in RFC1948 [7] in 1996 was an wall, we discover a new class of packet counters sequence-
number-dependent counters in Linux/Android (1 counter)
and BSD/Mac OS (8 counters) that can directly leak se-
quence numbers without requiring the presence of firewall
Permission to make digital or hard copies of all or part of this work for middleboxes, thereby elevating the danger of TCP injection
personal or classroom use is granted without fee provided that copies are and hijacking attacks.
not made or distributed for profit or commercial advantage and that copies We are able to complete the sequence number inference
bear this notice and the full citation on the first page. To copy otherwise, to within 45 round trips, which is much faster than the one
republish, to post on servers or to redistribute to lists, requires prior specific previously proposed [26], due to both the property of newly
permission and/or a fee.
CCS12, October 1618, 2012, Raleigh, North Carolina, USA. discovered sequence-number-dependent counters as well as
Copyright 2012 ACM 978-1-4503-1651-4/12/10 ...$15.00.
a more efficient probing scheme. For instance, we show that tamps) to tell if a spoofed packet has passed the firewall
it takes as little as 50ms to complete the inference, two or- and reached the end-host. In our work, we make a ma-
ders of magnitude faster than previous method. It can even jor improvement by eliminating the requirement of firewall
eliminate the need of conducting additional TCP hijacking middleboxes altogether with the help of a class of sequence-
attacks required before, resulting in a much higher attack number-dependent packet counters that we discover. In
success rate (See 5.1). addition to a more general attack model, we also show sig-
As a proof-of-concept demonstration, we show that our nificant improvements on success rate and attack speed with
attack allows a piece of unprivileged malware on Android much lower network resource requirements.
smartphones to hijack a Facebook connection, replacing the Other TCP-sequence-number-related attacks. (1)
login page, or injecting malicious Javascripts to post new TCP sequence number prediction attack. Different from
status on behalf of the victim user, or performing other ac- TCP sequence number inference attack, the prediction at-
tions. All these attacks (except the TCP hijacking attack) tack relies on the non-randomness of TCP Initial Sequence
work on the latest Linux kernel. TCP hijacking requires ker- Numbers (ISN) [25, 2]. To defend the attack, RFC1948 [7]
nel versions earlier than 3.0.2, which are still the case for the standardizes the ISN randomization behavior such that dif-
majority of the Android phones. Besides Android/Linux, we ferent connections should generate random sequence num-
also demonstrate that the attack is applicable to the latest bers independently. (2) Blind TCP RST attack. Due to the
BSD/Mac OS. We believe our work presents an important fact that a connection will be reset as long as the sequence
message that todays systems still expose too much shared number of the reset (RST) packet falls in the current receive
state with poor isolation. window, in a long-lived connection (e.g., a BGP session), an
The rest of the paper is organized as follows: 2 thor- attacker can brute force all possible target connections and
oughly describes the related work. 3 explains how to infer sequence number ranges [8, 32] to cause denial of service.
TCP sequence number (including both previous study and Smartphone-based attacks. There have been a num-
our discovery). 4 covers how we can leverage the sequence ber of attacks against smartphones, many of which focus on
number inference as a building block to conduct a number of leaking sensitive information [15, 16, 28]. In addition, there
TCP attacks. 5 shows several cases studies demonstrating is a class of privilege escalation attacks on Android [17, 19,
the impact on specific applications. 6 discusses why the 14], but they are limited to gaining permissions that typi-
problem occurred and concludes. cally cannot affect the behavior of other applications. For
instance, one application may gain the permission of reading
2. RELATED WORK the contact list or GPS location through other colluding or
vulnerable apps, but it cannot tamper with the TCP connec-
TCP sequence number inference attack. By far,
tion of other applications given the OSs sandboxing mecha-
there are only a few reported TCP sequence number in-
nisms. Our study demonstrates that injection and hijacking
ference attacks. The first one goes back to 1999 where a
of TCP connections can be achieved without requiring any
TCP stack bug causes the kernel to silently drop the third
special permission other than the permission to access the
packet during three-way handshake if the ACK number is
Internet.
smaller than the expected ACK number, and sends a reset
Side-channel information leakage. A wide range of
otherwise [4]. This allows an attacker to send spoofed ACK
side channels have been investigated before: CPU, power,
packets and infer the correct ACK number. This minor bug
shared memory/files, and even electromagnetic waves, etc.
was quickly fixed. Besides it, there are three other closely
Researchers have found that it is possible to construct vari-
related studies. One of them is described in the Phrack
ous attacks, e.g., to infer keystrokes through many side chan-
magazine [1] that uses the IPID side channel on Windows
nels [30, 33, 29, 13, 18]. It is especially interesting to see how
to infer both the server-side and the client-side TCP se-
smartphones can allow malware to infer sensitive informa-
quence numbers. According to our empirical results, such
tion through on-board sensors (which can also be considered
attack is theoretically possible but very hard to carry out.
as side-channels). For instance, Soundcomber [28] uses the
It can succeed under rather limited conditions due to a large
audio sensor to record credit card numbers entered through
number of packets required as well as the noisy side-channel
keypad. In our work, we also rely on side-channels on the
that is leveraged. Following the same direction, a more re-
host, but the attacks infer information at the network-layer.
cent work [20] improves the reliability of the attack by re-
quiring certain control on the client (e.g., javascript through
browser), yet it still relies on the noisy IPID side channel
available on Windows only. 3. TCP SEQUENCE NUMBER INFER-
A closely related recent work [26] discusses how sequence- ENCE ATTACK
number-checking firewall middleboxes can leak the TCP se-
quence number state stored on the firewall. The idea is The ultimate goal of the attack is to inject malicious TCP
that if a packet has passed the sequence-number-checking payload into apps running on a victim smartphone or client
firewall, it implies that the sequence number of the packet is device. It is achieved by a piece of unprivileged on-device
considered within a legitimate window. Otherwise, it implies malware collaborating with an off-path attacker on the In-
that the packet has an out-of-window sequence number. As ternet. The main implication of this attack is that websites
a result, if an attacker can observe whether a spoofed packet that do not use HTTPS will be vulnerable to various at-
has passed the firewall, he will be able to know if a guessed tacks such as phishing and Javascript injection because the
sequence number is correct. To do so, an attacker can in- HTTP response can be potentially replaced. Even if HTTPS
tentionally craft a spoofed packet with certain errors (e.g., is used, they are still vulnerable to connection reset attacks
old timestamp) and then leverage the error packet coun- as we show that the sequence number can be quickly inferred
ters on the host (e.g., packets rejected due to old times- in under a second.
how the TCP stack treats a spoofed probing packet with
2 Feedback a guessed sequence number. Different from the recent
work [26] that uses certain error counters as an indica-
Probing tion of whether a spoofed packet has passed the sequence-
1 Packets number-checking firewall middlebox, our hypothesis is that
the TCP stack may increment certain counters when the
(Y, Y + WIN) ? ? guessed sequence number is wrong and remain the same
when it is correct, or vice versa. Such counters can directly
leak sequence numbers without the help of the firewall mid-
Figure 1: Threat model dlebox and are thus named sequence-number-dependent
counters (details in 3.4 and 3.5). To investigate such a
3.1 Threat Model possibility, we first need to understand how TCP stack han-
The threat model is illustrated in Figure 1. There are dles an incoming TCP packet and how various counters are
four main entities: (1) The victim smartphone and a target incremented during the process.
application, constituting the attack target. (2) The legiti- 3.3 TCP Incoming Packet Validation
mate server, which talks to the victim smartphone using an
unencrypted application-layer protocol (e.g., HTTP). The In this section, we provide background on how a standard
server can also become the attack target (see 5). (3) The TCP stack validates an incoming packet that belongs to an
on-device malware, which is unprivileged and cannot tam- established TCP connection. Specifically, we use the source
per with other apps directly. (4) The off-path attacker, who code of the latest Linux kernel 3.2.6 (at the time of writing)
is capable of spoofing the IP address of the legitimate server as reference to extract the steps taken and checks performed
and the victim smartphone. The off-path attacker and the on an incoming packet (the packet validation logic is sta-
malware collaborate to infer the correct TCP sequence num- ble since 2.6.28). Based on the source code, we summarize
ber of the connection established between the target app and sequence-number-dependent side-channels on Linux and
the legitimate server. Note that different from the threat extend it to BSD/Mac OS.
model described in the recent study [26], this attack does
not require the network firewall middlebox, making our at- Error check Error
Fail
tack model much more general. counter++
At a high level, as shown in Figure 1, the off-path at- Pass
tacker needs two pieces of information: (1) the four tuples Sequence number
of a target connection, i.e., source/destination IP addresses check Out-of-window tcp_send_dupack()

and source/destination port numbers and (2) the correct se- In-window
quence number. The on-device malware can easily identify Ack number
the current active connections (e.g., through netstat), but Invalid Drop
check
it does not know the sequence number in use. In this at- Valid
tack model, the off-path attacker can send probe packets
using the target four tuples with different guessed sequence 0-payload check 0-payload Ignore
numbers. The unprivileged malware then uses certain side-
Payload >= 1
channels to provide feedback on whether the guessed se-
quence numbers are correct. Guided by the feedback, the Retransmission Immediate
check Retransmission
off-path attacker can then adjust the sequence numbers to ACK
Not retransmission
narrow down the correct sequence number.
Accept
3.2 Packet Counter Side Channels
In this study, we look at a particular type of side chan- Figure 2: Incoming packet validation logic
nel, packet counters, that can potentially provide indirect
feedback on whether a guessed sequence number is correct. As we can see in Figure 2, there exist five main checks
In Linux, the procfs [24] exposes aggregated statistics on performed by Linux TCP stack based on the corresponding
the number of incoming/outgoing TCP packets, with certain source code as well as our controlled experiments. These
properties (e.g., wrong checksums). Alternatively, netstat checks are performed for any incoming TCP packet that is
-s exposes a similar set of information on all major OSes deemed to belong to an established connection based on the
including Microsoft Windows, Linux, BSD, Mac OS and four tuples:
smartphone OSes like Android and iOS. Since such coun- (1). Error check is for the purpose of dropping invalid
ters are aggregated over the entire system, they are gener- packets early on. There are a number of specific error checks:
ally considered safe and thus accessible to any user or pro- 1) MD5 option check, 2) timestamp option check, 3) packet
gram without requiring special permissions. The IPID side- length and checksum check. Each has a corresponding error
channel [27] can be considered as a special form of packet packet counter. If a specific error is caught, the correspond-
counter that records the total number of outgoing packets ing host packet counter is incremented and the packet is not
since it is incremented for every outgoing packet. However, inspected further. Otherwise, it goes to the next step.
such side-channel is nowadays only available on Microsoft (2). Sequence number check is the most relevant check.
Windows and is typically very noisy. It basically checks if a packet is in window by making sure
Even though it is generally perceived safe, we show that that the ending sequence number of the incoming packet is
an attacker can correlate the packet counter update with larger than or equal to X, and the starting sequence number
is smaller than or equal to X+rcv win, where X is the next which means that the corresponding error counters used by
expected sequence number and rcv win is the current re- the recent study [26] alone cannot provide any feedback on
ceive window size. If the sequence number is out of window, a guessed TCP sequence number.
it triggers an immediate duplicate acknowledgment packet
to be sent back, indicating the correct sequence number that 3.4 Sequence-Number-Dependent Counter in
it is expecting. Otherwise, the next check is conducted. Linux
(3). Acknowledge number check is an additional validity The reason why the Phrack attack [1] is difficult to carry
check on the packet. A valid ACK number should theoreti- out is two-fold: (1) The required number of packets is too
cally be within [Y, Y+outstanding bytes] to be considered large; an attacker needs to send at least one packet per re-
valid. Here Y is the first unacknowledged sequence num- ceive window in order to figure out the right sequence num-
ber and outstanding bytes is total number of outstanding ber range. (2) The counter that records the total number of
bytes not yet acknowledged. Linux has a relaxed implemen- outgoing packets is too noisy. Subsequently, we show that
tation which allows half of the ACK number space to be both problems can be addressed by using a newly discov-
considered valid (we discuss its impact later). If the ACK ered set of sequence-number-dependent packet counters that
number is considered invalid, then it is dropped without increment when the sequence number of an incoming packet
further processing. Else, the packet goes through the later matches certain conditions.
non-validity-related checks.
(4). At this point the packet has the correct sequence if (TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(skb)->seq
number and the ACK number. The stack needs to check if it
&& before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
has any payload. If it does not have any payload, the packet
is silently ignored unless there happens to be pending data NET_INC_STATS_BH(sock_net(sk),
that can be piggybacked. In particular, the host cannot send LINUX_MIB_DELAYEDACKLOST);

another 0-payload acknowledgment packet for the 0-payload }
incoming ACK packet, which will create endless TCP ACK
storm [23]. Figure 3: tcp send dupack() source code snippet in Linux
(5). If the packet has non-zero payload, the final check is
Server-side sequence number inference. We closely
to detect retransmission by checking if the ending sequence
study the function tcp send dupack() which is called af-
number of the packet is smaller than or equal to the next
ter the sequence number check (depicted in Figure 2).
expected sequence number. If so, it does not process the
Within the function, we discover an interesting piece of
packet further and immediately sends an ACK packet to in-
code shown in Figure 3. The if condition says if the
form the other end of the expected sequence number. Since
packets starting sequence number is not equal to its end-
step 2 has already ensured that the ending sequence number
ing sequence number (i.e., the packet has nonzero pay-
cannot be smaller than the next expected sequence number,
load), and its starting sequence number is before the ex-
the only possible ending sequence number that can satisfy
pected sequence number, then a packet counter named De-
the retransmission check is the one equal to the next ex-
layedACKLost is incremented (which is publicly accessible
pected sequence number.
from /proc/net/netstat). This particular logic is to detect
From the above description on how a TCP packet is han-
lost delayed ACK packets sent previously and switch from
dled, it is not hard to tell that depending on whether the
the delayed ACK mode into the quick ACK mode [12]. The
sequence number is in or out of window, the TCP stack may
presence of an old/retransmitted TCP packet is an indica-
behave differently, which can be observed by the on-device
tion that the delayed ACKs were lost.
malware. Specifically, if it is an out-of-window packet with
The question is how before() is implemented. In Linux
0-payload, it most likely will not trigger any outgoing packet.
(and Mac OS), it basically subtracts an unsigned 32-bit in-
However, if it is an in-window packet, it immediately trig-
teger from another unsigned 32-bit integer and converts the
gers an outgoing duplicate ACK packet. As a result, it is
result into a signed 32-bit integer. This means that half of
possible to use the counter that records the total number of
the sequence number space (i.e., 2G) is considered before
outgoing packets to tell if a guessed sequence number is in
the expected sequence number. For instance, two unsigned
window.
integers 1G minus 2G would lead to an unsigned integer 3G.
A similar observation has been made by the previous
When converting to an signed value, we obtain -1G.
study in the Phrack magazine [1]. The problem with their
The net effect of the tcp send dupack() is that it allows an
approach to infer sequence number is that such general
attacker to easily determine if a guessed sequence number
packet counters can be very noisy there may be back-
is before or after the expected sequence number. Since the
ground traffic which can increment the system-wide outgo-
DelayedACKLost counter very rarely increments naturally
ing packet counters. It is especially problematic when the
(See 3.8), an attacker can use this counter as a clean and
receive window size is small a large number of packets
reliable side-channel.
need to be sent and the probing is very likely to have limited
Binary search. Using this special counter, it is straight-
success. In fact, we have implemented such sequence num-
forward to conduct a binary search on the expected sequence
ber inference attack on a smartphone at home connected
number. Note that the process is significantly different than
to the broadband ISP through WiFi with 10Mbps down-
the one proposed in the earlier work [26] in that the earlier
link bandwidth. Through 20 repeated experiments, we find
work still requires sending one packet per window, which
that the inference always failed because of the noise of the
results in a total of thousands or tens of thousands of pack-
background traffic
ets. Here, as illustrated in Figure 4, the attacker only needs
It is also worth noting that the error checks are performed
to send one packet each round and only a total of 32 packets,
at the very beginning, preceding the sequence number check,
resulting in hardly any bandwidth requirement.
Specifically, as shown in the figure, in the first iteration, smaller than 2G, it is no longer circular (unlike the first
the attacker can try the middle of the sequence number space iteration where the counter increment in the first bin can be
(i.e., 2G). If the expected sequence number falls in the first impacted by the fourth bin). Now, if the sequence number
half (i.e., bin 1), the DelayedACKLost counter increments falls in the first bin, then the counter remains the same; if
by 1. Otherwise, (i.e., if it falls in bin 2), the counter remains it falls in the second bin, the counter will increment 1; and
the same. Suppose the attacker finds that the expected se- so on. We discuss the realistic settings and performance of
quence number is in the first half after the first iteration, in different N in 3.7.
the second iteration, he can try 1G to further narrow down
the sequence number. After log2 4G = 32 rounds (also 32 # of packets: 1 3 2
packets), the exact sequence number can be pinpointed. The
total inference time can be roughly calculated as 32 RT T . 0 1G 2G 3G 4G
In reality, the number of RTTs can be further reduced by Bin 1 Bin 2 Bin 3 Bin 4
Counter += 2 Counter += 1 Counter += 4 Counter += 5
stopping the inference at an earlier iteration. For instance, if
(a). First iteration
it is stopped at the 31st iterations, the attacker would know
that the sequence number is either X or X+1. Similarly,
# of packets: 1 1 1
if the number of iterations is 22, the attacker knows that
the sequence number is within [X, X+1024). In many cases, 0 250M 500M 750M 1G
this is sufficient because the attacker can still inject a single Bin 1 Bin 2 Bin 3 Bin 4
Counter += 0 Counter += 1 Counter += 2 Counter += 3
packet with payload of 1460 bytes and pad the first 1024
(b). A later iteration
bytes with whitespace (which effectively leaves 436 bytes of
effective payload). For instance, if the application-layer pro- Figure 5: Sequence number inference illustration using the
tocol is HTTP, the whitespace is safely ignored even if they DelayedACKLost packet counter (four-way search)
happen to be accepted as part of the HTTP response.
Client-side sequence number inference. Sometimes,
it is necessary to infer the client-side sequence number, for
# of packets: 1
the purpose of either injecting data to the victim server,
or injecting data to the victim client with an appropri-
0 2G 4G
Bin 1 Bin 2 ate ACK number. The latter is currently unnecessary as
Counter++ Counter += 0
Linux/Android and BSD/Mac OS allows half of the ACK
(a). First iteration number space to be valid [26]. For the former, we can still
# of packets: 1 use the same DelayedACKLost counter to infer the ACK
number.
0 1G 2G Specifically, as discussed in 3.3, the only ending sequence
Bin 1 Bin 2
Counter++ Counter += 0 number that can satisfy the retransmission check is the one
(b). Second iteration equal to the next expected sequence number. When that
Figure 4: Sequence number inference illustration using the happens, the TCP stack increments the DelayedACKLost
DelayedACKLost packet counter (binary search) packet counter again. The source code of the retransmission
check is shown in Figure 6.
N-way search. To further improve the inference speed, Since the retransmission check is after the ACK num-
we devise a variation of the N-way search proposed in the ber check, it allows an attacker to send a non-zero payload
recent work [26]. The idea is similar instead of eliminating packet that has the ending sequence number equal to the
half of the sequence number space each iteration, we can next expected sequence number with a guessed ACK num-
eliminate NN1 of the search space by simultaneously probing ber. If it does not pass the ACK number check, the packet
N-1 of N equally-partitioned bins. The difference is that is dropped and the DelayedACKLost counter does not incre-
the inference requires one or two orders of magnitude fewer ment. Otherwise, the packet is considered a retransmitted
packets compared to the previously proposed search. packet and triggers the counter to increment. Based on such
Figure 5 illustrates the process of a 4-way search. In the behavior, we can perform a binary search or N-way search
first iteration, the search space is equally partitioned into on the ACK number similar to the sequence number search.
4 bins. The attacker sends one packet with sequence num- In fact, the procedure is mostly identical.
ber 1G, three packets with sequence number 2G, and two
packets with sequence number 3G. If the expected sequence
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
number falls in the first bin, the DelayedACKLost counter
increments by 2, as the two packets sent with sequence num-
NET_INC_STATS_BH(sock_net(sk),
ber 3G are considered before the expected sequence number. LINUX_MIB_DELAYEDACKLOST);
Similarly, the counter increments by a different number for
different bins. In general, as long as the number of packets }
sent for each bin follow the distance between two consecu- Figure 6: Retransmission check source code snippet from
tive marks on a circular/modular Golomb ruler [3], the De- tcp data queue() in Linux
layedACKLost counter increment will be unique when the
expected sequence number falls in different bins.
In the later iterations, however, a much simpler strategy 3.5 Sequence-Number-Dependent Counters
can be used. In Figure 5(b), an attacker can just send one in BSD/Mac OS
packet per bin instead of following the circular Golomb ruler. Inspired by the newly discovered counter in Linux, we
The reason is that now that the search space is reduced to further conduct a survey on the latest FreeBSD source code
(version 10). Surprisingly, we find that at least four pairs s. These packet counters do not leak sequence numbers
of packet counters can leak TCP sequence number. The directly.
counters are confirmed to exist in Mac OS as well. This find-
ing shows that the sequence-number-dependent counters are 3.7 Inference Performance and Overhead
widely available and apparently considered safe to include in We have implemented the sequence number inference on
the OS. They are: 1) rcvduppack and rcvdupbyte; 2) rcvpack- both Android (which incorporates the Linux kernel) and
afterwin and rcvbyteafterwin; 3) rcvoopack and rcvoobyte; 4) Mac OS. We are interested in the tradeoffs between different
rcvdupack and rcvacktoomuch. They can be either accessed strategies in picking N in the N-way search.
through the standard netstat -s interface or sysctl API [11]. Generally, as N goes up, the total number of bytes sent
The first three pairs can be used to infer server-side se- should also increase. Since the first iteration in the N-way
quence numbers. Specifically, based on the source code, the search requires sending more bytes, we pick a smaller N
semantic of rcvduppack is identical to that of DelayedACK- for the first iteration and a bigger N in the later iterations
Lost. rcvdupbyte, however, additionally provides informa- to ensure that the number of bytes sent in each round is
tion on the number of bytes (payload) carried in the incom- similar. In the Linux implementation, we pick the following
ing packets that are considered duplicate (with an old se- pairs of N, (2/2, 4/6, 8/30, 12/84); For Mac OS, we pick
quence number). This counter greatly benefits the sequence (2/2, 4/6, 34/50, 82/228). Here 4/6 means that we pick
number inference. Following the same N-way procedure, N=4 for the first iteration and N=6 for the later iterations.
the first iteration can be improved by changing the k pack- As shown in Figure 7, we can see that the general tradeoff
ets sent per bin to a single packet with k bytes payload. is that the fewer iterations an attacker wants, the more bytes
This improvement substantially reduces the number of pack- he needs to send in total. For instance, when the number of
ets/bytes sent in each iteration, especially when N is large iterations is 4, an attacker on Linux needs to send 13.7KB.
(shown in 3.7). With the presence of the rcvdupbyte counter in Mac OS, it
The semantic of rcvpackafterwin and rcvbyteafterwin is requires to send only 8.4KB. This is a rather low network
similar to rcvduppack and rcvdupbyte, except that the for- resource requirement because it takes only 70ms to push
mer increments only when the sequence number is bigger 8.4KB onto the wire with even just 1Mbps bandwidth. Go-
than (instead of smaller than) certain sequence number X. ing further down to 3 iterations requires sending 27.75KB
In this case, X is the expected sequence number plus the for Mac OS. Depending on the available bandwidth and the
receive window size. rcvbyteafterwin can be used similarly RTT, we may or may not want to increase the number of
as rcvdupbyte to conduct the sequence number inference. bytes to save one round trip.
rcvoopack and rcvoobyte differ from the previous two pairs. Next, we pick N=34/50 (4 round trips) for Mac OS at-
They increment only when packets arrive out of order, or tacks, and N=8/30 (5 round trips) for Linux attacks (with
more precisely, when the sequence number is bigger than roughly the same resource requirement), and plot the infer-
the expected sequence number yet smaller than the expected ence time measured under various conditions. We control
sequence number plus the receive window size. Even though the RTT between the attacker and the victim in three dif-
an attacker needs to send a lot more packets to infer the ferent settings: 1) The victim is in an office environment
TCP sequence number using this counter pair, at least they (enterprise-like) connected to the network using WiFi, and
can be used to replace the original noisy side-channel in the the attacker is in the same building (the RTT is around
Phrack attack [1] to improve success rate. 5-10ms). 2) The victim is in a home environment and the
rcvdupack and rcvacktoomuch are used to determine the attacker is 50ms RTT away. 3) The victim is in a home envi-
client-side sequence numbers. Specifically, the former in- ronment and the attacker is 100ms RTT away. In Figure 8,
crements when the ACK number of an incoming packet we see that in the first setting the inference time for Android
is smaller than or equal to the unacknowledged number and Mac OS are 80ms and 50ms, which are low enough to
(SND.UNA). The latter increments when the ACK num- directly launch injection attacks on HTTP connections with
ber is greater than the sequence number of the next origi- the guarantee that the inference finishes before the first le-
nal transmit (SND.MAX). The comparison again follows the gitimate response packet comes back (also discussed later
unsigned integer to signed integer conversion such that half in 4.2). In fact, inference time between 350ms and 700ms
of the ACK number space is considered to match the condi- can be short enough in certain scenarios (see 5.1).
tion.
We currently did not combine the counters together to im- 3.8 Noisiness of Sequence-Number-
prove the inference speed. However, we do realize there are Dependent Counters
potential ways to speed things up. For instance, the rcvdup-
So far, we have claimed that these sequence-number-
byte and rcvdupack allows the client-side sequence number
dependent counters are clean side-channels that rarely in-
inference to be piggybacked with the server-side sequence
crement naturally even with background traffic. To quanti-
number inference.
tatively support this claim, we conduct a worse-case-scenario
experiment as follows: We open a YouTube video at the
3.6 Sequence-Number-Dependent Counters background and browse web pages at the same time to see
in Microsoft Windows how often the counters get incremented. Since it is easier
Interestingly, Microsoft Windows OSes do not appear to to do the multi-tasking on Mac OS, we choose it over the
expose such sequence-number-dependent counters and are Android platform. The Android counters should increment
thus not vulnerable to the attack. On Windows 7, for ex- even less frequently since smartphones are rarely used for
ample, the TCP-related packet counters include the total video streaming and web browsing simultaneously.
number of incoming packets, outgoing packets, and the num- We pick the rcvdupbyte counter (which is equivalent to De-
ber of packets retransmitted from the output of netstat - layedACKLost on Linux) and run the experiments for about
8.5 minutes. The video is long enough that it has not been commonly satisfied, since many NAT mapping types allow
fully buffered by the end of the experiment. To quantify the external port to be predictable to facilitate NAT traver-
the counter noisiness, we break down the time into 30ms in- sal. For instance, our home routers directly map the internal
tervals to mimic the window of exposure during one round ports to the external ports. According to recent measure-
of probing, and then count how many intervals in which ment studies on the NAT mapping types [21, 31], the major-
we observe any counter increment. As expected, there are ity of the NATs studied do have predictable external ports.
only 10 intervals out of 16896 that have the increment. This Further, even if the prediction is not 100% accurate, attacks
indicates that the probability that the counter increments may still succeed by guessing the mappings.
due to noise and interference with one round of probing is Additional requirements for passive TCP hijacking are C1
roughly 0.059%. Even if there are 22 rounds (worse case), and S1:
the probability that the entire probing will be affected by (C1). Client-side ISN has only the lower 24-bit random-
the counter noisiness is only 1.2%. ized. This requirement is necessary so that the malware
can roughly predict the range of the ISN of a newly created
TCP connection. In Linux kernels earlier than 3.0.2, the
4. DESIGN AND IMPLEMENTATION OF ISN generation algorithm is designed such that ISNs for dif-
TCP ATTACKS ferent connections are not completely independent. Instead,
In the previous section, we described how to infer TCP the high 8 bits for all ISNs is a global number that incre-
sequence number efficiently and reliably using the newly dis- ments slowly (every five minutes). This feature is designed
covered set of sequence-number-dependent packet counters. to balance security, reliability, and performance. It is long
Since the sequence number inference only takes less than a perceived as a good optimization, with the historical details
second, it can be fast enough to launch many application- and explanations in this article [5]. The result of this design
layer attacks. In this section, we discuss four possible TCP is that the ISN of two back-to-back connections will be at
attacks that can be launched against a variety of applica- most 224 = 16, 777, 216 apart. Even though it is a design
tions. All of the attacks leverage the TCP sequence number decision and not considered a vulnerability, since Linux
inference as the essential building block, but the main dif- 3.0.2, the kernel has changed the ISN generation algorithm
ference is in the timing and reliability with slightly different such that two consecutive connections will have independent
requirements. We have implemented the attacks on both ISNs. The majority of Android systems that are on the mar-
Android and Mac OS. We use Android as the example for ket are still on Linux 2.6.XX, which means that they are all
description vulnerable to the passive TCP hijacking attack.
Injection vs. Hijacking. Using the same terminology as a (S1). The legitimate server has a host-based stateful TCP
recent work [26], we define TCP hijacking to be the more firewall. Such a firewall is capable of dropping out-of-state
powerful attack than TCP injection. Specifically, TCP hi- TCP packets. Many websites such as Facebook and Twitter
jacking allows an attacker to inject packets right after the deploy such host firewalls to reduce malicious traffic. For
TCP 3-way handshake. For instance, it enables an attacker instance, iptables can be easily configured to achieve this
to inject a complete HTTP response without any interfer- purpose [10]. Interestingly, as we will discuss later, this se-
ence. In contrast, TCP Injection is more general and does curity feature on the server actually enables TCP hijacking
not require this capability. attacks.
The four attacks are named as: (1). client-side TCP Injec- In order to perform active TCP hijacking attacks, the ad-
tion, (2). passive TCP hijacking, (3). active TCP hijacking, ditional requirements include S1 and C2:
(4). server-side TCP injection. (C2). Client-side ISN monotonically incrementing for the
same four tuples. This client-side requirement is in fact ex-
4.1 Attack Requirements plicitly defined in RFC 793 [9] to prevent packets of old con-
nections, with in-range sequence numbers, from being ac-
There are a number of base requirements that need to
cepted by the current connection mistakenly. Even though
be satisfied for all of these TCP attacks. Note that our
the latest Linux kernel has eliminated the requirement C1,
attacks have much fewer requirements than the one proposed
C2 is still preserved.
in the recent study [26]. Specifically, we do not require a
firewall middlebox in the network, which makes our attacks
applicable in a much more general environment. 4.2 Client-Side TCP Injection
The set of requirements include: (1) malware on the client In this attack, an attacker attempts to inject malicious
with Internet access, (2) malware that can run in the back- data into a connection established by other apps on the
ground and read packet counters, (3) malware that can phone. The essential part of the attack is the TCP sequence
read the list of active TCP connections and their four tu- number inference which has already been described in de-
ples, and (4) a predictable external port number if NAT tail. The challenge is that the injected data may compete
is deployed. The first three requirements are straightfor- with the data sent from the legitimate server. For instance,
ward. All of the Android applications can easily request In- considering the connection under attack is an HTTP session
ternet access, read packet counters (i.e.,/proc/net/netstat where a valid HTTP response typically follows immediately
and /proc/net/snmp, or netstat -s), and read active TCP after the request is sent, by the time the sequence number
connections four tuples (e.g., through /proc/net/tcp and inference is done, at least part of the HTTP response is al-
/proc/net/tcp6, or netstat). The requirements can be eas- ready sent by the server. The injected HTTP packets likely
ily satisfied on most modern OSes as well. In addition, an can only corrupt the response and cause denial of service
off-path attacker needs the clients external port mapping to instead of serious damage.
choose the correct four tuples when sending probing packets, Even though the timing requirement sounds difficult to
so we need the fourth requirement. This requirement is also satisfy, we did implement this attack against websites such
total # of bytes required (KB)
30
Android
25 Mac Phone Phone
20
Victim Unprivileged Off-path Legit Victim Unprivileged Off-path Legit
15
App malware attacker Server App malware attacker Server
10
1. SYN 1. Conn(X)
5
2. Notification of new conn 2. Notification of conn(X)
0
2 4 6 8 10 12 14 16 18 20 22 3. Seq + ACK inference -- start
3. SYN-ACK (seq = Y)

...
# of round trips (iterations)
Figure 7: Tradeoff between inference 4. Spoofed 4. Seq + ACK inference -- end
speed and overhead RSTs 5. Port jamming
5. ACK/request 6. Conn(X)

Connection reset
700
600 6. Seq number inference -- start 7. Notification of conn(X)
Inference time (ms)

Connection reset
500 8. Spoofed
9. Seq number inference -- start RSTs

...
400

...
300
200 7. Seq number inference -- end 10. Seq number inference -- end
100 Android
0
Mac 8. Malicious response 11. Malicious response
0 10 20 30 40 50 60 70 80 90 100
RTT between attacker and client (ms)

Figure 8: Relationship between RTT Figure 9: Passive TCP hijacking se- Figure 10: Active TCP hijacking se-
and inference time quence quence
as Facebook where we are able to inject malicious Javascripts TCP connection. In addition, the malware also needs to es-
to post new status on behalf of a victim user. The detail is tablish a connection to the off-path attacker to report the
described in 5.1. current ISN value (high 8 bits). With this information, at
The idea is to leverage two common scenarios: (1) The time 4, the off-path attacker can flood the legitimate server
server may take a long time to process a request and as- with a number of spoofed RSTs enumerating the lower 24
semble the response. This is especially common as many bits (sequence numbers can increment by a step size as large
services (websites) take longer than 100ms or more to pro- as the servers receive window size). Note that the RST
cess a request. The fact that the sequence number inference packets have to arrive before the ACK/request packets at
time in certain scenarios (when RTT from the server to the time 5; otherwise, the server may send back the response
client is small) can be made below 100ms makes the injection packets before the attacker. Of course, the server may need
attack as powerful as hijacking. (2) A single TCP connec- some time to process the request as well, which can vary
tion is reused for more than one pair of HTTP request and from case to case, allowing the attacker additional time to
response. The idea is to use the inferred sequence number complete the reset procedure. After the legitimate servers
for injecting malicious data not on the first HTTP request connection is reset, all future packets from the victim app
but the later ones. In both cases, an attacker has enough will be considered out-of-state and silently dropped due to
time to conduct sequence number inference. requirement S1. For instance, the ACK packet received at
time 5 is silently discarded. From time 6 to 7, the attacker
4.3 Passive TCP Hijacking conducts the sequence number inference described earlier
Passive TCP hijacking allows an attacker to hijack TCP and injects malicious content afterwards at time 8 with the
connections that are passively detected. This means that the inferred sequence number. A more detailed analysis on the
attacker can hijack TCP connections issued by the browser bandwidth and time requirement is discussed in a similar
or any other app, regardless of how and when they are made. setting in a prior work [26].
It is the most powerful TCP attack in this study. As demon-
strated in 5, with this attack, it is possible to replace the 4.4 Server-side TCP Injection
Facebook login page with a phishing one. In this attack, an attacker tries to inject malicious payload
The high-level idea is the same as proposed in the recent into a victim connection, destined for the server (as opposed
work [26], which is to reset the connection on the legitimate to the client). For instance, as shown in the case study in 5,
server as soon as possible to allow the attacker to claim to we are able to target at Windows live messenger protocols
be the legitimate server talking to the victim. The key is to inject malicious commands to cause persistent changes to
that such reset has to be triggered right after the legitimate the victim user account, e.g., adding new friends or removing
server sends SYN-ACK. Requirement C1 allows the mal- existing friends.
ware and the attacker to predict the rough range of victims This attack is straightforward by combining the sequence
ISN and send reset packets with sequence numbers in that number inference and ACK number inference as described
range. This is helpful because the attacker is required to in 3. We omit the detailed attack sequence as it does not
send fewer spoofed RST packets (thus with lower bandwidth include other important steps. This attack has no additional
requirement) compared to enumerating the entire 4G space. requirements besides the base requirements. In general, ap-
Further, after the legitimate server is reset, requirement S1 plications with unencrypted and stateful protocols are good
is necessary since it helps prevent the legitimate server from attack targets.
generating RST upon receiving out-of-state data or ACK
packets from the victim. 4.5 Active TCP Hijacking
The attack sequence diagram is shown in Figure 9. Time In this attack, an attacker attempts to hijack connections.
steps 1 to 3 are the same as the previous attack where the un- However, because the latest Linux kernel since 3.0.2 has the
privileged malware detects and reports the newly established entire 32-bit randomized for ISNs of different four tuples,
requirement C1 is no longer satisfied. In this case, we show limit). The local port numbers are not immediately released
that it is still possible to launch a weaker version of TCP since the closed connections enter the TCP TIME WAIT
hijacking by actively performing offline analysis as long as state for a duration of 1 to 2 minutes.
requirement C2 is satisfied. As shown in 5, we have success-
fully used the port-jamming-assisted active TCP hijacking
to replace a Facebook login page with a phishing one. 5. ATTACK IMPACT ANALYSIS FROM
Requirement C2 specifies that the ISN for the same four- CASE STUDIES
tuple always increments with time. This implies that as long Experiment setup. As discussed earlier, even though our
as an attacker can infer the clients ISN for a particular four- attacks are implemented on both Android and Mac OS, we
tuple once, he can store the value for a future connection choose to focus on Android in our implementation and ex-
that reuses the same four-tuple, and reset the server using periments. We use two different phones: Motorola Atrix and
the stored ISN (plus the increment by time) so that the Samsung Captivate. We verified that all attacks work on
attacker can hijack the connection. both Android phones, although the experimental results are
The detailed attack sequence is demonstrated in Fig- repeated based on Atrix. The WiFi networks include a home
ure 10, at time 1, the unprivileged malware establishes a network and a university network. The off-path attacker is
connection on its own to a target server of interest (e.g., hosted on one or more Planetlab nodes in California.
Facebook server), and notifies the off-path attacker imme- We describe four case studies corresponding to the four
diately (at time 2) so that it can infer the client ISN of the TCP attacks proposed in the previous section. We also
used four tuples (through time 3 to 4). Now, assuming that present experimental results such as how likely we can suc-
the attacker knows that a victim app is about to initiate a ceed in hijacking the Facebook login page based on repeated
connection to the same server, an attacker can immediately experiments.
perform port jamming to exhaust all the local port numbers For all attacks, we implemented the malware as a benign
(at time 5) so that the victim apps connection can only use app that has the functionality of downloading wallpapers
the local port number that was in the inferred four tuples from the Internet (thus justifying the Internet permission).
(we will describe how port jamming can be done later). Now Since the malware needs to scan netstat (or /proc/net/tcp
that the victim connection reuses the same four tuples, the and /proc/net/tcp6 equivalently) for new connection detec-
malware can immediately notify the off-path attacker (at tion, which can drain the phones battery very quickly, we
time 6) which uses the previously inferred client-side ISN make the malware stealthy such that it only scans for new
to reset the server (at time 7). Subsequently, the attack connections when it detects that the victim app of interest
sequence is identical to the end of passive TCP hijacking. is at the foreground. This can be achieved by querying each
In the above attack sequence, one critical part is the apps IMPORTANCE FOREGROUND flag which is typi-
knowledge of when the victim app initiates the connection to cally set by the Android OS whenever it is brought to the
the target website. One simple strategy is to actively trigger foreground. Further, the malware queries the packet counter
the victim app to make the connection through the unpriv- only when the off-path attacker instructs it to do so. The
ileged malware. On Android, for instance, any app could malware is only used in our controlled experiment environ-
directly invoke the browser going to a given URL, before ments without affecting real users.
which the attacker can perform the port jamming. Note that most apps except the browser on the smart-
One alternative strategy is to perform offline analysis on phones do not have an indication about whether the con-
as many four tuples as possible so that it can essentially ob- nection is using SSL, which means that the users may be
tain the knowledge of ISN for all possible four tuples going completely unaware of the potential security breach for un-
to a particular website (without requiring port jamming). encrypted connections (e.g., HTTP connections used in the
This way, after the offline analysis is performed, the attacker Facebook app).
basically can launch passive TCP hijacking on any of the
four tuples that have been previously analyzed. Since each 5.1 Facebook Javascript Injection
client-side ISN inference should take a little over a second,
We launch the attack based on client-side TCP injec-
an attacker can infer, for instance, 1000 four tuples in 15
tion as described in 4.2. Recall that the injection can hap-
minutes. Even though a connection to Facebook may have
pen only after the sequence number inference finishes. If the
1% probability falling in the range, the user may repeatedly
inference cannot be done earlier than the response comes
visit the website and the probability that all of the connec-
back, the attacker will miss the window of opportunity.
tions failing to match any existing four tuples is likely very
By examining the packet trace generated by visiting the
low. We have verified that the ISN for the same four-tuple
Facebook website where a user is already logged in, we iden-
does increment consistently over time for over an hour. We
tify two possible ways to launch the Javascript injection at-
suspect that the cryptographic key for computing ISN does
tack. The first attack is surprisingly straightforward. Ba-
not change until reboot in Linux 3.0.2 and above.
sically, when the user visits m.facebook.com, the browser
To jam local ports, the unprivileged malware can simply
issues an HTTP request that fetches all recent news. We ob-
start a local server, then open many connections to the local
serve that it consistently takes the server more than 1.5 sec-
server intentionally occupying most of the local port except
onds to process the request before sending back the first re-
the ones that are previously seen for inference. One chal-
sponse packet. According to our results in 3.7, the inference
lenge is that the OS may limit the total number of ports that
time usually finishes within 0.7s even when RTT=100ms. It
an application can occupy, thus preventing the attacker from
allows enough time for an attacker to inject the malicious
opening too many concurrent connections. Interestingly, we
response in time (or inject a phishing login page as well).
find such limit can be bypassed if the established connections
As shown in Table 1, the success rate is 87.5% based on
are immediately closed (which no longer counts towards the
40 repeated experiments in our home environment where
RT Ta =70ms1 RT Ta =100ms
Succ Rate 97.5% (39/40) 87.5% (35/40)
1
RT Ta is the RTT between the attacker and the client
Table 1: Success rate of Facebook Javascript injection (case study 1)

RTT=100ms. It goes up to 97.5% when the experiment is to reset the server. In addition, the result also verifies that
conducted in the university network where RTT=70ms. The the larger the RTT, the more likely the attack can succeed.
failed cases are mostly due to packet loss. Note that the 100ms RTT to Facebook may sound very
The second attack is based on the observation that mul- large given the popularity of CDN services. However, the
tiple requests are issued over the same TCP connection to CDNs are mostly used for hosting static contents such as
the Facebook site. Even if the attacker is not able to in- images and Javascripts. For webpages that are highly cus-
fer the sequence number in time to inject response for the tomized and dynamic (e.g., personalized Facebook news
first request (e.g., Facebook may improve the server pro- feed), they are very likely to be stored on the main server in
cessing time in the future), he can still perform inference a single location (e.g., Facebook main servers are hosted in
for the second request. Specifically, if the user visits the California). We find that this is a common design for many
root page on Facebook, the browser on one of the Android sites with dynamic contents (e.g., twitter).
phones (Samsung Captivate) will send two HTTP requests:
the first request is asking for the recent news; the second 5.3 Command Injection on Windows Live
request seems to be related to prefetching (e.g., retrieving Messenger
the friend list information in case a user clicks on any friend Leveraging server-side TCP injection described
for detailed information). in 4.4, the case study of command injection attack on Win-
Since there is a delay of about 1s between the end of the dows Live Messenger is an interesting example of server-side
first request and the start of the second request, an attacker attack carried out on a connection where the user is already
can monitor if the sequence number remains the same for a logged in. The main connection of Windows Live Messenger
certain period of time to detect the end of the first response. runs on port 1863 and uses Microsoft Notification Protocol
Furthermore, the second request takes about 100ms to pro- (MSNP) which is a complex instant messenger protocol de-
cess on the server. A simple strategy that an attacker can veloped by Microsoft [6]. Many Windows Live Messenger
employ is to just wait for around 1.1s before injecting the clients on Android as well as the ones on the desktops (in-
malicious response for the second request. A more sophis- cluding official ones) use plaintext in their connections, thus
ticated attacker could also monitor the start of the second allowing the attack. Once upon the detection of a vulner-
request by tracking the current ACK number. Specifically, able Windows Live Messenger app running or a connection
when the second request is sent, the valid ACK number established to known port numbers and IP addresses that
range moves forward by the number of bytes in the request are associated with the app, an attacker can launch this at-
payload. tack.
In our proof-of-concept implementation, we always inject We have verified that the commands that are possible to
the Javascript after waiting for a fixed amount of time after inject into the server include, but not limited to, (1) adding
the connection is detected, which can already succeed for a new friend or removing an existing friend (specified by the
a few times. However, a more sophisticated attacker can account email address), (2) changing the status messages,
definitely do better. and (3) sending messages to friends. Given that the messen-
ger client is idle most of the time and the fact that the client-
side sequence number inference only takes 23 seconds, the
5.2 Phishing Facebook Login Page attack can be launched fairly easily. The commands can
We launch this attack based on passive TCP hijack cause serious damage. For instance, the add-friend com-
which passively monitors if a new connection to Facebook mand allows an attacker to add its malicious account as a
is made. In this case study, we look at how to replace the friend which can subsequently send spam or phishing mes-
Facebook login page by resetting the Facebook immediately sages. In addition, after being added as a friend, the attacker
after it has responded with SYN-ACK. can read the friend list (email accounts) of the victim user,
We assume that the user is not already logged in to Face- delete them, or spam them. Finally, new status posting can
book. Otherwise, as described in the previous attack, the be part of the phishing attack against the friends as well.
server processing delay for the first HTTP request is so long
that is is too easy to succeed. When the user is not logged 5.4 Restricted Facebook Login Page Hijack
in, the server processing delay will become negligible and This attack is launched based on active TCP hijack as
the effective time window for reset to succeed is basically a described in 4.5. The goal of this attack is still to hijack
single round trip time. This scenario is also generic enough TCP connections. However, due to the lack of ability to
that the attack can be applied for many other websites such reset the server-side connection in the new version of the
as twitter.com. Linux kernel, it requires offline analysis on the client-side
In Table 2, we show how likely the attack can succeed un- ISN of the target four tuples.
der different conditions. For instance, when theres a single In our implementation, we develop a simple Android test
Planetlab node, the success rate is a little below 50%. How- malware that performs the offline analysis right after it is
ever, when we use two nodes for latency values of 70ms and started. The four tuples we target include a pre-selected
100ms respectively, the success rate increases significantly to local port and the Facebook server IP thats resolved for
62.5% and 82.5% , indicating that we have more bandwidth m.facebook.com. After the analysis, the attack takes a lit-
One Planetlab node Two Planetlab nodes
RT Tb =70ms1 RT Tb =100ms RT Tb =70ms RT Tb =100ms
Succ Rate 42.5% (17/40) 47.5% (19/40) 62.5% (25/40) 82.5% (33/40)
1
RT Tb is the RTT between the attacker and the Facebook server
Table 2: Success rate of Facebook login page injection (case study 2)

tle over one second, and it performs port jamming immedi- 7. REFERENCES
ately (which takes about 5 seconds). After this, our mal-
ware app immediately sends an Intent that asks to open
m.facebook.com through the browser. An attacker may [1] Blind TCP/IP Hijacking is Still Alive. http:
come up with reasons such as asking a user to use his Face- //www.phrack.org/issues.php?issue=64&id=15.
book account to register for the app. When the browser [2] CERT Advisory CA-1995-01 IP Spoofing Attacks and
starts the connection to Facebook, the malware works with Hijacked Terminal Connections.
the off-path attacker to hijack the connection (as described http://www.cert.org/advisories/CA-1995-01.html.
in 4.5). We have verified that the Facebook login page can [3] Golomb Ruler.
indeed be hijacked following these steps. http://en.wikipedia.org/wiki/Golomb_ruler.
The main difficulty in this attack is not about successfully [4] Linux Blind TCP Spoofing Vulnerability.
inferring the sequence number. Instead, it requires the user http://www.securityfocus.com/bid/580/info.
to be convinced that the app indeed has a relationship with [5] Linux: TCP Random Initial Sequence Numbers.
the target website (i.e., Facebook) so that the user will enter http://kerneltrap.org/node/4654.
his password into the browser. [6] MSN Messenger Protocol.
http://www.hypothetic.org/docs/msn/.
6. DISCUSSION AND CONCLUSION [7] RFC 1948 - Defending Against Sequence Number
From these real attacks, there are a few lessons that Attacks. http://tools.ietf.org/html/rfc1948.
we learn: (1) Even though OS statistics are aggregated [8] RFC 5961 - Improving TCPs Robustness to Blind
and seemingly harmless, they can leak critical internal net- In-Window Attacks.
work/system state through unexpected interactions from the http://tools.ietf.org/html/rfc5961.
on-device malware and the off-path attacker. Similar obser- [9] RFC 793 - Transmission Control Protocol.
vations have been made recently in a few other studies as http://tools.ietf.org/html/rfc793.
well, e.g., using procfs as side channels [22]. Our study [10] Stateful Firewall and Masquerading on Linux. http:
reveals specifically that the packet counters can leak TCP //www.puschitz.com/FirewallAndRouters.shtml.
sequence numbers. (2). Our systems today still have too [11] sysctl Mac OS X Manual.
much shared state: the active TCP connection list shared https://developer.apple.com/library/mac/
among all apps (through netstat or procfs); the IP address of #documentation/Darwin/Reference/Manpages/man3/
the malwares connection and other apps; the global packet sysctl.3.html#//apple_ref/doc/man/3/sysctl.
counters. Future system and network design should carefully [12] TCP Delayed Ack in Linux. http://wiki.hsc.com/
evaluate what information an adversary can obtain through wiki/Main/InsideLinuxTCPDelayedAck.
these shared state. [13] S. Chen, R. Wang, X. Wang, and K. Zhang.
On the defense side, there are a few measures that may Side-channel Leaks in Web Applications: A Reality
improve security: (1) always using SSL/TLS, (2) removing Today, a Challenge Tomorrow. In Proc. of IEEE
unnecessary global state (such as the active TCP connection Security and Privacy, 2010.
list and packet counters) or only allow privileged programs [14] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S.
to access such state, (3) providing better isolation among Wallach. Quire: Lightweight Provenance for Smart
resources, e.g., providing a separate set of packet counters Phone Operating Systems. In Proc. of USENIX
for each app. With IPv6 widely deployed, we may even Security Symposium, 2011.
provide different source IP addresses for connections in dif- [15] M. Egele, C. Kruegel, E. Kirda, and G. Vigna. PiOS:
ferent processes on a device so that malware will not be able Detecting Privacy Leaks in iOS Applications. In
to learn the IP address of the connection established by an- NDSS, 2011.
other process. In the extreme case, each app may run in its
[16] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung,
own virtual machine.
P. McDaniel, and A. N. Sheth. TaintDroid: An
To conclude, we have demonstrated an important type
Information-flow Tracking System for Realtime
of TCP sequence number inference attack enabled by host
Privacy Monitoring on Smartphones. In OSDI, 2010.
packet counter side-channels under a variety of client OS
and network settings. We also offer insights on why they [17] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri.
occur and how they can be mitigated. A Study of Android Application Security. In Proc. of
USENIX Security Symposium, 2011.
[18] R. Ensafi, J. C. Park, D. Kapur, and J. R. Crandall.
Idle Port Scanning and Non-interference Analysis of
Network Protocol Stacks using Model Checking. In
Proc. of USENIX Security Symposium, 2010.
[19] A. P. Felt, H. J. Wang, A. Moshchuk, S. Hanna, and
E. Chin. Permission Re-delegation: Attacks and
Defenses. In Proc. of USENIX Security Symposium, [27] Z. Qian, Z. M. Mao, Y. Xie, and F. Yu. Investigation
2011. of Triangular Spamming: A Stealthy and Efficient
[20] Y. Gilad and A. Herzberg. Off-Path Attacking the Spamming Technique. In Proc. of IEEE Security and
Web. In Proc. of USENIX Workshop on Offensive Privacy, 2010.
Technologies (WOOT), 2012. [28] R. Schlegel, K. Zhang, X. yong Zhou, M. Intwala,
[21] S. Guha and P. Francis. Characterization and A. Kapadia, and X. Wang. Soundcomber: A Stealthy
Measurement of TCP Traversal through NATs and and Context-Aware Sound Trojan for Smartphones. In
Firewalls. In Proc. ACM SIGCOMM IMC, 2005. NDSS, 2011.
[22] S. Jana and V. Shmatikov. Memento: Learning secrets [29] D. X. Song, D. Wagner, and X. Tian. Timing Analysis
from process footprints. In Proc. of IEEE Security and of Keystrokes and Timing Attacks on SSH. In Proc. of
Privacy, 2012. USENIX Security Symposium, 2001.
[23] L. Joncheray. A Simple Active Attack against TCP. In [30] M. Vuagnoux and S. Pasini. Compromising
Proc. of USENIX Security Symposium, 1995. electromagnetic emanations of wired and wireless
[24] G. LEECH, P. RAYSON, and A. WILSON. Procfs keyboards. In Proc. of USENIX Security Symposium,
Analysis. http://www.nsa.gov/research/_files/ 2009.
selinux/papers/slinux/node57.shtml. [31] Z. Wang, Z. Qian, Q. Xu, Z. M. Mao, and M. Zhang.
[25] R. Morris. A Weakness in the 4.2BSD Unix TCP/IP An Untold Stody of Middleboxes in Cellular
Software. Technical report, 1985. Networks. In SIGCOMM, 2011.
[26] Z. Qian and Z. M. Mao. Off-Path TCP Sequence [32] P. A. Watson. Slipping in the Window: TCP Reset
Number Inference Attack How Firewall Middleboxes Attacks. In CanSecWest, 2004.
Reduce Security. In Proc. of IEEE Security and [33] K. Zhang and X. Wang. Peeping Tom in the
Privacy, 2012. Neighborhood: Keystroke Eavesdropping on
Multi-User Systems. In Proc. of USENIX Security
Symposium, 2009.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy