4、SIP协议安全测试：SIP消息篡改、方法滥用与会话劫持
聊到IMS网络渗透测试，SIP协议绝对是绕不开的核心战场。说白了，IMS整个呼叫控制、会话管理，全靠SIP在背后撑着。如果SIP层出了问题，那整个网络就像纸糊的一样。
我个人习惯把SIP安全测试分成三个维度：消息篡改、方法滥用、会话劫持。这三个维度基本覆盖了从信令层面到媒体层面的攻击面。今天我们就一个一个拆开来讲。
核心观点：SIP协议本身设计时并未充分考虑安全性，很多头域和方法可以被攻击者利用。测试的目的，就是提前发现这些漏洞，避免被黑产盯上。
4.1 SIP消息篡改：从Via/From/To头域入手
先说说消息篡改。你想想看，SIP消息里那么多头域，哪个最容易被动手脚？我个人经验是，Via、From、To这三个头域是重灾区。
Via头域记录了请求经过的路径。攻击者可以修改Via头域中的地址，让后续的响应发到错误的地方，甚至直接丢弃。我在一次红队项目中，就遇到过运营商核心网对Via头域校验不严的情况。我们修改了Via中的received参数，结果后续的200 OK响应直接发到了我们控制的服务器上。嗯，这就是典型的信令路由劫持。
From头域标识了呼叫发起方。篡改From头域，说白了就是伪造主叫号码。这在电信诈骗中非常常见。测试时，我们可以尝试将From头域中的URI改成任意号码，看看IMS核心网是否校验。
To头域标识了呼叫接收方。篡改To头域，可以改变呼叫的最终目的地。比如，原本要打给10086的呼叫，被我们改成了打给一个收费号码。
测试技巧：使用SIPp或定制脚本，构造带有篡改头域的INVITE请求。重点关注P-CSCF和S-CSCF是否对头域进行合法性校验。我曾经遇到过S-CSCF完全不校验From头域的情况，直接放行，导致可以任意伪造主叫。
# 示例：使用SIPp构造篡改From头域的INVITE
# 原始From: <sip:10086@ims.example.com>
# 篡改后From: <sip:110@ims.example.com>
INVITE sip:13800138000@ims.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK12345
From: <sip:110@ims.example.com>;tag=abc123
To: <sip:13800138000@ims.example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 INVITE
Contact: <sip:110@192.168.1.100>
Content-Type: application/sdp
Content-Length: 150
v=0
o=- 0 0 IN IP4 192.168.1.100
s=-
c=IN IP4 192.168.1.100
t=0 0
m=audio 10000 RTP/AVP 0
a=rtpmap:0 PCMU/8000警告：在实际生产环境中进行篡改测试前，务必获得书面授权。未经授权的篡改测试可能触犯法律。我曾经见过一个测试人员因为没拿到授权就动手，结果被当成黑客抓了。
4.2 SIP方法滥用：OPTIONS洪水与REGISTER风暴
方法滥用，说白了就是利用SIP协议中的各种方法，对IMS核心网发起拒绝服务攻击。这里我重点讲两个：OPTIONS洪水和REGISTER风暴。
OPTIONS洪水：OPTIONS方法用于查询服务器的能力。攻击者可以发送大量OPTIONS请求，消耗服务器资源。你想想看，如果每秒发送几万个OPTIONS请求，P-CSCF的CPU很快就打满了。我在一次渗透测试中，用一台普通的笔记本，跑了5分钟OPTIONS洪水，就把一个测试环境的P-CSCF打挂了。
REGISTER风暴：REGISTER方法用于用户注册。攻击者可以伪造大量REGISTER请求，尝试注册不存在的用户，或者频繁刷新注册。这会导致HSS（归属用户服务器）和S-CSCF的数据库压力剧增。更严重的是，如果攻击者注册了合法用户的号码，就可以劫持该用户的呼叫。
| 攻击类型 | 目标方法 | 攻击效果 | 防御手段 |
|---|---|---|---|
| OPTIONS洪水 | OPTIONS | 耗尽服务器CPU/内存 | 限速、源IP白名单 |
| REGISTER风暴 | REGISTER | HSS/S-CSCF过载、用户劫持 | CAPTCHA、注册频率限制 |
| INVITE洪泛 | INVITE | 呼叫处理能力下降 | 会话建立速率限制 |
| BYE/CANCEL滥用 | BYE/CANCEL | 异常终止合法会话 | 会话状态校验 |
避坑指南：我曾经在测试REGISTER风暴时，忘记设置合理的速率，结果把生产环境的HSS打崩了，导致全网用户无法注册。后来我学乖了，测试前一定先确认限速阈值，并且从低速率开始逐步增加。
# 使用hping3模拟OPTIONS洪水（简化示例）
# 注意：实际测试请使用SIPp或定制工具
hping3 --udp -p 5060 --flood --rand-source \
--data "OPTIONS sip:test@ims.example.com SIP/2.0\r\nVia: SIP/2.0/UDP 1.2.3.4:5060\r\nFrom: <sip:attacker@evil.com>\r\nTo: <sip:test@ims.example.com>\r\nCall-ID: flood123\r\nCSeq: 1 OPTIONS\r\nContent-Length: 0\r\n\r\n" \
192.168.1.14.3 SIP会话劫持：中间人攻击
会话劫持，这是SIP安全测试里最刺激的部分。说白了，就是攻击者插入到两个合法用户之间，控制他们的通信。
中间人攻击（MITM）在SIP场景下非常有效。攻击者可以通过ARP欺骗、DNS劫持或路由篡改，让SIP信令经过自己的设备。然后，攻击者可以修改SDP中的媒体地址，把RTP流引到自己的机器上。这样，通话内容就被窃听了。
我记得有一次红队项目，我们通过ARP欺骗，成功劫持了一个VoIP网关和P-CSCF之间的流量。我们修改了INVITE请求中的SDP，把媒体地址改成了我们的RTP代理。结果，所有通话的音频流都经过了我们这里。嗯，那感觉就像在偷听别人的秘密会议。
关键点：会话劫持的核心在于SDP篡改。攻击者需要修改SDP中的c=行（连接地址）和m=行（媒体端口），将媒体流重定向到攻击者控制的RTP代理。
# 中间人攻击中的SDP篡改示例
# 原始SDP（UE发送的）
v=0
o=- 0 0 IN IP4 10.0.0.100
s=-
c=IN IP4 10.0.0.100
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
# 篡改后的SDP（攻击者修改）
v=0
o=- 0 0 IN IP4 192.168.1.200
s=-
c=IN IP4 192.168.1.200
t=0 0
m=audio 30000 RTP/AVP 0
a=rtpmap:0 PCMU/8000注意事项：会话劫持测试必须在完全隔离的测试环境中进行。在生产环境中进行MITM攻击，可能导致合法用户的通话中断，甚至引发法律纠纷。我建议使用专门的IMS测试床，或者至少使用虚拟化环境。
防御会话劫持，最有效的手段是使用IPsec或TLS加密SIP信令，以及使用SRTP加密RTP媒体流。另外，IMS网络中的网络域安全（NDS/IP）机制，也能有效防止中间人攻击。但说实话，很多运营商为了性能，并没有开启这些加密。这就给了攻击者可乘之机。
个人建议：在测试IMS网络时，先检查SIP信令是否加密。如果发现明文传输，那基本上可以断定存在会话劫持的风险。我曾经在一个项目中，发现整个IMS核心网的信令都是明文，连基本的TLS都没开。那感觉，就像看到银行金库的门没锁。
好了，关于SIP协议安全测试的三个核心维度，我们就聊到这里。消息篡改、方法滥用、会话劫持，每一个都是IMS网络中的硬骨头。测试时一定要胆大心细，拿到授权再动手。