Cyber Threats
Attacks on 5G Infrastructure From User Devices: ASN.1 Vulnerabilities in 5G Cores
In the second part of this series, we will examine how attackers can trigger vulnerabilities by sending control messages masquerading as user traffic to cross over from user plane to control plane.
Save to Folio
In the first part of this series, we explored how GTP-U (GPRS tunnelling protocol-user plane) tunnels can be abused by user devices to send GTP-U-in-GTP-U packets that could crash packet cores. In the second part of this series, we will examine how attackers can trigger vulnerabilities by sending control messages masquerading as user traffic to cross over from user plane to control plane. We also discuss the potential impact of an attack, which can disrupt operations (leading to monetary and reputational loss) or even cripple vital infrastructure for industries that employ 5G technologies.
5G and Private 5G
5G is the fifth generation of wireless technology for cellular networks, following the progression of 1G, 2G, 3G, and 4G networks. Its appeal does not lie solely in its own capabilities, but also in what it can offer private cellular networks. The emergence of 5G coincides with the growing demand for private networks in various sectors, which require the key capabilities of 5G: more spectrum options, enhanced capabilities, and better security features.
This growing adoption of private networks has attracted many new vendors providing solutions for different parts of the network, including the 5G core. Unlike the established players with (mostly) mature proprietary Cellular Technology (CT) stacks, these new vendors either build from scratch or use open-source solutions. In many cases, however, there is still some distance to go before these new solutions attain the product maturity found in the solutions offered by proven vendors.
5G Control Plane: N1/N2 Interfaces
The N2 interface is used to exchange control messages between the Base Station (gNodeB or gNB) and the 5G core. In the 5G core, the Access and Mobility Management Function (AMF) is the specific component that is connected to the N2 interface.
Meanwhile, the N1 interface is the transparent interface that connects the User Device (UE) to the AMF. It is transparent in the sense that it is not a direct connection to the AMF — N1 messages are delivered by gNB through N2.
The Next Generation Application Protocol (NGAP) is the upper layer protocol used for the N1 and N2 interfaces and defined in 3GPP TS 38.413. On N2, NGAP is carried over Stream Control transmission Protocol/IP (SCTP/IP). NGAP messages are sent serialised in Abstract Syntax Notation One (ASN.1).
ASN.1 supports several encoding types such as Basic Encoding Rules (BER), Packet Encoding Rules (PER), and Aligned PER (APER). BER follows a type-length-value (TLV) format.
The End-of-Content octets are present for those types with length not specified.
PER follows a similar format, but unlike BER, when the data type is known or fixed, PER does not send the type or length. Meanwhile, APER is PER but aligned to octet boundaries for faster processing by receiving nodes. Finally, NGAP follows APER.
At face value, this looks like a simple format. However, considering the nesting of encoded elements, it becomes evident that the format is more complex than it initially appears. We can consider the following problem based on Figure 1: What happens when the length and value are mismatched?
ASN.1 decoders have a history of running into problems with malformed data. In the last two years, there have been at least 12 vulnerability CVEs associated with the ASN.1 decoders of various products, including OpenSSL.
NGAP Messages
Different vendors of 5G cores use different implementations of the NGAP ASN.1 decoder, with some opting for open-source decoders, while others use proprietary ones. We tested multiple commercial and free-open-source products for NGAP decoding vulnerabilities. The results were not surprising: we were able to identify hundreds of vulnerabilities in both commercial and free-open-source products. We’ll provide an analysis on one of them, which we found on free5gc, a free-open-source 5gc implementation.
Consider an NGAP message decoded in Wireshark — an initialUE message sent from UE to AMF to start registration of the UE. There are five Information Elements (IE), Item 0 to Item 4. Let us take Item 1, NAS-PDU, as an example.
The first two bytes represent the IE id, 0x0026, which is NAS-PDU. The next bytes denote the criticality (0x00) and length (0x26) of the value field. The value follows the length field, starting with 0x7e for a length of 0x26 bytes.
Now consider the following NGAP message:
There are several problems in this message.
- The procedure code (0x0028) indicates that this is a UEContextModification message. UEContextModification messages are sent from AMF to gNB. But in this case, it was sent to AMF from gNB.
- The length field indicates that the message has a total length of 0x30. The following bytes (0x3030 = 12336) indicate the number of IEs present, which is a random incorrect value. If we try to decode it, we will encounter values that do not make sense. For example, the length in a nested IE states that the following value has a length of 0x30. This obviously can’t be correct because the entire message has a length of 0x30.
When free5gc receives this packet, AMF crashes, resulting in the vulnerability that is assigned to CVE-2022-43677. In May 2023, a related fix for free5gc was released.
Looking at the fix, it seems that the problem was addressed in NGAP parsing. However, we encountered additional issues. We were able to trigger this crash from user equipment, via normal user traffic (that is, without needing to access the baseband modem).
NGAP is the protocol for Control Plane (signalling), running on SCTP port 38412. GTP-U is the encapsulating protocol for user data, running on UDP port 2152. From the UE, the control plane signalling is handled by the baseband modem.
Users do not have access to baseband modem. The user-plane traffic (data sent from the user such as browsing and streaming) is sent to the User Plane Function (UPF) over a GTP-U tunnel. In 5G Control Plane User Plane Separation (CUPS) architecture, UPF and AMF are functionally separated: they are separate network functions with their own IP addresses. Normal users do not have the authorisation to access the network infrastructure, so user data going to the Control Plane is a security risk.
We were able to establish an SCTP connection with AMF from the UE application layer. Through this SCTP connection, the anomalous NGAP payload was sent. From the 5GC side, the packet will appear as NGAP-in-GTPU. This NGAP message was delivered to the AMF and resulted in it crashing.
The most concerning weakness here is the routing of the User Plane messages. This allowed the delivery of anomalous signalling messages to the AMF. As a prerequisite of an attack, the attacker must know the AMF IP address. We were able to accomplish this using SCTP scanning through the User Plane.
Note that this test was done with a free5gc all-in-one virtual machine and not a containerised version of it. These will have different routing setups.
Attack Vector
In our test case, the attack vector employed was user traffic from User Equipment, taking advantage of the poor separation of the control plane and the user plane.
There are two problems here:
- The ASN.1 parser was not robust
- The Control Plane and User Plane was not properly separated.
The first issue might be related to coding. ASN.1 decoders used for parsing Control Plane messages are complicated and are often vulnerable to malformed messages.
The second issue, user traffic being able to penetrate to the control plane, is an architectural problem that could lead to more problems.
When the control plane and the user plane is properly separated, malformed N1 messages could still be sent from the UE to trigger the crash. For this, the UE needs the ability to craft control messages. There are open-source solutions capable of doing this (such as srsUE).
Business Impact
The free5GC project is one of the most popular open-source implementations of 5G core. We know of commercial solutions based on free5GC from major packet core vendors that target the private 5G market and the telecoms industry. In fact, there are national defence agencies in Asia and Europe that get their 5G network products from one such vendor.
The CVE-2022-43677 vulnerability exploits weak CUPS implementation in free5gc to trigger a Control Plane Denial-of-Service (DoS) through user traffic. A successful DoS attack on the packet core disrupts the connectivity of the entire network. In critical sectors such as defence, policing, mining, and traffic control, disruption to connectivity lead to dire consequences. In factories that use real-time sensors for manufacturing processes, this could result in defective products being created.
Recommendations and insights
We recommend the following best practises for users of the technologies we’ve discussed in this blog entry:
- Access Control: Allow only trusted devices to connect to networks. The registration and use of SIM cards must be strictly regulated and managed.
- Clear separation of Control and Data Planes: Separation of planes in the packet core prevents data packets crossing over to the control plane.
- Open-source, with responsibility: While using open-source software to make critical infrastructure nodes, users must be able to immediately patch and prevent any defect. It is highly recommended that users thoroughly learn and understand the underlying code or if not, have dedicated support for the software they use.
- Use CT-aware DPI solutions/firewalls: It is not easy to frequently update critical infrastructure nodes, because doing so might interrupt service. Virtual patching tailored for packet-cores is strongly recommended; On N2 to detect anomalous NGAP messages; On N3 to watch out for misuse of GTP-U tunnels (NGAP in GTP-U, GTP-U in GTP-U).
We recommend using layered security solutions that combine IT and communications technology security and visibility. Implementing zero-trust solutions, such as Trend Micro™ Mobile Network Security, powered by CTOne, adds another security layer for enterprises and critical industries to prevent the unauthorised use of their respective private networks for a continuous and undisrupted industrial ecosystem, and by ensuring that the SIM is used only from an authorised device. Trend Mobile Network Security also brings CT and IT security into a unified visibility and management console.