5G开启了传统无线连接无法实现的前所未有的应用，帮助企业加速数字化转型、降低运营成本，并最大限度地提高生产力，以获得最佳投资回报。为了实现目标，5G依赖关键的服务类别：大规模机器类型通信（mMTC）、增强型移动宽带（eMBB）和超可靠低延迟通信（uRLLC）。

随着商用频谱不断增加，专用5G网络的使用率和普及率也随之提高。制造、国防、港口、能源、物流和采矿等行业只是这些专用网络的早期采用者之一，特别是对于那些迅速依赖物联网以实现生产系统和供应链数字化的公司。与公共电网不同，专用5G中的蜂窝基础设施设备可能归用户企业、系统集成商或运营商拥有和运营。然而，鉴于针对使用5G开发各种技术的研究和探索越来越多，网络犯罪分子也在考虑利用种种威胁和风险，企图通过这种新的通信标准，入侵用户和组织的系统和网络。本文探讨了普通用户设备如何在5G网络基础设施和用例中被滥用。

在端到端5G蜂窝系统中，用户设备（又名UE，比如移动电话和物联网设备）通过无线电波连接到基站，基站则通过有线IP网络连接到5G核心。

从功能上来说，5G核心可以分为两个平面：控制平面和用户平面。在网络中，控制平面承载信号，并根据流量从一个端点到另一个端点的交换方式为流量传输提供方便。同时，用户平面负责连接和处理通过无线局域网（RAN）传输的用户数据。

基站发送与设备连接相关的控制信号，并通过NGAP（下一代应用协议）与控制平面建立连接。来自设备的用户流量使用GTP-U（GPRS隧道协议用户平面）发送到用户平面。数据流量从用户平面路由传输到外部网络。

图1. 基本的5G网络基础设施

UE子网与基础设施网络相互分离、隔离，不允许用户设备访问基础设施组件。这种隔离有助于保护5G核心免受来自用户设备的CT（蜂窝技术）协议攻击。

有没有办法绕过这种隔离、攻击5G核心呢？接下来的章节将详细介绍网络犯罪分子如何可以滥用5G基础设施的组件、尤其是GTP-U。

GTP-U是一种隧道协议，存在于基站和5G用户平面之间，使用端口2152。下面是用GTP-U封装的用户数据分组结构。

图2. GTP-U数据分组

GTP-U隧道分组是通过将报头附加到原始数据分组而形成的。添加的报头由UDP（用户数据报协议）传输报头和GTP-U特有的报头组成。GTP-U报头则由以下字段组成：

• 标志：这包含版本及其他信息（比如表明是否存在可选的报头字段等信息）。

• 消息类型：对于承载用户数据的GTP-U分组而言，消息类型为0xFF。

• 长度：这是隧道端点标识符（TEID）字段之后的所有内容的长度（以字节为单位）。

• TEID：隧道的独特值，用于将隧道映射到用户设备。

GTP-U报头由GTP-U节点（基站和用户平面功能即UPF）添加。然而，用户无法在设备的用户界面上看到报头。因此，用户设备无法操纵报头字段。

虽然GTP-U是一种标准的隧道技术，但其使用主要局限于基站和UPF之间或UPF和UPF之间的CT环境。假设在理想场景下，基站和UPF之间的回程经过加密，受到防火墙保护，并且不允许外部访问。下面详述这种理想场景：GSMA建议在基站和UPF之间使用IP安全（IPsec）。在这种场景下，到达GTP-U节点的分组只来自授权的设备。如果这些设备遵循规范并合理实施，它们不会发送异常分组。此外，可靠的系统应该有强大的完整性检查机制，以处理接收到的异常信息，特别是明显的异常信息，比如无效的长度、类型和扩展等。

然而在现实中，场景可能往往不同，需要完全不同的分析。运营商不愿意在N3接口上部署IPsec，因为它耗用大量CPU资源，降低了用户流量的吞吐量。此外，由于用户数据被认为在应用层受到保护（借助额外协议，比如TLS即传输层安全），一些人认为IP安全是多余的。有人可能认为，只要基站和分组-核心符合具体要求，就不会出现异常情况。此外，有人可能还认为，对于所有可靠的系统而言，都需要进行完整性检查，以发现任何明显的异常。然而之前的研究表明，全球各地的许多N3节点（比如UPF）暴露在互联网上，尽管不应该如此。这将在以下的章节中介绍。

图3. 因配置错误或缺少防火墙而暴露的UPF接口，截图来自Shodan，并用于之前发表的研究结果

我们讨论了两个可以使用CVE-2021-45462利用GTP-U的概念。在Open5GS这种面向5G核心和进化分组核心（EPC）的C语言开源实现中，从用户设备发送零长度、类型=255的GTP-U分组导致了UPF遭到拒绝服务（DoS）。这是CVE-2021-45462，分组核心中的这个安全漏洞可以通过从用户设备制作的异常GTP-U分组，并通过在GTP-U中发送该异常GTP-U分组，导致UPF（5G中）或服务网关用户平面功能（4G/LTE中的SGW-U）崩溃。鉴于该漏洞影响基础设施的关键组件，并且无法轻易解决，该漏洞的严重性等级为中到高。

GTP-U节点是对GTP-U分组进行封装和解封装的端点。基站是用户设备端上的GTP-U节点。基站从UE接收用户数据时，将数据转换成IP分组，并在GTP-U隧道中封装。

UPF是5G核心端的GTP-U节点。当UPF接收到来自基站的GTP-U分组时，UPF对外部的GTP-U报头进行解封装，取出内部分组。UPF不检查内部分组的内容，直接查询路由表（也由UPF维护）中的目的地IP地址，然后继续发送分组。

如果用户设备制作了一个异常的GTP-U分组，并将其发送到分组核心，会怎么样？

图4. 一个精心特制的异常GTP-U分组

图5. 从用户设备发送异常的GTP-U分组

果不其然，基站将把该数据包放入到其GTP-U隧道中，发送给UPF。这导致GTP-U分组中的GTP-U到达UPF。UPF中现在有两个GTP-U分组：外部GTP-U分组报头由基站创建的，用于封装来自用户设备的数据分组。这个外部GTP-U分组的消息类型为0xFF，长度为44。这个报头是正常的。内部GTP-U报头由用户设备制作并作为数据分组来发送。与外部GTP-U分组一样，这个内部GTP-U分组的消息类型为0xFF，但长度0不正常。

内部分组的源IP地址属于用户设备，而外部分组的源IP地址属于基站。内部分组和外部分组的目的地IP地址一样：都是UPF的目的地IP地址。

UPF对外部GTP-U进行解封装，并通过功能检查。内部GTP-U分组的目的地还是同样的UPF。接下来发生的事情因实现方法而异：

• 一些实现维护用于分组遍历的状态机。状态机的不正确实现可能导致处理这个内部GTP-U分组。该分组可能已经通过了检查阶段，因为它与外部分组拥有相同的分组上下文。这导致系统内部有一个异常分组通过完整性检查。

• 由于内部分组的目的地是UPF本身的IP地址，因此分组可能被发送到UPF。在这种情况下，分组很可能会通过功能检查，因此问题不如前一种情况来得严重。

一些5G核心供应商利用Open5GS代码。比如说，NextEPC（4G系统，2019年更名为Open5GS以添加5G，剩余产品来自旧品牌）提供了面向LTE/5G的企业版，借鉴了Open5GS的代码。没有观察到外头有任何攻击或威胁迹象，但我们的测试使用已确定的场景表明存在潜在风险。

攻击的重要性在于攻击途径：来自UE的蜂窝基础设施攻击。利用该漏洞只需要一部移动电话（或通过蜂窝加密狗连接的计算机）和几行Python代码，就可以滥用该缺口，并发动这类攻击。GTP-U中的GTP-U攻击是一种众所周知的技术，回程IP安全和加密无法阻止这种攻击。事实上，这些安全措施可能会阻碍防火墙检查内容。

医疗和电力等关键行业只是专用5G系统的早期采用者之一，5G广泛使用的广度和深度只会与日俱增。对于这些行业来说，确保持续不间断运作的可靠性至关重要，因为这关系到千万条生命和实际影响。这些行业的性质决定了它们选择使用专用5G系统，而不是Wi-Fi。专用5G系统必须提供持久的连接，因为对任何5G基础设施的攻击得逞都可能导致整个网络瘫痪。

在本文中，滥用CVE-2021-45462可能导致DoS攻击。CVE-2021-45462（以及大多数GTP-U中的GTP-U攻击）的根本原因是分组核心中的错误检查和错误处理不当。虽然GTP-U-中的GTP-U本身无害，但修复这个漏洞的适当措施必须来自分组核心供应商，而基础设施管理员必须使用最新版本的软件。

GTP-U中的GTP-U攻击还可以用于泄露敏感信息，比如基础设施节点的IP地址。因此，GTP-U对等体应该准备好处理GTP-U中的GTP-U分组。在CT环境下，它们应该使用能够理解CT协议的入侵防御系统（IPS）或防火墙。由于GTP-U不是正常的用户流量，特别是在专用5G中，安全团队可以优先考虑并丢弃GTP-U中的GTP-U流量。

一般来说，SIM卡的注册和使用必须严格加以规范和管理。拥有被盗SIM卡的攻击者可以将其插入攻击者的设备，连接到网络部署恶意软件。此外，对于采用共享操作模式的一些人来说，安全责任可能很模糊，比如企业拥有的基础设施链的终端设备和边缘。同时，蜂窝基础设施归集成商或运营商所有。这给安全运营中心（SOC）带来了一项艰巨的任务：将来自不同领域和解决方案的相关信息整合在一起。

此外，由于需要停机和测试，定期更新关键基础设施软件以跟上供应商的补丁并不容易，也永远不会容易。因此，强烈建议使用IPS打虚拟补丁或采用分层防火墙。幸好，GTP中的GTP很少在实际应用中使用，因此可以完全阻止所有GTP中的GTP流量。我们建议使用结合IT和通信技术（CT）安全性和可视性的分层安全解决方案。实施零信任解决方案，为企业和关键行业增加另一层安全，以防止未经授权使用专用网络，以实现连续不中断的工业生态系统，并确保SIM卡只能从授权设备上使用。

参考及来源：https://www.trendmicro.com/en_gb/research/23/i/attacks-on-5g-infrastructure-from-users-devices.html