Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-19 17:44:47 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

261 lines
20 KiB
Markdown
Raw Blame History

# SIP (Session Initiation Protocol)
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
{% endhint %}
{% endhint %}
## Basic Information
SIP (Session Initiation Protocol) é um **protocolo de sinalização e controle de chamadas** amplamente utilizado para estabelecer, modificar e encerrar sessões multimídia, incluindo voz, vídeo e mensagens instantâneas, sobre redes IP. Desenvolvido pelo **Internet Engineering Task Force (IETF)**, o SIP é definido na **RFC 3261** e se tornou o padrão de fato para VoIP e comunicações unificadas.
Alguns recursos principais do SIP incluem:
1. **Protocolo Baseado em Texto**: O SIP é um protocolo baseado em texto, o que o torna legível por humanos e mais fácil de depurar. Ele é baseado em um modelo de solicitação-resposta, semelhante ao HTTP, e usa métodos como INVITE, ACK, BYE e CANCEL para controlar sessões de chamadas.
2. **Escalabilidade e Flexibilidade**: O SIP é altamente escalável e pode ser usado em implantações de pequeno porte, bem como em ambientes empresariais e de operadoras de grande porte. Ele pode ser facilmente estendido com novos recursos, tornando-o adaptável a vários casos de uso e requisitos.
3. **Interoperabilidade**: A ampla adoção e padronização do SIP garantem melhor interoperabilidade entre diferentes dispositivos, aplicativos e provedores de serviços, promovendo comunicação sem interrupções em várias plataformas.
4. **Design Modular**: O SIP funciona com outros protocolos como **RTP (Real-time Transport Protocol)** para transmissão de mídia e **SDP (Session Description Protocol)** para descrever sessões multimídia. Esse design modular permite maior flexibilidade e compatibilidade com diferentes tipos de mídia e codecs.
5. **Servidores Proxy e de Redirecionamento**: O SIP pode usar servidores proxy e de redirecionamento para facilitar o roteamento de chamadas e fornecer recursos avançados como encaminhamento de chamadas, transferência de chamadas e serviços de correio de voz.
6. **Presença e Mensagens Instantâneas**: O SIP não se limita à comunicação de voz e vídeo. Ele também suporta presença e mensagens instantâneas, permitindo uma ampla gama de aplicativos de comunicação unificada.
Apesar de suas muitas vantagens, o SIP pode ser complexo de configurar e gerenciar, especialmente ao lidar com problemas de travessia de NAT e firewall. No entanto, sua versatilidade, escalabilidade e amplo suporte na indústria o tornam uma escolha popular para comunicação VoIP e multimídia.
### SIP Methods
Os métodos principais do SIP definidos na **RFC 3261** incluem:
1. **INVITE**: Usado para **iniciar uma nova sessão (chamada)** ou modificar uma existente. O método INVITE carrega a descrição da sessão (tipicamente usando SDP) para informar o destinatário sobre os detalhes da sessão proposta, como tipos de mídia, codecs e protocolos de transporte.
2. **ACK**: Enviado para **confirmar o recebimento** de uma resposta final a uma solicitação INVITE. O método ACK garante a confiabilidade das transações INVITE, fornecendo reconhecimento de ponta a ponta.
3. **BYE**: Usado para **encerrar uma sessão estabelecida (chamada)**. O método BYE é enviado por qualquer uma das partes na sessão para indicar que deseja encerrar a comunicação.
4. **CANCEL**: Enviado para **cancelar uma solicitação INVITE pendente** antes que a sessão seja estabelecida. O método CANCEL permite que o remetente cancele uma transação INVITE se mudar de ideia ou se não houver resposta do destinatário.
5. **OPTIONS**: Usado para **consultar as capacidades de um servidor SIP ou agente de usuário**. O método OPTIONS pode ser enviado para solicitar informações sobre métodos suportados, tipos de mídia ou outras extensões sem realmente estabelecer uma sessão.
6. **REGISTER**: Usado por um agente de usuário para **registrar sua localização atual com um servidor registrador SIP**. O método REGISTER ajuda a manter um mapeamento atualizado entre o URI SIP de um usuário e seu endereço IP atual, permitindo o roteamento e a entrega de chamadas.
{% hint style="warning" %}
Note que para chamar alguém **não é necessário usar o REGISTER** para nada.\
No entanto, é possível que para realizar um **INVITE** o chamador precise **se autenticar** primeiro ou receberá uma resposta **`401 Unauthorized`**.
{% endhint %}
Além desses métodos principais, existem **vários métodos de extensão SIP** definidos em outras RFCs, como:
1. **SUBSCRIBE**: Definido na RFC 6665, o método SUBSCRIBE é usado para **solicitar notificações** sobre o estado de um recurso específico, como a presença ou status de chamada de um usuário.
2. **NOTIFY**: Também definido na RFC 6665, o método NOTIFY é enviado por um servidor para **informar um agente de usuário inscrito** sobre mudanças no estado de um recurso monitorado.
3. **REFER**: Definido na RFC 3515, o método REFER é usado para **solicitar que o destinatário realize uma transferência ou se refira a um terceiro**. Isso é tipicamente usado para cenários de **transferência de chamadas**.
4. **MESSAGE**: Definido na RFC 3428, o método MESSAGE é usado para **enviar mensagens instantâneas entre agentes de usuário SIP**, permitindo comunicação baseada em texto dentro da estrutura SIP.
5. **UPDATE**: Definido na RFC 3311, o método UPDATE permite **modificar uma sessão sem afetar o estado do diálogo existente**. Isso é útil para atualizar parâmetros de sessão, como codecs ou tipos de mídia, durante uma chamada em andamento.
6. **PUBLISH**: Definido na RFC 3903, o método PUBLISH é usado por um agente de usuário para **publicar informações de estado de eventos em um servidor**, tornando-as disponíveis para outras partes interessadas.
### SIP Response Codes
* **1xx (Respostas Provisórias)**: Essas respostas indicam que a solicitação foi recebida e o servidor está continuando a processá-la.
* 100 Trying: A solicitação foi recebida e o servidor está trabalhando nela.
* 180 Ringing: O chamado está sendo alertado e atenderá a chamada.
* 183 Session Progress: Fornece informações sobre o progresso da chamada.
* **2xx (Respostas de Sucesso)**: Essas respostas indicam que a solicitação foi recebida, compreendida e aceita com sucesso.
* 200 OK: A solicitação foi bem-sucedida e o servidor a atendeu.
* 202 Accepted: A solicitação foi aceita para processamento, mas ainda não foi concluída.
* **3xx (Respostas de Redirecionamento)**: Essas respostas indicam que mais ações são necessárias para atender à solicitação, normalmente contatando um recurso alternativo.
* 300 Multiple Choices: Existem várias opções disponíveis, e o usuário ou cliente deve escolher uma.
* 301 Moved Permanently: O recurso solicitado foi atribuído a um novo URI permanente.
* 302 Moved Temporarily: O recurso solicitado está temporariamente disponível em um URI diferente.
* 305 Use Proxy: A solicitação deve ser enviada a um proxy especificado.
* **4xx (Respostas de Erro do Cliente)**: Essas respostas indicam que a solicitação contém uma sintaxe incorreta ou não pode ser atendida pelo servidor.
* 400 Bad Request: A solicitação estava malformada ou inválida.
* 401 Unauthorized: A solicitação requer autenticação do usuário.
* 403 Forbidden: O servidor entendeu a solicitação, mas se recusa a atendê-la.
* 404 Not Found: O recurso solicitado não foi encontrado no servidor.
* 408 Request Timeout: O servidor não recebeu uma solicitação completa dentro do tempo que estava preparado para esperar.
* 486 Busy Here: O chamado está atualmente ocupado e não pode atender a chamada.
* **5xx (Respostas de Erro do Servidor)**: Essas respostas indicam que o servidor falhou em atender a uma solicitação válida.
* 500 Internal Server Error: O servidor encontrou um erro ao processar a solicitação.
* 501 Not Implemented: O servidor não suporta a funcionalidade necessária para atender à solicitação.
* 503 Service Unavailable: O servidor está atualmente incapaz de lidar com a solicitação devido a manutenção ou sobrecarga.
* **6xx (Respostas de Falha Global)**: Essas respostas indicam que a solicitação não pode ser atendida por nenhum servidor.
* 600 Busy Everywhere: Todos os destinos possíveis para a chamada estão ocupados.
* 603 Decline: O chamado não deseja participar da chamada.
* 604 Does Not Exist Anywhere: O recurso solicitado não está disponível em nenhum lugar da rede.
## Examples
### SIP INVITE Example
```
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/8000te
```
<details>
<summary>Cada Parâmetro Explicado</summary>
1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Esta linha indica o método (INVITE), o URI de solicitação (sip:[jdoe@example.com](mailto:jdoe@example.com)) e a versão SIP (SIP/2.0).
2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - O cabeçalho Via especifica o protocolo de transporte (UDP) e o endereço do cliente (pc33.example.com). O parâmetro "branch" é usado para detecção de loops e correspondência de transações.
3. **Max-Forwards**: `Max-Forwards: 70` - Este campo de cabeçalho limita o número de vezes que a solicitação pode ser encaminhada por proxies para evitar loops infinitos.
4. **To**: `To: John Doe <sip:jdoe@example.com>` - O cabeçalho To especifica o destinatário da chamada, incluindo seu nome de exibição (John Doe) e URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)).
5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - O cabeçalho From especifica o remetente da chamada, incluindo seu nome de exibição (Jane Smith) e URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). O parâmetro "tag" é usado para identificar exclusivamente o papel do remetente no diálogo.
6. **Call-ID**: `Call-ID: a84b4c76e66710` - O cabeçalho Call-ID identifica exclusivamente uma sessão de chamada entre dois agentes de usuário.
7. **CSeq**: `CSeq: 314159 INVITE` - O cabeçalho CSeq contém um número de sequência e o método usado na solicitação. É usado para corresponder respostas a solicitações e detectar mensagens fora de ordem.
8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - O cabeçalho Contact fornece uma rota direta para o remetente, que pode ser usada para solicitações e respostas subsequentes.
9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - O cabeçalho User-Agent fornece informações sobre o software ou hardware do remetente, incluindo seu nome e versão.
10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - O cabeçalho Allow lista os métodos SIP suportados pelo remetente. Isso ajuda o destinatário a entender quais métodos podem ser usados durante a comunicação.
11. **Content-Type**: `Content-Type: application/sdp` - O cabeçalho Content-Type especifica o tipo de mídia do corpo da mensagem, neste caso, SDP (Session Description Protocol).
12. **Content-Length**: `Content-Length: 142` - O cabeçalho Content-Length indica o tamanho do corpo da mensagem em bytes.
13. **Message Body**: O corpo da mensagem contém a descrição da sessão SDP, que inclui informações sobre os tipos de mídia, codecs e protocolos de transporte para a sessão proposta.
* `v=0` - Versão do protocolo (0 para SDP)
* `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originador e identificador da sessão
* `s=-` - Nome da sessão (um único hífen indica que não há nome de sessão)
* `c=IN IP4 pc33.example.com` - Informações de conexão (tipo de rede, tipo de endereço e endereço)
* `t=0 0` - Informações de tempo (horários de início e parada, 0 0 significa que a sessão não está limitada)
* `m=audio 49170 RTP/AVP 0` - Descrição da mídia (tipo de mídia, número da porta, protocolo de transporte e lista de formatos). Neste caso, especifica um fluxo de áudio usando RTP/AVP (Real-time Transport Protocol / Audio Video Profile) e formato 0 (PCMU/8000).
* `a=rtpmap:0 PCMU/8000` - Mapeamento de atributo do formato (0) para o codec (PCMU) e sua taxa de clock (8000 Hz).
</details>
### Exemplo de SIP REGISTER
O método REGISTER é usado no Protocolo de Iniciação de Sessão (SIP) para permitir que um agente de usuário (UA), como um telefone VoIP ou um softphone, **registre sua localização em um servidor registrador SIP**. Este processo informa ao servidor **onde encaminhar as solicitações SIP recebidas destinadas ao usuário registrado**. O servidor registrador geralmente faz parte de um servidor proxy SIP ou de um servidor de registro dedicado.
Aqui está um exemplo detalhado das mensagens SIP envolvidas em um processo de autenticação REGISTER:
1. Solicitação inicial **REGISTER** do UA para o servidor registrador:
```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
```
Esta mensagem inicial de REGISTER é enviada pelo UA (Alice) para o servidor registrador. Ela inclui informações importantes, como a duração de registro desejada (Expires), o URI SIP do usuário (sip:[alice@example.com](mailto:alice@example.com)) e o endereço de contato do usuário (sip:alice@192.168.1.100:5060).
2. **401 Unauthorized** resposta do servidor registrador:
```css
cssCopy codeSIP/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
```
O servidor registrador responde com uma mensagem "401 Unauthorized", que inclui um cabeçalho "WWW-Authenticate". Este cabeçalho contém informações necessárias para que o UA se autentique, como o **domínio de autenticação, nonce e algoritmo**.
3. Solicitação REGISTER **com credenciais de autenticação**:
```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
```
O UA envia outra solicitação REGISTER, desta vez incluindo o **cabeçalho "Authorization" com as credenciais necessárias, como o nome de usuário, realm, nonce e um valor de resposta** calculado usando as informações fornecidas e a senha do usuário.
É assim que a **resposta de Authorization** é calculada:
```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}")
```
4. **Resposta de registro bem-sucedido** do servidor registrador:
```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
```
Após o servidor registrador verificar as credenciais fornecidas, **ele envia uma resposta "200 OK" para indicar que o registro foi bem-sucedido**. A resposta inclui as informações de contato registradas e o tempo de expiração para o registro. Neste ponto, o agente do usuário (Alice) está registrado com sucesso no servidor registrador SIP, e as solicitações SIP recebidas para Alice podem ser roteadas para o endereço de contato apropriado.
### Exemplo de Chamada
<figure><img src="../../../.gitbook/assets/image (1101).png" alt=""><figcaption></figcaption></figure>
{% hint style="info" %}
Não é mencionado, mas o Usuário B precisa ter enviado uma **mensagem REGISTER para o Proxy 2** antes de poder receber chamadas.
{% endhint %}
{% hint style="success" %}
Aprenda e pratique Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Aprenda e pratique Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
{% endhint %}
</details>
{% endhint %}
Reference in a new issue View git blame Copy permalink