SIP (Session Initiation Protocol)

Reading time: 18 minutes

Informações Básicas

SIP (Session Initiation Protocol) é um protocolo de sinalização e controle de chamadas amplamente usado para estabelecer, modificar e terminar sessões multimídia, incluindo voz, vídeo e mensagens instantâneas, sobre redes IP. Desenvolvido pelo Internet Engineering Task Force (IETF), o SIP está definido em RFC 3261 e tornou-se o padrão de fato para VoIP e comunicações unificadas.

Algumas características principais do SIP incluem:

1. Protocolo baseado em texto: SIP é um protocolo baseado em texto, o que o torna legível por humanos e mais fácil de depurar. Baseia-se em um modelo de requisição-resposta, similar ao HTTP, e utiliza métodos como INVITE, ACK, BYE e CANCEL para controlar sessões de chamada.
2. Escalabilidade e Flexibilidade: SIP é altamente escalável e pode ser usado em implantações de pequena escala assim como em ambientes empresariais e de nível carrier. Pode ser facilmente estendido com novas funcionalidades, 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, aplicações e provedores de serviço, promovendo comunicação contínua entre várias plataformas.
4. Design Modular: 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 Redirect: SIP pode usar servidores proxy e redirect para facilitar o roteamento de chamadas e fornecer funcionalidades avançadas como encaminhamento de chamadas, transferência de chamadas e serviços de voicemail.
6. Presence e Instant Messaging: SIP não se limita a voz e vídeo. Também suporta presence e instant messaging, permitindo uma ampla gama de aplicações de comunicação unificada.

Apesar de suas muitas vantagens, o SIP pode ser complexo de configurar e gerenciar, particularmente quando se lida com traversal de NAT e questões de firewall. Contudo, sua versatilidade, escalabilidade e amplo suporte na indústria o tornam uma escolha popular para VoIP e comunicação multimídia.

SIP Methods

Os métodos centrais do SIP definidos em 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 requisição INVITE. O método ACK garante a confiabilidade das transações INVITE fornecendo uma confirmação de ponta a ponta.
3. BYE: Usado para terminar 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 um INVITE pendente antes que a sessão seja estabelecida. O método CANCEL permite ao remetente abortar 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 em um servidor registrar SIP. O método REGISTER ajuda a manter um mapeamento atualizado entre o SIP URI de um usuário e seu endereço IP atual, possibilitando o roteamento e a entrega de chamadas.

Além desses métodos centrais, existem vários métodos de extensão SIP definidos em outros RFCs, tais como:

1. SUBSCRIBE: Definido em RFC 6665, o método SUBSCRIBE é usado para solicitar notificações sobre o estado de um recurso específico, como a presence de um usuário ou o status de uma chamada.
2. NOTIFY: Também definido em 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 em RFC 3515, o método REFER é usado para solicitar que o destinatário realize uma transferência ou encaminhe para um terceiro. Isso é tipicamente usado em cenários de transferência de chamadas.
4. MESSAGE: Definido em RFC 3428, o método MESSAGE é usado para enviar mensagens instantâneas entre user agents SIP, possibilitando comunicação baseada em texto dentro do framework SIP.
5. UPDATE: Definido em 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 em 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 requisição foi recebida e que o servidor está continuando a processá-la.
• 100 Trying: The request was received, and the server is working on it.
• 180 Ringing: The callee is being alerted and will take the call.
• 183 Session Progress: Provides information about the progress of the call.
• 2xx (Successful Responses): Essas respostas indicam que a requisição foi recebida, entendida e aceita com sucesso.
• 200 OK: The request was successful, and the server has fulfilled it.
• 202 Accepted: The request was accepted for processing, but it hasn't been completed yet.
• 3xx (Redirection Responses): Essas respostas indicam que é necessária ação adicional para cumprir a requisição, tipicamente contactando um recurso alternativo.
• 300 Multiple Choices: There are multiple options available, and the user or client must choose one.
• 301 Moved Permanently: The requested resource has been assigned a new permanent URI.
• 302 Moved Temporarily: The requested resource is temporarily available at a different URI.
• 305 Use Proxy: The request must be sent to a specified proxy.
• 4xx (Client Error Responses): Essas respostas indicam que a requisição contém sintaxe inválida ou não pode ser atendida pelo servidor.
• 400 Bad Request: The request was malformed or invalid.
• 401 Unauthorized: The request requires user authentication.
• 403 Forbidden: The server understood the request but refuses to fulfill it.
• 404 Not Found: The requested resource was not found on the server.
• 408 Request Timeout: The server did not receive a complete request within the time it was prepared to wait.
• 486 Busy Here: The callee is currently busy and unable to take the call.
• 5xx (Server Error Responses): Essas respostas indicam que o servidor falhou em atender a uma requisição válida.
• 500 Internal Server Error: The server encountered an error while processing the request.
• 501 Not Implemented: The server does not support the functionality required to fulfill the request.
• 503 Service Unavailable: The server is currently unable to handle the request due to maintenance or overload.
• 6xx (Global Failure Responses): Essas respostas indicam que a requisição não pode ser atendida por nenhum servidor.
• 600 Busy Everywhere: All possible destinations for the call are busy.
• 603 Decline: The callee does not wish to participate in the call.
• 604 Does Not Exist Anywhere: The requested resource is not available anywhere in the network.

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/8000

SIP REGISTER Exemplo

O método REGISTER é usado no Session Initiation Protocol (SIP) para permitir que um user agent (UA), como um telefone VoIP ou um softphone, registre sua localização em um servidor registrador SIP. Esse processo permite que o servidor saiba para onde encaminhar as requisições SIP recebidas destinadas ao usuário registrado. O servidor registrador normalmente faz parte de um SIP proxy ou de um servidor de registro dedicado.

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:

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 REGISTER é enviada pela UA (Alice) ao servidor registrador. Ela inclui informações importantes, como a duração desejada do registro (Expires), o SIP URI do usuário (sip: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:

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

O servidor registrar responde com uma mensagem "401 Unauthorized", que inclui um cabeçalho "WWW-Authenticate". Esse cabeçalho contém informações necessárias para que o UA se autentique, como o realm de autenticação, nonce e algoritmo.

3. Requisição REGISTER com credenciais de autenticação:

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 outro REGISTER request, desta vez incluindo o cabeçalho "Authorization" header with the necessary credentials, such as the username, realm, nonce, and a response value calculado usando as informações fornecidas e a senha do usuário.

É assim que a Authorization response é calculada:

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:

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 registrar 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 do registro. Neste ponto, o user agent (Alice) está registrado com sucesso no SIP registrar server, e requisições SIP entrantes para Alice podem ser roteadas para o endereço de contato apropriado.

Call Example

Segurança SIP e Pentesting Notes

Esta seção adiciona dicas práticas específicas de protocolo sem duplicar a orientação mais ampla sobre VoIP. Para a metodologia de ataque end-to-end em VoIP, ferramentas e cenários, veja:

Pentesting VoIP

Fingerprinting and Discovery

• Envie uma requisição OPTIONS e analise os headers Allow, Supported, Server e User-Agent para fingerprinting de dispositivos e stacks:

# 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

Username/Extension Enumeration Behavior

• Enumeration tipicamente abusa das diferenças entre 401/407 vs 404/403 em REGISTER/INVITE. Harden os servidores para responder de forma uniforme.
• Asterisk chan_sip: configure alwaysauthreject=yes (geral) para evitar divulgar usuários válidos. Em versões mais novas do Asterisk (PJSIP), guest calling é desabilitado a menos que um endpoint anonymous seja definido e um comportamento similar de "always auth reject" é o padrão; ainda assim, imponha ACLs de rede e fail2ban na perímetro.

SIP Digest Authentication: algorithms and cracking

• O SIP comumente usa autenticação no estilo HTTP-Digest. Historicamente MD5 (e MD5-sess) são prevalentes; stacks mais novos suportam SHA-256 e SHA-512/256 conforme RFC 8760. Prefira esses algoritmos mais fortes em implantações modernas e desative MD5 quando possível.
• Cracking offline a partir de um pcap é trivial para digests MD5. Depois de extrair o challenge/response, você pode usar o modo 11400 do hashcat (SIP digest, MD5):

# 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

SIP over TLS (SIPS) and over WebSockets

• Criptografia de sinalização:
• URIs sips: e TCP/TLS tipicamente na porta 5061. Verifique a validação de certificados nos endpoints; muitos aceitam certificados self-signed ou wildcard, possibilitando MitM em implantações fracas.
• Softphones WebRTC frequentemente usam SIP sobre WebSocket conforme RFC 7118 (ws:// ou wss://). Se o PBX expõe WSS, teste autenticação e CORS, e assegure que limites de taxa sejam aplicados também no front-end HTTP.

DoS quick checks (protocol level)

• O flooding de INVITE, REGISTER ou mensagens malformadas pode esgotar o processamento de transações.
• Exemplo simples de rate-limiting para UDP/5060 (Linux iptables hashlimit):

# 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

Recent, relevant SIP-stack CVE to watch (Asterisk PJSIP)

• CVE-2024-35190 (publicado em 17 de maio de 2024): Em releases específicos do Asterisk, res_pjsip_endpoint_identifier_ip podia identificar incorretamente requisições SIP não autorizadas como um endpoint local, potencialmente permitindo ações não autorizadas ou exposição de informações. Corrigido nas versões 18.23.1, 20.8.1 e 21.3.1. Valide a versão do seu PBX ao testar e reporte de forma responsável.

Hardening checklist (SIP-specific)

• Prefira TLS para sinalização e SRTP/DTLS-SRTP para mídia; desative cleartext quando possível.
• Exija senhas fortes e algoritmos de digest robustos (SHA-256/512-256 onde suportado; evite MD5).
• Para Asterisk:
• chan_sip: alwaysauthreject=yes, allowguest=no, ACLs CIDR permit/deny por endpoint.
• PJSIP: não crie um endpoint anonymous a menos que necessário; imponha acl/media_acl por endpoint; habilite fail2ban ou equivalente.
• Ocultação de topologia em proxies SIP (por exemplo, outbound proxy/edge SBC) para reduzir information leakage.
• Tratamento estrito de OPTIONS e limites de taxa; desative métodos não usados (por exemplo, MESSAGE, PUBLISH) se não forem necessários.

Referências

• RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): 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