分析开放式无线接入网的安全现状
开放式无线接入网 (ORAN or 分析O-RAN) 是搭建一个开放 、虚拟化和智能的开放无线接入网 (RAN) 体系结构 ，从而创造一个包含多家厂商 、式无各家厂商的线接产品之间可以互操的生态系统 。开放无线接入网(ORAN)体系结构为以前封闭的入网系统提供了标准化的接口和协议。然而 ，全现通过对ORAN的分析研究表明 ，恶意xApps构成的开放潜在威胁能够危及整个Ran智能控制器(RIC)子系统 。Open RAN为5G无线接入网(RAN)引入了模块化和解耦的模板下载式无设计范式 ，并承诺通过O-RAN定义的线接RAN智能控制器(RIC, RAN Intelligent Controller)实现完全的可编程性 。
开放式无线电接入网架构通过建立标准接口和协议提供了对先前封闭的入网无线电接入网系统的接入 。预计不同的全现供应商将在O-RAN中创建eXtended应用程序（xApps），由运营商安装 ，分析这使得xApps成为恶意攻击者的开放潜在攻击向量 ，目的式无是在关键通信节点中站稳脚跟。
本文将会介绍恶意xApp如何危害整个RAN智能控制器（RIC）子系统 。亿华云
5G网络下图为5G蜂窝网络的总体架构。通过对分组核心的一些修改 ，拓扑结构也可以扩展以适应前几代网络（如3G和4G） 。在下图的左侧是用户 ：
5G网络的端到端架构
基站（如图2所示）由以下组件组成：
1.发射和接收无线电信号的天线 。
2.一种远程无线电头（RRH） ，它容纳射频（RF）收发器 ，负责将数字信号转换为无线电信号 ，反之亦然 。
3.一种基带单元（BBU） ，用于处理数字数据处理 ，免费模板包括调制 、编码和解码以及更高层协议 。BBU可以管理多个RRH和天线 。
典型RAN架构的组件
rrh通常位于天线附近 ，安装在手机信号塔上 。BBUs曾经与蜂窝塔同处一处 ，但目前的基础设施促使它们会位于更远的中心位置 。RAN的演变如本文所示 。
vRAN(虚拟化RAN)是一种运行在商用现成硬件上的虚拟化BBU 。在分离式vRAN设计中 ，云计算BBU分为CU (central unit)和DU (distributed unit)两部分 。
Open RAN尽管虚拟化和分解 ，RAN体系结构仍然相对封闭(也就是说 ，大多数组件必须来自同一供应商以确保兼容性) 。当网络架构关闭时 ，运营商通常需要向单一供应商支付巨额费用来购买设备和技术 。
O-RAN架构旨在通过采用开放的标准 、接口和协议来实现互操作性和灵活性 。开放式RAN打破了系统的封闭性 ，允许运营商从不同的供应商选择设备和软件 ，从而实现更高程度的网络定制(例如 ，香港云服务器从一个供应商购买CU，然后从另一个供应商获得DU) 。这允许更多的二 、三线设备制造商参与进来 。
O-RAN不仅仅是开放接口 ，它还通过基于人工智能的控制实现对下一代ran的开放访问 。本地网络实体和RIC之间的开放接口可以促进无线电资源的实时感知 、管理和响应 。然而 ，由于其开放标准的高防服务器性质 ，O-RAN本质上更容易受到攻击和其他威胁，因此设计适当的安全机制非常重要。
O-RAN联盟O-RAN联盟是一个开放的技术组织 ，由移动运营商 、供应商 、研究组织和学术机构组成 ，致力于推进open RAN概念 ，该联盟已经设计了一套open RAN规范 。
该联盟之前与Linux基金会合作开发了该规范的参考实现 ，称为O-RAN SC, O-RAN SC规范是开源的 ，其代码来自爱立信 、诺基亚 、三星 、Radisys和AT&T等顶级RAN供应商。鉴于这种协作努力 ，许多供应商更有可能将O-RAN SC代码纳入其商业产品中 。
O-RAN架构O-RAN联盟在其网站上提供了O-RAN架构的概述 ，下图显示了O-RAN如何适应5G网络拓扑结构 。
O-RAN如何适应5G网络拓扑结构
Near-RT RIC使用E2接口来控制底层的RAN组件(包括CU 、DU和RU) ，可以将它看作OpenFlow在RAN中的对应组件 。E2接口的要求是能够将Near-RT RIC连接不同供应商的不同类型的RAN组件 。这个要求反映在围绕服务模型(Service Model) 抽象的API中，其思想是每个RAN组件都发布一个服务模型 ，定义该组件能够支持的RAN功能集 。
Near-RTRIC是O-RAN体系结构的重要组成部分之一，它对网络中的RF资源进行监控和管理 ，以优化网络性能 。它可以实时收集和分析网络数据 ，还可以做出智能决策 ，优化无线资源的配置，使这些资源能够满足不同终端设备和服务的需求 。
在Near-RT的RIC中 ，还有许多其他子组件 ，如E2term 、E2Mgr和xApps。这些组件之间的通信依赖于RIC Message Router (RMR)表 ，在Near-RT的RIC中 ，该表通常包含与消息的路由和管理相关的信息 。这些表包括消息的目的地 、优先级、队列和其他相关属性等详细信息 。
RMR表包括以下信息 ：
消息目的地 ：指定应将消息路由到何处以及应处理该消息的实体或处理程序 。优先事项指示处理消息的优先级 ，以确保重要消息得到更快的响应 。排队 ：用于存储消息以供后续处理。消息类型 ：标识消息的类型 ，以便正确的处理程序能够处理它 。消息标识符：标识消息的唯一值：它用于跟踪消息状态和处理进度 。RMR库是一组用于与RMR表交互的api，它包含在组成Near-RTRIC的组件中 ，例如xApp和E2Term 。例如，两个独立xapp之间的交互将通过RMR进行 。在这种情况下 ，xApp_A将根据KPI信息做出判断，然后通过RMR调用xApp_B 。
下图显示了使用RMR库和路由表的Near-RTRIC中组件之间的交互 。
RIC组件如何使用RMR
我们的研究揭示了Near-RTRIC的消息传递基础设施中的多个漏洞 。
攻击方法在Near-RT的RIC中运行 ，xApps是提供诸如无线电资源优化 、网络监控和性能增强等功能的软件组件 。这些组件可以由网络运营商 、第三方开发人员或网络设备供应商进一步开发 ，以增加独特的价值和功能 。从这个意义上说，xApps可以被认为是所有O-RAN组件中最开放的 。
这种多厂商生态系统推动了创新 ，但也带来了以下挑战 ：
安全xApp登录；
互操作性；
鲁棒性问题；
通常情况下 ，xApps应该来自多个供应商。因此，我们开始研究时假设xApps是一种潜在的攻击媒介 ，xApp可能会通过供应链或劫持引导进程而受到攻击 。即使是良性的xApp ，如果它发出意外的或异常的消息 ，也会造成伤害 。我们的研究结果证实了这些假设。
RMR漏洞CVE-2023-40998 ：来自xApp的精心制作的恶意数据包导致RT RIC的E2term崩溃 。
CVE-2023-40998漏洞涉及错误的数据包信息 ，可能导致解码过程中的数据包大小为负，从而导致执行内存操作时崩溃 。
CVE-2023-40998消息流
消息大小变为负数的原因是它由数据包的前四个字节决定 。如果设置不正确 ，它可能在解码过程中导致负值 ，从而导致崩溃 。
CVE-2023-40997 ：以无效格式发送的精心制作的消息导致Near-RTRIC的E2term崩溃 。
CVE-2023-40997消息流
CVE-2023-40997发送报文无法正确解码 ，导致内存地址计算错误 ，导致E2Term崩溃 。
CVE-2023-41627 ：RMR表欺骗E2Term依赖路由管理器定期发送的路由表信息来与RIC系统中的其他组件建立通信，但E2Term不会验证它接收到的路由表信息的发送方 。由于缺乏验证 ，攻击者可以通过向E2Term发送伪造路由表信息来利用CVE-2023-41627漏洞 ，通过使用路由管理器以更高的频率将此信息发送给E2Term ，攻击者可以欺骗E2Term并中断其与其他组件的通信 。
CVE-2023-41627消息流
当xApp_A向订阅E2节点发送函数ID时，xApp_B向订阅E2节点发送相同的函数ID 。然后 ，xApp_A RMR表项将被覆盖 ，这意味着它不能从E2节点接收消息 。相反 ，E2节点将向第二个xApp_B发送消息 。
O-RAN是通信网络的关键组成部分 ，O-RAN节点存储加密密钥并处理用户流量。
这里描述的两个漏洞会导致DoS事件 ，它们与xApps 、RMR和Near-RT的RIC有关 。这些组件提供射频资源优化和流量管理等增值服务。
O-RAN设计用于在RIC/E2组件不可用的情况下进行流量处理 。理论上，RIC组件的崩溃不应该关闭蜂窝连接。但是，这可能导致资源利用不畅和服务退化 。
同时 ，RMR欺骗和劫持可以在不关闭任何组件的情况下破坏RIC中的xApp生态系统。这就造成了资源利用率低下和服务退化 。
即使是良性的xapp也可能由于实现不当而造成损害 。这可能会对O-RAN中多厂商组件的互操作性产生不利影响 。
缓解严格的验证和登录过程可以防止恶意xApps进入系统 ，即使RIC组件发生故障 ，确保O-RAN也可以处理网络流量 ，这也可以缓解攻击的影响 。
建议使用深度包检测(DPI)系统来检查组件之间的流量，以便可以根据需要应用热补丁。
这个DPI系统能够理解O-RAN协议 。