上个月的 USENIX Security（第 35 届）上，新加坡南洋理工大学（NTU）的团队公开了一套叫 iFinder 的多智能体工具：它在管控 4G/5G 移动核心网的开源软件里，累计挖出了 84 个安全漏洞。这 84 个漏洞分布在 7 个开源核心网实现里，包括 Open5GS、free5GC 和 OpenAirInterface；开发者已确认其中 83 个，相关机构为 81 个分配了 CVE 编号，58 个已经出了补丁。风险最高的一条，能让攻击者把用户的互联网流量静默重定向到自己的服务器。最值得琢磨的不是"AI 又挖到洞了"这个结论，而是它挖到的东西几乎都指向同一个根因：核心网功能模块之间互传消息时不做校验。这条根因是过去物理隔离时代留下的遗产，也是这 84 个漏洞真正值得拆的地方。

根因：核心网 NF 之间的隐式信任

传统核心网是单体硬件盒子，跑在运营商机房里，网段物理隔离、组件之间完全互信。所以协议设计时默认：一个网元发来的消息，字段一定是合法的，用不着校验。5G 核心网（5GC）改成了服务化架构（SBA），网元拆成一个个 NF（网络功能），用 HTTP/2 的 SBI 接口互相调用；用户面、控制面分离，控制面的 SMF 通过 N4 接口用 PFCP 协议（3GPP TS 29.244）去控制用户面的 UPF。软件组件迁上云、跑在 COTS 硬件上之后，那个"边界内全都可信"的前提就不成立了。NTU 团队的原话是：如果系统里任意一个组件被攻破，或者存在缺陷允许攻击者从外部注入信息，这种默认的隐式信任会把风险成倍放大。

84 个漏洞里，有相当一部分直接继承自 4G 代码。现在很多运营商是 4G/5G 双网并存，同一段有缺陷的逻辑在两代网络里都能被触发。这个"代码级继承"的细节很重要：它意味着修 5G 的洞，不能只看 5G 分支，得顺着 4G 的老代码一路追。

最危险的一条：UPF 不校验 PDR ID 唯一性

整篇论文里风险最高的是用户面功能（UPF）里的一个会话劫持漏洞。要讲清楚它，得先把 UPF 是怎么被控制的说清楚。

UPF 负责真正转发用户的业务流量，但它不自己决定转发规则，而是被动接受 SMF 下发。SMF 和 UPF 之间走 N4 接口，用的协议是 PFCP。SMF 通过 PFCP 的会话修改请求（Session Modification Request）往 UPF 里塞三类规则：包检测规则 PDR（决定匹配哪些包）、转发动作规则 FAR（决定匹配到的包往哪转发）、QoS 执行规则 QER。每条 PDR 有唯一的 PDR ID、一个优先级 Precedence、一段描述匹配条件的 PDI（包检测信息，比如源/目的 IP、GTP 隧道端点 TEID），再挂一个指向某条 FAR 的 FAR ID，告诉 UPF 匹配上的包该转发到哪条路。

问题出在 UPF 收到会话修改请求时，不校验请求里带进来的 PDR ID 是不是和已有规则冲突。攻击者只要能注入一条优先级更高的重复 PDR，把它的 FAR ID 指到自己控制的服务器，受害者的上行流量就会被劫走——正常应该转发到互联网的数据，拐进了攻击者的 N6 出口。NTU 团队在受控环境下的两套商用 5G 核心网里完整复现了这条链路，不是纸面推演。

这里有个反直觉的点值得单独说：即便用户面流量全都加密，劫持依然有效。流量分析早就不需要看明文了——包大小、包序列、包间间隔这些元数据就够提取出大量敏感信息。所以"上了加密就安全"在这个场景里是个误区。

攻击面：注入消息的入口在哪

要理解这个洞的真实威胁，得先回答"攻击者怎么把伪造的 PFCP 消息送到 UPF 面前"。答案是 5GC 服务化之后暴露面变多了。SBA 架构里 NF 之间走 HTTP/2 的 SBI 接口，AMF、SMF、AUSF、NEF 这些控制面网元通过统一的服务注册与发现机制互相调用；NEF（网络开放功能）这类网元本来就是设计给第三方应用访问的入口，AF（应用功能）也会触发核心网做会话修改。任何一个 NF 被攻破，或者 SBI 接口上存在能伪造请求的缺陷，攻击者就拿到了"注入消息"的能力。剩下的，就是 SMF 到 UPF 这条 N4 链路上那句"消息不校验"。

也就是说，UPF 的 PDR ID 唯一性缺陷不是孤立的，它是"控制面信任塌陷"这条链上的最后一环。前面任何一环薄弱，最终都会汇聚到 UPF 这里变成流量劫持。这也是为什么 NTU 团队反复强调"任何组件被攻破都会放大风险"，而不是把它当成某个模块的孤立 bug。

iFinder 的多智能体流水线

工具本身的设计比"拿大模型扫代码"精细得多。iFinder 的起点是 GitHub 上公开上报的 22 个 Open5GS、free5GC 历史漏洞。团队按根因给它们分类，归纳出 6 种检测模式。举例：一种是代码直接访问消息里的必填字段，却从不校验字段是否存在。这类"直接解引用"的缺陷，正是 NF 之间隐式信任在代码层面的投影。

检测流程拆成四个 Agent 分工：

  1. 标准整理 Agent：把 3GPP 标准文档和那 6 种检测模式喂给模型，建立"什么字段该校验、什么消息该拒绝"的规范上下文。
  2. 匹配 Agent：在 7 个开源项目的源码里找符合模式的缺陷位置。
  3. 核验 Agent：对候选漏洞做真伪判定，过滤掉假阳性。
  4. 利用 Agent：给确认的漏洞写 PoC，把代码部署到测试环境里跑，再根据运行日志反复迭代，直到利用成功或达到重试上限。

四个 Agent 跑在 Anthropic 的 Claude Opus 4.5 上。最后一步是人工复核，再上报给开源项目维护者——不是全自动甩手，AI 负责把候选集合压缩到人看得过来的规模。

精度数据：从 28% 到 75%

论文里的对照实验把"直接提示模型"和"iFinder 流水线"放一起比。在 22 个已知漏洞上，如果直接把检测模式塞给模型让它扫，只能检出 8 个，同时产生 56 个误报；iFinder 检出 15 个，误报压到 12 个。检测精度从 28% 提到 75%。利用 Agent 更明显：它给 19 个已知漏洞写出了能跑的利用代码，而直接调模型只能完成 8 个。

团队还试了别的模型。Lin Ziyu（论文一作、NTU 博士生）特别提了一句：Kimi K3 在基准测试里分数很高，真拿去挖洞还是会幻觉。原话是"要找到真实存在的漏洞，必须设计专门的工作流"。这句话其实是整套工具最有价值的方法论结论——大模型在漏洞挖掘上的瓶颈不是模型能力，而是没有把"标准 → 模式 → 匹配 → 验证 → 利用"这条闭环搭起来。直接一句提示词让模型"找出所有漏洞"，得到的只有高分幻觉。

我的看法：防御侧能立刻做的三件事

对做移动核心网或相关协议栈的人，这篇论文给出的防御建议里有几条可以直接落地：

第一，优先修已公开的 CVE。这 81 个 CVE 已经摊在桌上了，攻击者会用 AI 自动去翻 3GPP 变更请求和历史披露，把"没人留意"变成"随时可用的武器"。拖得越久，被动的不是漏洞本身，而是你还在用"信息不对称"当防线——这条防线在 AI 面前已经失效。

第二，内部接口上双向认证，把零信任推到网元之间。UPF 那个洞的本质是"控制面消息默认可信"。如果 N4、SBI 这些内部接口强制双向 TLS、校验消息来源和完整性，注入伪造会话修改请求的难度会上升一个量级。核心网软件定义化之后，补丁推送越来越快，这反而让"认证 + 快速修复"的组合比过去更可行。

第三，别指望加密或后量子密码兜底。NTU 团队明确点了这个：PQC 设计目标不包含阻止侧信道信息泄露，流量一旦被重定向，元数据分析照样有效。安全的重心得放在"别让流量被劫走"这件事上，而不是"劫走了也看不懂"。

一个更朴素的观察：这 84 个漏洞几乎都来自"消息不做校验"这一个根因。对做协议实现的开发者来说，最划算的防御不是追着每个 CVE 打补丁，而是在入口处加一层统一的输入校验——字段存在性、ID 唯一性、边界值。iFinder 那 6 种检测模式，反过来就是一张现成的防御清单。

顺带提一句标准侧的问题。NTU 团队对 3GPP 的漏洞处理流程并不客气：3GPP 发布的海量文档里，包括变更请求，其中记录的安全问题有些能拖上好几年没人修。Wang Xiaofeng 的原话是"他们把大量信息直接堆在网上，指望没人会留意"。放在过去信息不对称的年代，这招或许管用；现在威胁行为者可以用 AI 自动去翻这些公开文档挖可利用的洞，等于给 3GPP 和运营商换了一批实力更强的对手。

⚠️ 网络安全免责声明

本文内容仅供技术研究与安全学习之用。文中描述的漏洞分析、攻击链拆解和方法介绍均基于公开披露的安全研究（NTU 团队在第 35 届 USENIX Security 上发表的论文及 ComputerWeekly 的公开报道），旨在帮助开发者理解核心网安全风险、提升防御意识与能力。

请勿将本文所述技术用于任何未经授权的安全测试、渗透攻击或非法用途。任何因滥用本文信息而造成的法律后果，由使用者自行承担，与本文作者无关。

如发现系统安全漏洞，请通过合法渠道向相关厂商或平台报告，共同维护网络安全生态。

参考：ComputerWeekly《NTU uses AI agents to uncover flaws in mobile networks》；NTU 团队在第 35 届 USENIX Security 上的论文（iFinder）。