漏洞攻擊
蜂巢式行動網路封包核心漏洞第四篇：認證
根據我們的研究，Microsoft Azure Private 5G Core (AP5GC) 當中存在著兩個目前已解決的重大漏洞，本文深入探討這兩個漏洞。
重點摘要：
- 本文深入討論 Microsoft Azure Private 5G Core (AP5GC) 當中的兩個漏洞：CVE-2024-2068 與 ZDI-CAN-23960。
- CVE-2024-20685 漏洞可能導致行動服務中斷，而 ZDI-CAN-23960 漏洞則可能干擾部分的行動網路連線。
- 根據我們的分析，這兩個漏洞遭到攻擊都可能造成不同程度的阻斷服務 (DoS)，由於封包核心是關鍵的網路基礎架構節點，這意味著其衝擊將遠超過直接受影響的裝置，可能干擾一整個區段的網路。
簡介
本文是一系列有關蜂巢式行動網路封包核心漏洞的最新一篇文章，並以各種商用和開放原始碼產品來舉例，這些文章的重點在於發掘系統性問題與攻擊途徑，而非個別的漏洞。先前已經討論過的問題包括：元件之間缺乏交互檢查將如何導致連線階段注入攻擊、使用者裝置如何利用通道 (tunneling) 來攻擊基礎架構，以及元件之間的隔離不足將如何導致內部漏洞遭到攻擊。
本文將討論我們研究團隊發現的兩個 Microsoft Azure Private 5G Core (AP5GC) 漏洞：
- 利用一個特製的網路訊息讓控制平面當機。
- 利用一個特製的網路訊息將一台已連線的基地台斷線並加以取代。
這些是 AP5GC 實作上的漏洞，但駭客之所以能利用這些漏洞，其根本的問題在於一個系統性弱點：基地台與封包核心之間缺乏必要的認證程序。
Microsoft 已在 AP5GC 版本 2403.0-2 中修正了 CVE-2024-20685 漏洞 (攻擊途徑：網路)，並保證未來會解決 ZDI-CAN-23960 漏洞 (攻擊途徑：貼近)。
致謝
非常感謝台灣電信技術中心 (TTC) 的 Shumin Chuang 博士，感謝她在此研究期間所給予的指導和支持。
蜂巢式行動網路架構
蜂巢式行動裝置 (如手機和蜂巢式 IoT 裝置) 會透過無線射頻 (RF) 訊號連上無線電基地台，基地台再將這些 RF 訊號轉換成 IP 封包。基地台透過 IP 連線連上一個名為「封包核心」(Packet Core) 的中央基礎架構單元，這些回程 (backhaul) 的 IP 連線通常走有線網路。
蜂巢式行動網路架構大致分成兩個平面：控制平面與資料平面。控制平面負責處理用戶設備 (UE) 與封包核心之間的訊號連接，負責管理 UE 註冊 (attach)、認證、資料階段的建立等工作。資料平面 (也就是使用者平面) 負責處理使用者應用程式的流量。
此外，基地台與封包核心之間的連線也反映了這樣的劃分。控制平面會經由 SCTP 傳輸協定來執行，使用者平面流量會封裝在 UDP 當中，使用連接埠 2152。
5G 控制平面中對應第 7 層的通訊協定是「次世代應用程式協定」(NGAP)，經由 SCTP 連接埠 38412 來執行。NGAP 定義了各種訊號連接程序的網路訊息，這些訊息是以「抽象語法統一表示法」(Abstract Syntax Notation One，簡稱 ASN.1) 來執行序列化。
註：在 5G 術語中，基地台稱為「gNB」或「gNodeB」。在封包核心這端，控制平面節點稱為「存取與行動管理功能」(Access and Mobility Management Function，簡稱 AMF) ，使用者平面節點則稱為「使用者平面功能」(User Plane Function，簡稱 UPF)。
基地台和封包核心都需要 ASN.1 解析器，5G 控制訊息的 ASN.1 解析有時相當複雜。我們在這篇文章當中說明了使用者裝置如何觸發 ASN.1 漏洞來造成封包核心停擺。該文所介紹的技巧是從使用者平面觸發控制平面的 ASN.1 漏洞，而本文所探討 ASN.1 漏洞則是直接從控制平面觸發。
5G 訊息交換流程
基地台與封包核心之間會建立一個 SCTP 連線來傳送 NGAP 訊息。圖 4 顯示連線建立之後的典型訊息交換流程。
基地台會發送一個 NGSetUpRequest 來開始與 5G 核心 (5GC) 建立控制連線。
5GC 收到此訊息之後會先檢查其參數，然後透過 NGSetUpResponse 傳送「成功」或「失敗」的狀態。此步驟不需要認證。
此時，UE 可能會與基地台建立 RF 連線。一旦 RF 連線建立之後，UE 就會向基地台發送註冊請求。基地台會加入一些額外資訊，將資料封裝成一個 NGAP 封包，然後傳送至封包核心。
接著，UE 與封包核心之間會互相認證 (圖 4，封包 4、5)，接著再進行安全模式交涉 (封包 6、7)，最後再建立資料連線階段 (封包 10、11)。
圖 5 顯示訊息交換流程。
重點整理：
基地台與封包核心之間沒有規定一定要認證。
- 3GPP 標準並無 NGAP 認證的規定，而是建議基地台和 5GC 彼此建立一條 IPSec 連線或使用憑證式認證。
註冊是 UE 發送至 5GC 的第一個訊息，在認證與安全性功能建立「之前」傳送。
- 這意味著註冊請求會以純文字形式發送，並在未經認證的情況下由 5GC 處理。
本文所討論的漏洞是在 UE 認證與加密建立之前的前三個 NGAP 訊息當中觸發 (參見圖 4)。
Microsoft Azure Private 5G Core (AP5GC)
Microsoft Azure Private 5G Core 是 Microsoft 針對私人網路設計的 5G 封包核心。封包處理功能在 Azure Stack Edge (ASE) 硬體上執行，大多數的組態設定與管理都是從 Azure 雲端進行，ASE 硬體和 Azure 都採用訂閱方式。
AP5GC 是歸在 Microsoft Azure for Operator 產品陣容當中。
AP5GC 當中的認證
基地台與 AP5GC 之間預設不需要認證。事實上，我們在 AP5GC 的說明文件或組態設定入口網站上都找不到任何與這項認證相關的資訊。
攻擊的先決條件與準備
前述兩項攻擊的先決條件相同。
先決條件 1
AP5GC 需要使用者建立一個閘道來讓 gNB 連上 AMF。駭客必須連上這個閘道才能與 AP5GC 通訊。
準備工作：我們用來攻擊的電腦已連上閘道，我們使用 SCTP 掃描來尋找 AMF 介面。
先決條件 2
駭客必須先找到「公眾陸地行動網路」(PLMN)，其組態設定在封包核心 (AP5GC) 當中。蜂巢式行動基地台會將 PLMN 以純文字形式廣播，以便讓 UE 找到。
準備工作：使用軟體定義無線電 (SDR) 可擷取來自基地台的廣播訊息並找到 PLMN。
先決條件 3
駭客必須知道「切片服務類型」(Slice Service Type，簡稱 SST) 和「切片差分器」(Slice Differentiator，簡稱 SD)。
SST 數值一般使用標準值：1、2 或 3。SD 是選擇性的。請參閱 Microsoft 說明文件。
準備工作：由於 SST 最常用的數值是「1」，所以我們將 gNB 設定成：SST=1，SD 為空白。
CVE-2024-20685：Azure Private 5G Core 阻斷服務漏洞
駭客只要發送一個格式錯誤的特製 UE 註冊訊息，就能造成 AP5GC 服務阻斷，網路內所有行動裝置都將失去連線。
此漏洞的 CVE 編號為 CVE-2024-20685，在 ZDI 的編號為 ZDI-24-362 和 ZDI-CAN-23397。下圖顯示從封包追蹤中看到的攻擊過程。
攻擊環境架設
步驟 1、2 和 3 的訊息可手動製作並從一般的 SCTP 用戶端發送，不過，使用軟體定義無線電 (SDR) 來發送這類訊息以連上 5G 核心連線會更為方便。
srsRAN 是一個 SDR 套件，可同時支援軟體 UE (srsUE) 和 gNB (srsRAN gNB)。我們將 srsRAN 安裝在一台 Linux 電腦上，由於 srsRAN 可模擬無線電介面，因此就不需要無線電硬體。
我們的 srsUE – srsRAN gNB – AP5GC 連線架構如下：
192.168.1.101 是一個實際的無線電硬體基地台。
192.168.1.102 是安裝 srsRAN 的 Linux 電腦。
192.168.1.100 是閘道交換器。
192.168.1.10 是 AMF。
圖中的 Modifier 模組會攔截來自 gNB 的 InitialUEMessage Registration 訊息 (註冊訊息)，並將內容變更為我們所特製的惡意內容。我們使用 NFQ Python 腳本來執行這項工作。
結果
我們使用特製的內容來修改 InitialUEMessage Registration 請求，圖 9 顯示修改過的封包傳送之後所擷取到的封包。
AP5GC NGAP 層在 InitialUEMessage 之後便不再回應 (圖 9，封包編號：150)。此時任何傳送至 AMF 的 NGAP 控制訊息都會觸發 AMF 關機/重新啟動。有時，AMF 會自動重新啟動，但有時則必須「手動」重新啟動之後才能恢復正常運作。
圖 10 顯示圖 5 中的訊息傳送流程在攻擊情境下的變化。
問題根源
- 由於基地台與封包核心缺乏認證，因而使得駭客能夠將自己的 SDR 連上封包核心來發動更多攻擊。
- 此時，若 ASN.1 解析過程出錯，或者解析器發生錯誤而未正確處理，都可能造成當機。
ZDI-CAN-23960：Microsoft Azure Private 5G Core 未認證基地台覆寫
只要傳送一個含有合法基地台 ID 的任意 NGSetupRequest 至 AP5GC，就有可能讓原本已合法連線的基地台 (gNB) 遭網路剔除，原本基地台所服務的行動裝置將被迫中斷連線，惡意基地台將取代原本合法的基地台。
此漏洞在 ZDI 的編號是 ZDI-CAN-23960。
攻擊環境架設
192.168.1.102 是一個合法的基地台。
192.168.1.101 是一台安裝了 srsRAN 的 Linux 電腦。
192.168.1.100 是閘道交換器。
192.168.1.10 是 AMF。
圖中的 Fuzzer 會攔截來自 srsRAN gNB 的 NGSetupRequest，變更 gNB-ID，然後重複發送多個不同版本給 AMF。
結果
圖 12 顯示完整地封包追蹤過程。封包 52 當中的 NGSetupRequest (gNB-ID = 0) 是來自合法 gNB。它會在封包 54 當中收到一個成功的回應，並且連上網路。接著在封包 88 當中，駭客使用同樣的 gNB-ID (0) 又發送了一次 NGSetupRequest，此時 AP5GC 會中斷第一個 gNB 的連線 (封包 90)，並且在封包 91 中回應最後收到的請求。
此漏洞的根源是 AP5GC 直接信任最後收到的 NGSetupRequest 而未經任何檢驗，並且會中斷任何目前連上該 gNB (相同 gNB-ID) 的連線。
問題根源
- 由於過程缺乏認證，因此駭客能發送連線請求給 AP5GC 並獲得回應。
- 由於收到的訊息未經過適當檢查，因此駭客才能騙過 AP5GC，誤將駭客當成合法基地台。
衝擊
以上兩項攻擊都會造成不同程度的阻斷服務 (DoS)，由於封包核心是關鍵的網路基礎架構節點，所以其衝擊遠超過直接受影響的裝置，可能干擾一整個區段的網路。
第一項攻擊 (CVE-2024-20685) 可癱瘓整個控制平面，導致服務完全中斷，所有連上行動網路的裝置都會失去連線。
第二項攻擊 (ZDI-CAN-23960) 會將某個中繼節點 (也就是基地台) 踢出網路，所有連上該基地台的裝置都會失去連線。除此之外，還會讓駭客所掌控的基地台進入網路當中，進而發動更多其他攻擊。
公共網路發生中斷的情況並不常見，但也並非罕見 (如 1 & 1 、AT&T 、T-Mobile 就曾經發生過)。5G 專網廣泛應用於關鍵基礎設施，所以服務中斷會嚴重影響安全和營運。
駭客若要執行本文介紹的攻擊，必須得存取控制平面子網路，這點也許可以稍微和緩可能立即遭到攻擊的憂慮。以上兩個漏洞在 CVSS 都被列為「中」嚴重性等級。
截至目前為止，我們尚未見過任何這些漏洞的攻擊案例。
如何降低風險
CVE-2024-20685 利用的是 ASN.1 解析器的問題；ZDI-CAN-23960 則是利用訊息未嚴格檢查的問題。但這兩項攻擊都得在基地台與封包核心之間缺乏認證的情況下才能實現，所以這一點才應該是解決問題的第一步，包括：
- 在基地台與封包核心之間使用 IPSec 連線。
- 在基地台與封包核心之間使用憑證式認證。
- 建立已授權基地台允許名單/白名單。
- 實施控制平面子網路的存取控管與隔離。
- 採用深度封包檢查 (DPI) 解決方案在廠商釋出修正之前提供虛擬修補。
揭露及回應
我們已透過 Zero Day Initiative (ZDI) 漏洞懸賞計畫向 Microsoft 通報這兩項漏洞。
Microsoft 已修正了 CVE-2024-20685。
ZDI-CAN-23960 是在 2024 年 4 月 25 日通報給 Microsoft，Microsoft 的回覆是：「我們已將您的通報轉交給負責維護該服務的團隊以確保我們客戶的安全，他們會根據其內部時間表採取必要的行動。」