By Salim S.I. and Richard Y Lin

The first part of our study on O-RAN explained vulnerabilities in RIC Message Router (RMR) architecture and library. In this second article, we cover potential threats to the E2 interface, which connects the Near Real Time RIC (near-RT RIC) with other RAN components (see Figure 1 below). A successful attack on the E2 interface can lead to non-availability or abnormal functioning of E2 services, which can degrade the performance of the cellular network.

This article discusses two vulnerabilities in the O-RAN Software Community (SC) reference implementation that attackers can exploit. One vulnerability stems from insufficient access control, and the other vulnerability arises from faulty message handling (CVE-2023-41628).

Figure 1. 5G end-to-end architecture with O-RAN

The attack vector originates from xApp to other O-RAN components. This vector is addressed by MITRE FiGHT framework as 'Rogue xApps unauthorized access'.

RIC and E2 infrastructure

In O-RAN architecture, near-RT RIC monitors and manages radio frequency (RF) resources in the network to optimize network performance. Other subcomponents within near-RT RIC, include E2 Terminator (E2Term or E2T), E2 Manager (E2Mgr), and xApps.

Near-RT RIC is interconnected with other O-RAN components such as O-DU (Open Distributed Unit) and O-CU (Open Central Unit) via the E2 interface. Components of the RAN equipped with an E2 interface are referred to as E2 nodes.

E2Term, a component in near-RT RIC, serves as a RAN function and provides E2 interface to RAN nodes. E2 nodes communicate with the E2Term over the E2 interface using E2 Application Protocol (E2AP) messages. Subsequently, E2Term routes the messages to the appropriate xApps using the RMR service bus.

xApps can be seen as functionally independent software plug-ins that enable near-RT RIC to make intelligent decisions. Vehicle to Everything (V2X) communication is one of the highly anticipated use cases of O-RAN. The cellular traffic management required for Vehicular User Equipment (UEs) is unique, and xApps are ideal for providing this capability.

xApps are expected to be sourced from multiple vendors. Consequently, 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. Due to its nature and the various ways it can be compromised, the xApp has been the focus of our study.

xApp Communication Flow

After an xApp is onboarded to near-RT RIC, typically, the communication flow is as follows:

1. xApp Sends Subscription Request to RIC: The xApp sends a subscription request to the RIC, specifying the events, metrics, or information it is interested in monitoring or receiving updates about.
2. RIC Processes Subscription Request: The RIC subscription manager processes the subscription request from the xApp and determines the relevant E2 nodes or entities that need to be involved in fulfilling the subscription.
3. RIC Communicates with E2 Nodes: With the help of the Routing Manager, the RIC sends relevant messages or requests to E2 nodes using the E2 interface. The messages may include instructions to start monitoring specific events, obtain measurements, or perform other actions related to the radio access network.
4. E2 Nodes Respond to RIC: The E2 nodes receive the messages from the RIC and perform the requested actions. For example, they may start monitoring specific cells, collect performance metrics, or provide updates based on the subscription criteria.
5. RIC Sends Updates to xApp: As events occur or metrics meet certain conditions, the RIC receives updates from the E2 nodes. The RIC, in turn, sends notifications or indications back to the xApp, informing it of the relevant information or changes.

E2Term acts as the gateway for sending and receiving E2 messages between E2 nodes.

Figure 2. xApp normal communication flow

Out-of-Order Message Vulnerability

Out-of-Order messages can occur in networks due to various reasons; sometimes because a message gets lost in transit, sometimes because of sender malfunctioning, or sometimes an attacker injects such a message.

If not handled properly, out-of-order messages can disrupt the receiver’s processing flow, leading to unexpected behavior. Our research found one such vulnerability (CVE-2023-41628) in ORAN-SC’s RIC subsystem.

Figure 3. Out-of-Order message from an xApp

When E2Term receives a RIC Subscription response without a corresponding RIC subscription request, it crashes. It does not matter who the sender of this RIC subscription response is. Usually, RIC subscription requests are sent out by xApps, and RIC subscription responses are sent out by E2 nodes. Initially, we discovered that an out-of-order RIC subscription response from an E2 node results in a crash of E2Term.

We then found that even an xApp could trigger this crash of E2Term by sending a RIC subscription response.

E2Mgr Access Control Violation

Apart from the officially documented protocol messages, there might be additional APIs providing access to a node, either intentionally or unintentionally. These APIs could be included for purposes such as management or debugging.

Unlike the well-documented APIs, these may not be widely known, documented, or subjected to authentication and authorization requirements, potentially posing security risks due to their lack of access control. We found such an API that accesses E2Mgr, whose function was to shut down the node.

Figure 4. Unauthorized access of management API

The exposed HTTP API could be invoked from any xApp, thus shutting down all E2 services of the near-RT RIC.

ARP Spoofing of E2Term

The Address Resolution Protocol (ARP) is the mechanism by which network nodes identify the Media Access Control (MAC) address of other nodes when their IP addresses are known. This process is necessary in ethernet networks, where a node must know the MAC address of its peer nodes to establish communication. ARP facilitates the translation of known IP addresses into corresponding MAC addresses.

ARP spoofing is a type of attack where an attacker sends false (spoofed) Address Resolution Protocol messages. The goal of ARP spoofing is to link the attacker's MAC address with the IP address of a legitimate network device, redirecting traffic intended for that device through the attacker's system.

Our tests found that an xApp can impersonate E2Term by sending out ARP messages with E2Term’s MAC address, thus redirecting all E2 traffic through the xApp.

Figure 5. ARP Spoofing of E2Term

Impact

In all three cases, E2 services will be disrupted or entirely shut down. The O-RAN architecture is designed to function even when E2 services are unavailable, so end-to-end connectivity for user devices may still be available. However, the network performance may suffer.

In V2X use cases, non-availability of E2 services may result in unpredictable functioning of vehicles. And, in the case of ARP spoofing, an xApp might be able to intercept the data communication of other xApps for which it has no authorization.

Even non malicious xApps could cause harm due to improper implementations. This could adversely affect interoperability of multivendor components in O-RAN. We were able to build a 6-in-1 attack xApp, which can execute six of the attacks found in the study.

Mitigation

There are several ways to mitigate the impact of the security issues outlined above. Organizations that could be affected should consider the following:

• Rigorous verification and onboarding process could prevent malicious xApps from entering the system.
• xApps should be run with the least required privileges.
• Ensuring that O-RAN can handle network traffic even if RIC components malfunction could reduce the impact of these issues.

We also recommend implementing a DPI system to inspect traffic between components, so that hot patches can be applied. The DPI system must be able to understand O-RAN protocols.

This research was conducted by National Taiwan University of Science and Technology in collaboration with Trend Micro and CTOne.