SIP (会话发起协议)

Reading time: 22 minutes

tip

学习和实践 AWS 黑客技术:HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术:HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术:HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

基本信息

SIP (Session Initiation Protocol) 是一种广泛用于在 IP 网络上建立、修改和终止多媒体会话(包括语音、视频和即时消息)的信令和呼叫控制协议。由 Internet Engineering Task Force (IETF) 制定,SIP 在 RFC 3261 中定义,已成为 VoIP 和统一通信的事实标准。

SIP 的一些关键特性包括:

  1. Text-based Protocol:SIP 是一种基于文本的协议,使其对人类可读且更易于调试。它基于请求-响应模型,类似于 HTTP,并使用 INVITE、ACK、BYE、CANCEL 等方法来控制呼叫会话。
  2. Scalability and Flexibility:SIP 高度可扩展,可用于小规模部署以及大型企业和运营级环境。它可以轻松通过新功能扩展,适应各种用例和需求。
  3. Interoperability:SIP 的广泛采用和标准化确保了不同设备、应用和服务提供商之间更好的互操作性,促进跨平台的无缝通信。
  4. Modular Design:SIP 与其他协议协同工作,例如 RTP(实时传输协议) 用于媒体传输,SDP(会话描述协议) 用于描述多媒体会话。这种模块化设计允许在不同媒体类型和编解码器间具有更大的灵活性和兼容性。
  5. Proxy and Redirect Servers:SIP 可以使用代理和重定向服务器来促进呼叫路由并提供呼叫转移、呼叫保持和语音信箱等高级功能。
  6. Presence and Instant Messaging:SIP 不仅限于语音和视频通信,还支持在线状态和即时消息,从而实现广泛的统一通信应用。

尽管 SIP 有许多优点,但在处理 NAT 遍历和防火墙问题时配置和管理可能比较复杂。然而,其多功能性、可扩展性以及行业内的广泛支持使其成为 VoIP 和多媒体通信的流行选择。

SIP Methods

RFC 3261 中定义的核心 SIP 方法包括:

  1. INVITE:用于**发起新会话(呼叫)**或修改现有会话。INVITE 方法携带会话描述(通常使用 SDP)以告知接收方拟议会话的详细信息,例如媒体类型、编解码器和传输协议。
  2. ACK:用于确认收到对 INVITE 请求的最终响应。ACK 方法通过提供端到端确认来确保 INVITE 事务的可靠性。
  3. BYE:用于终止已建立的会话(呼叫)。BYE 方法由会话中的任一方发送,以表示其希望结束通信。
  4. CANCEL:用于在会话建立之前取消挂起的 INVITE 请求。CANCEL 方法允许发送方在改变主意或未收到接收方响应时中止 INVITE 事务。
  5. OPTIONS:用于查询 SIP 服务器或用户代理的能力。OPTIONS 方法可用于请求有关支持的方法、媒体类型或其他扩展的信息,而无需实际建立会话。
  6. REGISTER:由用户代理用于向 SIP registrar 服务器注册其当前位置。REGISTER 方法有助于维护用户的 SIP URI 与其当前 IP 地址之间的最新映射,从而实现呼叫路由和投递。

warning

Note that to call someone it's not neccesary to use the REGISTER for anything.
However, it's possible that in order to perform an INVITE the caller needs to authenticate first or he will receive a 401 Unauthorized response.

除了这些核心方法外,还有在其他 RFC 中定义的 若干 SIP 扩展方法,例如:

  1. SUBSCRIBE:在 RFC 6665 中定义,SUBSCRIBE 方法用于请求有关特定资源状态的通知,例如用户的在线状态或呼叫状态。
  2. NOTIFY:也在 RFC 6665 中定义,NOTIFY 方法由服务器发送,用于通知已订阅的用户代理被监控资源状态的变化。
  3. REFER:在 RFC 3515 中定义,REFER 方法用于请求接收方执行转接或引用第三方。这通常用于呼叫转移场景。
  4. MESSAGE:在 RFC 3428 中定义,MESSAGE 方法用于在 SIP 用户代理之间发送即时消息,在 SIP 框架内实现基于文本的通信。
  5. UPDATE:在 RFC 3311 中定义,UPDATE 方法允许在不影响现有对话状态的情况下修改会话。这对于在通话期间更新会话参数(例如编解码器或媒体类型)非常有用。
  6. PUBLISH:在 RFC 3903 中定义,PUBLISH 方法由用户代理用于向服务器发布事件状态信息,使其他感兴趣方能够获取该信息。

SIP Response Codes

  • 1xx (Provisional Responses):这些响应表示请求已被接收,服务器正在继续处理它。
  • 100 Trying: 请求已被接收,服务器正在处理。
  • 180 Ringing: 被叫方正在被提醒并将接听呼叫。
  • 183 Session Progress: 提供有关呼叫进展的信息。
  • 2xx (Successful Responses):这些响应表示请求已成功接收、理解并被接受。
  • 200 OK: 请求成功,服务器已完成处理。
  • 202 Accepted: 请求已被接受用于处理,但尚未完成。
  • 3xx (Redirection Responses):这些响应表示要完成请求需要进一步操作,通常通过联系备用资源来实现。
  • 300 Multiple Choices: 存在多个可选项,用户或客户端必须选择一个。
  • 301 Moved Permanently: 请求的资源已被分配了新的永久 URI。
  • 302 Moved Temporarily: 请求的资源暂时可在不同的 URI 获取。
  • 305 Use Proxy: 必须将请求发送到指定的代理。
  • 4xx (Client Error Responses):这些响应表示请求包含语法错误或服务器无法完成该请求。
  • 400 Bad Request: 请求格式错误或无效。
  • 401 Unauthorized: 请求需要用户认证。
  • 403 Forbidden: 服务器理解请求但拒绝执行。
  • 404 Not Found: 请求的资源在服务器上未找到。
  • 408 Request Timeout: 服务器在准备等待的时间内未收到完整请求。
  • 486 Busy Here: 被叫方当前忙碌,无法接听呼叫。
  • 5xx (Server Error Responses):这些响应表示服务器未能完成有效的请求。
  • 500 Internal Server Error: 服务器在处理请求时遇到错误。
  • 501 Not Implemented: 服务器不支持完成请求所需的功能。
  • 503 Service Unavailable: 服务器当前因维护或过载无法处理请求。
  • 6xx (Global Failure Responses):这些响应表示任何服务器都无法完成该请求。
  • 600 Busy Everywhere: 呼叫的所有可能目的地都很忙。
  • 603 Decline: 被叫方不愿意参与呼叫。
  • 604 Does Not Exist Anywhere: 请求的资源在网络中任何地方都不可用。

示例

SIP INVITE 示例

INVITE sip:jdoe@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:jdoe@example.com>
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jsmith@pc33.example.com>
User-Agent: ExampleSIPClient/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 142

v=0
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
s=-
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
每个参数说明
  1. Request-Line: INVITE sip:jdoe@example.com SIP/2.0 - 这一行表示方法 (INVITE)、请求 URI (sip:jdoe@example.com) 和 SIP 版本 (SIP/2.0)。
  2. Via: Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds - Via 头指定了传输协议 (UDP) 和客户端地址 (pc33.example.com)。"branch" 参数用于环路检测和事务匹配。
  3. Max-Forwards: Max-Forwards: 70 - 此头字段限制请求被代理转发的次数,以避免无限循环。
  4. To: To: John Doe <sip:jdoe@example.com> - To 头指定呼叫的接收者,包括显示名称 (John Doe) 和 SIP URI (sip:jdoe@example.com)。
  5. From: From: Jane Smith <sip:jsmith@example.org>;tag=1928301774 - From 头指定呼叫的发送者,包括显示名称 (Jane Smith) 和 SIP URI (sip:jsmith@example.org)。"tag" 参数用于唯一标识发送者在对话中的角色。
  6. Call-ID: Call-ID: a84b4c76e66710 - Call-ID 头在两个用户代理之间唯一标识一次呼叫会话。
  7. CSeq: CSeq: 314159 INVITE - CSeq 头包含序列号和请求中使用的方法。它用于将响应与请求匹配并检测乱序消息。
  8. Contact: Contact: <sip:jsmith@pc33.example.com> - Contact 头提供了到发送者的直接路由,可用于后续的请求和响应。
  9. User-Agent: User-Agent: ExampleSIPClient/1.0 - User-Agent 头提供有关发送者软件或硬件的信息,包括名称和版本。
  10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Allow 头列出发送者支持的 SIP 方法,帮助接收方了解通信期间可使用的方法。
  11. Content-Type: Content-Type: application/sdp - Content-Type 头指定消息体的媒体类型,此处为 SDP (Session Description Protocol)。
  12. Content-Length: Content-Length: 142 - Content-Length 头指示消息体的字节大小。
  13. Message Body: 消息体包含 SDP 会话描述,其中包括关于媒体类型、编解码器和建议会话的传输协议的信息。
  • v=0 - 协议版本(SDP 的版本为 0)
  • o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com - 发起者和会话标识符
  • s=- - 会话名称(单个连字符表示没有会话名称)
  • c=IN IP4 pc33.example.com - 连接信息(网络类型、地址类型和地址)
  • t=0 0 - 时间信息(开始和停止时间,0 0 表示会话不受时间限制)
  • m=audio 49170 RTP/AVP 0 - 媒体描述(媒体类型、端口号、传输协议和格式列表)。在此示例中,指定使用 RTP/AVP 的音频流和格式 0(PCMU/8000)。
  • a=rtpmap:0 PCMU/8000 - 将格式 (0) 映射到编解码器 (PCMU) 及其时钟速率 (8000 Hz)。

SIP REGISTER 示例

The REGISTER method is used in Session Initiation Protocol (SIP) to allow a user agent (UA), such as a VoIP phone or a softphone, to 向 SIP 注册服务器注册其位置。此过程使服务器知道 应将发往已注册用户的传入 SIP 请求路由到何处。注册服务器通常是 SIP 代理服务器的一部分或一个独立的注册服务器。

Here's a detailed example of the SIP messages involved in a REGISTER authentication process:

  1. Initial REGISTER request from UA to the registrar server:
yaml
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

这个初始 REGISTER 消息由 UA (Alice) 发送到注册服务器。它包含重要信息,例如期望的注册时长 (Expires)、用户的 SIP URI (sip:alice@example.com),以及用户的联系地址 (sip:alice@192.168.1.100:5060)。

  1. 来自注册服务器的 401 Unauthorized 响应:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
Content-Length: 0

注册服务器以 "401 Unauthorized" 响应,该响应包含一个 "WWW-Authenticate" 头。该头包含 UA 用于认证自身所需的信息,例如 认证域、nonce 和算法

  1. 带有认证凭证的 REGISTER 请求:
vbnet
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
Content-Length: 0

UA 会发送另一个 REGISTER 请求,这次包括 "Authorization" header,其中包含必要的凭证,例如用户名、realm、nonce,以及使用提供的信息和用户密码计算出的 response 值。

下面是 Authorization response 的计算方法:

python
import hashlib

def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
# 1. Calculate HA1 (concatenation of username, realm, and password)
ha1_input = f"{username}:{realm}:{password}"
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()

# 2. Calculate HA2 (concatenation of method and uri)
ha2_input = f"{method}:{uri}"
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()

# 3. Calculate the final response value (concatenation of h1, stuff and h2)
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
response = hashlib.md5(response_input.encode()).hexdigest()

return response

# Example usage
username = "alice"
password = "mysecretpassword"
realm = "example.com"
method = "REGISTER"
uri = "sip:example.com"
nonce = "abcdefghijk"
nc = "00000001"
cnonce = "lmnopqrst"
qop = "auth"

response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
print(f"MD5 response value: {response}")
  1. 注册成功 来自注册服务器的响应:
yaml
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

在注册服务器验证所提供的凭证后,它会发送一个 "200 OK" 响应以表示注册成功。响应包含已注册的联系信息和注册的过期时间。此时,用户代理(Alice)已成功在 SIP registrar 服务器上注册,对 Alice 的传入 SIP 请求可以路由到相应的联系地址。

呼叫示例

tip

虽然未提及,但 User B 需要先发送 REGISTER message to Proxy 2,才能接收呼叫。


SIP 安全与 Pentesting 注意事项

本节补充了实用的协议特定提示,而不重复更广泛的 VoIP 指南。有关端到端 VoIP 攻击方法、工具和场景,请参见:

Pentesting VoIP

指纹识别与发现

  • 发送一个 OPTIONS 请求并检查 AllowSupportedServerUser-Agent 头以对设备和堆栈进行指纹识别:
bash
# nmap NSE (UDP 5060 by default)
sudo nmap -sU -p 5060 --script sip-methods <target>

# Minimal raw OPTIONS over UDP
printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060

用户名/分机 枚举行为

  • 枚举通常利用在 REGISTER/INVITE401/407404/403 之间的差异。应加强服务器以统一返回响应。
  • Asterisk chan_sip:设置 alwaysauthreject=yes(通用)以避免泄露有效用户。在较新的 Asterisk (PJSIP) 中,除非定义了 anonymous endpoint,否则 guest calling 被禁用,并且类似的 "always auth reject" 行为为默认;仍应在边界处强制实施网络 ACL 和 fail2ban。

SIP Digest 验证:算法与破解

  • SIP 通常使用 HTTP-Digest 风格的认证。历史上 MD5(及 MD5-sess)较为常见;较新的栈根据 RFC 8760 支持 SHA-256 和 SHA-512/256。应在现代部署中优先使用这些更强的算法,并在可能时禁用 MD5。
  • 对于 MD5 摘要,从 pcap 中离线破解非常简单。在提取挑战/响应后,你可以使用 hashcat 模式 11400(SIP digest,MD5):
bash
# Example hash format (single line)
# username:realm:method:uri:nonce:cnonce:nc:qop:response
echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash

# Crack with a wordlist
hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt

note

RFC 8760 为 HTTP Digest(SIP 中也使用)定义了 SHA-256 和 SHA-512/256。采纳程度不均;在针对现代 PBX 时,确保你的工具支持这些算法。

SIP over TLS (SIPS) 和 WebSockets

  • 信令加密:
  • sips: URI 和 TCP/TLS 通常使用 5061。验证端点上的证书校验;许多接受自签或通配符证书,这会在弱部署中使 MitM 成为可能。
  • WebRTC softphones 通常根据 RFC 7118 使用通过 WebSocket 的 SIP(ws://wss://)。如果 PBX 暴露了 WSS,应测试认证和 CORS,并确保在 HTTP 前端也实施速率限制。

DoS 快速检查(协议层)

  • 洪泛 INVITE、REGISTER 或畸形消息可能耗尽事务处理能力。
  • 对于 UDP/5060 的简单速率限制示例(Linux iptables hashlimit):
bash
# Limit new SIP packets from a single IP to 20/s with burst 40
iptables -A INPUT -p udp --dport 5060 -m hashlimit \
--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \
--hashlimit-mode srcip -j ACCEPT
iptables -A INPUT -p udp --dport 5060 -j DROP

最近相关的 SIP 栈 CVE 关注(Asterisk PJSIP)

  • CVE-2024-35190 (published May 17, 2024): 在特定的 Asterisk 版本中,res_pjsip_endpoint_identifier_ip 可能错误地将未授权的 SIP 请求识别为本地端点,可能导致未授权操作或信息泄露。已在 18.23.1、20.8.1 和 21.3.1 中修复。在测试时验证你的 PBX 版本并负责任地报告。

强化清单(SIP 专用)

  • 优先对信令使用 TLS,对媒体使用 SRTP/DTLS-SRTP;在可行时禁用明文。
  • 强制使用强密码和摘要算法(在支持时使用 SHA-256/512-256;避免 MD5)。
  • 对于 Asterisk:
  • chan_sip:alwaysauthreject=yesallowguest=no,以及按端点的 permit/deny CIDR ACLs。
  • PJSIP:除非必要,不要创建 anonymous endpoint;强制端点 acl/media_acl;启用 fail2ban 或等效工具。
  • 在 SIP 代理上进行拓扑隐藏(例如,出站代理/边缘 SBC),以减少信息泄露。
  • 严格处理 OPTIONS 并施加速率限制;禁用不需要的方法(例如 MESSAGEPUBLISH)如果不需要。

参考资料

  • RFC 8760 – 为 HTTP Digest 使用 SHA-256 和 SHA-512/256(也适用于 SIP Digest):https://www.rfc-editor.org/rfc/rfc8760
  • Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9

tip

学习和实践 AWS 黑客技术:HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术:HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术:HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks