Vulnerability within the UNISOC baseband opens mobile phones communications to remote hacker attacks

Introduction

Do you remember push-button telephones? Many of them were based on chips from Spreadtrum Communications Inc., a Chinese chip manufacturer founded in 2001. In 2011, over half of all phones in China were powered by Spreadtrum chips.

In 2018, Spreadtrum rebranded itself as UNISOC. Today, the manufacturer produces budget chipsets that power 2/3/4/5G devices ranging from smartphones to smart TVs. UNISOC is extremely popular in Africa and Asia due to their low prices. By the end of 2021, UNISOC was firmly in fourth place among the largest smartphone chip manufacturers in the world (after MediaTek, Qualcomm and Apple), with 11% of the global market.

Despite the fact that UNISOC has been on the market for a long time, the UNISOC chip firmware used in Android mobile phones, including the radio modem (baseband), has not been studied extensively. There are no references for any UNISOC baseband vulnerabilities on the Internet.

However, the smartphone modem is a prime target for hackers as it can be easily reached remotely through SMS or radio packet.

In this study, CPR did a quick analysis of the UNISOC baseband to find a way to remotely attack UNISOC devices. We reverse-engineered the implementation of the LTE protocol stack and discovered a vulnerability that could be used to deny modem services and block communications.

LTE background

Where is the smartphone modem in the LTE network?

The Long-Term Evolution (LTE) network consists of a dozen components and protocols. You can easily find a detailed description of the LTE standard on the Internet. Let’s take a look at some basic concepts to understand the UNISOC modem side.

The 3GPP Telecommunication Standards Group introduced the concept of the evolved packet system (EPS), which is a high-level architecture of the LTE technology. Such architecture is comprised of three key components: the user equipment (UE), the evolved UMTS terrestrial radio access network (E-UTRAN), and the evolved packet core (EPC), which are all interconnected.

Figure 1: EPS architecture of the LTE network.

The E-UTRAN component has only one stack, the eNodeB station, which controls the radio communications between the UE and the EPC. A UE can be connected to one eNodeB at a time.

The EPC component is made of four stacks, one of which is the mobility management entity (MME). The MME controls the high-level operations of mobile devices in the LTE network. It sends signaling messages related to security control, tracks area management, and maintains mobility between the different 3GPP access networks, and EPS bearer management.

For us, the UE is a smartphone with the UNISOC modem. In our research, we focused on the messaging between the MME stack and the UE stack that occurs through the EPS session management (ESM) and the EPS mobility management (EMM) protocols.

In Figure 2, you can see the modem protocol stack. The non-access stratum (NAS) level hosts EPS and EMM signaling messages.

Figure 2: LTE protocol stacks.

The NAS protocol operates with high-level structures. Therefore, it does not take much effort for an attacker to create a malformed EMM packet and send it to a target device. When a new NAS message arrives, the UNISOC modem parses it and creates internal objects based on the received data. A bug in the parsing code can be used by the attacker to remotely crash the modem, which could lead to Denial of Service (DoS) or Remote Code Execution (RCE).

Messaging between the modem and the MME

You can find the full technical specification of the NAS protocol in the 3GPP TS 24.301 document. For an idea of the protocol, let’s take a look at the procedure to add a device to the LTE network. It covers the most common EMM messages. In Figure 3, you can see a snippet of NAS traffic when a smartphone attaches to the LTE network.

Figure 3: Network attach flow.

In the example, the modem’s IP is 10.90.10.1 and the MME’s IP is 10.201.150.41. The communication flow follows the scheme in Figure 4.

Figure 4: Message exchange scheme.

As you can see, when a device attaches to a LTE network, the MME server takes care of the device authentication, establishing the bearer, and more. To connect to the network, the smartphone modem must support (provide handlers for) dozens of NAS messages. We want to analyze these handlers for errors.

Before we explore the implementation of the NAS message handlers in the UNISOC modem, we will take a look at these handlers in a popular open-source LTE project such as srsRAN, because it is easier to deal with source code than with disassembly. The UE stack has not changed for a long time and all its implementations are very similar to each other. In addition, some of the NAS handler functions implemented in the srsRAN project are vulnerable, and these vulnerabilities could theoretically be replicated in the smartphone modem.

Open-source UE stack

The srsRAN is the most popular open-source implementation of EPS components, including the UE stack we are interested in. The srsue/src/stack/upper/nas.cc module represents the NAS level. There you can find functions that handle NAS messages.

Each handler function receives the message in the form of a data blob that needs to be parsed into internal structures before the system can react to it. The parsing functions are implemented in the lib/src/asn1/liblte_mme.cc module.

In Figure 5, you can see an example of the ATTACH_ACCEPT EMM message. This message contains a list of tracking area identifiers, a GPRS timer, an ESM message container, and a dozen optional objects such as mobile identity, emergency numbers, protocol configuration options, etc.

Figure 5: Attach accept message.

Therefore, we have a large amount of miscellaneous information that must be deserialized. The liblte_mme.cc module contains a separate unpacking (parsing) function for each content type. The UNISOC modem code has similar functions.

The ATTACH_ACCEPT message handler of the srsRAN project has several vulnerabilities. Let’s take a look at one of them as an example.

The liblte_mme_unpack_emergency_number_list_ie function extracts emergency numbers from the message data.

The maximum length of the emergency list is 12. However, the check that the idx value is less than 12 was omitted. The MME can set the sent_length value large enough to cause more than 12 cycles of the while loop and thus overwrite the emerg_num_list->emerg_num array with arbitrary values. This issue leads to stack overflow.

A similar vulnerability exists in the liblte_mme_unpack_protocol_config_options_ie function, which parses the protocol configuration options used to pass additional information about the network. The maximum number of the supported options is 83, but there is no check that the number of options sent by the MME does not exceed this maximum. Overflowing the options array results in stack overflow.

We know what the NAS message parsing functions are, and we also have a code for references. Now we need to find the NAS data parsing functions in the UNISOC modem firmware.

UNISOC modem firmware

In our research, we used the Motorola Moto G20 (XT2128-2) with the Android January 2022 update (RTAS31.68.29) as a test device. The device is based on the UNISOC T700 chip.

The Moto G20 factory update can be downloaded from the Internet, which eliminates the need to root the device. In the update file, the modem firmware is represented by the SC9600_sharkl5pro_pubcp_modem.dat image.

The image has a proprietary structure, but it can easily be reconstructed. It starts with a magic, followed by data block headers. The block header has the following structure:

The offset value is the offset in bytes of the beginning of the block in the image file, and the length is the block size.

In Figure 6, you see that the modem image of our test device contains two data blocks. The first block is of type 0x402, which presumably means “parsing library”. The second block is of type 0x301, which is the modem binary.

Figure 6: Modem image header.

We can easily cut both data blocks from the image. The parsing library block is a 7-zip archive that contains libraries for testing (parsing and tracing) network messaging from an external machine. For example, the lteps_air_msg_dll.dll library (compiled for x86) implements functions for packing and unpacking NAS messages.

The modem binary block is a file with a proprietary format. The header size is 0x600 bytes. After the header, the modem code (ARM instructions) begins. We wrapped this code with an ELF32 header, and specified 0x8B000600 as the base address of the code segment. In addition, we added an empty data segment starting at 0x8D0C0000. The resulting binary can be easily decompiled.

Log messages implemented in the modem firmware contain the name of the current source module. This gives us the ability to quickly find the NAS message handlers. The NAS related module names start with “lnas_air_msg”. For example, the PS/stack/nas/emm/msg_codec/msg_emm/lnas_air_msg_emm_att_acc.c module parses the ATTACH_ACCEPT message.

Looking for vulnerabilities in the NAS handlers

The vast majority of NAS message parsers have three arguments: an output buffer, which is an object of the appropriate message structure, the NAS message data blob to decode, and the current offset in the message blob. The unified function format allows us to easily implement the harness to fuzz the NAS parsing functions. In our research, we used the classic combination of AFL and QEMU to fuzz the modem binary on a PC. We patched the modem binary to redirect malloc calls to the libc equivalent. The fuzzer permuted the NAS message data and passed it as an input buffer to the parsing function.

One of the optional ATTACH_ACCEPT fields is the mobile identity. The modem firmware implements an unpacking function like the liblte_mme_unpack_mobile_id_ie from the srsRAN to extract the mobile identity from the NAS message. The identity data block begins with the length of the identity. If the device is represented by an International mobile subscriber identity (IMSI), length-2 bytes of the message data are copied to the output buffer as the IMSI number.

The check to make sure that the provided length value is greater than one is omitted. Therefore, if the length field value is zero, 0-2 = 0xFFFFFFFE bytes are copied from the NAS message to the heap memory, which leads to DoS.

In Figure 7, you can see the ATTACH_ACCEPT message, which causes the overflow.

Figure 7: Malformed NAS message.

The highlighted 0x23 value indicates that the following data is the message identity block, where the first 0x01 is the length and the second 0x01 is the IMSI type.

UNISOC assigned the CVE-2022-20210 to this vulnerability. In addition, we found several out-of-bound read issues when the NAS handler functions read data from outside the NAS message.

Summary

In this study, we looked at the UNISOC baseband as an attack target for the first time. We scanned NAS message handlers within a short period of time and found a vulnerability which can be used to disrupt the device’s radio communication through a malformed packet. A hacker or a military unit can leverage such a vulnerability to neutralize communications in a specific location.

CPR responsibly disclosed these findings to UNISOC in May 2022, who acknowledged the vulnerability, giving it a 9.4 scoring (critical). UNISOC have since patched the CVE-2022-20210 vulnerability in May 2022.

Check Point’s customers remain fully protected against such threats while using Harmony Mobile Security.

We recommend mobile users to always update their phone’s OS to the latest version.

Google have updated that they will be publishing the patch in the upcoming Android Security bulletin.