The Open Radio Access Network (ORAN) architecture provides standardized interfaces and protocols to previously closed systems. However, our research on ORAN demonstrates the potential threat posed by malicious xApps that are capable of compromising the entire Ran Intelligent Controller (RIC) subsystem.
The Open Radio Access Network (Open RAN or O-RAN) architecture has provided access to previously closed Radio Access Network (RAN) systems by establishing standard interfaces and protocols. Different vendors are expected to create the eXtended applications (xApps) in O-RAN, which will be installed by the operator. This makes xApps a potential attack vector for malicious actors aiming to gain a foothold in critical communication nodes. Our research shows how a malicious xApp can jeopardize the entire RAN Intelligent Controller (RIC) subsystem. While there have been theoretical studies on O-RAN security, we believe that ours is the first hands-on work on the O-RAN Software Community (SC) reference implementation.
5G network
The diagram in Figure 1 illustrates the general architecture of a 5G cellular network. With some modifications to the Packet Core, the topology can be extended to suit previous network generations (such as 3G and 4G) as well. On the left side of Figure 1 are user equipment (UE), such as mobile phones, cellular routers, computers with 5G connectivity, and robot arms. UEs connect via radio waves to a base station, which then converts radio signals into IP packets and sends them to Packet Core via an IP backhaul. Beyond this point, it is an IT network.
Base station
The base station (shown in Figure 2 based on this diagram from Radiall) consists of the following components:
- An antenna to transmit and receive radio signals.
- A remote radio head (RRH) that houses radio frequency (RF) transceivers responsible for converting digital signals to radio signals and vice versa.
- A baseband unit (BBU) that handles digital data processing — including modulation, encoding and decoding, and higher layer protocols. A BBU can manage multiple RRHs and antennas.
RRHs are usually located close to antennas, often mounted on the cell tower. The BBUs used to be co-located with the cell-tower but current infrastructure has them located further away, at a central site. The evolution of RAN is shown in this diagram from Analysys Mason.
Virtualized RAN (vRAN) is a virtualized BBU that runs on commercial off-the-shelf hardware. In a disaggregated vRAN design, the BBU is split into two components, the central unit (CU) and the distributed unit (DU).
Open RAN
Despite virtualization and disaggregation, RAN architecture remained relatively closed (that is, most components had to come from the same vendor to ensure compatibility). When the network architecture is closed, operators usually need to pay huge costs to a single vendor to purchase equipment and technology.
O-RAN architecture aims to achieve interoperability and flexibility by adopting open standards, interfaces, and protocols. Open RAN breaks the closed nature of the system, allowing operators to choose equipment and software from different suppliers, therefore achieving a higher degree of network customization (for example, purchasing the CU from one vendor, then getting the DU from another). This allows for greater participation from second- and third-tier equipment manufacturers.
O-RAN is more than just open interfaces — it enables open access to next-generation RANs through artificial intelligence-based control. An open interface between local network entities and the RIC can facilitate real-time sensing and management of and reaction to radio resources. However, due to its open-standard nature, O-RAN is inherently more vulnerable to attacks and additional threats, so designing appropriate security mechanisms is a key issue.
O-RAN Alliance
The O-RAN ALLIANCE, an open technical organization consisting of mobile operators, vendors, research organizations, and academic institutions that strive for the advancement of the Open RAN concept, has devised a set of Open RAN specifications.
The Alliance previously collaborated with the Linux Foundation to develop a reference implementation for the specification, called the O-RAN SC. The O-RAN SC specification is open-source, with code contributions coming from top RAN vendors like Ericsson, Nokia, Samsung, Radisys, and AT&T. Given this collaborative effort, it is more likely that many vendors will incorporate O-RAN SC code into their commercial products.
O-RAN architecture
The O-RAN Alliance provides an overview of the O-RAN architecture on their website. Note that it is not necessary to understand all the components in the diagram for the purpose of this write-up. Figure 3 shows how O-RAN fits into the 5G network topology.
Near-RT RIC and RIC Message Router (RMR)
One of the important components of the O-RAN architecture is the near-RT RIC, which monitors and manages RF resources in the network to optimize network performance. It can collect and analyze network data in real time. It can also make intelligent decisions to optimize the configuration of wireless resources, allowing such resources to meet the needs of different terminal devices and services.
In near-RT RIC, there are many other subcomponents such as E2term, E2Mgr, and xApps. The communication between these components depend on the RIC Message Router (RMR) table, which in a near-RT RIC, typically contains information related to the routing and management of messages. These tables include details such as the message’s destination, priority, queue, and other relevant attributes.
RMR tables include the following information:
- Message destination. Specifies where the message should be routed to and which entity or handler should process it.
- Priority. Indicates the priority in which messages should be handled to ensure that important messages receive faster responses.
- Queues. Used for storing messages for subsequent processing.
- Message type. Identifies the type of message so that the correct handler can process it.
- Message identifier. A unique value that identifies the message. It’s used for tracking message status and processing progress.
The RMR library is a set of APIs that’s used to interact with the RMR table. It is included by the components that make up near-RT RIC, such as xApp and E2Term. As an example, the interaction between two separate xApps will take place through the RMR. In this case, xApp_A will make judgments based on KPI information and then call xApp_B through RMR.
Figure 4 shows the interaction between components in near-RT RIC using the RMR library and routing table.
Our research reveals multiple vulnerabilities in the messaging infrastructure of near-RT RIC.
Attack vector
Running in near-RT RIC, xApps are software components that provide functions such as radio resource optimization, network monitoring, and performance enhancement. These components can be further developed by network operators, third-party developers, or network equipment vendors to add unique value and functions. In that sense, xApps can be considered as the most open of all O-RAN components.
This multivendor ecosystem drives innovation, but it also brings the following challenges:
- Secure xApp onboarding
- Interoperability
- Robustness concerns
Normally, xApps are expected to be sourced from multiple vendors. Therefore, we started our research assuming that xApps are a potential attack vector. An xApp could be compromised through the supply chain or by hijacking the onboarding process. Even a benign xApp can cause harm if it sends out unexpected or anomalous messages. The results of our research confirmed these assumptions.
RMR vulnerabilities
The CVE-2023-40998 vulnerability involves incorrect packet information that can result in a negative packet size during decoding, leading to a crash when performing the memcpy operation.
The reason why the message size becomes negative is that it is determined by the first four bytes of the packet. If not set correctly, it can result in a negative value during decoding, leading to crashes.
CVE-2023-40997 involves a sent packet that cannot be properly decoded, causing an incorrect memory address calculation and resulting in an E2Term crash.
E2Term relies on the route table information sent by the Routing Manager at regular intervals to establish communication with other components within the RIC system. However, E2Term does not validate the sender of the route table information it receives. This lack of validation allows an attacker to exploit CVE-2023-41627 by sending forged route table information to E2Term. By sending this information to E2Term at a higher frequency using the Routing Manager, an attacker can deceive E2Term and disrupt its communication with other components.
When xApp_A sends a function ID to subscribe to E2 node, xApp_B sends the same function ID to the subscribe E2 node. The xApp_A RMR table entry will then be overwritten, which means it cannot receive messages from the E2 node. Instead, the E2 node will send messages to the second xApp_B. This issue was independently reported by another developer as well.
Impact
O-RAN is a critical part of the communication network, with O-RAN nodes storing encryption keys and processing user traffic.
Two of the vulnerabilities described here result in DoS incidents and are related to xApps, RMR, and near-RT RIC. These components provide value-added services, including the optimization of RF resources and traffic management.
O-RAN is designed to do traffic processing even if RIC/E2 components are not available. In theory, the crashing of RIC components should not shut down cellular connectivity. However, it could result in poor resource utilization and service degradation.
Meanwhile, RMR spoofing and hijacking could disrupt the xApp ecosystem in RIC without shutting down any component. The result is the same: poor resource utilization and service degradation.
Even benign xApps could cause harm due to improper implementations. This could adversely affect the interoperability of multivendor components in O-RAN.
Mitigation
Rigorous verification and onboarding processes can prevent malicious xApps from entering the system. Ensuring that O-RAN can handle network traffic even if RIC components malfunction could also reduce the impact of attacks.
We also recommend having a deep packet inspection (DPI) system to inspect traffic between components, so that hot patches can be applied as needed. This DPI system must be able to understand O-RAN protocols.
Acknowledgements
This research was conducted by the National Taiwan University of Science and Technology, in collaboration with TrendMicro/CTOne.
Source: https://www.trendmicro.com/en_us/research/23/l/the-current-state-of-open-ran-security.html