NUMBER: JACK | RESEARCH REPORT

Weak ISN Generationin Embedded TCP/IP Stacks

by Forescout Research Labs

RESEARCH REPORT | NUMBER: JACK

Contents
Executive summary

3

1.

Introduction

3

2.

New vulnerabilities found3

3.

Impact5

4.

Recommendations for network operators

5

5.

Technical dive-in

65.1. TCP connections and ISN generation

6

5.2. ISN generation vulnerability

7

5.3. Historical vulnerabilities

8

5.3. New vulnerabilities and non-vulnerable stacks

8

Conclusion

96.

References

FORESCOUT RESEARCH LABS

10

RESEARCH REPORT | NUMBER: JACK | Executive summary

Executive summary• In the second study of Project Memoria, Forescout
Research Labs discloses NUMBER:JACK, a set of 9
new vulnerabilities affecting embedded TCP/IP stacks.
• The vulnerabilities are all related to the same problem:
weak Initial Sequence Number (ISN) generation, which
can be used to hijack or spoof TCP connections.
Ultimately, attackers may be able to leverage thosevulnerabilities to close ongoing connections, causing
limited denials of service, to inject malicious data on a
device or to bypass authentication.
• Although NUMBER:JACK vulnerabilities are not as
critical as those of AMNESIA:33, they are even moreprevalent, affecting 9 of 11 stacks analyzed. This study
shows one more instance of historical vulnerabilities
considered eradicated in the IT world affecting large
numbers of IoT and OT devices.
• Recommended mitigations include using encrypted
connections (for instance with IPsec), limiting the
network exposure of critical vulnerable devices, andpatching whenever device vendors release advisories.

ISNs ensure that every TCP connection between two
devices is unique and that there are no collisions,preventing third parties from interfering with an ongoingconnection. To guarantee these properties, ISNs mustbe randomly generated so that an attacker cannot guess
an ISN and hijack an ongoing connection or spoof a newone. As discussed below, in many of the TCP/IP stacks
that Forescout analyzed, ISNs are improperly generated,
thereby leaving TCP connections of a device open to
attacks.

2. New vulnerabilities foundIn this second study of Project Memoria, Forescout
researchers analyzed 11 TCP/IP stacks: 7 are theopen source embedded TCP/IP stacks analyzed
in AMNESIA:33 (uIP, FNET, picoTCP, Nut/Net, lwIP,
cycloneTCP and uC/TCP-IP), while the remaining 4 areMicrochip’s MPLAB Net, Texas Instruments’ NDKTCPIP,
ARM’s Nanostack and Siemens’ Nucleus NET. Forescout
found vulnerabilities in 9 of the 11 analyzed stacks. Table
1 details our findings.

1. Introduction
In 2020 Forescout Research Labs started Project
Memoria, an initiative that seeks to provide thecybersecurity community with the largest study on
the security of TCP/IP stacks. The first outcome of the
project was AMNESIA:33 – a set of 33 vulnerabilities
affecting 4 open source TCP/IP stacks.
The AMNESIA:33 technical report discussed how
implementation flaws that have been well-known for
decades have resurfaced as vulnerabilities that affectmillions of IoT, OT and IT devices. While AMNESIA:33
was primarily focused on memory corruption bugs,
NUMBER:JACK focuses on a fundamental aspect of
TCP communication: Initial Sequence Number (ISN)
generation.

FORESCOUT RESEARCH LABS

3RESEARCH REPORT | NUMBER: JACK | New vulnerabilities foundTable 1 – The summaries of new vulnerabilities found in this research

CVE ID

CVSSv3Score

TCP/IP Stackanalyzed

Description

CVE-2020-27213

7.5

Nut/Net 5.1

ISN generator relies on a highly predictablesource (system timer) and has constantincrements.

Patch in progress.

uC/TCP-IP 3.6.0

ISN generator relies on LCG, which isreversible from observed output streams.
The algorithm is seeded with publicly
recoverable information (i.e., system timer
count).

uC/TCP-IP is no longer
supported. Patched in thelatest version of Micrium
OS (successor project).

Patched in version 2.0.0.

CVE-2020-27630

7.5

Fix

CVE-2020-27631

7.5

CycloneTCP 1.9.6

ISN generator relies on LCG, which isreversible from observed output streams.
The algorithm is initially seeded with apublicly observable CRC value.

CVE-2020-27632

7.5

NDKTCPIP 2.25

ISN generator is initialized with a constantvalue and has constant increments.

Patched in version 7.02 ofProcessor SDK.
Documentation updated
to warn users andrecommend implementing their own PRNG.

CVE-2020-27633

7.5

FNET 4.6.3

ISN generator is initialized with a constantvalue and has constant increments.

CVE-2020-27634

7.5

uIP 1.0
Contiki-OS 3.0
Contiki-NG 4.5

ISN generator is initialized with a constantvalue and has constant increments.

No response frommaintainers.
Version 2.1 removes
the default (vulnerable)
implementation andrecommends users
implement their own
PRNG.

CVE-2020-27635

7.5

PicoTCP 1.7.0
PicoTCP-NG

ISN generator relies on LCG, which isreversible from observed output streams.
The algorithm is seeded with publicly
recoverable information (i.e., system timer
count).

CVE-2020-27636

7.5

MPLAB Net 3.6.1

ISN generator relies on LCG, which isreversible from observed output streams.
The algorithm is seeded with a static value.

Patched in version 3.6.4.

Nucleus NET 4.3

ISN generator relies on a combination ofvalues that can be inferred from a network
capture (MAC address of an endpoint and avalue derived from the system clock).

Patched in Nucleus
NET 5.2 and Nucleus
ReadyStart v2012.12.

CVE-2020-28388

FORESCOUT RESEARCH LABS

6.5

4

RESEARCH REPORT | NUMBER: JACK | New vulnerabilities found

These vulnerabilities were discovered and disclosed
to the vendors and maintainers of the affected TCP/IP
stacks in October 2020. While most vendors havealready issued patches and/or mitigation
recommendations to their users (shown in the Fixcolumn of Table 1), the developers of Nut/Net are stillworking on a solution, and Forescout has not received
a response from the uIP developers.
The vulnerabilities found (except CVE-2020-28388)
have a common CVSSv3 score and vector of 7.5 and
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, respectively.
Siemens has assigned to CVE-2020-28388 a score of 6.5
with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L.
However, the actual severity on a particular device andTCP connection may vary depending on, for example,
the use of encrypted sessions and the sensitivity ofdata exchanged. The impact of these vulnerabilities isdiscussed in the next section, and comments about
the stacks that were not found vulnerable (lwIP and
Nanostack) are in Section 5.4.

3. Impact
There are two basic ways to exploit a weak TCP ISN.
1. By predicting the ISN of an existing TCP connection,
attackers can close it, thus achieving a Denial-ofService. Or, they can hijack it, thus injecting data
into a session. Data can be injected on sensitive
unencrypted traffic, such as Telnet sessions (to injectcommands), FTP file downloads (to serve malware)or HTTP responses (to direct the victim to a maliciouspage).
2. By targeting new TCP connections, attackers may
successfully complete a three-way handshakeand spoof network packets intended for the victim
endpoint or bypass address-based authentication andaccess control [1] [2] [3].

FORESCOUT RESEARCH LABS

Although this type of vulnerability has been usedhistorically to break into general-purpose computers(notoriously by Kevin Mitnick, which led it to be known
as the “Mitnick attack”), the stacks Forescout researched
are primarily used in embedded devices.
The popularity and some use cases of the vulnerable
stacks uIP, FNET, picoTCP and Nut/Net were discussed in
the AMNESIA:33 report. That report showed that thesestacks are used by millions of devices of several different
types, from IT file servers to IoT embedded components.
As for the new vulnerable stacks, Forescout believes
that CycloneTCP, uC/TCP-IP, NDKTCPIP, MPLAB Net andNucleus NET are no less popular than the previous ones.
For example, according to the 2019 Embedded Markets
Study [4], the Texas Instruments RTOS (which may
be used with NDKTCPIP) is used by 6% of embedded
projects, while Micrium’s uC/OS-II or uC/OS-III (which
may be used with uC/TCP-IP) are used by 7%. The
website of Nucleus RTOS mentions that it is deployed in
more than 3 billion devices. In all three cases, assuming
a sizeable chunk of these projects utilizes TCP/IP
connectivity, this certainly translates into other millionsof devices running this software.
In this research, Forescout has not tried to identify
affected devices or device manufacturers. Still, there
are several notable public use cases of some of thestacks, such as medical devices, wind turbine monitoring
systems, remote terminal units (RTUs) and IT storage
systems.

4. Recommendations for
network operators
As is always the case with vulnerabilities affecting TCP/
IP stacks (such as AMNESIA:33 and Ripple20), identifying
and patching devices running the vulnerable stacks
is at the same time the best mitigation and the mostchallenging one. This process is challenging because it isoften unknown which devices run a particular stack and

5

RESEARCH REPORT | NUMBER: JACK | Recommendations for network operators

because embedded devices are notoriously difficult tomanage and update, often being part of mission-criticalinfrastructure.

next section). Therefore, Forescout recommends that
network operators focus on the preventive measuresdescribed above.

For the reasons above, we recommend the following
mitigation strategy.

5. Technical dive-in• Discover and inventory devices that run a vulnerable
TCP/IP stack. Although it is challenging to identify the
TCP/IP stack running on a device, there are tools to
help. Forescout Research Labs has released an open
source script that uses active fingerprinting to detect
which stack a target device is running. The script is
updated constantly with new signatures. Besides
that, Nmap allows the collection of ISN metrics andperforms statistical analyses to understand whether atarget device suffers from weak ISN generation.
• Patch when possible. Monitor progressive patches
released by affected device vendors and devise aremediation plan for your vulnerable asset inventory
balancing business risk and business continuity
requirements.
• Segment to mitigate risk. For vulnerable IoT and OT
devices, use segmentation to minimize their network
exposure and the likelihood of compromise without
impacting mission-critical functions or business
operations. Segmentation and zoning also limit theblast radius and business impact if a vulnerable
device becomes compromised.
• Deploy IPsec. End-to-end cryptographic solutions
built on top of the Network layer (IPsec) do not
require any modifications to a TCP/IP stack in use
while allowing to defend against TCP spoofing andconnection reset attacks [1]. Unfortunately, thiscomes at the cost of network bandwidth.

5.1. TCP connections and ISN generation
TCP is a connection-oriented networking protocol thatallows two endpoints to exchange data [5]. TCP is oneof the protocols used in the TCP/IP Transport Layer, andit aims for ordered and error-checked delivery of data
between network endpoints.
The protocol relies on sequence numbers that aretransmitted with every packet over a TCP connection.
Since every transmitted byte is sequenced, each of themcan be accounted for during reception. A TCP connectionis uniquely defined by a pair of network sockets – a
combination of a network address and a network port.
Since there is a finite number of ports in an endpoint, newconnections may reuse the sockets utilized by alreadyterminated connections, which becomes problematic ifconnections are open and closed in quick succession.
The initial sequence number (ISN) mechanism [5] wasintroduced to prevent connection collisions when sockets
are reused.

SYN, ISNClient
SYN, ISNServer, ACK(ISNClient)
ClientACK(ISNServer)

ServerFigure 1 – TCP three-way handshake

Monitoring the network to detect attempts to exploit
weak ISN generation vulnerabilities is impractical. Thesevulnerabilities are related to cryptographic weaknesses,
so there is no obviously malicious packet to exploit them(details of what an exploit looks like are shown in the

FORESCOUT RESEARCH LABS

6RESEARCH REPORT | NUMBER: JACK | Technical dive-in

An ISN generator is used at each endpoint to select a
32-bit sequence number that is supposed to be
unique for every connection so that both endpoints
can synchronize by exchanging their ISNs. The ISN
synchronization occurs at the beginning of a connection
with the three-way handshake mechanism [5] (illustrated
in Figure 1): a Client sends a SYN packet with its unique
ISNClient, the Server acknowledges its reception andprovides its own ISNServer within a SYN-ACK packet andthe Client acknowledges the reception of ISNServer withan ACK packet. These three steps establish a TCP
connection, allowing endpoints to exchange data.

5.2. ISN generation vulnerability
The original TCP design document [5] mentions that the
32-bit counter in an ISN generator should be incremented
every 4 microseconds with the intention of being random,
thus preventing accidental connection collisions.
However, this does not prevent attackers from deliberately
forcing collisions to their advantage. As early as 1985,
Morris [6] showed that ISNs can be easily guessedby attackers (because the ISN generator increments
are constant), allowing them to disrupt or hijack TCP
connections. TCP connection hijacking facilitates
the execution of other kinds of attacks, such as
unauthenticated access and Denial-of-Service, but thisdepends on the use of IP-based authentication
protocols [1].

SYN, ISNAttacker
ACK(ISNServer′)

SYN, ISNServer′, ACK(ISNAttacker)
ClientServer

Attacker

Figure 2 – ISN attack illustration

This attack [6] is illustrated in Figure 2. Attacker
impersonates a legitimate Client (see [2]) and opens
a connection to a Server (with a deterministic ISN
generator). Server, thinking that the SYN packet iscoming from Client, sends a SYN-ACK packet to Client,which includes ISNServer. Attacker cannot see the SYNACK packet sent to Client. However, if Attacker can guessthe value of ISNServer, they can still send an ACK packet
back to Server with the guessed ISNServer and complete
the three-way handshake. In this way, the Server will thinkit has a legitimate connection with Client, when in fact itwill be communicating with Attacker.

FORESCOUT RESEARCH LABS

While the best possible solution to prevent this issue isstrong cryptographic authentication [1, 2, 3], it may not be
feasible for all networking scenarios. Therefore,
RFC1948 [2] (updated by RFC6528 [3] after 16 years of
its initial release) has proposed to compute the ISN as
follows:
ISN = M + F (localip, localport, remoteip, remoteport, secretkey)
where M is the 4 microsecond timer, and F() is a pseudorandom function of the connection id (defined by the tuple<localip, localport, remoteip, remoteport>) and some secretdata secretkey. RFC6528 [3] requires that neither F() nor
secretkey are computable from the outside, otherwise
attackers can still guess arbitrary ISNs by observing

7

RESEARCH REPORT | NUMBER: JACK | Technical dive-in

enough ISNs from other connections. It is important tonote that the aforementioned attack is possible becauseof a flaw in the original TCP design (RFC0793 [5]), and itis the responsibility of the developers who implement a
TCP/IP stack for their device/platform to ensure that aproper protection mechanism is put in place.

5.3. Historical vulnerabilities
The vulnerability described above was known as early
as 1985 [6], but the first exploitation attempts were
demonstrated only about 10 years later [7]. The firstpublicly known vulnerability reports (as found in the
National Vulnerability Database) followed only from1999 until 2001, affecting several individual operating
systems (namely Windows NT 4.0, FreeBSD, Cisco IOS,
WindowsCE and Livingston ComOS). It is difficult todistill the real root cause from the vulnerability
descriptions, although the most likely root cause
was non-compliance with RFC1948 [2].
Later in 2001, the CERT released a large vulnerability
advisory [1] warning that even if RFC1948 [2] is followed,
the pseudo-random number generator (PRNG) used in
the ISN generator may rely on a known weak algorithm,
and it would be practical for attackers to predict its
outputs, as if constant increments to the ISN number
are being used. The corresponding vulnerability(CVE-2001-0328) has been reported to affect many
vendors and projects: Cisco, Sun, IBM, HP, SGI, Fujitsu,
FreeBSD, OpenBSD and Linux. The root cause was that
all the affected parties relied on the same weak PRNG
algorithm.
These publications surmise that there are essentially
two possible root causes of weak ISN generation
vulnerability: (1) the RFC documents detailing thecountermeasures are being ignored; or (2) a known weakor flawed PRNG is used when attempting to randomize
the ISN generator output.
From 2001 until 2019, there were 15 more weak ISN
generation vulnerabilities mostly reported for individual

FORESCOUT RESEARCH LABS

devices, such as network switches, gateways andsmartphones. The vulnerability descriptions suggest thatsome of the affected vendors could be non-compliant
with the RFCs (i.e., no PRNG has been used for ISN
generation whatsoever), which is very surprising giventhat RFC1498 has been around for at least 16 years.
While this is still only Forescout’s hypothesis (based on
vulnerability descriptions alone), next section shows that
this still happens in 2021.
Out of these historical vulnerabilities, it is worth to single
out CVE-2014-7284 found in the Linux Kernel. Thisvulnerability is more foundational than the rest. The
PRNG seeding mechanism used by the ISN generator(and potentially other consumer APIs outside theLinux Kernel) was found to be flawed. In 2020, Klein [8]released a report arguing that the PRNG in the Linux
Kernel is weak and can be used to facilitate various
cross-layer attacks against its TCP/IP protocol suite,
such as DNS cache poisoning and UDP port prediction.
While the author does not mention the ISN flaw, it might
be among possible attacks.

5.4. New vulnerabilities and nonvulnerable stacks
As shown in Table 1, the root causes for the newly foundvulnerabilities are conceptually very similar to the root
causes of the historical vulnerabilities discussed above.
For example, 5 of the stacks seem to ignore RFC1948[2] /RFC6528 [3], as they did not use any kind of PRNG
to generate ISN values. At best, Nut/Net generated
ISNs based on the state of a system timer. Given that
ISN is only 32 bits wide, and attackers may have theknowledge of the system uptime or be able to observe
previous ISN values as well as other leakages of thesystem timer over the network, this value can be easily
inferred. On the other hand, uIP (also Contiki-OS andContiki-NG), FNET and NDKTCPIP initialized ISNs with aconstant value, which attackers may find by examining
the corresponding source or byte code, or by looking at ashort network capture.

8

RESEARCH REPORT | NUMBER: JACK | Technical dive-in

The remaining 4 issues listed in Table 1 were due to theusage of a weak PRNG algorithm. Moreover, the PRNG
algorithm seeding was not implemented properly in allcases, which would help the attackers to further reduce
the search space (which is already quite limited) for
predicting the output of the PRNG and guessing ISNs.
PicoTCP, PicoTCP-NG, CycloneTCP, uC/TCP-IP and MPLAB
Net all relied on a variation of a simple Linear Congruential
Generator (LCG) algorithm for generating ISNs, which
is known to be easily reversible from the observed
output streams [9] [10] (e.g., network communications).
Additionally, all these stacks used either a constant value
or a dynamic value derived from a system clock forseeding the algorithm, which would defeat the purpose ofusing a PRNG.
Moreover, it is also challenging to account for all possible
configurations in which an embedded TCP/IP stack will
be used. Therefore, to ensure flexibility of a protocol
suite, developers of TCP/IP stacks may implementnaïve ISN generation solutions (e.g., using weak PRNG
or no PRNG at all), expecting that system integratorsand product developers will override this functionality
according to their needs. The lwIP project handled thisissue by introducing the possibility for system integratorsand product developers to implement their own PRNG
for ISN generation, as well as documented this feature.
While Forescout cannot claim that lwIP is vulnerable to
the weak ISN generation vulnerability per se, Forescout
believes this kind of solution might still introduce
vulnerabilities if the system integrators and productdevelopers are not carefully reading the documentation.
However, if a project/vendor provides no documentationthat warns users about this, such implementations
must be considered vulnerable, which was the case forthe vulnerability Forescout reported to the PicoTCP-NG
project maintainers.

6. Conclusion
Forescout’s main conclusions from the NUMBER:JACK
research are:• As initially discussed in AMNESIA:33, misinterpretation
or mis-implementation of RFCs is a major causeof vulnerabilities in TCP/IP stacks. In the case of
ISN generation, stacks completely ignoring RFC
recommendations are often seen.
• Weak ISN generation is one more instance of historicalvulnerabilities discovered and fixed in the IT world
decades ago that today affects large numbers of IoTand OT devices.
• This type of vulnerability is much easier for researchers
to discover than the memory corruption issues
discussed in AMNESIA:33. Although they do not allow
for remote code execution directly, attackers canquickly and easily analyze several TCP/IP stacks andfind similar issues that can be part of a larger attack
campaign in a heterogeneous network with many IoT/OT devices.
• Unfortunately, this type of vulnerability is also difficult
to fix permanently because of the resource constraintsof many embedded devices, and what is considered asecure PRNG today may be considered insecure in the
future. Some stack developers opt to rely on system
integrators to implement their own ISN generation,
which is a fair decision, but which means not all devices
using a patched stack will be secure automatically.

• This research again highlights the security challengesof the IoT world and why it is fundamental for
network operators to employ cybersecurity tools that
ensure visibility and control of networked devices,
including granular classification to detect vulnerable
components, as well as the possibility of segmenting
Finally, the developers of Nanostack have implemented theand enforcing policies on the network.
ISN generation mechanism in accordance with FC6528[3], which is the only stack (out of the 11 that Forescout
analyzed) that implements this functionality properly.

FORESCOUT RESEARCH LABS

9

RESEARCH REPORT | NUMBER: JACK | References

References[1]

CERT Division, “2001 CERT Advisories,” 2001. [Online]. Available: https://resources.sei.cmu.edu/asset_files/			WhitePaper/2001_019_001_496192.pdf.

[2]

S. Bellovin, “RFC1948: Defending Against Sequence Number Attacks,” 1996.

[3]

F. Gont and S. Bellovin, “RFC6528: Defending Against Sequence Number Attacks,” 2012.

[4]

Embedded.com, “2019 Embedded Markets Study,” [Online]. Available: https://www.embedded.com/wp-content/		
uploads/2019/11/EETimes_Embedded_2019_Embedded_Markets_Study.pdf.

[5]

J. Postel, “RFC0793: Transmission Control Protocol,” 1981.

[6]

R. Morris, “A Weakness in the 4.2BSD UNIX TCP/IP Software,” CSTR 117, 1985.

[7]

T. Shimomura, “Technical Details of the Attack Described by Markoff in NYT,” http://www.gont.com.ar/docs/post-		
shimomura-usenet.txt, 1995.

[8]

A. Klein, “Cross Layer Attacks and How to Use Them (DNS Cache Poisoning, Device Tracking and More),” https://		arxiv.org/abs/2012.07432, 2020.

[9]

G. Argyros and A. Kyayias, “I Forgot Your Password: Randomness Attack Against {PHP} Applications,” in USENIX 		Security, 2012.

[10] P. Bouchareine, “BSD Weak Initial Sequence Number Vulnerability,” Bugtraq (SecurityFocus), 2010. [Online]. 			
Available: https://www.securityfocus.com/bid/1766/discuss. [Accessed 11 January 2021].

Don’t just see it.
Secure it.
TMContact us today to actively
defend your Enterprise of Things.

forescout.com/research-labs/

research@forescout.com

Forescout Technologies, Inc.
190 W Tasman Dr.
San Jose, CA 95134 USA
Toll-Free (U.S.) 1-866-377-8771
Tel (Intl) +1-408-213-3191
Support +1-708-237-6591

toll free 1-866-377-8771

Learn more at Forescout.com© 2021 Forescout Technologies, Inc. All rights reserved. Forescout Technologies, Inc. is a Delaware
corporation. A list of our trademarks and patents is available at www.forescout.com/company/
legal/intellectual-property-patents-trademarks. Other brands, products or service names may be
trademarks or service marks of their respective owners. Version 02_21