New Architecture, New Challenges: Service Security Issues in the 5G Core Network and How to Detect Them

September 24, 2021 | Jie Ji

Abstract: 5G is the fifth-generation technology standard for mobile communication networks. The service-based architecture (SBA) of the 5G core network is designed with a cloud-native approach. By borrowing the “microservice” concept implemented in the IT field and dividing a whole entity with multiple functions into individual parts, each providing an independent function, the SBA provides the 5G core network with more flexibility. However, between elements of the 5G core network lie service security risks, similar to the case with microservice scenarios. This article briefly introduces service security issues in the 5G network and how to detect these issues.

5G, as the newest-generation mobile communication technology, is intended to provide higher speeds and capacities for communication between mobile devices. It should allow customization of network functions for specific business scenarios, for example, Internet of vehicles (IoV) scenario where low-latency transmission is required or streaming media scenario where high bandwidth is required, via the network slicing feature. For this purpose, the 5G core network is built on SBA. SBA contains different network elements (NEs), which connect to the system through interfaces. This makes services carried by the 5G core network run in finer granularities than traditional services. Besides, these services are loosely coupled with one another. That is to say, you can choose to update a service, with the minimal impact on the other services. In this manner, the core network becomes easier to configure, expand, and upgrade. Compared with the 4G network, the 5G core network promises a higher level of exposure and so is faced with many new security threats, including service security issues.

About the 5G Core Network

Figure 1 shows the 5G core network architecture defined by the 3rd Generation Partnership Project (3GPP).

Acronyms in this figure are described as follows:

AF: application function
AMF: access and mobility management function
AUSF: authentication server function
NEF: network exposure function
NRF: network repository function
NSSF: network slice selection function
PCF: policy control function
SMF: session management function
UDM: unified data management
UPF: user plane function
(R)AN: (radio) access network (base station)
UE: user equipment

5G Service Security Issues

The service-based architecture (SBA) of the 5G core network is designed with a cloud-native approach. It borrows the “microservice” concept implemented in the IT field and divides a whole entity with multiple functions into individual parts, each providing an independent function. Each NE, through the service-based interface, exposes its capability to the network as a service and has this capability reused by other NEs. Therefore, between elements of the 5G core network lie service security risks, similar to the case with microservice scenarios. In a previous article^[1], we have introduced the service security of application programming interfaces (APIs) in microservice scenarios. This article, with usage scenarios of the 5G core network in mind, describes service security issues facing NEs, including anomalies in the call logic, parameter calls, and call frequency.

Call logic anomaly

In the 5G core network, an attacker can exploit a vulnerability in an NE to compromise the NE and then initiate a request from the open interface to other NEs, resulting in an anomaly in the NE access sequence. For example, in the authentication procedure for UE registration, the AMF first initiates an authentication request to the AUSF, which then requests the UDM to generate an authentication vector. Figure 2 shows the NE access sequence of this procedure.

However, if an attacker compromises the AMF, he or she will directly call the interface of the UDM to generate an authentication vector, thus stealing the user’s authentication information. Figure 3 shows this abnormal NE access sequence.

Another example: The NRF provides the network repository function to maintain available network function (NF) instances and NF profiles of supported services. If this NE contains a vulnerability, an attacker may exploit this vulnerability to register a malicious NE and make an address and Uniform Resource Identifier (URI) point to this malicious NE. Then the attacker can use this NE to communicate with other NEs, resulting in anomalous call logic between NEs.

Parameter call anomaly

Parameters exchanged between NEs may be anomalous. This happens in either of the following cases: (1) An attacker exploits the potential vulnerability of improper parameter checks in an NE to pass an illegitimate parameter in the NE call procedure to achieve a specific purpose. (2) An attacker exploits a vulnerability in some interface to launch an attack, resulting in an error in returned parameters.

Call frequency anomaly

An attacker sends a large number of requests for access to the open interface of an NE in the 5G core network, resulting in a signaling storm, hence the unavailable service.

Detection of Service Anomalies in 5G Core Network Elements

To address security threats to the service layer of 5G core network elements, we need to employ different anomaly detection mechanisms for different scenarios like we do for API service security in the context of microservices. An example is to trace API call sequences and parameters by deploying an additional API call sequence tracing framework, such as Jaeger and Skywalking, to form normal behavior baselines. However, in usage scenarios of the 5G core network, deploying such a tracing framework is usually prohibited. Therefore, when it comes to the 5G core network, we should start from raw packets in the core network, with the characteristics of 5G services taken into account, and identify service associations from the data before developing normal behavior baselines of NEs. To cope with anomalous service logic, we should sum up normal NE access sequences from the raw data. In a live 5G environment, a large number of UE devices may initiate different requests to the core network, as shown in Figure 4. Therefore, in the procedure of developing baselines for identifying anomalous service logic, the first step is to aggregate the raw data of all UE devices.

According to 3GPP standards, in 5G scenarios, UE provides the Subscription Permanent Identifier (SUPI) parameter in the procedure of interacting with the core network, such as initiating a registration request. The SUPI uniquely identifies UE on a 5G network, like the international mobile subscriber identity (IMSI) in the Long-Term Evolution (LTE) network. First, we can aggregate all users’ requests to the core network and then put all requests of the same user together based on SUPIs. Next, we should classify such data by service. In the core network, NEs communicate with one another by using HTTP2 as the application-layer protocol, that is, in the request-response form. By associating HTTP2 streams and matching requests with responses, we can distinguish between services and then get the NE call sequence of a single service request from a UE device.

To identify anomalous service parameters, we should establish parameter value baselines based on 3GPP standards and historical data. If the current request parameters deviate from the baselines, we can infer that these parameters are anomalous.

To determine whether the service frequency is normal, we still need to establish baselines. Based on 3GPP standards and historical access data, we can use the statistical analysis method to establish access frequency baselines, against which access requests will be measured for detection of anomalies.

Example of Determining the NE Call Sequence

The preceding sections describe service anomalies in the 5G core network and how to detect such anomalies. Reproduction of anomaly scenarios can be implemented based on the open-source project free5GC. Here we provide a case of determining the NE call sequence based on packets generated in the procedure of multiple UE devices requesting registration in the free5GC environment. In such an environment, we simulate the UE registration procedure and capture packets transmitted in the procedure. Figure 5 shows the captured packets opened with Wireshark.

From packets shown in Figure 5, we can see that UE’s HTTP2 requests contain IMSI/SUCI data. The Subscription Concealed Identifier (SUCI) is the encrypted form of the SUPI. Using the method described in the previous section, we first aggregate requests based on IMSIs/SUCIs and then match requests with responses based on HTTP2 streams. Finally, we learn the relationships between NEs accessed for UE registration, as shown in Figure 6.

To directly show how NEs are called in the registration procedure, we draw a NE call sequence diagram, as shown in Figure 7.

Conclusion

Service security is a new concern in the 5G core network. Because Anomalies in 5G services are hard to detect for traditional security devices. This article briefly introduces service anomalies in the 5G network and how to detect these anomalies. In practice, more user data such as billing data and slice information can be introduced, to establish finer-grained baselines to support service anomaly detection.

References