2. SIP协议劫持与篡改：SIP消息结构、INVITE劫持、SDP篡改、Via/Contact头域伪造
聊到VoLTE攻击，SIP协议劫持绝对是个绕不开的话题。我个人习惯把SIP比作VoLTE的“神经系统”——它负责建立、维护和拆除通话。一旦这个神经系统被动了手脚，整个通话的质量和安全就全完了。
今天这一章，咱们就深入看看攻击者是怎么在SIP消息上做文章的。说白了，就是怎么劫持你的INVITE请求，怎么篡改SDP参数，以及怎么伪造Via和Contact头域。这些手法我在实际项目中都遇到过，有些甚至让我吃了不少苦头。
2.1 SIP消息结构：攻击者眼中的“藏宝图”
先简单回顾一下SIP消息的结构。一个标准的SIP消息由三部分组成：起始行、消息头和消息体。攻击者最感兴趣的就是消息头和消息体。
- 起始行：包含方法（如INVITE、ACK、BYE）和请求URI。
- 消息头：包含Via、Contact、From、To、Call-ID、CSeq等关键字段。
- 消息体：通常包含SDP（会话描述协议），描述媒体参数。
你想想看，攻击者只要能在网络路径上截获这些消息，就能像读地图一样找到所有可以利用的“漏洞点”。
核心观点：SIP消息的每个字段都可能成为攻击的入口。尤其是那些用于路由和身份标识的头域，比如Via和Contact，一旦被伪造，整个呼叫流程就可能被重定向。
2.2 INVITE劫持：把别人的通话“接”到自己手里
INVITE劫持是我在项目中见过最“脏”的手法之一。攻击者通过篡改INVITE请求中的某些字段，让本该发往被叫方的请求，转而发往攻击者控制的设备。
举个例子，一个正常的INVITE请求长这样：
INVITE sip:bob@ims.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK74b43
From: <sip:alice@ims.example.com>;tag=12345
To: <sip:bob@ims.example.com>
Contact: <sip:alice@192.168.1.100:5060>
Call-ID: abcdef123456
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 142
v=0
o=alice 2890844526 2890844526 IN IP4 192.168.1.100
s=-
c=IN IP4 192.168.1.100
t=0 0
m=audio 49170 RTP/AVP 97
a=rtpmap:97 AMR-WB/16000攻击者如果截获了这个请求，可以做什么？
- 篡改To头域：把To字段改成攻击者自己的SIP URI。这样，INVITE请求就会被路由到攻击者的终端。
- 篡改Contact头域：把Contact字段改成攻击者的IP和端口。这样，后续的响应（如200 OK）就会发往攻击者。
- 篡改Via头域：插入或修改Via字段，让响应经过攻击者的代理服务器。
我记得有一次，一个客户反馈说通话总是被“静默监听”。我们排查后发现，攻击者就是在核心网侧做了INVITE劫持。他把Contact头域改成了自己的SBC地址，所有媒体流都先经过他的设备，再转发给被叫方。通话内容被完整录制，用户却毫无察觉。
避坑指南：我曾经在测试中发现，很多IMS网络对INVITE请求的合法性校验并不严格。尤其是Contact头域，很多网元只检查格式，不检查内容是否与From头域一致。这给了攻击者可乘之机。
2.3 SDP篡改：让语音质量“断崖式”下跌
SDP是SIP消息体中的核心内容，它描述了媒体流的参数，比如编码格式、IP地址、端口号等。攻击者篡改SDP，可以直接影响语音质量，甚至让通话完全无法进行。
常见的SDP篡改手法包括：
- 修改编码格式：把AMR-WB（宽带）改成PCMA（窄带），或者把rtpmap中的编码名称改成不支持的格式。通话双方协商失败，要么降级到低质量编码，要么直接断线。
- 修改IP地址和端口：把c=行或m=行中的IP地址改成攻击者控制的服务器地址。这样，媒体流就会被重定向到攻击者的设备，实现中间人攻击。
- 修改带宽参数：把b=行中的带宽值改得很小，比如从64 kbps改成8 kbps。语音质量会急剧下降，出现严重的卡顿和丢包。
举个例子，攻击者篡改后的SDP可能长这样：
v=0
o=alice 2890844526 2890844526 IN IP4 192.168.1.100
s=-
c=IN IP4 10.0.0.1 <-- 攻击者篡改的IP地址
t=0 0
m=audio 49170 RTP/AVP 97
a=rtpmap:97 PCMA/8000 <-- 攻击者篡改的编码格式你想想看，如果被叫方收到了这个SDP，它会尝试向10.0.0.1发送RTP包。而10.0.0.1是攻击者的设备，攻击者可以随意处理这些媒体流——转发、录制、甚至注入噪声。
个人经验：我建议在SDP协商过程中，一定要做完整性校验。比如，使用SDP的a=fingerprint属性进行DTLS-SRTP指纹验证。这样，即使SDP被篡改，也能通过指纹不匹配发现异常。
2.4 Via/Contact头域伪造：让信令“迷路”
Via和Contact头域是SIP路由的关键。攻击者伪造这两个头域，可以让信令消息走错路，或者让响应消息无法到达正确的目的地。
2.4.1 Via头域伪造
Via头域记录了SIP请求经过的每个代理服务器。攻击者可以：
- 插入伪造的Via条目：让响应消息先经过攻击者的服务器，再转发给真正的接收方。这样，攻击者就能截获所有响应消息。
- 修改Via中的branch参数：branch参数用于事务匹配。如果攻击者修改了branch值，可能导致事务匹配失败，引发超时或重传。
举个例子，攻击者插入了一个伪造的Via条目：
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK74b43
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bKattack <-- 攻击者插入的条目这样，响应消息会先发往10.0.0.1，攻击者可以查看或修改响应内容，然后再转发给192.168.1.100。
2.4.2 Contact头域伪造
Contact头域用于后续请求的路由。攻击者伪造Contact头域，可以让后续的请求（如ACK、BYE、re-INVITE）发往错误的地址。
我记得有一次，一个攻击者伪造了Contact头域，把Contact改成了一个不存在的IP地址。结果，主叫方发送的ACK请求一直无法到达被叫方，通话建立失败。更严重的是，如果攻击者把Contact改成自己的地址，他就能持续接收后续的所有信令消息，实现长期监听。
关键点：伪造Via和Contact头域，本质上是在破坏SIP的路由机制。攻击者不需要破解加密，只需要在信令路径上做手脚，就能让整个通话“迷路”。
2.5 知识体系与核心逻辑
为了让你更直观地理解这一章的知识结构，我画了一张图。它展示了SIP协议劫持与篡改的核心逻辑：从消息结构入手，到INVITE劫持、SDP篡改、头域伪造，最终影响语音质量或导致通话中断。
这张图把本章的核心逻辑串起来了。从SIP消息结构出发，攻击者可以选择三个方向：INVITE劫持、SDP篡改、头域伪造。每个方向都有具体的攻击手法，最终都指向同一个结果——语音质量下降或通话中断。
我的建议：防御这些攻击，不能只靠单一手段。我个人的做法是：在SIP信令层面做完整性校验（如使用SIP over TLS），在SDP层面做指纹验证（如DTLS-SRTP），在网络层面做访问控制（如只允许信任的代理服务器转发信令）。三层防护，缺一不可。
嗯，这一章的内容就到这里。SIP协议劫持与篡改，说白了就是攻击者在信令路径上“做手脚”。你只要理解了SIP消息的结构，就能明白攻击者为什么能得手，以及怎么防住他们。