阅读： 2

一、前言

随着5G网络的建设完善和相关设备的普及，人们逐渐享受到5G带来的便利——不仅仅在于网速变快，还有生产效率的提升，甚至生产方式的革新。5G在各行各业都将得到应用，但综合来看，核心应用场景主要有以下3个^[1]：

1. 增强型移动宽带（eMBB）：意味着更大的网络吞吐量、峰值速率和低延时；
2. 海量机器通信（mMTC）：意味着巨大的连接数量，以支持海量物联网设备；
3. 高可靠低时延通信（uRLLC）：意味着网络的高可靠性和超低时延。

安全的价值通常随着业务价值的提高而提高。毫无疑问，5G安全正在变得越来越重要。我们梳理了现有的5G安全相关资料，其中：

3GPP TS 33.501规定了“5G系统的安全架构和步骤”（Security architecture and procedures for 5G system）^[2]；ENISA编写了《5G规范中的安全（Securtity in 5G Specifications）》^[3]；5G Americas推出了《5G网络安全的演进（The Evolution of Security in 5G）》^[4]及《5G时代的安全考虑（Security Considerations for The 5G Era）》。

另外一些文章及议题^[5][6][7][8]则从攻击者视角对5G网络的脆弱性和威胁进行了分析，但是主要集中在接入网和承载网两部分。

绿盟科技曾通过系列文章介绍5GC网元异常检测，相关研究成果已经发表在“绿盟科技研究通讯”公众号上，供读者参考：

1. 如何用全流量检测5G核心网网元服务异常
2. 新架构，新挑战：5G核心网业务安全问题与异常检测
3. 5G核心网：模拟环境搭建与网元通信关系还原

本文将跟大家分享绿盟科技在5GC威胁分析工作中的典型案例。这些研究基于台湾阳明大学开源的5G核心网free5GC^[9]展开。

后文的组织结构如下：

• 背景知识：介绍理解本文所需的必要背景知识。由于前述已经发表的5G安全研究文章中已经对5GC基本概念做了介绍，本文将不再介绍那些与正文内容相关度小的5G专业知识。
• 威胁案例：这部分是文章的核心内容，我们将按照网元来分类介绍不同的5GC威胁场景。
• 自动化测试：这部分将展示一个测试程序，该程序部分固化了前述威胁场景，我们将使用该程序演示一个多步威胁案例。
• 防御对策：针对前文描述的威胁场景提出防御对策。
• 总结与思考：对本文介绍的内容进行总结。

二、背景知识

2.1 基于服务的5GC架构

移动通信网络一般由三部分组成^[10]：

1. 接入网：指手机等移动通信设备直接连接到的网络，基站就属于接入网设备的一种。
2. 承载网：指用来打通基站与核心网，负责承载、汇聚数据的网络。
3. 核心网（对于5G而言就是5GC）：指用来进行数据处理和路由交换的骨干网络，实现移动通信设备与互联网的通道建立。

5G通信网络广泛采用了SDN和NFV技术。其中，5GC采用了基于服务的架构，整个5GC被拆分为不同的网元（Network Function，简称NF），每个网元以RESTful API的形式对外提供特定服务。关于5GC网络的详细介绍，可见本期文章《深中肯綮：利用全流量检测5GC网元服务异常》基于服务的5GC架构部分。

3GPP协议详细描述了各网元提供的服务，例如3GPP TS 29.510描述了NRF的相关服务。内容较多，大家可自行查看，这里不再展开，后文中我们会结合具体威胁场景对相关服务进行介绍。

2.2 free5GC

5G相关协议虽然是公开的，但5G网络设备却不易获得，这给包括安全在内的各方面研究带来了困难。幸而，5GC多采用软件方式实现，如容器、云原生技术，因此人们可以根据协议开发一套符合规范的5GC系统。free5GC^[9]正是这样的一套系统，它由台湾阳明大学研究者采用Go语言开发并开源。free5GC已经支持docker-compose^[11]和Kubernetes^[12]部署，非常方便。

以docker-compose方式部署为例，部署完成后，我们可以使用相关命令列出free5GC各个网元容器实例。

后续可能需要用到特定网元（如NRF）的IP，可以在命令行执行以下命令获得：

ctr_id=$(docker ps | grep nrf | cut -d’ ‘ -f 1); docker exec -it $ctr_id cat /etc/hosts | grep $ctr_id

需要注意的是，free5GC虽然提供了较为完善的5GC环境，甚至能够配合基站等基础设施真正实现设备接入和正常使用，但是它并不具备认证授权等非实验必要的机制。后文绝大多数攻击场景成立的前提正是攻击者对5GC网络的可达性和认证授权机制的缺失，这一点与真实5GC环境存在差异，也是研究的局限性所在。然而，开展这些研究仍有意义，我们将在第6部分对此进行阐述。

三、威胁案例

本部分将以NRF、AUSF、UDR这3个网元为例，展示6个针对它们的威胁场景。

3.1 攻击NRF

NRF即Network Repository Function，中文名称是“网络存储库功能”，相当于一个加强版DNS，用来维护在线的网元实例信息。

对于攻击者来说，如果能够与NRF交互，就能够利用NRF获得其他网元的信息，还能够直接影响5GC的正常运行，价值巨大。因此，NRF是首当其冲的目标之一。

3.1.1 窃取网元信息

攻击者可能会利用NRF的查询、订阅等功能窃取网元活动信息，从而监视5GC的运行状态，并利用这些信息实施假冒网元等进一步恶意活动。

例如，我们能够借助NRF提供的NFDiscovery服务窃取信息。

3.1.2 恶意注销网元

攻击者可能会在NRF中注销现有网元的记录（NF Profile），导致其他网元不能发现该网元，进而无法使用该网元提供的服务，最终导致5GC网络无法正常运行，表现为拒绝服务。

例如，我们首先查询到正常SMF网元的ID，把正常的SMF网元恶意注销掉，然后再次查看，NRF就会报告查无此网元。

3.1.3 注册恶意网元

攻击者可能会注册恶意网元，并与其他网元进行交互，从而在5GC中长期潜伏，进行数据窃取和破坏活动。

例如，我们可以向NRF注册假冒SMF。

上图中，我们将SMF的apiPrefix设定为http://uuu.free5gc.org:29502，攻击者可能会设定为他能控制的任意地址。

注册成功后，我们能够从NRF中查询到该网元：

3.2 攻击AUSF

AUSF即Authentication Service Function，中文名称是“鉴权服务功能”，顾名思义，提供鉴权服务。

借助AUSF，攻击者可能获得UE的SUPI，从而为后续渗透打开局面。

3.2.1 窃取UE的SUPI

SUPI是5G网络里用户的永久标识符，相当于IMSI，由MCC（移动国家代码，如中国是460）、MNC（移动网络代码，各运营商不同）和MSIN（移动用户识别号码）组成。为了防止SUPI在传输过程中被嗅探，网络中实际传输的是SUPI加密后的SUCI（用户隐藏标识符）。SUPI中实际被加密的部分只有MSIN，MCC和MNC是公开、已获得的。

free5GC环境AUSF的Nausf_UEAuthentication服务接口有一个特性，用户正确提供SUCI号码时相关接口会返回SUPI，SUCI错误时返回USER_NOT_FOUND。攻击者可能会利用这一点特性，以两种方式窃取UE的SUPI信息，从而进行后续恶意活动。

1. 的SUCI情况下，直接请求相关接口，获得UE SUPI；
2. UE的SUCI的情况下，将MCC、MNC与随机生成的加密部分（秘钥组索引+密文）组合，生成SUCI字典，暴力破解出合法SUPI。

我们可以简单测试验证。例如，下图中在传递错误SUCI时（supi-0-208-93-0000-0-0-0000000002，系统中不存在该UE），AUSF返回400错误；但在传递正确SUCI加错误的resStar消息后，系统虽然提示认证失败，但是返回了相应的SUPI（imsi-208930000000003）。

大家可能会有疑问：因为上面的SUCI并不是加密后的SUPI。这是因为free5GC作为实验系统，在生成SUCI的过程中并没有对SUPI加密。但是，根据3GPP TS 29.509协议^[13]，在符合协议的5GC环境中，使用SUCI按照上述方式请求相关接口，确实会返回SUPI，这种方式是存在的。协议附带的YAML^[14]对返回结果的内容定义如下：

3.3 攻击UDR

UDR网元即Unified Data Repository，中文名称是“统一数据仓库”。顾名思义，它的主要功能就是存储数据。它可供UDM存储和检索用户数据，供PCF存储和检索策略数据等。

数据库的重要性不言而喻，攻击者同样能够从数据库中获得有价值的信息，甚至修改数据库内容，以达到某些目的。

3.3.1 窃取UE的AMF ID

攻击者可以利用已经获得的特定UE的SUPI，从UDR中窃取负责该UE接入的AMF ID，为后续渗透提供帮助（如在NRF中指定AMF ID注销网元）。

例如，下图中我们窃取了SUPI为imsi-208930000000003的UE的AMF ID信息。

3.3.2 重置UE认证状态

UDR存储了UE的认证状态，并提供修改接口。如果攻击者修改了特定UE的认证状态（改为false，如下图所示），后续其他网元将发现该UE处于未认证状态，通信服务可能受到影响。

四、自动化测试

基于在free5GC中发现的威胁场景，我们编写了一个集成脚本，自动化发起相关场景的测试行为，以检测防御机制的有效性。

下面，我们以“从UPF发起攻击”的场景为例（本文结尾的总结部分将对该场景的合理性进行简单阐述），通过3个连贯的综合性测试对自动化测试流程做简单介绍。为了贴近现实环境，我们使用Kubernetes部署5GC^[12]。

测试1：在这个环境中，假设攻击者已经通过攻击取得UPF的控制权限，并得知NRF的IP和端口，那么他可以在UPF内通过NRF获得其他网元的IP及端口信息（3.1.1“窃取网元信息”）。

窃取成功后，程序已经自动记录了相关数据，我们可以查看相关网元的IP及端口。

+-> 0
[nrf]  service(s): 192.168.36.5:8000
[ausf] service(s): 192.168.36.4:8000
[nssf] service(s): 192.168.36.6:8000
[smf]  service(s): 192.168.36.3:8000
[udm]  service(s): 192.168.36.7:8000
[amf]  service(s): 192.168.36.2:8000
[udr]  service(s): 192.168.36.8:8000
[pcf]  service(s): 192.168.36.9:8000

测试2：假设攻击者已经掌握了某UE的SUCI（通过嗅探等方式得到），他希望获得该UE的SUPI，从而根据SUPI将对应UE修改为未认证状态（3.2.1“窃取UE的SUPI”和3.3.2“重置UE认证状态”）。

测试3：假设攻击者已经掌握了某UE SUPI（来自“测试2”），他希望将该UE对应的AMF网元注销掉（3.3.1“窃取UE的AMF ID”、3.1.2“恶意注销网元”和3.1.1“窃取网元信息”）。

首先获得该UE对应的AMF ID。

+-> 7
SUPI: imsi-208930000000003
id of amf specified by ue <imsi-208930000000003> is [fb672ae1-8ffd-49b4-859b-c8765f2ffd27]

然后看下在“测试1”中窃取到的对应AMF信息。

+-> 1
NF type (lowercase, ‘all’ for all NFs): amf
–> amf instance <–
id: 039fba76-20c5-4629-bbd4-dd33829db170
ipv4 address(es): 192.168.36.2
plmn:  mcc: 208   mnc: 93
s-nssai:  sst: 1 sd: 010203
s-nssai:  sst: 1 sd: 112233
… # 省略多个AMF实例
–> amf instance <–
id: fb672ae1-8ffd-49b4-859b-c8765f2ffd27
…

接着，使用拿到的AMF实例ID注销对应实例。

+-> 5
NF instance ID: fb672ae1-8ffd-49b4-859b-c8765f2ffd27
nf instance <fb672ae1-8ffd-49b4-859b-c8765f2ffd27> deregistered in nrf successfully

再次从NRF中窃取AMF网元信息，并查看更新后的AMF实例列表。

可以发现，fb672ae1-8ffd-49b4-859b-c8765f2ffd27对应的AMF实例已经不存在了。

五、防御对策

前面，我们已经为大家介绍了针对3个网元的6个威胁场景。如何避免5GC环境遭受以上威胁及其他类似但文中没有提到的威胁呢？

加固对策：首先，一定要有健全的网络隔离机制和认证授权机制。确保攻击者不能轻易进入5GC网络，即使进入也不能轻易与5GC网元交互。

检测对策：5GC采用基于服务的架构，网元服务间的调用频繁而有规律。“前言”部分给出了绿盟科技已经发表的3篇检测相关的文章，文章中提到的链路还原和历史基线方法能够较为有效地针对上述威胁进行检测，供读者参考。

攻击是点的突破，安全却是面的防护。5GC及5G的安全势必需要一套完整的解决方案实现全面覆盖。挂一漏万，此处不再详细展开，感兴趣的朋友可以联系绿盟科技进一步交流。

六、总结

本文分享了多个针对5GC网元的威胁分析案例，并借助自动化攻击测试程序固化威胁场景，基于free5GC环境进行演示。最后，针对前述威胁场景，我们也给出了一些切实可行的防御对策。读者也可参考“前言”部分提到的3篇历史文章。

显而易见的是，以上威胁场景均基于一个前提：攻击者能够向任意网元发送任意请求。结合实际环境，这一前提可以拆解为两个子条件。

1. 攻击者能够访问到5GC网元；
2. 攻击者具有一定权限。

第一点要求网络可达，第二点要求能够绕过认证授权机制（如果存在）。大家可能会存在疑问：这样的环境在现实中真的存在吗？

不可否认，现实中的5GC作为关系到国计民生的关键基础设施的核心组成部分，其安全机制设计与执行必然是重中之重。普通的攻击者与一般的攻击行为基本没有威胁到5GC网元的可能。然而，它的重要程度也意味着一旦受到攻击，后果将十分严重——无论是拒绝服务还是通过注册恶意网元等形式长期潜伏（后者可能更糟）。

另外，结合现实就必须全盘结合现实，考虑到各种现实场景。例如，为了减少数据传输的迂回，现实中运营商可能会采取“UPF下沉”的方案^[15]，简单来说，就是将UPF部署在各地传输节点，甚至与基站融合。这样一来，UPF面临的物理和虚拟安全环境将可能与集中部署的5GC其他网元不同，但它却仍然需要与其他网元保持网络畅通（至少需要与SMF网元通信）。从这一角度来讲，UPF可能会成为整个系统中的相对薄弱之处，其安全性需要更加重视，而相关研究将进入MEC安全范畴，在此不再展开。

综上所述，5GC是名副其实的“要害之地”，相关威胁不可不察，不可不防。希望本文能够帮助大家增进对5GC安全的认识和重视。如有描述不当之处还请指出，欢迎交流。

参考文献

[1] https://www.ithome.com/0/522/208.htm

[2] https://itectec.com/archive/3gpp-specification-ts-33-501/

[3] https://www.enisa.europa.eu/publications/security-in-5g-specifications

[4] https://www.5gamericas.org/wp-content/uploads/2019/08/5G-Security-White-Paper_8.15.pdf

[5] Security and Protocol Exploit Analysis of the 5G Specifications

[6] Security Analysis Of 5G Mobile Networks

[7] New Vulnerabilities in 5G Networks

[8] https://conference.hitb.org/files/hitbsecconf2021ams/materials/D2%20COMMSEC%20-%205G%20Networks%20and%20Interconnect%20Threats%20-%20Martin%20Kacer.pdf

[9] https://www.free5gc.org

[10] https://www.zhihu.com/question/325934238

[11] https://github.com/free5gc/free5gc-compose

[12] https://zhuanlan.zhihu.com/p/138629674

[13] https://itectec.com/archive/3gpp-specification-ts-29-509/

[14] https://github.com/jdegre/5GC_APIs/blob/master/TS29509_Nausf_UEAuthentication.yaml

[15] https://blog.csdn.net/weixin_39678451/article/details/111670982

版权声明

本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。