Ccs12 Qian
Ccs12 Qian
Ccs12 Qian
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.
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: