開源BTS產品中存在多處漏洞，攻擊者或可劫持手機通信基站

前言

在過去的幾周時間裏，我從多個方面對GSM的安全性進行了調查和研究，例如GSM通訊協議中存在的漏洞。除此以外，我還對目前世界上應用最爲普遍的BTS軟件進行了安全審計。在這篇文章中，我將會給你們介紹一下我在這款開源產品中所發現的多個漏洞，這些漏洞將容許攻擊者入侵基站收發信臺（BTS），並遠程控制它的信號收發模塊。

背景知識

一個基站收發信臺（BTS）是由軟件和無線電設備組成的，它是智能手機鏈接GSM、UMTS、以及LTE網絡時必不可少的關鍵組件。BTS主要分爲基帶單元、載頻單元和控制單元三部分。基帶單元主要用於話音和數據速率適配以及信道編碼等；載頻單元主要用於調製/解調與發射機/接收機間的耦合；控制單元則用於BTS的操做與維護。BTS中存儲編碼算法A5和密鑰Kc，用於解密接收到的密文形式的用戶數據和信令數據（包括解密）。

它至關於Wi-Fi網絡中的無線接入點，它負責管理Um接口的通訊過程。Um接口是MS(MobileStation，移動臺)和BTS之間的接口，經過該接口，MS完成與網絡側的通訊，完成分組數據傳送、移動性管理、會話管理、無線資源管理等多方面的功能。Um接口是GSM/GPRS/EDGE網絡中，MS與網絡之間的接口，也被稱爲空中接口(AirInterface)。Um接口用於傳輸MS與網絡之間的信令信息和業務信息。具體如圖一所示：

圖一：MS與BTS的鏈接

BTS的底層軟件其實是一個信號收發器，而它就是無線硬件設備的直接接口。它主要負責頻率調諧，並處理GMSK（高斯最小移頻鍵控）數據的調製與解調。簡而言之，它主要負責的是將無線電波轉化成數字信號。BTS其他邏輯單元的通訊和同步操做都是由圖二所示的三個UDP數據包負責處理的。

圖二：信號收發模塊以及用來與BTS其他邏輯單元進行通訊的三個UDP數據包

其如上圖所示，「ClockSocket」數據包主要負責進行時間同步；BTS會使用「CommandSocket」數據包來向信號收發器發送控制命令；最後，「DataSocket」數據包負責將GSM數據包從BTS經過無線電信號廣播出去，而後接收返回的響應信息。其中，信號收發器模塊中的「UDPSocket」類主要負責處理上述三個信道的通訊過程。

咱們的分析代表，目前大多數BTS軟件所使用的都是同一個（或者極其類似的）收發器代碼庫。所以，基本上這些BTS軟件都會受到相同漏洞的影響。惡意攻擊者能夠利用這些漏洞來遠程控制信號收發器模塊，從而影響BTS的正常功能。

不只如此，攻擊者還有可能向收發器模塊發送GSM數據脈衝，而後對移動用戶進行各類網絡攻擊，例如IMSI分離、加密降級、以及拒絕服務攻擊等等。

爲了讓信號收發器模塊可以接收並處理攻擊者發送的信息，發送至數據信道套接字的UDP數據包必須遵循下列格式：

當信號收發器模塊接收到了這些數據包以後，它會解碼這些數據包，而後使用GMSK來進行信號調製。最終，不一樣內容的信號脈衝將會被髮送到與之相連的移動臺（MS）。

即使是下方列表中標註的產品只使用了GMS或者UMTS網絡，可是它們的信號收發器模塊（這是一個獨立組件）自己倒是基本相同的。因此咱們推測，負責處理LTE鏈接的BTS軟件一樣也使用了相似的信號收發器代碼。

受影響產品

－YateBTS<= 5.0.0

－OpenBTS<= 4.0.0

－OpenBTS-UMTS<= 1.0.0

－Osmo-TRX/Osmo-BTS<= 0.1.10

－以及其餘使用了相同信號收發器代碼的產品

相關廠商

－Legba股份有限公司（YateBTS）

－RangeNetworks（OpenBTS和OpenBTS-UMTS）

－OsmoCOM（Osmo-TRX和Osmo-BTS）

問題一：過分暴露的服務綁定

概述

這個漏洞存在於上述產品的網絡庫中，這個問題致使信號收發器的UDPsockets地址綁定到了0.0.0.0，可是這三個信號收發器的地址應該綁定到用戶設置的地址上（默認爲127.0.0.1）。這也就意味着，攻擊者能夠利用這些地址來與BTS系統進行鏈接，並從信號收發器中接收（發送）數據包。除此以外，訪問這些暴露了UDP網絡套接字的服務其安全性將沒法獲得保障，由於任何身份驗證機制都沒法保證這些服務的安全。

圖三：三個信號收發器的套接字地址所有綁定到了地址0.0.0.0

影響

攻擊者可使用IP鏈接來發送UDP數據包，並獲取BTS的全部功能。這也就意味着，攻擊者能夠實現遠程控制、GSM流量劫持、獲取用戶的通訊數據、DoS拒絕服務攻擊，甚至還會發生更加糟糕的事情。

細節披露

咱們能夠在UDPSocket類的構造器中找到引發這個漏洞的根本緣由。在源文件「CommonLibs/Sockets.cpp」中，你能夠找到「UDPSocket::open」方法，而正是這個方法中的錯誤代碼才致使了這個漏洞的存在。值得注意的是，全部受影響的產品中都包含有這份源文件。下面這段代碼就是漏洞代碼：

從上面的代碼段中咱們能夠看到，系統將綁定的地址保存到了mDestination類的成員變量中，可是UDPSocket::open方法的實現方式倒是這樣的：

儘管UDPSocket類提供了一個構造參數來指定服務器所要綁定的IP地址，可是這部分數據卻被代碼忽略了。正如上圖第272行代碼所示，通訊socket被綁定到了INADDR_ANY，然而並無使用mDestination地址變量。

問題二：基於棧的遠程緩衝區溢出

概述

攻擊者能夠經過向設備的控制信道發送一個較大的UDP數據包來引發棧緩衝區的溢出。

影響

攻擊者能夠實現遠程代碼執行（RCE）或者對設備發動拒絕服務（DoS）攻擊。

細節披露

控制信道是由源文件Transceiver.cpp中的Transceiver::driveControl方法控制的。這部分代碼以下所示：

注意代碼中數據包的緩存空間，這部分空間存在於方法棧中，其大小被定義爲100字節（MAX_PACKET_LENGTH）。

接下來，咱們對源文件Sockets.cpp中聲明的DatagramSocket::read方法（DatagramSocket類是UDPSocket類的父類）進行了分析，結果咱們發現了下列信息：

咱們能夠看到，代碼讀取的是MAX_UDP_LENGTH所表明的長度，並不是MAX_PACKET_LENGTH變量的值。而MAX_UDP_LENGTH的值是在Sockets.h源文件中定義的，以下圖所示：

所以，攻擊者只須要向信號收發器發送一個大小超過100字節的UDP數據包，就能夠成功在目標設備上引發棧溢出。圖四顯示的是該漏洞所引起的錯誤調試信息：

圖四：因爲UDP數據包過大所致使的數據包切分錯誤

問題三：未經身份驗證的遠程控制

概述

控制信道並無引入任何形式的身份驗證機制。再加上‘問題一’使得其部分信息暴露在了外部網絡中，因此惡意攻擊者就能夠利用這個漏洞來遠程控制信號收發器模塊。

影響

攻擊者能夠：

－經過關閉模塊來實現拒絕服務攻擊。

－經過修改無線電信號頻率來阻塞信號發送。

－經過「SETBSIC」命令遠程劫持BTS。

細節披露

控制信道使用源文件Transceiver.cpp中的Transceiver::driveControl方法來處理UDP協議。該協議暴露的部分功能包括：

－開啓或關閉TRX模塊：CMDPOWERON / CMD POWEROFF

－更改TRX的無線頻率：CMDRXTUNE frequency / CMD TXTUNE frequency

－設置GSM信號的驗證信息：CMDSETBSIC value

攻擊者只須要向服務器的5701端口發送一個簡單的UDP數據包，就能夠遠程執行上面這些

結論，緩解方案，以及建議

經過這篇文章，想必你們已經瞭解了這些代碼漏洞和身份驗證機制的缺少將會如何影響上述的這些BTS產品了。並且不只如此，攻擊者甚至還能夠利用這些漏洞來發動大規模的網絡攻擊。

咱們強烈建議廠商趕忙採起下列的緩解措施，以提高相應產品的安全性能：

1. 更新你的BTS軟件，若是收到了更新補丁推送，請儘快安裝補丁程序。

2. 將用於控制操做和數據轉換的socket地址綁定到本地接口（127.0.0.1）。

3. 防火牆：阻止流經端口5701（控制端口）和端口5702（數據端口）的全部外部網絡流量。

4. 引入身份驗證系統，以防止沒有權限的攻擊者經過BTS控制端口來登陸服務器或訪問網絡。

5. 修復代碼中的緩衝區大小問題。

6. 進行額外的代碼審計。

* 參考來源：ZIMPERIUMzLabs