信息來(lái)源：FreeBuf

前言

在過(guò)去的幾周時(shí)間里，我從多個(gè)方面對(duì)GSM的安全性進(jìn)行了調(diào)查和研究，例如GSM通信協(xié)議中存在的漏洞。除此之外，我還對(duì)目前世界上應(yīng)用最為廣泛的BTS軟件進(jìn)行了安全審計(jì)。在這篇文章中，我將會(huì)給大家介紹一下我在這款開(kāi)源產(chǎn)品中所發(fā)現(xiàn)的多個(gè)漏洞，這些漏洞將允許攻擊者入侵基站收發(fā)信臺(tái)（BTS），并遠(yuǎn)程控制它的信號(hào)收發(fā)模塊。

背景知識(shí)

一個(gè)基站收發(fā)信臺(tái)（BTS）是由軟件和無(wú)線電設(shè)備組成的，它是智能手機(jī)連接GSM、UMTS、以及LTE網(wǎng)絡(luò)時(shí)必不可少的關(guān)鍵組件。BTS主要分為基帶單元、載頻單元和控制單元三部分。基帶單元主要用于話音和數(shù)據(jù)速率適配以及信道編碼等；載頻單元主要用于調(diào)制/解調(diào)與發(fā)射機(jī)/接收機(jī)間的耦合；控制單元?jiǎng)t用于BTS的操作與維護(hù)。BTS中存儲(chǔ)編碼算法A5和密鑰Kc，用于解密接收到的密文形式的用戶數(shù)據(jù)和信令數(shù)據(jù)（包括解密）。

它相當(dāng)于Wi-Fi網(wǎng)絡(luò)中的無(wú)線接入點(diǎn)，它負(fù)責(zé)管理Um接口的通信過(guò)程。Um接口是MS(MobileStation，移動(dòng)臺(tái))和BTS之間的接口，通過(guò)該接口，MS完成與網(wǎng)絡(luò)側(cè)的通信，完成分組數(shù)據(jù)傳送、移動(dòng)性管理、會(huì)話管理、無(wú)線資源管理等多方面的功能。Um接口是GSM/GPRS/EDGE網(wǎng)絡(luò)中，MS與網(wǎng)絡(luò)之間的接口，也被稱為空中接口(AirInterface)。Um接口用于傳輸MS與網(wǎng)絡(luò)之間的信令信息和業(yè)務(wù)信息。具體如圖一所示：

圖一：MS與BTS的連接

BTS的底層軟件實(shí)際上是一個(gè)信號(hào)收發(fā)器，而它就是無(wú)線硬件設(shè)備的直接接口。它主要負(fù)責(zé)頻率調(diào)諧，并處理GMSK（高斯最小移頻鍵控）數(shù)據(jù)的調(diào)制與解調(diào)。簡(jiǎn)而言之，它主要負(fù)責(zé)的是將無(wú)線電波轉(zhuǎn)化成數(shù)字信號(hào)。BTS其余邏輯單元的通信和同步操作都是由圖二所示的三個(gè)UDP數(shù)據(jù)包負(fù)責(zé)處理的。

圖二：信號(hào)收發(fā)模塊以及用來(lái)與BTS其余邏輯單元進(jìn)行通信的三個(gè)UDP數(shù)據(jù)包

 其如上圖所示，“ClockSocket”數(shù)據(jù)包主要負(fù)責(zé)進(jìn)行時(shí)間同步；BTS會(huì)使用“CommandSocket”數(shù)據(jù)包來(lái)向信號(hào)收發(fā)器發(fā)送控制命令；最后，“DataSocket”數(shù)據(jù)包負(fù)責(zé)將GSM數(shù)據(jù)包從BTS通過(guò)無(wú)線電信號(hào)廣播出去，然后接收返回的響應(yīng)信息。其中，信號(hào)收發(fā)器模塊中的“UDPSocket”類主要負(fù)責(zé)處理上述三個(gè)信道的通信過(guò)程。

我們的分析表明，目前大多數(shù)BTS軟件所使用的都是同一個(gè)（或者極其相似的）收發(fā)器代碼庫(kù)。因此，基本上這些BTS軟件都會(huì)受到相同漏洞的影響。惡意攻擊者可以利用這些漏洞來(lái)遠(yuǎn)程控制信號(hào)收發(fā)器模塊，從而影響B(tài)TS的正常功能。

不僅如此，攻擊者還有可能向收發(fā)器模塊發(fā)送GSM數(shù)據(jù)脈沖，然后對(duì)移動(dòng)用戶進(jìn)行各種網(wǎng)絡(luò)攻擊，例如IMSI分離、加密降級(jí)、以及拒絕服務(wù)攻擊等等。

為了讓信號(hào)收發(fā)器模塊能夠接收并處理攻擊者發(fā)送的信息，發(fā)送至數(shù)據(jù)信道套接字的UDP數(shù)據(jù)包必須遵循下列格式：

當(dāng)信號(hào)收發(fā)器模塊接收到了這些數(shù)據(jù)包之后，它會(huì)解碼這些數(shù)據(jù)包，然后使用GMSK來(lái)進(jìn)行信號(hào)調(diào)制。最終，不同內(nèi)容的信號(hào)脈沖將會(huì)被發(fā)送到與之相連的移動(dòng)臺(tái)（MS）。

即便是下方列表中標(biāo)注的產(chǎn)品只使用了GMS或者UMTS網(wǎng)絡(luò)，但是它們的信號(hào)收發(fā)器模塊（這是一個(gè)獨(dú)立組件）本身卻是基本相同的。所以我們推測(cè)，負(fù)責(zé)處理LTE連接的BTS軟件同樣也使用了類似的信號(hào)收發(fā)器代碼。

 受影響產(chǎn)品

－YateBTS<= 5.0.0

－OpenBTS<= 4.0.0

－OpenBTS-UMTS<= 1.0.0

－Osmo-TRX/Osmo-BTS<= 0.1.10

－以及其他使用了相同信號(hào)收發(fā)器代碼的產(chǎn)品

 相關(guān)廠商

－Legba股份有限公司（YateBTS）

－RangeNetworks（OpenBTS和OpenBTS-UMTS）

－OsmoCOM（Osmo-TRX和Osmo-BTS）

 問(wèn)題一：過(guò)度暴露的服務(wù)綁定

概述

這個(gè)漏洞存在于上述產(chǎn)品的網(wǎng)絡(luò)庫(kù)中，這個(gè)問(wèn)題導(dǎo)致信號(hào)收發(fā)器的UDPsockets地址綁定到了0.0.0.0，但是這三個(gè)信號(hào)收發(fā)器的地址應(yīng)該綁定到用戶設(shè)置的地址上（默認(rèn)為127.0.0.1）。這也就意味著，攻擊者可以利用這些地址來(lái)與BTS系統(tǒng)進(jìn)行連接，并從信號(hào)收發(fā)器中接收（發(fā)送）數(shù)據(jù)包。除此之外，訪問(wèn)這些暴露了UDP網(wǎng)絡(luò)套接字的服務(wù)其安全性將無(wú)法得到保障，因?yàn)槿魏紊矸蒡?yàn)證機(jī)制都無(wú)法保證這些服務(wù)的安全。

圖三：三個(gè)信號(hào)收發(fā)器的套接字地址全部綁定到了地址0.0.0.0

影響

攻擊者可以使用IP連接來(lái)發(fā)送UDP數(shù)據(jù)包，并獲取BTS的所有功能。這也就意味著，攻擊者可以實(shí)現(xiàn)遠(yuǎn)程控制、GSM流量劫持、獲取用戶的通信數(shù)據(jù)、DoS拒絕服務(wù)攻擊，甚至還會(huì)發(fā)生更加糟糕的事情。

細(xì)節(jié)披露

我們可以在UDPSocket類的構(gòu)造器中找到引起這個(gè)漏洞的根本原因。在源文件“CommonLibs/Sockets.cpp”中，你可以找到“UDPSocket::open”方法，而正是這個(gè)方法中的錯(cuò)誤代碼才導(dǎo)致了這個(gè)漏洞的存在。值得注意的是，所有受影響的產(chǎn)品中都包含有這份源文件。下面這段代碼就是漏洞代碼：

從上面的代碼段中我們可以看到，系統(tǒng)將綁定的地址保存到了mDestination類的成員變量中，但是UDPSocket::open方法的實(shí)現(xiàn)方式卻是這樣的：

盡管UDPSocket類提供了一個(gè)構(gòu)造參數(shù)來(lái)指定服務(wù)器所要綁定的IP地址，但是這部分?jǐn)?shù)據(jù)卻被代碼忽略了。正如上圖第272行代碼所示，通信socket被綁定到了INADDR_ANY，然而并沒(méi)有使用mDestination地址變量。

 問(wèn)題二：基于棧的遠(yuǎn)程緩沖區(qū)溢出

概述

攻擊者可以通過(guò)向設(shè)備的控制信道發(fā)送一個(gè)較大的UDP數(shù)據(jù)包來(lái)引起棧緩沖區(qū)的溢出。

影響

攻擊者可以實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行（RCE）或者對(duì)設(shè)備發(fā)動(dòng)拒絕服務(wù)（DoS）攻擊。

細(xì)節(jié)披露

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

注意代碼中數(shù)據(jù)包的緩存空間，這部分空間存在于方法棧中，其大小被定義為100字節(jié)（MAX_PACKET_LENGTH）。

接下來(lái)，我們對(duì)源文件Sockets.cpp中聲明的DatagramSocket::read方法（DatagramSocket類是UDPSocket類的父類）進(jìn)行了分析，結(jié)果我們發(fā)現(xiàn)了下列信息：

我們可以看到，代碼讀取的是MAX_UDP_LENGTH所代表的長(zhǎng)度，并非MAX_PACKET_LENGTH變量的值。而MAX_UDP_LENGTH的值是在Sockets.h源文件中定義的，如下圖所示：

因此，攻擊者只需要向信號(hào)收發(fā)器發(fā)送一個(gè)大小超過(guò)100字節(jié)的UDP數(shù)據(jù)包，就可以成功在目標(biāo)設(shè)備上引起棧溢出。圖四顯示的是該漏洞所引發(fā)的錯(cuò)誤調(diào)試信息：

圖四：由于UDP數(shù)據(jù)包過(guò)大所導(dǎo)致的數(shù)據(jù)包切分錯(cuò)誤

 問(wèn)題三：未經(jīng)身份驗(yàn)證的遠(yuǎn)程控制

概述

控制信道并沒(méi)有引入任何形式的身份驗(yàn)證機(jī)制。再加上‘問(wèn)題一’使得其部分信息暴露在了外部網(wǎng)絡(luò)中，所以惡意攻擊者就可以利用這個(gè)漏洞來(lái)遠(yuǎn)程控制信號(hào)收發(fā)器模塊。

影響

攻擊者可以：

－通過(guò)關(guān)閉模塊來(lái)實(shí)現(xiàn)拒絕服務(wù)攻擊。

－通過(guò)修改無(wú)線電信號(hào)頻率來(lái)阻塞信號(hào)發(fā)送。

－通過(guò)“SETBSIC”命令遠(yuǎn)程劫持BTS。

 細(xì)節(jié)披露

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

－開(kāi)啟或關(guān)閉TRX模塊：CMDPOWERON / CMD POWEROFF

－更改TRX的無(wú)線頻率：CMDRXTUNE frequency / CMD TXTUNE frequency

－設(shè)置GSM信號(hào)的驗(yàn)證信息：CMDSETBSIC value

攻擊者只需要向服務(wù)器的5701端口發(fā)送一個(gè)簡(jiǎn)單的UDP數(shù)據(jù)包，就可以遠(yuǎn)程執(zhí)行上面這些控制命令了。關(guān)于協(xié)議的完整內(nèi)容可以在TRXManager/README.TRXManager文件中找到。

結(jié)論，緩解方案，以及建議

通過(guò)這篇文章，想必大家已經(jīng)了解了這些代碼漏洞和身份驗(yàn)證機(jī)制的缺乏將會(huì)如何影響上述的這些BTS產(chǎn)品了。而且不僅如此，攻擊者甚至還可以利用這些漏洞來(lái)發(fā)動(dòng)大規(guī)模的網(wǎng)絡(luò)攻擊。

我們強(qiáng)烈建議廠商趕緊采取下列的緩解措施，以提升相應(yīng)產(chǎn)品的安全性能：

1.    更新你的BTS軟件，如果收到了更新補(bǔ)丁推送，請(qǐng)盡快安裝補(bǔ)丁程序。

2.    將用于控制操作和數(shù)據(jù)轉(zhuǎn)換的socket地址綁定到本地接口（127.0.0.1）。

3.    防火墻：阻止流經(jīng)端口5701（控制端口）和端口5702（數(shù)據(jù)端口）的所有外部網(wǎng)絡(luò)流量。

4.    引入身份驗(yàn)證系統(tǒng)，以防止沒(méi)有權(quán)限的攻擊者通過(guò)BTS控制端口來(lái)登錄服務(wù)器或訪問(wèn)網(wǎng)絡(luò)。

5.    修復(fù)代碼中的緩沖區(qū)大小問(wèn)題。

6.    進(jìn)行額外的代碼審計(jì)。

* 參考來(lái)源：ZIMPERIUMzLabs，本文由Alpha_h4ck編譯，轉(zhuǎn)載請(qǐng)注明來(lái)自FreeBuf（Freebuf.COM）