漏洞攻擊
從使用者裝置攻擊 5G 基礎架構
利用 5G 核心網路中的漏洞，從手機之類的行動裝置發送精心製作的封包，就能攻擊蜂巢式行動基礎架構。一些關鍵產業，如：國防、公共事業、醫療業在日常營運中使用的智慧裝置都仰賴 5G 所帶來的速度、效率及生產力。本文說明 CVE-2021-45462 漏洞可能被用來對 5G 私有專屬網路發動阻斷服務 (DoS) 攻擊的情境。
5G 帶來了傳統無線網路做不到的各種前所未見的應用，協助企業加快數位轉型、降低營運成本、發揮最大的生產力與投資報酬。要達成這些目標，5G 須仰賴幾項關鍵服務：大規模機器型通訊 (mMTC)、增強型行動寬頻通訊 (eMBB) 以及超可靠低延遲通訊 (URLLC)。
隨著更多商用頻譜的釋出，5G 專網的普及率也不斷攀升。製造、國防、港埠、能源、物流以及採礦只不過是幾個最早採用這類私有專屬網路的領域，特別是一些加速導入物聯網 (IoT) 來將生產線與供應鏈數位化的企業。有別於公共網路，5G 專網中的蜂巢式行動基礎架構設備可能屬於私人所有，並由企業使用者本身、系統整合商或電信業者負責營運。然而，隨著各種 5G 應用技術開發相關的研究及探索不斷增加，網路駭客也正利用各種可經由這項最新通訊標準來駭入一般使用者與企業機構系統及網路的威脅與風險。本文說明一般使用者裝置如何被用於攻擊 5G 網路基礎架構的情境。
5G 網路拓樸
在一個端對端 5G 蜂巢式行動網路中，用戶設備 (簡稱 UE，如：手機與物聯網 [IoT] 裝置) 是透過無線電波來連上基地台，基地台再透過有線的 IP 網路連上 5G 核心網路。
從功能上劃分，5G 核心網路大致可分成兩個部分：控制平面 (control plane) 與使用者平面 (user plane)。控制平面負責在網路內部傳遞訊號並促進流量的交換，好讓流量從一個端點順利送達另一個端點。至於使用者平面，則是負責連接和處理流經無線區域網路 (RAN) 的使用者資料。
基地台會利用「次世代應用程式協定」(Next-Generation Application Protocol，簡稱 NGAP) 發送與裝置連接相關的控制訊號給控制平面，並建立連線。裝置產生的使用者流量會透過「GPRS 通道協定使用者平面」(GPRS Tunneling Protocol User Plane，簡稱 GTP-U) 發送到使用者平面，使用者平面再將資料流量發送至外部網路。
用戶設備 (UE) 子網路與基礎架構網路彼此是分開隔離的，所以用戶設備不得存取基礎架構元件。這樣的隔離有助於保護 5G 核心網路，防止來自用戶設備的蜂巢式技術 (Cellular Technology，簡稱 CT) 通訊協定攻擊。
那麼，駭客有辦法打破這樣的隔離並攻擊到 5G 核心網路嗎？ 以下詳細說明駭客如何利用 5G 基礎架構當中的元素 (尤其是 GTP-U) 來做到這點。
GTP-U
GTP-U 是一種存在於基地台與 5G 使用者平面之間的通道協定 (tunneling protocol)，使用連接埠 2152。下圖是使用者資料封包被封裝 (encapsulate) 在 GTP-U 當中的樣子。
GTP-U 通道封包是在原始的資料封包之外再附加一個標頭，這個附加上去的標頭包含了一個 UDP (User Datagram Protocol) 傳輸標頭和一個 GTP-U 專屬的標頭。GTP-U 專屬的標頭包含下列欄位：
- 旗標：含有版本與其他資訊 (例如是否包含選擇性的標頭欄位等等)。
- 訊息類型：對於攜帶使用者資料的 GTP-U 封包，訊息類型為 0xFF。
- 長度：這是「通道端點識別碼」(Tunnel Endpoint Identifier，TEID) 欄位之後所有資料的總長度 (位元組)。
- TEID：用來將通道對應至使用者裝置的獨一無二識別碼。
GTP-U 標頭是由 GTP-U 節點所附加上去，例如基地台和「使用者平面功能」(User Plane Function，簡稱 UPF)，不過在使用者裝置的操作介面上是看不到標頭的，因此使用者裝置無法竄改標頭裡的欄位。
雖然 GTP-U 是一種標準的通道技術，但它卻僅限用於 CT 環境的「基地台與 UPF」或者「UPF 與 UPF」之間。最好的情況是：基地台與 UPF 之間的回程流量 (backhaul) 都採用了加密，並設有防火牆保護，而且從外部無法存取。以下就是理想的狀況：GSMA 建議基地台與 UPF 之間應採用 IP 安全協定 (IPsec)。在這樣的情況下，GTP-U 節點所收到的封包必定是源於已被授權的裝置。只要這些裝置確實依照規格正確地實作，那它們就不會產生任何異常的封包。此外，任何嚴謹的系統也應該要有嚴格的正確性檢查機制來處理收到異常封包的情況，尤其是一些明顯的問題，例如無效的資料長度、類型、延伸資料等等。
但現實情況經常並非如此，所以才需要一套截然不同的分析方法。電信業者通常不願意在 N3 介面上部署 IPsec，原因是會耗費大量 CPU 運算資源，並且降低使用者流量的吞吐量。此外，由於使用者資料原本就應該仰賴應用程式層次的防護，並搭配「傳輸層安全性」(TLS) 之類的通訊協定，因此有人覺得 IPsec 是多餘的。他們覺得，只要基地台與封包處理核心完全符合規範，那就不會發生異常狀況。更何況，他們也認為所有嚴謹的系統都應該有一些正確性檢查機制來抓出明顯異常的情況。但先前已有研究指出，世界各地都有許多 N3 節點 (如 UPF) 暴露在網際網路上 (儘管這不應該發生)。下圖說明了這樣的狀況。
圖 3：由於態設定錯誤或未設置防火牆而暴露在網際網路上的 UPF 介面：引用自先前發表的研究所刊登的一張 Shodan 截圖。
以下討論兩個利用 CVE-2021-45462 漏洞來攻擊 GTP-U 的概念。Open5GS 是一套以 C 語言撰寫的開放原始碼 5G 核心網路與「演進式封包核心」(Evolved Packet Core，簡稱 EPC，也就是 4G 網路核心) 的實作，它可讓使用者裝置發送一個長度為零、類型為 255 的 GTP-U 封包，進而導致 UPF 發生阻斷服務 (DoS) 狀況。這就是 CVE-2021-45462 漏洞，這是一個存在於封包處理核心的資安漏洞，駭客可在 UE 上特製一個異常的 GTP-U 封包，然後將這個異常封包放入一個 GTP-U 封包當中發送，就能導致 5G 網路的 UPF 或 4G/LTE 網路的「服務閘道使用者平面功能」(Serving Gateway User Plane Function，簡稱 SGW-U) 當掉。由於這項攻擊手法影響的是基礎架構中的關鍵元件，而且不容易解決，因此該漏洞已被歸類為中高嚴重性的漏洞。
GTP-U 節點：基地台與 UPF
GTP-U 節點是負責封裝 (encapsulate) 與解封 (decapsulate) GTP-U 封包的端點。基地台是使用者裝置端的 GTP-U 節點。當基地台收到來自 UE 的使用者資料時，它會將資料轉成 IP 封包，然後封裝在 GTP-U 通道中。
UPF 是 5G 核心網路 (5GC) 端的 GTP-U 節點。當它收到一個來自基地台的 GTP-U 封包時，UPF 會將它外層的 GTP-U 標頭去除，分離出內層的封包。UPF 會尋找封包的目的地 IP 位址是否在 UPF 所保留的路由表中，但不會查看內層封包的內容，接著，將封包往目的地發送。
GTP-U 內的 GTP-U
假使，駭客在使用者裝置上特製了一個異常的 GTP-U 封包，然後發送給封包處理核心，會發生什麼狀況？
如駭客所願，基地台會將這個封包封裝在 GTP-U 通道當中發送到 UPF，結果就導致 UPF 收到一個封裝在 GTP-U 內的 GTP-U 封包 (GTP-U-in-GTP-U)。現在 UPF 當中出現了兩個 GTP-U 封包：外層 GTP-U 封包的標頭是由基地台在封裝使用者裝置的資料封包時產生。外層 GTP-U 封包的訊息類型為 0xFF，長度為 44，這是一個正常的標頭。內層 GTP-U 封包的標頭是使用者裝置特製並且當成資料封包傳送的。如同外層封包，這個內層 GTP-U 封包的訊息類型也是 0xFF，但長度卻為零 (0)，所以不正常。
內層封包的來源 IP 位址是使用者裝置的位址，而外層封包的來源 IP 位址則是基地台的位址。不論內層或外層封包的目的地 IP 位址都一樣，也就是：UPF 的位址。
UPF 會將外層 GTP-U 解封，然後執行功能性檢查。但內層 GTP-U 封包的目的地還是同一個 UPF，接下來會發生的狀況將隨系統的實作而異：
- 有些實作當中會有一個封包處理狀態機器 (state machine)，這個狀態機器如果沒寫好，系統可能接下來就會著手處理這個內層 GTP-U 封包，但此時封包已經過了正確性檢查階段，因為它與外層封包同屬一個相同的封包情境。這將導致系統內出現一個已經通過正確性檢查的異常封包。
- 另一種可能狀況是，既然內層封包的目的地 IP 就指向 UPF 自己，因此封包將被發回給 UPF 自己。此時，封包很可能會再回到功能檢查階段，所以造成的問題會比前面來得輕微。
攻擊途徑
有些 5G 核心網路廠商使用的是 Open5GS 的程式碼，例如，NextEPC (4G 系統，在 2019 年重新改名為 Open5GS 並增加了 5G 功能，同時保留了舊的產品) 所提供的一個企業級 LTE/5G 產品就是使用了 Open5GS 的程式碼。網路上目前還沒看到相關的攻擊或威脅指標，但經過我們使用上述情境測試的結果顯示它仍存在著潛在的風險。
這類攻擊之所以重要，就在於它的攻擊途徑：從 UE 攻擊蜂巢式行動基礎架構。此攻擊手法需要一台手機 (或一台使用蜂巢式行動網路卡上網的電腦)，再配合幾行的 Python 程式碼就能利用這個漏洞發動攻擊。GTP-U-in-GTP-U 攻擊其實是一種眾所周知的技巧，而且就算回程流量使用了 IPsec 及加密也無法防止這類攻擊。事實上，這些安全措施還可能妨礙防火牆執行流量檢查。
解決之道與洞見
一些關鍵產業 (如醫療與公共事業) 只不過 5G 專網的少數早期採用者，但其應用的廣度及深度未來只會持續擴大。對這些產業來說，持續而不間斷的穩定運作至關重要，因為這關乎到生命安全與真實的衝擊。這些產業扮演著基石的功能，而這正是他們選擇採用 5G 專網而非 Wi-Fi 的原因。5G 專網必須提供不間斷的連線，因為任何 5G 基礎架構如果被攻擊得逞，很可能讓整個網路癱瘓。
本文介紹的 CVE-2021-45462 漏洞如果遭到利用，將引發 DoS 攻擊。CVE-2021-45462 (以及大多數 GTP-U-in-GTP-U 攻擊) 的問題根源在於封包處理核心未能做好錯誤檢查與錯誤處置。儘管 GTP-U-in-GTP-U 本身並無害，但封包處理核心廠商還是必須修正這類問題，而且基礎架構的系統管理人員也必須將軟體更新到最新版本。
除此之外，GTP-U-in-GTP-U 攻擊還可能洩露一些敏感的資訊，例如基礎架構節點的 IP 位址。因此 GTP-U 節點彼此之間必須要能應付 GTP-U-in-GTP-U 封包才行。此外，CT 環境必須採用一套真正了解 CT 通訊協定的入侵防護系統 (IPS) 或防火牆。既然 GTP-U 不是一般的使用者流量，尤其在 5G 專網當中，資安團隊就能優先過濾掉 GTP-U-in-GTP-U 流量。
正常來說，SIM 卡的註冊與使用都必須受到嚴格管制與管理。駭客一旦拿到一張失竊的 SIM 卡，就能插入他們的裝置並連上網路來做壞事。不僅如此，在一個責任共同分擔的架構下，資安的責任有時會變得模糊不清，例如：企業擁有的是終端裝置與基礎架構邊緣，而系統整合商或電信業者則擁有蜂巢式行動基礎架構。這使得資安營運中心 (SOC) 很難從不同的領域與解決方案將相關的資訊彙整在一起。
再者，想要定期更新關鍵基礎架構軟體來套用廠商最新的修補也不容易，因為必須停機和進行測試，未來也是如此。所以，強烈建議採用基於 IPS 技術的虛擬修補或多層式防火牆。所幸，GTP-in-GTP 在真實世界當中很少用到，所以大可乾脆將 GTP-in-GTP 流量全部擋掉。我們建議採用能將 IT 與通訊技術 (CT) 資安及可視性整合的多層式資安解決方案。此外，建置一套零信任解決方案，例如 CTOne 推出的 Trend Micro™ Mobile Network Security，也可為企業和關鍵產業添加一道額外防護來防範私有專屬網路遭到未經授權的使用，進而維持工業系統的持續運轉，確保 SIM 卡只能在獲得授權的裝置上使用。不僅如此，Trend Mobile Network Security 還能將 CT 與 IT 資安的可視性與管理整合至單一主控台上。