Cinterion EHS5 3G UMTS/HSPA Module Research

Modems play an important role in enabling connectivity for a wide range of devices. This includes not only traditional mobile devices and household appliances, but also telecommunication systems in vehicles, ATMs and Automated Process Control Systems (APCS).

When integrating the modem, many product developers do not think of protecting their device from a potential modem compromise. As one of the main communication channels for the end device, the modem not only has access to the information flow between the device and the outside world, but also may have almost unlimited access to the most critical systems and resources of the end device. Thus, modem security is a significant matter.

To make the problem worse, when a critical vulnerability is discovered in just one modem model and version, significant time may be required to update all the devices in which it is installed. And some of them may even not have a remote modem updating feature at all, such as a car’s Telematic Control Unit (TCU). In such cases, installing the update typically requires additional effort and expense for the manufacturer of the end product to manually address each vulnerable device or vehicle.

For this reason, a particular modem manufactured by Telit Cinterion caught our interest. We decided to perform the security analysis of the modem in course of a bigger project of analyzing security of a popular model of a truck. When we began our assessment, the only known registered vulnerability was CVE-2020-15858, which is described in greater detail elsewhere.

The study focused on the EHS5-E series modem, originally manufactured by Thales before the business unit was acquired by Telit. Several modem models from this vendor share similar software and hardware architectures. Therefore, the findings of this study apply to devices across multiple model series:

• Cinterion BGS5;
• Cinterion EHS5/6/7;
• Cinterion PDS5/6/8;
• Cinterion ELS61/81;
• Cinterion PLS62.

Modem software components

According to the software model, the modem consists of four software components:

• Firmware (FW);
• Application (App);
• Java Remote Control (JRC);
• Service LWM2M Agent (SLAE).

The modem comes along with an SDK for creating software components that execute business logic, known as MIDlets. The firmware (FW) and application (App) components form part of the modem’s low-level code, which includes the operating system and the execution environment for the MIDlets. A MIDlet is a Java application supported by a specialized subsystem, Java ME (Micro Edition), which features a limited set of Java commands. The JRC and SLAE components are special MIDlets developed by the manufacturer.

It is possible to install MIDlets and to configure the security settings for their execution. The following security mechanisms are used for MIDlets:

• Java bytecode checks during installation (always enabled);
• MIDlet digital signatures (configured by the end product developer).

By default, only the manufacturer’s certificate is installed on the modem to validate MIDlets with manufacturer-level execution privileges. Installing and configuring certificates for custom MIDlets is the responsibility of the end product developer. This is described in more detail in the EHSx Java User’s Guide.

Types of MIDlets

Based on our analysis, all MIDlets on the modem can be divided into two categories by their privilege level:

• Manufacturer MIDlets;
• User MIDlets (signed / unsigned).

Only the JRC and SLAE MIDlets initially belong to the manufacturer level. They have the highest privileges without any code execution restrictions at the Java level.

The second category of privileges is granted to user MIDlets. Their functionality is restricted in relation to file system (FS) operations, GSM module operations, etc. For example, a user MIDlet cannot read the entire modem FS, but the JRC module can.

If a user certificate is installed, only a signed user MIDlet with User Signed privileges will be executed on the modem. In other words, User Signed MIDlets are only used to protect the modem from executing a MIDlet from an illegitimate user, such as an attacker or security researcher.

MIDlet installation

MIDlets can be installed both locally and remotely. Local installation of MIDlets is done through the JRC component. Remote installation is possible via a special OTAP mechanism, or in M2M scenarios, via the SLAE component.

Using the modem in an M2M scenario involves creating a personal user account on the manufacturer’s website. This personal account allows the user to perform standard actions with MIDlets on all paired devices, such as installing and uninstalling MIDlets. In our study, we did not analyze the mechanisms of remote M2M installation of MIDlets.

Local installation via MES

Local installation is performed via the MES (Module Exchange Suite) communication protocol and special AT commands. The interface itself and AT command processing are implemented in the JRC component. The MES protocol enables interaction with the modem’s user FS (hereinafter referred to as the “UFS”), including writing to or deleting files from the UFS.

Upon installing the driver provided with the SDK, the content of the modem’s UFS, which is mounted at the path ‘///a:/’, becomes accessible. The driver functions as a user add-on over the MES protocol. Although MES formally supports working with any path value except for ‘///a:/’, no other internal paths are known, and attempts to read paths starting with a different root result in an error. This is due to the filtering of query parameters in MES, ensuring that everything not belonging to the ‘a://’ root returns an error, even though the UFS has several valid roots.

Local installation of MIDlets is performed in two steps. First, the MIDlet files (.jar and .jad) must be copied to the modem UFS. Next, the MIDlet is installed on the modem using the AT^SJAM=0 AT command. During the execution of this command, the MIDlet files are copied to a part of the modem FS that is inaccessible to the user and are then removed from the UFS. The path to which MIDlets are copied during installation is unknown. This helps ensure the confidentiality of both user and manufacturer MIDlets. An installed MIDlet is launched from its new location in the modem FS. A list of all installed MIDlets can also be extracted using the AT^SJAM command. The image below shows an example of the output of this command.

Example output of the AT^SJAM command

The modem documentation states that the javax.microedition.io.file.File.FileConnection connector used to work with the FS filters requests to files with the .jar extension.

Snippet from the Cinterion documentation

This behavior was confirmed by a simple test: trying to access files with the .jar extension produced an error.

Attempting to access files with the .jar extension

Remote installation via OTAP

In the OTAP protocol, data is transmitted using SMS messages that have special values for the Class and PID fields.

Data transfer in OTAP protocol

OTAP messages are ASCII text contained within the SMS message body. An example of such a message is shown below.

Example of an OTAP message

OTAP support is provided by the App and JRC components. The process of installing and updating user MIDlets via OTAP requires prior activation of OTAP by the user on the modem. The user may specify additional attributes that will be used for OTAP: JAD File URL, HTTP User, HTTP Password, etc. The process of updating via OTAP is described in detail in the EHSx Java User’s Guide.

If OTAP was not activated beforehand by executing the AT^SJOTAP command, then the received message would not be processed. Activation involves creating a special OTAP settings file OTAP_AtParams.bin in the UFS.

OTAP activation check

Part of the file’s contents created during our tests is shown below.

Example of OTAP_AtParams.bin file contents

Debugging MIDlets and modem execution

According to the modem’s official documentation, several interfaces are available to interact with the modem, as shown below.

Available modem interfaces

From a security researcher’s perspective, a few of the hardware interfaces listed above are of a special interest, specifically ASC0/ASC1 and USB, since they can be used to transmit data between the modem and a host (e.g. PC) through the UART protocol. In the case of USB, the UART interface is emulated.

According to the vendor’s documentation, the UART can be used to communicate with the modem via the AT command interface or to perform step-by-step debugging of an executable MIDlet running on the modem. This is done using the MIDlet debugging subsystem. Interaction with the modem in debug mode takes place through a special PPP connection (dial-up modem emulation). The debugging mechanism is described in detail in the manufacturer’s documentation. The USB interface exposes additional functions in addition to the emulated UART interface, such as the MES interface, which can be used to access the modem’s User File System (UFS) though standard Windows OS mechanisms.

In addition to debugging MIDlets, the modem allows collection of the trace logs of its subsystems, including MIDlets. The AT+TRACE command determines what gets included in the output. An example of a command to enable output of debugging information on the modem is shown below.

The command parameters determine which modem subsystems to collect information from. The list of subsystems from which debugging information can be collected is available in the detailed help for this AT command.

Detailed help output of the AT+TRACE command

Obtaining the modem firmware

We focused on analyzing both MIDlet and OS security. To achieve this, we developed a research device based on a custom printed circuit board.

Research device

After analyzing the modem’s hardware components, we identified a NAND memory chip that contains the modem firmware. The firmware was extracted from the chip using the ChipProg universal programmer.

Hardware components of the modem

There is an additional challenge involved in extracting meaningful data from NAND memory due to its physical structure and wear-leveling algorithms. The data is stored together with the “Spare Area” – special blocks containing error correction codes and other auxiliary information. In addition, a bitwise XOR with a special gamma function may be applied to data to ensure even wear of the memory cells. Refer to the full version of the whitepaper (PDF, 9 MB) for the details regarding the process of reconstructing the NAND flash image.

Thanks to the NAND reconstruction, we were able to identify the UFS and examine its contents. We also succeeded in finding the binary images corresponding to the FW and App software components.

FAT FS

Analyzing the UFS contents

After reviewing the contents of the UFS, we found that it contained files and folders hidden from the user and inaccessible through the MES interface, namely .cinterion.internal and .cinterion.service. Access to them was restricted directly in the JRC MIDlet code, filtered by their name prefix. A code snippet from the JRC module that filters access to these folders is shown below.

Example code from the JRC module

By further examining the contents of these hidden directories, we determined that all MIDlets (both of user and manufacturer categories) are stored at /sys/.cinterion.internal/java. Each MIDlet is stored as a set of four files with .ss, .ii, .ap and .jar extensions.

After analyzing the contents of the folder containing installed MIDlets, we determined that each MIDlet is renamed during the installation process. To allow the user to run MIDlets by their name, the system keeps the mapping between the original name of the MIDlet and its alias in a simple database stored in the _suites.dat file. For example, by analyzing the binary contents of this file, it is clear that the file named 00000003.jar is actually JRC.jar.

Contents of the binary file _suites.dat

The .ap file is a Unicode-converted .jad file. This file contains information about the original name of the MIDlet and the libraries that were used. It may also contain the MIDlet’s digital signature. An example of such a file for a JRC MIDlet is shown below.

Contents of the .ap file for the JRC MIDlet

The .ii file contains information about the MIDlet installation path, the permissions assigned during installation, and other information.

Contents of a file with the .ii extension

Finally, the .ss file contains a description of the Java-level permissions available to this MIDlet. An example of the JRC vendor MIDlet permissions description is shown below.

Example of a JRC vendor MIDlet permissions description

It is important to note that this permission set gives unrestricted access to the Java virtual machine’s system classes. The example shown corresponds to the manufacturer level of privileges. Only two MIDlets have such permissions: JRC and SLAE. Any user MIDlet must list in its manifest the classes and methods it needs to access to at runtime. Part of the manifest for our test MIDlet is shown below.

Example manifest for our test MIDlet

Changing the security domain of a user MIDlet

As mentioned earlier, each installed MIDlet is stored in the modem FS as a set of four files under the path /sys/.cinterion.internal/java. When a MIDlet is started, its security domain is checked using the .ii file. Then, depending on the specified domain, access rights are assigned based on the .ss file. Quite important thing is that there is no verification of the digital signature when launching a MIDlet that has the manufacturer-level security domain.

Since any user MIDlet can use the aforementioned javax.microedition.io.file.FileConnection Java class, the MIDlet’s security permissions and security level can be escalated. A user MIDlet can replace its own .ii and .ss files so that it will start executing in the manufacturer security domain.

Running our MIDlet for the first time

Running our MIDlet for the second time

ULP protocol analysis

In addition to the ability to remotely provision and control MIDlets via SMS messages using the OTAP protocol, the modem offers geopositioning feature using SUPL (Secure User Plane Location) subsystem. This subsystem implements the SUPL specification, which facilitates the exchange of special messages between H-SLP (Home SUPL Location Platform) and SET (SUPL Enabled Terminal). The modem itself is a SET object under the specification. An example of such an exchange is shown below.

Interaction via the ULP protocol

Messages are exchanged using the ULP (User-plane Location Protocol) binary protocol. In this protocol, data is transmitted in the GSM network via PUSH messages using the WAP protocol stack. A typical ULP message is illustrated by the SUPL INIT message.

SUPL INIT message

The ULP protocol supports the ability to fragment the transmitted message allowing transmission of large binary messages via SMS at the PUSH layer of WSP messages. On the SET side, the WSP protocol provides indexing for the fragmented SMS message transmission. The first SUPL message contains the total size of the message to be received, whereas subsequent messages contain data fragments to be concatenated. An example of the structure of these SMS messages is shown below.

Example of the first SMS message

Example of subsequent SMS messages

During our analysis of the driver responsible for handling of ULP message fragmentation, we discovered a heap overflow vulnerability.

According to the transmission protocol, the ULPSizeFromPacket (size of the entire ULP packet) and wapTpduLen (size of the received WAP message) variables are calculated independently. That means a received WAP packet of size wapTpduLen will be unconditionally copied to a buffer whose size is ULPSizeFromPacket bytes. This is a classic example of a heap-based buffer overflow.

Heap-based buffer overflow

After crafting an appropriate SMS message, we managed to generate a heap overflow error, resulting in a hard fault and rebooting the modem. To learn the cause of the reboot, we used the previously mentioned AT+XLOG command.

Reason for the reboot

The resulting dump made clear that the R0 register contained data that we controlled. Thus, we confirmed our ability to not only overflow the heap, but also embed our data into executable code.

However, we had no way to get a dump of memory at the moment of the crash. To understand whether the discovered vulnerability is serious or just another non-exploitable BoF, we had to solve the problems of reading/writing the RAM, code execution, and OTAP activation. For details, please refer to the full white paper.

After overcoming many technical difficulties, which are described in detail in the full version of the article, by sending just a few specially-crafted SMS messages, we were able to launch the driver we developed on the modem OS, allowing us to:

• Allocate memory (malloc);
• Release memory (free);
• Open / create a file in the UFS (createFile).

Using this driver, we managed to create the files needed for OTAP activation, install our own MIDlet on the modem, and assign it maximum manufacturer privileges.

Installing our own MIDlet

Conclusion

Though being a special-purpose device, a modern modem implements numerous features and potential user scenarios. In fact, it is a complicated system, both from an architecture and implementation point of view. Due to performance requirements, most of the key features are implemented in low-level languages such as С and Assembler and therefore lack built-in safeguards mitigating potential developers’ mistakes.

In the course of the modem security analysis, we found seven locally exploited vulnerabilities and one remotely exploited vulnerability. The combination of these vulnerabilities could allow an attacker to completely get control over the modem. In our truck’s security audit project, having control of the modem we were able to get our foothold in the telecommunication unit embedding it, and further, to propagate to other truck ECUs ending with getting control over the main vehicle systems, such as the engine, the gearbox, the suspension, the breaks, etc., therefore being able to totally compromise the vehicle safety from remote.

All discovered vulnerabilities have been reported to the vendor. Some of them have not been addressed by the vendor so far as the product support discontinued. And even if the vendor fixed all the vulnerabilities, as we stated at the beginning of the report, in some cases, the modem is integrated in such a way that applying updates would be difficult.

Thus, to counter the threats posed by the found vulnerabilities, Kaspersky recommends:

• Contact the mobile operator to disable the sending of SMS messages to the device.
• Use private APN with carefully configured security settings to limit the impact of any potential exploit.
• Enforce application signature verification to prohibit the installation of untrusted MIDlets on the device.
• Control physical access to the device at all stages of supplying to protect against the embedding of backdoors.
• When developing a new product consider remote modem compromise as a high potential risk and restrict accordingly access from the modem (or the unit embedding it) to other products’ mission-critical components.

As for the vendors of the modems and similar devices, to mitigate potential risks at the design stage, Kaspersky recommends:

• Introduce additional memory access restrictions in the ThreadX operating system, such as using the MCU or Modules
• Use static code analysis tools to determine if there are any errors in logic or pointer arithmetic.
• Perform fuzz testing (“fuzzing”) for the application to find implementation bugs using malformed/semi-malformed data injection in an automated fashion.
• Perform code walk-through audits to look for confusing logic and other errors.
• Select the development tool stack enforcing security domain separation and promoting a Secure by Design approach such as the one advocated by the Kaspersky OS developers.