P1 Security has developed in the two last years a set of tools and libraries to help with testing, and pentesting, 5G Core Networks. A dedicated commercial Signaling Scanner is also available since June 2021 for that purpose: the PTA 5GC product that can be directly used by operators.
Many operators are currently in the process of sourcing vendors for their 5G core network, and many of them ask themselves about the security of the different products.
P1 Security had the opportunity to work with customers to assess the security of provided solutions. On the other side, P1 Security Labs also have worked with 5G test-beds, using different open-source solutions. In this post, we explain what kind of test-beds we have setup, the solutions we have developed for proper security assessment, and the kind of issues one can find during such a security evaluation.
Testing with open-source solutions
When dealing with an open-source 5G network, there is not so much choices available:
There are two main core network projects, Open5GS and free5gc, and a gNodeB and terminal emulator UERANSIM. More projects can be found online, but they are far from working stable (even at all, some times). The gNodeB and terminal emulator connects to the core network and enables stable and reproducible connections scenarios.
In turn, this produces standard signalling exchanges between the different core network functions (which are numerous in 5G). One could argue that this kind of test-bed do not enable end-to-end testing, through a radio interface, but there are currently not so much stable 5G base-station open-source implementations (OAI and srsRAN are the 2 main projects in this area). Moreover, working with radio imposes several challenges in terms of physical installation (running the transmitters into a Faraday cage, or wiring everything through variable attenuators…) and generally induces less stable and reproducible scenarios.
Developing dedicated auditing software
While working with this kind of setup helps to investigate standard signalling and connection scenarios, it does not enable advanced security testing. In the 5G core network, the different types of telecom interfaces we want to test are:
- The N1/N2 interface between the RAN and the AMF, with NGAP and NAS signalling ; in the 5G core, note that the NAS signalling can propagate to other NFs, such as the SMF, the SMSF, the LMF…
- The N3 interface between the RAN and the UPF, with GTP-U ; it is, after all, a generic GTP-U interface, similar at what exists in 4G for the SGW and PGW.
- All the SBA interfaces, where the numerous 5G Core NFs exposes HTTP/2 services and APIs, hopefully formally documented with OpenAPI. Those can be accessed directly for ease of testing, or through a SEPP for more real-world scenarios of 5G roaming partners.
- The PFCP interface, where the UPF is controlled by the SMF. This interface is generally not as exposed as the 3 first in a 5G deployment, but still is important to consider.
Therefore, we have developed a custom gNodeB and terminal emulator, handling the NGAP and NAS connection to the AMF. This enables to integrate easily numerous methods and hooks for attempting security bypasses and enabling smooth fuzzing of the core network. We have also developed a custom SEPP and generic SBA client / server, which relies on any OpenAPI specification to request and / or run a 5G core service. This last part is already fully integrated into our PTA product. We also have a GTP-C and PFCP fuzzer. Finally, and built on our experience, we have a classical security toolbox for pentesting OAM interfaces and services, which are quite similar in 5G as in older cellular technologies.
Those are not open-source (even if they rely on some of our open-source libraries), and generally integrates into our PTA and PTF commercial products as soon as they are considered mature enough.
Example of issues found
We will not elaborate on issues found on proprietary and vendor’s implementations, but they are generally similar to what can be found on open-source solutions. While open-source solutions are generally not targeting security but stability (which is already a challenge !), we expect proprietary solutions to be not only stable but also fully secure, and thus have less bugs and issues. Operators are paying a high price for this, after all. For instance, while testing Open5GS and free5gc from the RAN perspective, we found numerous crashes within both AMF, following are some examples:
- AMF breaking due to faulty NGAP messages: https://github.com/open5gs/open5gs/issues/960
- AMF breaking due to faulty NAS messages or call-flows: https://github.com/open5gs/open5gs/issues/959 & https://github.com/free5gc/free5gc/issues/199
- NAS security bypasses: https://github.com/open5gs/open5gs/issues/958 & https://github.com/free5gc/free5gc/issues/195
- Some functional bugs were found in the course of this security testing too e.g. : https://github.com/free5gc/free5gc/issues/197
Don’t be mistaken however to think Open5GS would be less secure than other solutions: this software has proven to be one of the most reliable already with its 4G Core and now with its 5G part. The main developer is moreover very reactive, eager to fix any issue efficiently and fast, and kind !
There are many other issues to be found in a 5G core network, each one depending of the tested interface and underlying protocol. A simple look at the list of issues related to crashes into both Open5GS and free5gc projects will help to understand all the things that can go wrong within a 5G core network. When working on closed source implementations, things are a bit different, as it can be hard to get proper logging or debugging information, making fuzzing and bug analysis more tedious.
When you want to have a good coverage while fuzzing a telecom interface, the hard part with many of the protocols is the need to manage the protocol state correctly (which is challenging for something like e.g., the RRC or NAS protocols). A single example with NGAP, used between the gNodeB and the AMF: it is useless to fuzz any of the UE-related procedures (e.g., handover procedures), unless you established a proper UE-context at first with the AMF.
To conclude
Finally, the overall security of a core network and the connected subscribers depends not only on the different telecom’s services implementation, but also on the configuration of all the hardware and software involved (e.g., the kind of cryptographic protocol used, configuration of IPsec and / or TLS and associated x.509 certificates). This also includes looking carefully at the hosting infrastructure, being services running directly on bare-metal, within VM or containers. All in all, assessing the overall security of a complete core network takes time and requires the appropriate skills and tooling, especially when it comes to checking signalling interfaces.
Some of the issues found during these security assessments, or found during tooling development, can be reviewed within P1 Security Vulnerability Knowledge Base.
P1 Security engineers are also regularly working with operators in order to help them assess the security of their core network. Feel free to get in touch with our commercial department for any related inquiries.
Find more on the P1 Labs!
