mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-19 01:24:50 +00:00
242 lines
19 KiB
Markdown
242 lines
19 KiB
Markdown
# SIP (Session Initiation Protocol)
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras maneiras de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
|
|
|
</details>
|
|
|
|
## Informações Básicas
|
|
|
|
O SIP (Protocolo de Iniciação de Sessão) é 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, em redes IP. Desenvolvido pelo **Internet Engineering Task Force (IETF)**, o SIP é definido no **RFC 3261** e se tornou o padrão de fato para VoIP e comunicações unificadas.
|
|
|
|
Algumas características-chave do SIP incluem:
|
|
|
|
1. **Protocolo Baseado em Texto**: O SIP é um protocolo baseado em texto, o que o torna legível para 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 chamada.
|
|
2. **Escalabilidade e Flexibilidade**: O SIP é altamente escalável e pode ser usado em implantações de pequena escala, 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 uma melhor interoperabilidade entre diferentes dispositivos, aplicativos e provedores de serviços, promovendo uma comunicação contínua em várias plataformas.
|
|
4. **Design Modular**: O SIP funciona com outros protocolos como **RTP (Protocolo de Transporte em Tempo Real)** para transmissão de mídia e **SDP (Protocolo de Descrição de Sessão)** para descrever sessões multimídia. Esse design modular permite uma maior flexibilidade e compatibilidade com diferentes tipos de mídia e codecs.
|
|
5. **Servidores de Proxy e Redirecionamento**: O SIP pode usar servidores de proxy e 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 por voz e vídeo. Ele também suporta presença e mensagens instantâneas, possibilitando 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.
|
|
|
|
### Métodos SIP
|
|
|
|
Os principais métodos SIP definidos no **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 parte na sessão para indicar que desejam 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 ou agente de usuário SIP**. 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 de registro 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, possibilitando o roteamento e entrega de chamadas.
|
|
|
|
{% hint style="warning" %}
|
|
Observe que para ligar para 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 ele receberá uma resposta **`401 Não Autorizado`**.
|
|
{% endhint %}
|
|
|
|
Além desses métodos principais, existem **vários métodos de extensão SIP** definidos em outros RFCs, como:
|
|
|
|
1. **SUBSCRIBE**: Definido no RFC 6665, o método SUBSCRIBE é usado para **solicitar notificações** sobre o estado de um recurso específico, como a presença de um usuário ou status de chamada.
|
|
2. **NOTIFY**: Também definido no RFC 6665, o método NOTIFY é enviado por um servidor para **informar um agente de usuário inscrito** sobre alterações no estado de um recurso monitorado.
|
|
3. **REFER**: Definido no 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 chamada**.
|
|
4. **MESSAGE**: Definido no RFC 3428, o método MESSAGE é usado para **enviar mensagens instantâneas entre agentes de usuário SIP**, possibilitando comunicação baseada em texto dentro do framework SIP.
|
|
5. **UPDATE**: Definido no 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 no RFC 3903, o método PUBLISH é usado por um agente de usuário para **publicar informações de estado de evento em um servidor**, tornando-as disponíveis para outras partes interessadas.
|
|
|
|
### Códigos de Resposta SIP
|
|
|
|
* **1xx (Respostas Provisórias)**: Essas respostas indicam que a solicitação foi recebida e o servidor está continuando a processá-la.
|
|
* 100 Tentando: A solicitação foi recebida, e o servidor está trabalhando nela.
|
|
* 180 Chamando: O destinatário está sendo alertado e atenderá a chamada.
|
|
* 183 Progresso da Sessão: Fornece informações sobre o progresso da chamada.
|
|
* **2xx (Respostas Bem-Sucedidas)**: 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 cumpriu.
|
|
* 202 Aceito: A solicitação foi aceita para processamento, mas ainda não foi concluída.
|
|
* **3xx (Respostas de Redirecionamento)**: Essas respostas indicam que é necessária uma ação adicional para atender à solicitação, geralmente entrando em contato com um recurso alternativo.
|
|
* 300 Múltiplas Escolhas: Existem várias opções disponíveis, e o usuário ou cliente deve escolher uma.
|
|
* 301 Movido Permanentemente: O recurso solicitado recebeu um novo URI permanente.
|
|
* 302 Movido Temporariamente: 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 ruim ou não pode ser atendida pelo servidor.
|
|
* 400 Solicitação Inválida: A solicitação estava malformada ou inválida.
|
|
* 401 Não Autorizado: A solicitação requer autenticação do usuário.
|
|
* 403 Proibido: O servidor entendeu a solicitação, mas se recusa a atendê-la.
|
|
* 404 Não Encontrado: O recurso solicitado não foi encontrado no servidor.
|
|
* 408 Tempo Limite da Solicitação: O servidor não recebeu uma solicitação completa dentro do tempo que estava preparado para esperar.
|
|
* 486 Ocupado Aqui: O destinatário está ocupado no momento 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 Erro Interno do Servidor: O servidor encontrou um erro ao processar a solicitação.
|
|
* 501 Não Implementado: O servidor não suporta a funcionalidade necessária para atender à solicitação.
|
|
* 503 Serviço Indisponível: O servidor atualmente não consegue 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 Ocupado em Todos os Lugares: Todos os destinos possíveis para a chamada estão ocupados.
|
|
* 603 Recusar: O destinatário não deseja participar da chamada.
|
|
* 604 Não Existe em Nenhum Lugar: O recurso solicitado não está disponível em nenhum lugar na rede.
|
|
## Exemplos
|
|
|
|
### Exemplo de 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/8000te
|
|
```
|
|
<details>
|
|
|
|
<summary>Cada Parâmetro Explicado</summary>
|
|
|
|
1. **Linha de Requisição**: `INVITE sip:jdoe@example.com SIP/2.0` - Esta linha indica o método (INVITE), o URI de requisição (sip:[jdoe@example.com](mailto:jdoe@example.com)), e a versão do 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 loop 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 requisiçã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 do 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 do SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). O parâmetro "tag" é usado para identificar unicamente o papel do remetente no diálogo.
|
|
6. **Call-ID**: `Call-ID: a84b4c76e66710` - O cabeçalho Call-ID identifica unicamente 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 requisição. É usado para corresponder respostas a requisiçõ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 requisiçõ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 (Protocolo de Descrição de Sessão).
|
|
12. **Content-Length**: `Content-Length: 142` - O cabeçalho Content-Length indica o tamanho do corpo da mensagem em bytes.
|
|
13. **Corpo da Mensagem**: 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 hífen único 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 temporização (horários de início e término, 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 (Protocolo de Transporte em Tempo Real / Perfil de Áudio Vídeo) e formato 0 (PCMU/8000).
|
|
* `a=rtpmap:0 PCMU/8000` - Atributo que mapeia o formato (0) para o codec (PCMU) e sua taxa de clock (8000 Hz).
|
|
|
|
</details>
|
|
|
|
### Exemplo de Registro SIP
|
|
|
|
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 com um servidor de registro SIP**. Esse processo permite que o servidor saiba **para onde encaminhar as solicitações SIP recebidas destinadas ao usuário registrado**. O servidor de registro 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 de REGISTRO:
|
|
|
|
1. Requisição de **REGISTER** inicial do UA para o servidor de registro:
|
|
```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
|
|
```
|
|
Este mensagem REGISTER inicial é enviada pelo UA (Alice) para o servidor de registro. Inclui informações importantes como a duração de registro desejada (Expires), o SIP URI 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. Resposta **401 Não Autorizado** do servidor de registro:
|
|
```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 de registro responde com uma mensagem "401 Não autorizado", que inclui um cabeçalho "WWW-Authenticate". Este cabeçalho contém informações necessárias para o UA se autenticar, como o **reino de autenticação, nonce e algoritmo**.
|
|
|
|
3. Pedido de REGISTRO **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 é como o **resposta de Autorização** é 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 de registro:
|
|
```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
|
|
```
|
|
Depois que o servidor de registro verifica 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 do registro. Neste ponto, o agente do usuário (Alice) está registrado com sucesso no servidor de registro SIP, e as solicitações SIP recebidas para Alice podem ser encaminhadas 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 %}
|