Vulnerabilities in Cellular Packet Cores Part IV: Authentication
Cellular devices like cell phones and cellular IoT devices connect to a radio base station via RF (Radio Frequency) signals. The base station then converts these RF signals into IP packets. The base stations are connected to a central infrastructure unit, called the packet-core, over IP links. These backhaul IP links are usually wired.
Cellular network architecture is divided into two planes: the control plane and the data plane. The control plane handles signaling between user equipment (UE) and the packet core, managing tasks such as initial UE attachment, authentication, data session setup, etc. The data plane (user plane) deals with user application traffic.
The connection between the base station and packet core also reflects this division. The control plane runs over the SCTP transport protocol. User plane traffic is encapsulated in UDP, with port number 2152.
The Layer 7 equivalent protocol in the 5G control plane is the Next Generation Application Protocol (NGAP). It runs over SCTP port 38412. NGAP defines network messages for various signaling procedures, which are serialized in Abstract Syntax Notation One (ASN.1) format.
Note: In 5G terminology, base stations are called gNBs or gNodeBs. On the packet-core side, the control plane node is called the access and mobility management function (AMF), and the user plane node is called the user plane function (UPF).
Both the base station and the packet core need ASN.1 parsers. ASN.1 parsing of 5G control messages can get complex. We wrote about it here, describing how user devices can potentially bring down a packet-core by triggering ASN.1 vulnerabilities. In that article, the technique was to trigger control plane ASN.1 vulnerabilities from the user plane. However, the ASN.1 vulnerabilities described in this article are triggered directly from the control plane.
An SCTP connection is established between the base station and packet core to carry NGAP messages. Figure 4 shows the typical message exchange after that.
The base station starts a control-connection setup with 5G Core by sending an NGSetUpRequest.
Upon receiving this message, the 5GC validates the parameters and sends ‘NGSetUpResponse’ with success or failure status. Authentication is not mandatory in this step.
Meanwhile, a UE may establish an RF link with the base station. Once the RF link is established, the UE sends a registration request to the base station. The base station adds additional information, encapsulates it into an NGAP packet, and forwards it to the packet core.
After that, mutual authentication between the UE and the packet core takes place (Figure 4, packets 4, 5), followed by security mode negotiation (packets 6, 7), and finally, the data session is set up (packets 10, 11).
The diagram in Figure 5 shows the message flow.
Key points:
Authentication is not mandatory between base stations and packet-cores.
- 3GPP standards do not have a provision for NGAP-based authentication. Instead, it is recommended that the base station and 5GC set up an IPSec link or use certificate-based authentication.
Registration is the first message from UEs to 5GC, sent before authentication and security capabilities are set up.
- This means the Registration Request is sent in plain text and is processed by 5GC without authentication.
The vulnerabilities described in this article are triggered within the first three NGAP messages (see Figure 4) before authentication and encryption are set up for UEs.
Microsoft Azure Private 5G Core is Microsoft’s 5G packet core designed for private networks. The packet processing functionality runs on Azure Stack Edge (ASE) hardware, while most configuration and management are from Azure cloud. Both ASE hardware and Azure require a subscription.
AP5GC is part of Microsoft’s Azure for Operator’s portfolio.
Authentication in AP5GC
No authentication is necessary between the base station and AP5GC in the default setting. In fact, we could not find any information related to this authentication in the documentation or the AP5GC configuration portal.
The preconditions for both described attacks are the same.
Precondition-1
AP5GC requires users to set up a gateway for gNBs to connect with AMF. An attacker must have connectivity to this gateway to be able to communicate with AP5GC.
Preparation: Our attack machine is connected to the gateway. We used an SCTP scan to identify the AMF interface.
Precondition-2
The attacker needs to know PLMN, which is configured in packet-core (AP5GC). Cell towers broadcast PLMN in clear text so that UEs can identify it.
Preparation: Software-defined Radios (SDRs) can be used to capture broadcasted messages from cell towers and find the PLMN.
Precondition-3
The attacker needs to know the Slice Service Type (SST) and (Slice Differentiator) SD.
SST values are generally standard 1,2, or 3. SD is optional. Microsoft Documentation
Preparation: 1 is the most common SST. We used SST=1 and empty SD on our gNB.
By sending a crafted malformed UE Registration message, an attacker can cause a denial-of-service in AP5GC. All cellular devices in the network will lose connectivity.
This vulnerability is assigned CVE ID CVE-2024-20685. Its ZDI tags are ZDI-24-362 and ZDI-CAN-23397. The figure gives an overview of the attack seen from the packet trace.
Attack Setup
It is possible to manually craft and send the messages in Steps 1, 2, and 3 from a generic SCTP client. However, it is easier to send these messages with software-defined radios (SDRs) designed to connect with 5G cores.
srsRAN is an SDR package that supports both software UE (srsUE) and gNB (srsRAN gNB). We installed srsRAN on a Linux machine. srsRAN supports the simulation of the radio interface, so no radio hardware is needed.
Our srsUE – srsRAN gNB – AP5GC connection setup is as follows.
192.168.1.101 is an actual radio hardware base station.
192.168.1.102 is the Linux machine with srsRAN.
192.168.1.100 is the gateway switch.
192.168.1.10 is AMF.
The Modifier module intercepts InitialUEMessage Registration sent from gNB and changes the payload to the one we crafted. An NFQ-based Python script does this job.
Results
We modified an “InitialUEMessage Registration Request” with a crafted payload. Figure 9 shows the packet capture after sending the modified packet.
The AP5GC NGAP layer no longer responds after InitialUEMessage (Fig: 9, pkt no: 150). Any NGAP control message to AMF at this point will trigger AMF shutdown/restart. Sometimes, AMF restarts automatically; sometimes, it remains inoperative until manually restarted.
Figure 10 shows the modified flow from Figure 5, with the attack scenario included.
Root Cause
- The lack of authentication between the base station and packet core allows attackers to connect their own SDRs to the packet core and mount more attacks.
- In this case, the crash is either caused by ASN.1 parsing or improperly handling the parser error.
An arbitrary NGSetupRequest sent to AP5GC, with the ID of a legitimate base station, can eject the original legitimate base station(gNB) from the network. Cellular devices served by the original base station will be forced to disconnect. A malicious base station can replace the original legitimate base station.
This vulnerability is assigned ZDI tag ZDI-CAN-23960.
Attack Setup
192.168.1.102 is a legitimate base station.
192.168.1.101 is a Linux PC with srsRAN.
192.168.1.100 is the gateway switch.
192.168.1.10 is AMF.
The fuzzer intercepts ‘NGSetupRequest’ from srsRAN gNB, changes gNB-ID, and replays several mutations to AMF.
Results
The packet trace is given in Figure 12. The ‘NGSetupRequest’ (gNB-ID = 0) in packet 52 is from a legitimate gNB. It gets a successful response in packet 54 and is connected. The attacker sends ‘NGSetupRequest’ with the same gNB-ID (0) in packet 88. AP5GC disconnects the first gNB (packet 90) and responds ‘success’ to the last received request in packet 91.
The root cause is that AP5GC trusts the last ‘NGSetupRequest’ received without verification and disconnects any currently attached gNB with the same gNB-ID.
Root cause
- Lack of authentication enables attackers to send setup requests to AP5GC and elicit a response.
- Lack of verification of received messages allows attackers to trick AP5GC into trusting them as legitimate base stations.
Both attacks result in varying degrees of denial-of-service (DoS). Since packet cores are critical network infrastructure nodes, the impact extends beyond the directly affected device, potentially disrupting a broader network segment.
The first attack (CVE-2024-20685) brought down the entire control plane, thus causing a total outage of services. All devices connected to the cellular network lose connectivity.
The second attack (ZDI-CAN-23960) ejects an intermediate node, a base station, from the network. All devices connected to that base station lose connectivity. Moreover, it adds an attacker-controlled base station to the network, which can be used to mount further attacks.
Outages in public networks are not common, but not rare either (E.g., 1 & 1, AT&T, T-Mobile). Private 5G networks are widely used in critical infrastructure, and service outages can seriously affect safety and business.
To execute the attacks detailed in this article, the attacker needs access to the control-plane subnet. This somewhat mitigates concerns about immediate exploitation. Both vulnerabilities are classified as “Medium” on the CVSS severity scale.
So far, we are not aware of any exploitation in the wild.
CVE-2024-20685 exploits an ASN.1 parser issue, and ZDI-CAN-23960 exploits insufficient message verification. However, both attacks rely on the lack of authentication between the base station and packet core for execution. Addressing this should be the first step toward mitigation.
- IPSec between base station and packet-core
- Certificate-based authentication between base station and packet core
- Allow-list/Whitelist for authorized base stations
- Access control and isolation of Control Plane subnet
- Deep Packet Inspection (DPI) solutions for virtual patching before vendor fixes
We reported both vulnerabilities to Microsoft through Zero Day Initiative (ZDI).
Microsoft has fixed CVE-2024-20685.
ZDI-CAN-23960 was reported to Microsoft on April 25, 2024. Microsoft responded, “We have shared your report with the team responsible for maintaining the service to ensure our customers are protected they will take the necessary action based on their internal timeline.”
Read More HERE
