SIP (Session Initiation Protocol)

Reading time: 18 minutes

Informazioni di base

SIP (Session Initiation Protocol) è un protocollo di segnalazione e controllo delle chiamate ampiamente usato per instaurare, modificare e terminare sessioni multimediali, comprese voce, video e messaggistica istantanea, su reti IP. Sviluppato dall'Internet Engineering Task Force (IETF), SIP è definito in RFC 3261 ed è diventato lo standard de facto per VoIP e comunicazioni unificate.

Alcune caratteristiche chiave di SIP includono:

1. Protocollo testuale: SIP è un protocollo testuale, il che lo rende leggibile dall'uomo e più facile da debug. Si basa su un modello request-response, simile a HTTP, e usa metodi come INVITE, ACK, BYE e CANCEL per controllare le sessioni di chiamata.
2. Scalabilità e flessibilità: SIP è altamente scalabile e può essere utilizzato sia in deployment di piccola scala che in ambienti enterprise o carrier-grade. Può essere facilmente esteso con nuove funzionalità, rendendolo adattabile a diversi casi d'uso e requisiti.
3. Interoperabilità: L'adozione diffusa e la standardizzazione di SIP garantiscono una migliore interoperabilità tra dispositivi, applicazioni e provider di servizi diversi, favorendo comunicazioni senza soluzione di continuità tra varie piattaforme.
4. Design modulare: SIP lavora con altri protocolli come RTP (Real-time Transport Protocol) per la trasmissione dei media e SDP (Session Description Protocol) per la descrizione delle sessioni multimediali. Questo design modulare permette maggiore flessibilità e compatibilità con diversi tipi di media e codec.
5. Proxy e Redirect Server: SIP può utilizzare proxy e redirect server per facilitare il routing delle chiamate e fornire funzionalità avanzate come inoltro di chiamata, trasferimento di chiamata e servizi di voicemail.
6. Presence e Instant Messaging: SIP non è limitato alla comunicazione voce e video. Supporta anche presence e instant messaging, abilitando una vasta gamma di applicazioni di comunicazione unificata.

Nonostante i molti vantaggi, SIP può essere complesso da configurare e gestire, soprattutto quando si affrontano problemi di NAT traversal e firewall. Tuttavia, la sua versatilità, scalabilità e l'ampio supporto nel settore lo rendono una scelta popolare per VoIP e comunicazioni multimediali.

SIP Methods

I metodi core di SIP definiti in RFC 3261 includono:

1. INVITE: Usato per inviare una nuova sessione (chiamata) o modificare una esistente. Il metodo INVITE trasporta la descrizione della sessione (tipicamente usando SDP) per informare il destinatario sui dettagli della sessione proposta, come tipi di media, codec e protocolli di trasporto.
2. ACK: Inviato per confermare la ricezione di una risposta finale a una richiesta INVITE. Il metodo ACK garantisce l'affidabilità delle transazioni INVITE fornendo un acknowledgment end-to-end.
3. BYE: Usato per terminare una sessione stabilita (chiamata). Il metodo BYE è inviato da una delle parti nella sessione per indicare che desidera terminare la comunicazione.
4. CANCEL: Inviato per annullare un INVITE pendente prima che la sessione sia stabilita. Il metodo CANCEL permette al mittente di abortire una transazione INVITE se cambia idea o se non riceve risposta dal destinatario.
5. OPTIONS: Usato per interrogare le capacità di un server SIP o di un user agent. Il metodo OPTIONS può essere inviato per richiedere informazioni sui metodi supportati, tipi di media o altre estensioni senza instaurare effettivamente una sessione.
6. REGISTER: Usato da un user agent per registrare la propria posizione corrente con un SIP registrar server. Il metodo REGISTER aiuta a mantenere una mappatura aggiornata tra l'SIP URI di un utente e il suo indirizzo IP corrente, abilitando il routing e la consegna delle chiamate.

Oltre a questi metodi core, esistono diversi metodi di estensione SIP definiti in altri RFC, come:

1. SUBSCRIBE: Definito in RFC 6665, il metodo SUBSCRIBE è usato per richiedere notifiche sullo stato di una risorsa specifica, come la presence di un utente o lo stato di una chiamata.
2. NOTIFY: Anch'esso definito in RFC 6665, il metodo NOTIFY è inviato da un server per informare un user agent iscritto su cambiamenti nello stato di una risorsa monitorata.
3. REFER: Definito in RFC 3515, il metodo REFER è usato per richiedere che il destinatario esegua un trasferimento o faccia riferimento a una terza parte. Questo è tipicamente usato per scenari di call transfer.
4. MESSAGE: Definito in RFC 3428, il metodo MESSAGE è usato per inviare messaggi istantanei tra user agent SIP, abilitando comunicazioni testuali all'interno del framework SIP.
5. UPDATE: Definito in RFC 3311, il metodo UPDATE permette di modificare una sessione senza alterare lo stato del dialogo esistente. Questo è utile per aggiornare parametri di sessione, come codec o tipi di media, durante una chiamata in corso.
6. PUBLISH: Definito in RFC 3903, il metodo PUBLISH è usato da un user agent per pubblicare informazioni sullo stato di eventi a un server, rendendole disponibili ad altre parti interessate.

SIP Response Codes

• 1xx (Provisional Responses): Queste risposte indicano che la richiesta è stata ricevuta e il server sta continuando a processarla.
• 100 Trying: La richiesta è stata ricevuta e il server sta lavorando su di essa.
• 180 Ringing: Il chiamato sta venendo avvisato e risponderà alla chiamata.
• 183 Session Progress: Fornisce informazioni sul progresso della chiamata.
• 2xx (Successful Responses): Queste risposte indicano che la richiesta è stata ricevuta, compresa e accettata con successo.
• 200 OK: La richiesta è riuscita e il server l'ha eseguita.
• 202 Accepted: La richiesta è stata accettata per l'elaborazione, ma non è ancora stata completata.
• 3xx (Redirection Responses): Queste risposte indicano che è richiesta un'azione ulteriore per soddisfare la richiesta, tipicamente contattando una risorsa alternativa.
• 300 Multiple Choices: Ci sono più opzioni disponibili e l'utente o il client deve sceglierne una.
• 301 Moved Permanently: La risorsa richiesta è stata assegnata a un nuovo URI permanente.
• 302 Moved Temporarily: La risorsa richiesta è temporaneamente disponibile a un URI diverso.
• 305 Use Proxy: La richiesta deve essere inviata a un proxy specificato.
• 4xx (Client Error Responses): Queste risposte indicano che la richiesta contiene una sintassi errata o non può essere soddisfatta dal client.
• 400 Bad Request: La richiesta era malformata o invalida.
• 401 Unauthorized: La richiesta richiede l'autenticazione dell'utente.
• 403 Forbidden: Il server ha compreso la richiesta ma rifiuta di soddisfarla.
• 404 Not Found: La risorsa richiesta non è stata trovata sul server.
• 408 Request Timeout: Il server non ha ricevuto una richiesta completa entro il tempo che era disposto ad aspettare.
• 486 Busy Here: Il chiamato è attualmente occupato e non può rispondere alla chiamata.
• 5xx (Server Error Responses): Queste risposte indicano che il server non è riuscito a soddisfare una richiesta valida.
• 500 Internal Server Error: Il server ha incontrato un errore durante l'elaborazione della richiesta.
• 501 Not Implemented: Il server non supporta la funzionalità richiesta per soddisfare la richiesta.
• 503 Service Unavailable: Il server non è attualmente in grado di gestire la richiesta a causa di manutenzione o sovraccarico.
• 6xx (Global Failure Responses): Queste risposte indicano che la richiesta non può essere soddisfatta da nessun server.
• 600 Busy Everywhere: Tutte le destinazioni possibili per la chiamata sono occupate.
• 603 Decline: Il chiamato non desidera partecipare alla chiamata.
• 604 Does Not Exist Anywhere: La risorsa richiesta non è disponibile da nessuna parte nella rete.

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

SIP REGISTER Esempio

Il metodo REGISTER è usato nel Session Initiation Protocol (SIP) per permettere a un user agent (UA), come un telefono VoIP o un softphone, di registrare la sua posizione presso un server registrar SIP. Questo processo permette al server di sapere dove instradare le richieste SIP in arrivo destinate all'utente registrato. Il server registrar fa normalmente parte di un SIP proxy server o di un server di registrazione dedicato.

Ecco un esempio dettagliato dei messaggi SIP coinvolti in un processo di autenticazione REGISTER:

1. Richiesta REGISTER iniziale dall'UA al server registrar:

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

Questo messaggio REGISTER iniziale viene inviato dall'UA (Alice) al registrar server. Include informazioni importanti come la durata di registrazione desiderata (Expires), la SIP URI dell'utente (sip:alice@example.com), e l'indirizzo di contatto dell'utente (sip:alice@192.168.1.100:5060).

2. 401 Unauthorized response from the registrar server:

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

Il server registrar risponde con un messaggio "401 Unauthorized", che include l'header "WWW-Authenticate". Questo header contiene le informazioni richieste affinché la UA si autentichi, come il realm di autenticazione, il nonce e l'algoritmo.

3. REGISTER request con credenziali di autenticazione:

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 invia un'altra richiesta REGISTER, questa volta includendo l'header "Authorization" con le credenziali necessarie, come username, realm, nonce e un valore di response calcolato usando le informazioni fornite e la password dell'utente.

Ecco come viene calcolato il Authorization response:

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. Risposta di registrazione riuscita dal server registrar:

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

Dopo che il registrar verifica le credenziali fornite, invia una risposta "200 OK" per indicare che la registrazione è avvenuta con successo. La risposta include le informazioni di contatto registrate e il tempo di scadenza della registrazione. A questo punto, lo user agent (Alice) è registrato con successo presso il SIP registrar, e le richieste SIP in arrivo per Alice possono essere instradate all'indirizzo di contatto appropriato.

Call Example

SIP: Sicurezza e note di Pentesting

Questa sezione aggiunge suggerimenti pratici, specifici del protocollo, senza duplicare le linee guida più ampie su VoIP. Per metodologia di attacco VoIP end-to-end, strumenti e scenari, vedere:

Pentesting VoIP

Fingerprinting and Discovery

• Inviare una OPTIONS request e rivedere gli header Allow, Supported, Server e User-Agent per fingerprinting di dispositivi e stack:

# 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 delle differenze tra 401/407 vs 404/403 su REGISTER/INVITE. Indurire i server in modo che rispondano in modo uniforme.
• Asterisk chan_sip: impostare alwaysauthreject=yes (generale) per evitare di rivelare utenti validi. Nelle versioni più recenti di Asterisk (PJSIP), le chiamate da guest sono disabilitate a meno che non sia definito un endpoint anonymous e un comportamento simile di "always auth reject" è il default; comunque applicare ACL di rete e fail2ban al perimetro.

SIP Digest Authentication: algorithms and cracking

• SIP comunemente usa l'auth in stile HTTP-Digest. Storicamente MD5 (e MD5-sess) sono prevalenti; gli stack più recenti supportano SHA-256 e SHA-512/256 secondo RFC 8760. Preferire questi algoritmi più forti nelle deployment moderne e disabilitare MD5 quando possibile.
• L'offline cracking da un pcap è banale per i digest MD5. Dopo aver estratto challenge/response, è possibile usare hashcat mode 11400 (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

• Crittografia del signaling:
• sips: URIs e TCP/TLS tipicamente su 5061. Verificare la validazione del certificato sugli endpoint; molti accettano cert self-signed o wildcard, permettendo MitM in deployment deboli.
• WebRTC softphones spesso usano SIP over WebSocket per RFC 7118 (ws:// or wss://). Se il PBX espone WSS, testare authentication e CORS, e assicurarsi che i rate limits siano applicati anche sul front end HTTP.

DoS quick checks (protocol level)

• Il flooding di INVITE, REGISTER o messaggi malformati può esaurire l'elaborazione delle transazioni.
• Esempio semplice di rate-limiting per 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 (pubblicata il 17 maggio 2024): in specifiche release di Asterisk, res_pjsip_endpoint_identifier_ip poteva identificare erroneamente richieste SIP non autorizzate come un endpoint locale, potenzialmente consentendo azioni non autorizzate o l'esposizione di informazioni. Risolto in 18.23.1, 20.8.1 e 21.3.1. Verifica la versione del tuo PBX durante i test e segnala responsabilmente.

Hardening checklist (SIP-specific)

• Preferire TLS per il signaling e SRTP/DTLS-SRTP per i media; disabilitare cleartext dove possibile.
• Applicare password forti e algoritmi digest robusti (SHA-256/512-256 dove supportati; evitare MD5).
• Per Asterisk:
• chan_sip: alwaysauthreject=yes, allowguest=no, per-endpoint permit/deny CIDR ACLs.
• PJSIP: non creare un endpoint anonymous a meno che non sia necessario; applicare endpoint acl/media_acl; abilitare fail2ban o equivalente.
• Topology hiding sui SIP proxies (es. outbound proxy/edge SBC) per ridurre information leakage.
• Gestione rigorosa di OPTIONS e rate limits; disabilitare metodi non usati (es. MESSAGE, PUBLISH) se non necessari.

Riferimenti

• 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