mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-voip/basic-voip-
This commit is contained in:
parent
0d60294a3f
commit
16370270cb
@ -1,75 +1,75 @@
|
||||
# SIP (Session Initiation Protocol)
|
||||
# SIP (会话发起协议)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本信息
|
||||
|
||||
SIP (会话发起协议) 是一种**信令和呼叫控制协议**,广泛用于在 IP 网络上建立、修改和终止多媒体会话,包括语音、视频和即时消息。SIP 由**互联网工程任务组 (IETF)** 开发,定义在**RFC 3261**中,已成为 VoIP 和统一通信的事实标准。
|
||||
SIP (Session Initiation Protocol) 是一种广泛用于在 IP 网络上建立、修改和终止多媒体会话(包括语音、视频和即时消息)的信令和呼叫控制协议。由 **Internet Engineering Task Force (IETF)** 制定,SIP 在 **RFC 3261** 中定义,已成为 VoIP 和统一通信的事实标准。
|
||||
|
||||
SIP 的一些关键特性包括:
|
||||
|
||||
1. **基于文本的协议**:SIP 是一种基于文本的协议,使其易于阅读和调试。它基于请求-响应模型,类似于 HTTP,并使用 INVITE、ACK、BYE 和 CANCEL 等方法来控制呼叫会话。
|
||||
2. **可扩展性和灵活性**:SIP 具有高度的可扩展性,可用于小规模部署以及大型企业和运营商级环境。它可以轻松扩展新功能,使其适应各种用例和需求。
|
||||
3. **互操作性**:SIP 的广泛采用和标准化确保了不同设备、应用程序和服务提供商之间更好的互操作性,促进了各种平台之间的无缝通信。
|
||||
4. **模块化设计**:SIP 与其他协议(如**RTP (实时传输协议)**用于媒体传输和**SDP (会话描述协议)**用于描述多媒体会话)协同工作。这种模块化设计允许更大的灵活性和与不同媒体类型和编解码器的兼容性。
|
||||
5. **代理和重定向服务器**:SIP 可以使用代理和重定向服务器来促进呼叫路由,并提供呼叫转移、呼叫转接和语音邮件服务等高级功能。
|
||||
6. **状态和即时消息**: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 有许多优点,但在处理 NAT 遍历和防火墙问题时配置和管理可能比较复杂。然而,其多功能性、可扩展性以及行业内的广泛支持使其成为 VoIP 和多媒体通信的流行选择。
|
||||
|
||||
### SIP 方法
|
||||
### SIP Methods
|
||||
|
||||
在**RFC 3261**中定义的核心 SIP 方法包括:
|
||||
在 **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 注册服务器注册其当前位置**。REGISTER 方法有助于维护用户的 SIP URI 和其当前 IP 地址之间的最新映射,从而实现呼叫路由和交付。
|
||||
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]
|
||||
> 请注意,呼叫某人**不需要使用 REGISTER**。\
|
||||
> 然而,可能需要在执行**INVITE**之前,呼叫者需要**进行身份验证**,否则将收到**`401 Unauthorized`** 响应。
|
||||
> 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 扩展方法**,例如:
|
||||
除了这些核心方法外,还有在其他 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 方法由用户代理用于**向服务器发布事件状态信息**,使其对其他相关方可用。
|
||||
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 响应代码
|
||||
### SIP Response Codes
|
||||
|
||||
- **1xx (临时响应)**:这些响应表示请求已被接收,服务器正在继续处理。
|
||||
- **1xx (Provisional Responses)**:这些响应表示请求已被接收,服务器正在继续处理它。
|
||||
- 100 Trying: 请求已被接收,服务器正在处理。
|
||||
- 180 Ringing: 被叫方正在被提醒,将接听电话。
|
||||
- 180 Ringing: 被叫方正在被提醒并将接听呼叫。
|
||||
- 183 Session Progress: 提供有关呼叫进展的信息。
|
||||
- **2xx (成功响应)**:这些响应表示请求已成功接收、理解和接受。
|
||||
- 200 OK: 请求成功,服务器已满足请求。
|
||||
- 202 Accepted: 请求已被接受处理,但尚未完成。
|
||||
- **3xx (重定向响应)**:这些响应表示需要进一步的操作来满足请求,通常是通过联系替代资源。
|
||||
- 300 Multiple Choices: 有多个可用选项,用户或客户端必须选择一个。
|
||||
- 301 Moved Permanently: 请求的资源已分配新的永久 URI。
|
||||
- 302 Moved Temporarily: 请求的资源暂时可在不同的 URI 上使用。
|
||||
- 305 Use Proxy: 请求必须发送到指定的代理。
|
||||
- **4xx (客户端错误响应)**:这些响应表示请求包含错误的语法或服务器无法满足请求。
|
||||
- **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: 服务器理解请求但拒绝满足。
|
||||
- 401 Unauthorized: 请求需要用户认证。
|
||||
- 403 Forbidden: 服务器理解请求但拒绝执行。
|
||||
- 404 Not Found: 请求的资源在服务器上未找到。
|
||||
- 408 Request Timeout: 服务器在准备等待的时间内未收到完整请求。
|
||||
- 486 Busy Here: 被叫方当前忙碌,无法接听电话。
|
||||
- **5xx (服务器错误响应)**:这些响应表示服务器未能满足有效请求。
|
||||
- 486 Busy Here: 被叫方当前忙碌,无法接听呼叫。
|
||||
- **5xx (Server Error Responses)**:这些响应表示服务器未能完成有效的请求。
|
||||
- 500 Internal Server Error: 服务器在处理请求时遇到错误。
|
||||
- 501 Not Implemented: 服务器不支持满足请求所需的功能。
|
||||
- 503 Service Unavailable: 服务器当前无法处理请求,因维护或过载。
|
||||
- **6xx (全局失败响应)**:这些响应表示请求无法被任何服务器满足。
|
||||
- 600 Busy Everywhere: 呼叫的所有可能目的地都忙。
|
||||
- 501 Not Implemented: 服务器不支持完成请求所需的功能。
|
||||
- 503 Service Unavailable: 服务器当前因维护或过载无法处理请求。
|
||||
- **6xx (Global Failure Responses)**:这些响应表示任何服务器都无法完成该请求。
|
||||
- 600 Busy Everywhere: 呼叫的所有可能目的地都很忙。
|
||||
- 603 Decline: 被叫方不愿意参与呼叫。
|
||||
- 604 Does Not Exist Anywhere: 请求的资源在网络中不可用。
|
||||
- 604 Does Not Exist Anywhere: 请求的资源在网络中任何地方都不可用。
|
||||
|
||||
## 示例
|
||||
|
||||
@ -94,43 +94,43 @@ s=-
|
||||
c=IN IP4 pc33.example.com
|
||||
t=0 0
|
||||
m=audio 49170 RTP/AVP 0
|
||||
a=rtpmap:0 PCMU/8000te
|
||||
a=rtpmap:0 PCMU/8000
|
||||
```
|
||||
<details>
|
||||
|
||||
<summary>每个参数解释</summary>
|
||||
<summary>每个参数说明</summary>
|
||||
|
||||
1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - 该行指示方法(INVITE)、请求URI(sip:[jdoe@example.com](mailto: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](mailto:jdoe@example.com))。
|
||||
5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - From头指定通话的发送者,包括他们的显示名称(Jane Smith)和SIP URI(sip:[jsmith@example.org](mailto: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(会话描述协议)。
|
||||
12. **Content-Length**: `Content-Length: 142` - Content-Length头指示消息体的大小(以字节为单位)。
|
||||
13. **Message Body**: 消息体包含SDP会话描述,其中包括有关媒体类型、编解码器和提议会话的传输协议的信息。
|
||||
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)
|
||||
- `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)。
|
||||
- `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)。
|
||||
|
||||
</details>
|
||||
|
||||
### SIP REGISTER 示例
|
||||
|
||||
REGISTER方法用于会话发起协议(SIP),允许用户代理(UA),例如VoIP电话或软电话,**向SIP注册服务器注册其位置**。此过程使服务器知道**将传入的SIP请求路由到注册用户的地方**。注册服务器通常是SIP代理服务器或专用注册服务器的一部分。
|
||||
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 代理服务器的一部分或一个独立的注册服务器。
|
||||
|
||||
以下是涉及REGISTER身份验证过程的SIP消息的详细示例:
|
||||
Here's a detailed example of the SIP messages involved in a REGISTER authentication process:
|
||||
|
||||
1. 从UA到注册服务器的初始**REGISTER**请求:
|
||||
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
|
||||
@ -143,11 +143,11 @@ 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](mailto:alice@example.com))和用户的联系地址(sip:alice@192.168.1.100:5060)。
|
||||
这个初始 REGISTER 消息由 UA (Alice) 发送到注册服务器。它包含重要信息,例如期望的注册时长 (Expires)、用户的 SIP URI (sip:[alice@example.com](mailto:alice@example.com)),以及用户的联系地址 (sip:alice@192.168.1.100:5060)。
|
||||
|
||||
2. **401 Unauthorized** 来自注册服务器的响应:
|
||||
```css
|
||||
cssCopy codeSIP/2.0 401 Unauthorized
|
||||
2. 来自注册服务器的 **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
|
||||
@ -156,9 +156,9 @@ CSeq: 1 REGISTER
|
||||
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
|
||||
Content-Length: 0
|
||||
```
|
||||
注册服务器以“401 Unauthorized”消息响应,其中包含“WWW-Authenticate”头。该头包含UA进行身份验证所需的信息,例如**身份验证域、nonce和算法**。
|
||||
注册服务器以 "401 Unauthorized" 响应,该响应包含一个 "WWW-Authenticate" 头。该头包含 UA 用于认证自身所需的信息,例如 **认证域、nonce 和算法**。
|
||||
|
||||
3. 带有身份验证凭据的REGISTER请求:
|
||||
3. 带有**认证凭证**的 REGISTER 请求:
|
||||
```vbnet
|
||||
REGISTER sip:example.com SIP/2.0
|
||||
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
|
||||
@ -172,9 +172,9 @@ 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"头,带有必要的凭据,如用户名、域、随机数和使用提供的信息和用户密码计算的响应值**。
|
||||
UA 会发送另一个 REGISTER 请求,这次包括 **"Authorization" header**,其中包含必要的凭证,例如用户名、realm、nonce,以及使用提供的信息和用户密码计算出的 response 值。
|
||||
|
||||
这就是**Authorization响应**的计算方式:
|
||||
下面是 **Authorization response** 的计算方法:
|
||||
```python
|
||||
import hashlib
|
||||
|
||||
@ -207,7 +207,7 @@ qop = "auth"
|
||||
response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
|
||||
print(f"MD5 response value: {response}")
|
||||
```
|
||||
4. **成功注册** 来自注册服务器的响应:
|
||||
4. **注册成功** 来自注册服务器的响应:
|
||||
```yaml
|
||||
SIP/2.0 200 OK
|
||||
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
|
||||
@ -219,13 +219,98 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
|
||||
Expires: 3600
|
||||
Content-Length: 0
|
||||
```
|
||||
在注册服务器验证提供的凭据后,**它发送一个 "200 OK" 响应以指示注册成功**。响应包括注册的联系信息和注册的过期时间。此时,用户代理(Alice)已成功注册到SIP注册服务器,针对Alice的传入SIP请求可以路由到适当的联系地址。
|
||||
在注册服务器验证所提供的凭证后,**它会发送一个 "200 OK" 响应以表示注册成功**。响应包含已注册的联系信息和注册的过期时间。此时,用户代理(Alice)已成功在 SIP registrar 服务器上注册,对 Alice 的传入 SIP 请求可以路由到相应的联系地址。
|
||||
|
||||
### 呼叫示例
|
||||
|
||||
<figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> 虽然没有提到,但用户B需要在能够接听电话之前向代理2发送**REGISTER消息**。
|
||||
> [!TIP]
|
||||
> 虽然未提及,但 User B 需要先发送 **REGISTER message to Proxy 2**,才能接收呼叫。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## SIP 安全与 Pentesting 注意事项
|
||||
|
||||
本节补充了实用的协议特定提示,而不重复更广泛的 VoIP 指南。有关端到端 VoIP 攻击方法、工具和场景,请参见:
|
||||
|
||||
{{#ref}}
|
||||
../README.md
|
||||
{{#endref}}
|
||||
|
||||
### 指纹识别与发现
|
||||
|
||||
- 发送一个 OPTIONS 请求并检查 `Allow`、`Supported`、`Server` 和 `User-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`/`INVITE` 上 `401/407` 与 `404/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=yes`、`allowguest=no`,以及按端点的 `permit`/`deny` CIDR ACLs。
|
||||
- PJSIP:除非必要,不要创建 `anonymous` endpoint;强制端点 `acl`/`media_acl`;启用 fail2ban 或等效工具。
|
||||
- 在 SIP 代理上进行拓扑隐藏(例如,出站代理/边缘 SBC),以减少信息泄露。
|
||||
- 严格处理 `OPTIONS` 并施加速率限制;禁用不需要的方法(例如 `MESSAGE`、`PUBLISH`)如果不需要。
|
||||
|
||||
|
||||
|
||||
## 参考资料
|
||||
|
||||
- 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
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user