RESEARCH REPORT | NUCLEUS:13

NUCLEUS: 13
Dissecting the Nucleus TCP/IP stack
By Forescout Research Labs & Medigate Labs

Forescout Research LabsDaniel dos Santos
Stanislav Dashevskyi
Amine Amri
Medigate Labs
Uriel Malin
Tal Zohar
Yuval Halaban

RESEARCH REPORT | NUCLEUS:13

Table of Contents
1. Executive Summary.......................................................................................................3
2. Main Findings.................................................................................................................5
2.1. What is Nucleus NET?................................................................................................5
2.2. Why analyze Nucleus NET?........................................................................................5
2.3. Analysis and findings................................................................................................6

3. Attack Scenarios Leveraging NUCLEUS:13.................................................................7
3.1. Scenario 1: hacking the hospital..................................................................................7
3.2. Scenario 2: crashing the trains....................................................................................9

4. Impact...........................................................................................................................10
5. Mitigation Recommendations...................................................................................14
6. Technical Dive-In: Exploiting CVE-2021-31886........................................................15
6.1. Root cause analysis..................................................................................................16
6.2. Exploiting a QEMU image.........................................................................................176.3. Exploiting a WAGO 750-852......................................................................................23

7. Conclusions..................................................................................................................27

FORESCOUT RESEARCH LABSRESEARCH REPORT | NUCLEUS:13 | Executive Summary

1. Executive Summary• In the fifth study of Project Memoria –• The new vulnerabilities allow for Remote
NUCLEUS:13 – Forescout Research Labs andCode Execution or Denial of Service, with
Medigate Labs identified a set of 13 new
three of the thirteen new vulnerabilities
vulnerabilities affecting the Nucleus TCP/IP
being critical and having CVSS scores ofstack.
either 9.8 or 8.8.
• Nucleus is currently owned by Siemens.
• Forescout Research Labs and Medigate
Originally released in 1993, Nucleus has
Labs exploited one of the Remote Codebeen deployed in many industries that
Execution vulnerabilities in their labs andhave safety and security requirements,
demonstrated that a successful attack could
such as medical devices, automotive andpotentially disrupt medical care and otherindustrial systems.
critical processes.
• Upon identifying new vulnerabilities,• Two of the recommended mitigations
Forescout Research Labs and Medigate Labs
for NUCLEUS:13 include using network
collaborated with Siemens, CISA, CERT/CC
segmentation to limit the networkand other agencies to confirm the findings
exposure of critical vulnerable devices
and notify vendors.
and patching devices as vendors release• According to the Siemens website, Nucleus
their patches. Some vulnerabilities canis deployed in three billion devices.
also be mitigated by blocking or disabling
Anesthesia machines, ventilators andsupport for unused protocols, such as FTP.
patient monitors are among the medical
devices possibly impacted by NUCLEUS:13.

FORESCOUT RESEARCH LABS

3RESEARCH REPORT | NUCLEUS:13 | Executive Summary

INFORMATIONAL

A recap on TCP/IP stacks
and Project Memoria
A TCP/IP stack is a piece of software that
implements basic network communication for
all IP-connected devices, including Internetof Things (IoT), operational technology (OT)and information technology (IT). Not only
are TCP/IP stacks widespread, they arenotoriously vulnerable due to (i) codebases
created decades ago and (ii) an attractive
attack surface, including protocols that crossnetwork perimeters and an abundance ofunauthenticated functionality.
Given the impact of these foundational
components, Forescout Research Labs haslaunched Project Memoria with the goal ofcollaborating with industry peers and research
institutes to provide the cybersecurity
community with the largest analysis of the
security of TCP/IP stacks.
The latest examples of TCP/IP stackvulnerabilities include:• Ripple20, a set of 19 vulnerabilities on the
Treck TCP/IP stack, disclosed by JSOF in June
2020. Forescout Research Labs worked inclose collaboration with JSOF to identify
vendors and devices potentially affected by
Ripple20.

FORESCOUT RESEARCH LABS

• AMNESIA:33, a set of 33 vulnerabilities
affecting four open-source TCP/IP stacks,
disclosed in December 2020 by Forescout
Research Labs.
• NUMBER:JACK, a set of nine vulnerabilities
affecting the Initial Sequence Number(ISN) implementation in nine TCP/IP stacks,
disclosed in February 2021 by Forescout
Research Labs.
• NAME:WRECK, a set of nine vulnerabilities
affecting DNS clients of four TCP/IP stacks,
disclosed in April 2021 by Forescout
Research Labs and JSOF.
• INFRA:HALT, a set of 14 vulnerabilities
affecting InterNiche’s NicheStack, disclosed
in August 2021 by Forescout Research Labs
and JFrog Security Research.
• NUCLEUS:13, a set of 13 vulnerabilities
affecting Siemens’ Nucleus TCP/IP stack,disclosed in October 2021 by Forescout
Research Labs and Medigate Labs.

4

RESEARCH REPORT | NUCLEUS:13 | Main Findings

2. Main Findings
2.1. What is Nucleus NET?

2.2. Why analyze Nucleus NET?

Nucleus NET is the TCP/IP stack of the Nucleus
Real-time Operating System (RTOS). The stackand the RTOS were originally developed byAccelerated Technology, Inc. (ATI) in 1993,
then acquired by Mentor Graphics in 2002 andfinally by Siemens in 2017. Since its original
release 28 years ago, Nucleus has been
deployed in many industries that have safety
and security requirements, such as medical
devices, automotive and industrial systems.
Nucleus is currently distributed as:

We chose to analyze Nucleus NET because ofits known uses in safety-critical applications,as described above. Nucleus NET was thetarget of previous analyses in Project Memoria,
during both NUMBER:JACK and NAME:WRECK.
Siemens also published two CVEs affecting theIPv6 components of the stack in 2021, which
are similar to some issues seen on AMNESIA:33.
Table 1 summarizes the previously known
vulnerabilities affecting Nucleus NET.

• ReadyStart: Containing source code, a
suite of tools for development and analysis,
middleware, board support packages (BSPs)
and examples

Since we had already analyzed Nucleus NET
for specific vulnerabilities in NUMBER:JACK
and NAME:WRECK (TCP ISN generation and
DNS client, respectively), we investigated othercomponents of the stack that we had access to.

• SafetyCert: A certified version of thekernel with runtime libraries, connectivity
middleware, networking and data storage.
The certification package includes sourcecode and documentation with traceability
and hyperlinks for easier safety reviews
CVE IDs

Description/Comment

CVE-2019-13939

DHCP client vulnerability allows attackers to change the IP address of a device to an invalid
value. Besides Nucleus, it also affects several devices in the APOGEE, TALON and Desigo linesof building automation products

CVE-2020-15795
CVE-2020-27009
CVE-2020-27736
CVE-2020-27737
CVE-2020-27738
CVE-2021-25677
CVE-2021-27393

Set of DNS client vulnerabilities
Part of Project Memoria’s NAME:WRECK

CVE-2020-28388

Predictable TCP ISN vulnerability
Part of Project Memoria’s NUMBER:JACK

CVE-2021-25663
CVE-2021-25664

IPv6 vulnerabilities, similar to AMNESIA:33

Table 1 – Previously known vulnerabilities on Nucleus NET
FORESCOUT RESEARCH LABS

5

RESEARCH REPORT | NUCLEUS:13 | Main Findings

2.3. Analysis and findings

We performed a deeper analysis of two
versions of the stack: incomplete sourcecode of version 4.3 (which we had analyzed
in NUMBER:JACK and NAME:WRECK); and abinary demo containing a newer version. In
those versions, we analyzed the following stackcomponents: IPv4, ICMP, TCP, UDP, DHCP
client, TFTP server and FTP server.

We performed only a manual analysis of thestack on both the source code and binary
versions. Table 2 shows the vulnerabilities that
we discovered.
As shown in Table 2, most of the vulnerabilities
allow for denial of service, while three allow
for remote code execution, a topic explored insubsequent sections of this report.

CVE ID

Description

Affected
Component

Potential
ImpactCVSSv3.1
Score

202131344

ICMP echo packets with fake IP options allow sending ICMP echo reply messages
to arbitrary hosts on the network.

ICMP

Confused
deputy5.3

202131345

The total length of an UDP payload (set in the IP header) is unchecked. This maylead to various side effects, including Information Leak and Denial-of-Service
conditions, depending on a user-defined application that runs on top of the UDP
protocol.

UDP

Applicationdependent

7.5

202131346

The total length of an ICMP payload (set in the IP header) is unchecked. This maylead to various side effects, including Information Leak and Denial-of-Service
conditions, depending on the network buffer organization in memory.

IP / ICMPInformation
leak / DoS

8.2

202131881

When processing a DHCP OFFER message, the DHCP client application does
not validate the length of the Vendor option(s), leading to Denial-of-Service
conditions.

DHCP client

DoS

7.1

202131882

The DHCP client application does not validate the length of the Domain Name
Server IP option(s) (0x06) when processing DHCP ACK packets. This may lead to
Denial-of-Service conditions.

DHCP client

DoS

6.5

202131883

When processing a DHCP ACK message, the DHCP client application does
not validate the length of the Vendor option(s), leading to Denial-of-Service
conditions.

DHCP client

DoS

7.1

202131884

The DHCP client application assumes that the data supplied with the “Hostname”
DHCP option is NULL terminated. In cases when global hostname variable is
not defined, this may lead to Out-of-Bound reads, writes and denial-of-service
conditions.

DHCP client

Applicationdependent

8.8

202131885

TFTP server application allows for reading the contents of the TFTP memory
buffer by sending malformed TFTP commands.

TFTP server

Information
leak

7.5

202131886

FTP server does not properly validate the length of the “USER” command, leading
to stack-based buffer overflows. This may result in Denial-of-Service conditions
and Remote Code Execution.

FTP server

RCE

9.8

202131887

FTP server does not properly validate the length of the “PWD/XPWD” command,
leading to stack-based buffer overflows. This may result in Denial-of-Service
conditions and Remote Code Execution.

FTP server

RCE

8.8

202131888

FTP server does not properly validate the length of the “MKD/XMKD” command,
leading to stack-based buffer overflows. This may result in Denial-of-Service
conditions and Remote Code Execution.

FTP server

RCE

8.8

202131889

Malformed TCP packets with a corrupted SACK option leads to Information Leaks
and Denial-of-Service conditions.

TCP server

DoS

7.5

202131890

The total length of an TCP payload (set in the IP header) is unchecked. This maylead to various side effects, including Information Leak and Denial-of-Service
conditions, depending on the network buffer organization in memory.

TCP server

DoS

7.5

Table 2 – Discovered vulnerabilities. Rows are colored according to the CVSS score: yellow for medium or high and red for critical.

FORESCOUT RESEARCH LABS

6RESEARCH REPORT | NUCLEUS:13 | Attack scenarios leveraging NUCLEUS:13

Siemens has released patches for all thevulnerabilities. Approximately half had alreadybeen patched in existing versions of the stack
but never issued CVE IDs.

in 2021 (after the NAME:WRECK disclosure)that listed critical vulnerable devices, suchas Siemens gas turbines, BD Alaris infusion
pumps and GE healthcare devices.

As we have seen in NAME:WRECK with CVE2016-20009 (which we independently foundon IPnet and had never been publicly reportedwith a CVE ID), vulnerabilities in TCP/IP stacks
that have been silently patched may still affectseveral devices. In the case of CVE-2016-20009(whose ID indicates original discovery year of2016), there were several advisories released

NUCLEUS:13 is the same, and in Section 6,
we discuss exploitation using one of the CVEs
that had been previously patched (CVE-202131886) but still impacted devices with current
firmware.

3. Attack Scenarios
Leveraging NUCLEUS:13
NUCLEUS:13 includes remote code execution
and denial-of-service vulnerabilities that canbe exploited by attackers to achieve different
goals based on their motivations, such as togain a foothold into a network or wreak havoc.
In this section, we discuss two examples ofattack scenarios that affect different industries
but leverage the same FTP-based exploitation(detailed in Section 6).

Research Labs has shown that other typesof IoT devices, including building automation
controllers, figure prominently among thosemost impacted by TCP/IP stack vulnerabilities
in healthcare organizations. The same holds
true for NUCLEUS:13, which impacts medical
devices, building automation devices andother types of OT and IoT devices (discussed in
Section 4).

A video showing both attacks as implemented
in our lab can be found here.

Building automation devices are used in
hospitals to control functions such as physicalaccess control, fire alarm systems, lighting
and HVAC (heating, ventilation and air
conditioning). These functions are not directly
connected to patients, but they are critical todelivering patient care.

3.1. Scenario 1: hacking the hospital

Although connected medical devices are
currently (and justifiably) the focus ofmuch cybersecurity discussion, Forescout

FORESCOUT RESEARCH LABS

7RESEARCH REPORT | NUCLEUS:13 | Attack scenarios leveraging NUCLEUS:13

HVAC systems, for instance, maintaintemperature, humidity and air quality
throughout a hospital as dictated byregulations. Changing some of theseparameters can have disastrous consequences:
reduced ventilation can increase the spreadof airborne diseases, such as COVID-19; anddrastic changes in temperature can render
operating rooms unusable or spoil biologicalsamples.

To demonstrate how an attacker could
leverage NUCLEUS:13 to disrupt the normal
functioning of a hospital’s building automation
systems, and thus impair patient care, we have
implemented in our lab the scenario shown in
Figure 1.

Figure 1 – Attack implemented in the lab

In this scenario, a motion sensor, a light bulb
and a model fan are connected to a building
automation controller. When someone
enters a patient’s room, the fan and lights
switch on automatically, and they switch off
automatically when the person leaves theroom. An attacker can crash the controller bysending a crafted FTP packet that exploits CVE2021-31886 (or any other DoS in NUCLEUS:13).
When the attack is successful, the fan
and lights stop working, thus creating anenvironment where patient care is hindered.

FORESCOUT RESEARCH LABS

Since the exploited vulnerability allows forcode execution (discussed in Section 6), this
attack could be extended to allow the attacker
to change temperature setpoints, control logic
and other variables in the controller. He could
also use the compromised device to issue
malicious commands to other devices in thehospital. The main difference is that those
attacks would be highly targeted to a specificenvironment (i.e., a particular hospital with aparticular set of controllers and logic), whereas
the denial of service works against several
targets, making it an easily commoditized asset
for cyber criminals).
8

RESEARCH REPORT | NUCLEUS:13 | Attack scenarios leveraging NUCLEUS:13

3.2. Scenario 2: crashing the trains

Recently, railway infrastructure providers
around the world have been under attack,including a ransomware incident in Germany
in 2017, a DDoS attack in Denmark in 2018
and a politically motivated hack of IranianRailways systems in July 2021. What these
attacks have in common is that they impacted
the IT systems of the targeted organizations,
not their operational technology. However,as Check Point researchers mentioned intheir analysis: “the extent and sophisticationof attacks in general is still a fraction of its
complete potential; oftentimes, threat actors
don’t do X, Y, Z even though they perfectly well
could.”
Railways and trains are increasingly
automated, with grades of automation that
include driverless train operation (DTO)

in which operation is automated and an
attendant remains on board in case of
emergencies, and unattended train operation(UTO) whereby operation is fully automatedwithout any on-board staff.
The devices affected by NUCLEUS:13 are
not used only for healthcare and building
automation. For example, the WAGO
controllers which we exploited (see Section 6)
are also part of railway infrastructure, anythingfrom station automation to train maintenanceand track signaling.
To demonstrate how an attacker could
leverage NUCLEUS:13 to disrupt the normal
functioning of an automated train system, andthus create the potential for major collisions,
we have implemented in our lab the scenario
shown in Figure 2.

Figure 2 – Attack implemented in the lab

FORESCOUT RESEARCH LABS

9

RESEARCH REPORT | NUCLEUS:13 | Impact

In this scenario, a presence sensor and a
train model are connected to an automation
controller placed at a station. When thesensor detects that the train is at the station,
it controls the train to stop for a certain periodof time, after which the train automaticallycontinues its journey. An attacker can crash

the controller by sending the same FTP packet
that exploits CVE-2021-31886 described above(or any other DoS in NUCLEUS:13). When theattack is successful, the train will not stop at
the station, and thus can collide with anothertrain, people or other objects on the track.

4. Impact
In this section, we estimate the impact of
NUCLEUS:13 based on the evidence collectedduring our research, using three main sources:• The official Nucleus website, which statesthat the RTOS is deployed in more than
three billion devices. A review of customer
success stories reveals its use in scenarios
such as healthcare (ZOLL defibrillators and
ZONARE ultrasound machines), IT (BDT AG
storage systems) and critical systems. Yet,

we believe that most of those three billion
devices are actually device components
such as baseband processors used insmartphones and other wireless devices.
We also found technical documentation
detailing the use of Nucleus for medical
devices, such as the GE S/5 AvanceAnesthesia Machine (shown in Figure 3) andthe Nihon Kohden Bedside Monitor (shownin Figure 4).

Figure 3 – Documentation of a GE S/5 Avance Anesthesia Machine showing the use of Nucleus RTOS
FORESCOUT RESEARCH LABS

10

RESEARCH REPORT | NUCLEUS:13 | Impact

Figure 4 – Documentation of a Nihon Kohden patient monitor detailing an error message caused by Nucleus• Shodan Queries. Shodan is a searchengine that allows users to look for devices
connected to the Internet. We queried
Shodan, looking for devices showing someevidence (e.g., application-layer banners)
indicating the use of Nucleus. As shown in
Figure 5 and Figure 6, with a query executedon 05/Aug/2021, we found more than
2,200 instances of devices running the
Nucleus FTP server (“220 Nucleus FTP”)
or the RTOS (“Operating System: Nucleus
PLUS”).

FORESCOUT RESEARCH LABS

Interestingly, these are the same queries weused during the NAME:WRECK research, andthey show a decrease of 13% of FTP servers
and 25% of exposed devices running the
RTOS. We believe this is a direct positive effectof NAME:WRECK, which most likely brought
increased attention to securing publicly exposed
embedded devices.

11

RESEARCH REPORT | NUCLEUS:13 | Impact

Figure 5 – Exposed devices running Nucleus FTP(“220 Nucleus FTP”)• Forescout Device Cloud. Forescout Device
Cloud is a repository of information forabout 13+ million devices monitored byForescout appliances. We queried it forsimilar banners to Shodan, as well as otherinformation, based on DHCP signatures, for

FORESCOUT RESEARCH LABS

Figure 6 – Exposed devices running Nucleus RTOS (“Operating System:
Nucleus PLUS”)

instance. We found close to 5,500 devices
from 16 vendors in place at 127 customers.
Thirteen of these customers had more than
100 vulnerable devices, with healthcare
being the most impacted sector(see Figure 7).

12

RESEARCH REPORT | NUCLEUS:13 | Impact

Figure 7 – Device functions running Nucleus (source: Forescout Device Cloud)Figure 8 – Devices running Nucleus in each vertical (source: Forescout Device Cloud)As we have done with our previous research,
we will maintain a list of advisories related

FORESCOUT RESEARCH LABS

to vendors impacted by NUCLEUS:13 on our
GitHub page.

13

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

5. Mitigation Recommendations
Complete protection against NUCLEUS:13
requires patching devices running thevulnerable versions of Nucleus. Siemens
has released its official patches, and device
vendors using this software should provide
their own updates to customers. Below, we
discuss mitigation strategies for network
operators.
Given that patching the embedded devices
is notoriously difficult (due to their missioncritical nature), we recommend the following
mitigation strategy:• Discover and inventory devices running
Nucleus. Forescout Research Labs has
released an open-source script that uses
active fingerprinting to detect devices
running Nucleus. The script is updated
constantly with new signatures to follow thelatest development of our research.

CVE

Affected Component• Enforce segmentation controls andproper network hygiene to mitigate
the risk from vulnerable devices. Restrict
external communication paths and isolate
or contain vulnerable devices in zones as a
mitigating control if they cannot be patchedor until they can be patched.
• Monitor progressive patches released
by affected device vendors and devise aremediation plan for your vulnerable asset
inventory, balancing business risk andbusiness continuity requirements.
• Monitor all network traffic for malicious
packets that try to exploit known
vulnerabilities or possible zero-days. You
should block anomalous and malformed
traffic, or at least alert its presence to
network operators.
Table 4 provides recommended mitigations foreach vulnerability.
Mitigation Recommendation

2021-31885
2021-31886
2021-31887

FTP / TFTP server

Disable FTP/TFTP if not needed, or whitelist connections.

2021-31888
2021-31881
2021-31882
2021-31883

DHCP client

Use switch-based DHCP control mechanisms: protocol-aware network switches may
be configured to block DHCP responses from rogue servers (“DHCP snooping”)1.
Alternatively, firewalls can be configured in a similar fashion. As a last resort, use static IP
addresses.

TCP / UDP / IP / ICMPMonitor traffic for malformed packets and block them. Having a vulnerable device behinda properly configured firewall should be sufficient.

2021-31884
2021-31344
2021-31345
2021-31346
2021-31889
2021-31890

Table 4 – Mitigation recommendations for specific vulnerabilities
1 See https://kb.isc.org/docs/aa-00573
FORESCOUT RESEARCH LABS

14RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

6. Technical Dive-In:
Exploiting CVE-2021-31886
There are three vulnerabilities in NUCLEUS:13
that allow for Remote Code Execution: CVE2021-31886, CVE-2021-31887 and CVE-202131888. All three vulnerabilities affect thedefault FTP server application shipped with the
Nucleus TCP/IP stack. In this section, we will
focus on CVE-2021-31886: unchecked input
size of the USER command.
At a high level, to trigger CVE-2021-31886,
attackers perform authentication attempts
on the affected FTP server, sending the FTP“USER” command with a username that islarger than the internal buffer designated tohold the input of this command (note that theactual size of this buffer may vary). Sendinga large enough username results in a stackbased buffer overflow, allowing performanceof controlled writes into the memory of
the affected device, hijacking the execution
flow and executing attackers’ code with few

FORESCOUT RESEARCH LABS

constraints. Note that the exploitation does
not require any authentication on the target,
as the vulnerability is triggered for any input of
the “USER” command that has a specific length.
The vulnerability is detailed in Section 6.1, andthe exploitation details are outlined in Sections
6.2 and 6.3.
Important note on exploitability: Some of thetechnical details of the exploitation are specificto the hardware/firmware being exploited,
including the presence of specific componentsof the affected TCP/IP stack and the absenceof exploit mitigations. Some of the details
discussed below may be specific to the chosentargets (QEMU image based on Nucleus Ready
Start for NXP i.MX28 evaluation software, and
WAGO 750-852 PLC with firmware version“01.07.21 (14)”, respectively).

15

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

6.1. Root cause analysis

The root cause of CVE-2021-31886 lies within
the FSP_Server_USER() function that parses
the FTP “USER” command (shown in Figure 9).

The code fails to ensure that the buffer
server->user that holds the suppliedusername is not overflown by the input.

Figure 9 – An excerpt from the FSP_Server_USER() function (CVE-2021-31886)

Figure 10 – Pseudocode excerpts from “FTP_SERVER”,“NU_EVENT_GROUP” and “CS_NODE” structures

FORESCOUT RESEARCH LABS

16RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

The server variable is a pointer to a variable
that holds the FTP_SERVER structure (shownin Figure 10). The server->replyBuff fieldholds the contents of the input buffer (inthis case, the entire “USER” command). In
our case, the contents of server->replyBuff
are expected to be of the following format:“USER\x20username\x0d\x0a\x00”, where
the command “USER” is followed by a spacecharacter (0x20), the “\r\n” characters and anull terminator (0x00) that signifies the end of
the input string.
The username is then copied fromserver->replyBuff into server->user (lines
21-24 in Figure 9). This code will copy asequence of characters (up to 250) until thefirst occurrence of the ‘\r’ character (0x0d or
13 in ASCII). It will finally add a null-terminatorto server->user (line 26 of Figure 9). Note, thatserver->user is, in fact, only 32-bytes long (seeFigure 10).
At line 7 of Figure 9, the code checks whether
the input string server->replyBuff is notlarger than 38 characters, using the strlen()2“USER”, one space character, 31 charactersof username and the two “\r\n” characters.
However, if we place a null-terminator in anarbitrary place within server->replyBuff suchthat strlen() returns a value less than 38, we
can still copy a longer string into server->user,
provided that we place the “\r” character at adesired offset.
In this way, we can overflow server->user, theremaining fields of the FTP_SERVER structure
as well as some local variables and themetadata of a stack frame, where FTP_SERVER
is declared (server happens to be a pointer toa local variable declared in the Control_Task()function). In essence, this is a stack-based
buffer overflow vulnerability.
6.2. Exploiting a QEMU image

In this Section, we describe the exploitation
details, based on a QEMU image built for
Nucleus Ready Start for NXP i.MX28 evaluation
software. We also managed to exploit thisvulnerability on a WAGO 750-852 PLC, which is
explained in Section 6.3.

function. The expected contents of this buffer
are as follows: four characters for the string2

strlen() returns the length of a byte sequence until the first 0x00 byte is encountered.

FORESCOUT RESEARCH LABS

17

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

The exploitation strategy involved thefollowing steps:
1. Patch the address of the input buffer (e.g.,
the buffer that stores the “USER” command),so that it points to a different memory
location: This allows the attacker to have
longer shellcode (we can upload only
218 bytes of shellcode at a time). This also
helps to avoid overwriting the shellcode(e.g., by buffer deallocation and other
FTP commands).
2. Prepare the shellcode and upload it to adesired location within the memory.
3. Redirect the execution flow to the shellcode.

Figure 11 shows a pseudocode excerpt fromthe Control_Task() function, which is an
RTOS task that is responsible for handling FTP
sessions. This function contains important local
variables: FTP_SERVER server that contains afield user, which we intend to overflow; andCHAR *buffer, which is a pointer to the bufferthat contains the raw user input (it will be later
copied into server->replyBuff).

Figure 11 – An excerpt from the Control_Task() function

FORESCOUT RESEARCH LABS

18

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

At this point, we can construct such inputthat will overflow the server->user field,
overwriting the fields of server past theserver->user field, as well as the local
variables in Control_Task() past server.
We could also overwrite the return addressof Control_Task() at this point and hijack
the execution flow. However, we incur two
problems: (1) we still need to store ourshellcode in some unused memory region
where more space is available; (2) since
Control_Task() is an RTOS task3, it runs in an
infinite loop and will not return as a traditional
C function; therefore, overwriting the return
address will at best cause a Denial-of-Service
under certain conditions but will not allow us
to hijack the execution flow in a useful way.

Figure 12 – A chosen memory location for the shellcode

Our first goal is to find an executable regionof memory to store the shellcode. For thispurpose, we have chosen the address
0x000b22bc located in the .bss segment (thismemory segment happens to be marked

as writable in our case). Figure 12 shows an
excerpt from this segment. It contains several
static variables which are not used in thecontext of the FTP server and therefore is agood location for our shellcode.

Figure 13 – The span_process_packet callback
3

Have a look at this blog post from CircuitsToday.com for a short overview of RTOS concepts.

FORESCOUT RESEARCH LABS

19

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

Since we cannot easily overwrite the return
address of Control_Task(), we must resort
to other means for redirecting the execution.
We have found several function pointersdeclared in the .bss memory segment. Oneof them is called span_process_packet and it
is set to zero by default. Figure 13 shows that
span_process_packet is a callback pointer,and if the pointer contains a non-zero address(it is supposed to be a function address), thiscallback will be triggered when a particular LLC
frame is received. Therefore, if we overwrite
the span_process_packet pointer with theaddress of our shellcode and send the LLC
frame4 that meets the right conditions, theshellcode will be executed.
To achieve this, we establish our first FTP
session with the target device and send a
malformed USER command with thefollowing bytes:

The payload contains the following bytes:• The address of the shellcode (0x000b22c4,• The “USER” command followed by a space
big endian), the address of the span_character (0x20)
process_packet pointer (0x00b14f8, big• Several dummy bytes that overflow the field
endian)server->user. Note that we have also placed When the field server->user is overwritten, wea null-terminator (0x00) in the middle ofwill write the two addresses into the first eightthe input, so that the input length checks
bytes of the server->FTP_Events field (see(shown on Figure 9) will be circumvented.
Figure 10; the addresses are marked in red
and green):

4

A Logical-Link Control (LLC) frame with the bytes 0x0026 or 0x0007 set in place of the ETHERTYPE/LENGTH field (bytes 13 and 14)of the Ethernet header

FORESCOUT RESEARCH LABS

20

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

These addresses will, essentially, be written
into the fields of the ev_created variableenclosed into server->FTP_events.

After these addresses are written, we close
the FTP session by sending a TCP RST packet.
When the session is closed, Control_Task() will
eventually call the NU_Remove_From_List()function (shown in Figure 14). This function willremove the current FTP event node from the
FTP event list (lines 9-10).

At this time, the pointers node->cs_previous
and node->cs_next are the same as server>FTP_Events->ev_created->cs_previous andserver->FTP_Events->ev_created->cs_next,
and they point to the desired shellcode address
and the address of span_process_packet
pointer, respectively. After the code on line 10 is
executed, we overwrite the value of the span_
process_packet pointer with our shellcode
address, which means that now this callback
is initialized, and whenever it is invoked, theshellcode will be executed.

Figure 14 – The NU_Remove_From_List() function

Next, we establish a new FTP session andattempt to patch the buffer pointer and towrite our shellcode at the desired location. To
patch the address of buffer, we use the same
technique as before. As buffer lies at the offset

FORESCOUT RESEARCH LABS

of 52 bytes from the end of server->user, we
simply construct an FTP user command that
contains the new address of buffer at therequired offset.

21

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

Note that after the USER command is handled
and the execution returns to Control_Task(),

buffer points to the address that we now
control:

Note that this time, we are supplying theaddress 0x000b22bc, which is different fromthe shellcode address 0x00b22c4 that we set
during the previous step. This is because weare patching the raw input buffer. Apart fromthe user-supplied contents, it will include theentire FTP command that starts with “USER\
x20”. Therefore, we will structure our input as“USER\x20\x00\x00\x00[shellcode]” and skip thefirst eight bytes to jump directly at the first
byte of the shellcode.

It is important that, at this time, we do not
close the current FTP session. Otherwise,
Control_Task() will allocate a new input buffer
pointer, and all the work we have done so far
will be lost. Therefore, to supply the shellcode,
we immediately follow with another USER
command that will be written into the memory
starting at address 0x000b22bc. This time, it
contains the following shellcode:

FORESCOUT RESEARCH LABS

22RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

Finally, we send an LLC frame that meets therequirements for triggering the span_process_packet callback, and the shellcode gets

executed. In this case, our shellcode simply
prints a line to the serial console of
the QEMU VM.

6.3.

because of the size limitations that constrain
stage 0. To do so, we needed to makestage 0 patch another function pointer ppe_
process_packet to point at a location which
we dynamically allocated. Whenever stage
0 gets triggered again, it will copy shellcode
fragments which we sent within the LLC frame
to be reassembled at the location pointed at by
ppe_process_packet. This pointer is anothercallback (similar to span_process_packet)
which is called at the function EightZeroTwo, as
follows:

Exploiting a WAGO 750-852

The exploitation of CVE-2021-31886 in the
WAGO 750-852 PLC is similar to the QEMU
image exploitation. That is, we overflow theserver structure to have our shellcode residing
at a stable location pointed to by the buffer
variable and calling it afterwards througha patched span_process_packet function
pointer.
After having a first payload running throughspan_process_packet (called “stage 0”), we
aimed at loading a second payload (“stage 1”)

FORESCOUT RESEARCH LABS

23

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

The stage 0 shellcode is illustrated in
Figure 15. It allocates the memory forstage 1 shellcode on lines 34-39. Wheneverstage 0 gets executed, it copies the fragmentsof stage 1 shellcode in the right order and into
a designated memory location (lines 66-72).

FORESCOUT RESEARCH LABS

Once the entire stage 1 shellcode is copied andis in good order (ensured by the checksum),
we patch the ppe_process_packet pointer topoint at the beginning of stage 1 shellcode(lines 53-64).

24

RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

Figure 15 – stage 0 shellcode

FORESCOUT RESEARCH LABS

25RESEARCH REPORT | NUCLEUS:13 | Mitigation Recommendations

TECHNICAL DIVE-IN

When this is done, we trigger the ppe_process_packet callback by sending a crafted Point-toPoint Protocol over Ethernet (PPOE) frame.
The stage 1 shellcode accesses the filesystemof the WAGO PLC, changing the HTML codeof a particular page used in the embedded
webserver. The effect of this change is shownin Figure 16 (normal operation) and Figure 17(after exploiting CVE-2021-31886).

Figure 16 – Web page as it appears normally in WAGO 750-852

Figure 17 – A defaced web page in WAGO 750-852

FORESCOUT RESEARCH LABS

26RESEARCH REPORT | NUCLEUS:13 | Conclusion

7. Conclusions
In this report, we discussed NUCLEUS:13, a setof 13 vulnerabilities affecting the Nucleus TCP/
IP stack, currently owned by Siemens and usedin billions of devices. The vulnerabilities include
three RCEs, which we managed to exploit in
our labs as discussed in Section 3. We saw
evidence of the stack running in industrial
controllers, building automation equipment,
and medical devices.
We strongly believe that the threat landscapefor every type of connected device is changing
fast, with an ever-increasing number of severe
vulnerabilities and attackers being motivated

FORESCOUT RESEARCH LABS

by financial gains more than ever. This isespecially true for operational technology andthe Internet of Things. The expanded adoptionof these types of technology by every type oforganization, and their deep integration into
critical business operations, will only increase
their value for attackers over the long term.
With this context in mind, Forescout ResearchLabs and Medigate Labs look forward toanalyzing additional software and devices,
driving opportunities for better industry
collaboration and continuing to help secure
the Enterprise of Things.

27