diff --git a/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md b/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md index 6c90d6635..7cb5213e3 100644 --- a/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md +++ b/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md @@ -2,78 +2,78 @@ {{#include ../../../banners/hacktricks-training.md}} -## Informazioni di Base +## Informazioni di base -SIP (Session Initiation Protocol) è un **protocollo di segnalazione e controllo delle chiamate** ampiamente utilizzato per stabilire, modificare e terminare sessioni multimediali, inclusi voce, video e messaggistica istantanea, su reti IP. Sviluppato dal **Internet Engineering Task Force (IETF)**, SIP è definito in **RFC 3261** ed è diventato lo standard de facto per VoIP e comunicazioni unificate. +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. -Al alcune caratteristiche chiave di SIP includono: +Alcune caratteristiche chiave di SIP includono: -1. **Protocollo Basato su Testo**: SIP è un protocollo basato su testo, il che lo rende leggibile dall'uomo e più facile da debug. Si basa su un modello di richiesta-risposta, simile a HTTP, e utilizza metodi come INVITE, ACK, BYE e CANCEL per controllare le sessioni di chiamata. -2. **Scalabilità e Flessibilità**: SIP è altamente scalabile e può essere utilizzato in implementazioni di piccole dimensioni così come in ambienti aziendali e di carrier di grandi dimensioni. Può essere facilmente esteso con nuove funzionalità, rendendolo adattabile a vari casi d'uso e requisiti. -3. **Interoperabilità**: L'adozione e la standardizzazione diffuse di SIP garantiscono una migliore interoperabilità tra diversi dispositivi, applicazioni e fornitori di servizi, promuovendo comunicazioni senza soluzione di continuità su varie piattaforme. -4. **Design Modulare**: SIP funziona con altri protocolli come **RTP (Real-time Transport Protocol)** per la trasmissione dei media e **SDP (Session Description Protocol)** per descrivere le sessioni multimediali. Questo design modulare consente una maggiore flessibilità e compatibilità con diversi tipi di media e codec. -5. **Server Proxy e di Reindirizzamento**: SIP può utilizzare server proxy e di reindirizzamento per facilitare l'instradamento delle chiamate e fornire funzionalità avanzate come inoltro di chiamata, trasferimento di chiamata e servizi di segreteria telefonica. -6. **Presenza e Messaggistica Istantanea**: SIP non è limitato alla comunicazione vocale e video. Supporta anche la presenza e la messaggistica istantanea, consentendo una vasta gamma di applicazioni di comunicazione unificata. +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 suoi molti vantaggi, SIP può essere complesso da configurare e gestire, in particolare quando si tratta di problemi di attraversamento NAT e firewall. Tuttavia, la sua versatilità, scalabilità e ampio supporto nell'industria lo rendono una scelta popolare per VoIP e comunicazione multimediale. +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. -### Metodi SIP +### SIP Methods -I metodi SIP fondamentali definiti in **RFC 3261** includono: +I metodi core di SIP definiti in **RFC 3261** includono: -1. **INVITE**: Utilizzato per **iniziare 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 riconoscimento end-to-end. -3. **BYE**: Utilizzato 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 una richiesta INVITE in sospeso** prima che la sessione venga stabilita. Il metodo CANCEL consente al mittente di abortire una transazione INVITE se cambia idea o se non c'è risposta dal destinatario. -5. **OPTIONS**: Utilizzato per **interrogare le capacità di un server SIP o di un agente utente**. Il metodo OPTIONS può essere inviato per richiedere informazioni sui metodi supportati, tipi di media o altre estensioni senza effettivamente stabilire una sessione. -6. **REGISTER**: Utilizzato da un agente utente per **registrare la propria posizione attuale con un server registratore SIP**. Il metodo REGISTER aiuta a mantenere una mappatura aggiornata tra l'URI SIP di un utente e il suo attuale indirizzo IP, abilitando l'instradamento e la consegna delle chiamate. +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. > [!WARNING] -> Nota che per chiamare qualcuno **non è necessario utilizzare il REGISTER** per nulla.\ -> Tuttavia, è possibile che per effettuare un **INVITE** il chiamante debba **autenticarsi** prima o riceverà una risposta **`401 Unauthorized`**. +> Nota che per chiamare qualcuno **non è necessario usare REGISTER** per nulla.\ +> Tuttavia, è possibile che per eseguire un **INVITE** il chiamante debba prima **autenticarsi** oppure riceverà una risposta **`401 Unauthorized`**. -Oltre a questi metodi fondamentali, ci sono **diversi metodi di estensione SIP** definiti in altri RFC, come: +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 è utilizzato per **richiedere notifiche** sullo stato di una risorsa specifica, come la presenza di un utente o lo stato della chiamata. -2. **NOTIFY**: Anch'esso definito in RFC 6665, il metodo NOTIFY è inviato da un server per **informare un agente utente iscritto** sui cambiamenti nello stato di una risorsa monitorata. -3. **REFER**: Definito in RFC 3515, il metodo REFER è utilizzato per **richiedere che il destinatario esegua un trasferimento o si riferisca a una terza parte**. Questo è tipicamente utilizzato per scenari di **trasferimento di chiamata**. -4. **MESSAGE**: Definito in RFC 3428, il metodo MESSAGE è utilizzato per **inviare messaggi istantanei tra agenti utente SIP**, abilitando la comunicazione basata su testo all'interno del framework SIP. -5. **UPDATE**: Definito in RFC 3311, il metodo UPDATE consente di **modificare una sessione senza influenzare lo stato del dialogo esistente**. Questo è utile per aggiornare i parametri della sessione, come codec o tipi di media, durante una chiamata in corso. -6. **PUBLISH**: Definito in RFC 3903, il metodo PUBLISH è utilizzato da un agente utente per **pubblicare informazioni sullo stato degli eventi a un server**, rendendole disponibili ad altre parti interessate. +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. -### Codici di Risposta SIP +### SIP Response Codes -- **1xx (Risposte Provvisorie)**: Queste risposte indicano che la richiesta è stata ricevuta e il server sta continuando a elaborarla. +- **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 è stato avvisato e risponderà alla chiamata. +- 180 Ringing: Il chiamato sta venendo avvisato e risponderà alla chiamata. - 183 Session Progress: Fornisce informazioni sul progresso della chiamata. -- **2xx (Risposte di Successo)**: Queste risposte indicano che la richiesta è stata ricevuta, compresa e accettata con successo. -- 200 OK: La richiesta è stata soddisfatta con successo e il server l'ha adempiuta. +- **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 (Risposte di Reindirizzamento)**: Queste risposte indicano che è necessaria un'ulteriore azione per soddisfare la richiesta, tipicamente contattando una risorsa alternativa. +- **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 (Risposte di Errore del Client)**: Queste risposte indicano che la richiesta contiene una sintassi errata o non può essere soddisfatta dal server. -- 400 Bad Request: La richiesta era malformata o non valida. +- **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 (Risposte di Errore del Server)**: Queste risposte indicano che il server non è riuscito a soddisfare una richiesta valida. -- 500 Internal Server Error: Il server ha riscontrato un errore durante l'elaborazione della richiesta. +- **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 (Risposte di Fallimento Globale)**: Queste risposte indicano che la richiesta non può essere soddisfatta da alcun server. -- 600 Busy Everywhere: Tutte le possibili destinazioni per la chiamata sono occupate. +- **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 in nessun luogo nella rete. +- 604 Does Not Exist Anywhere: La risorsa richiesta non è disponibile da nessuna parte nella rete. -## Esempi +## Examples -### Esempio SIP INVITE +### SIP INVITE Example ``` INVITE sip:jdoe@example.com SIP/2.0 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds @@ -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 ```
-Ogni Parametro Spiegato +Ogni parametro spiegato -1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Questa riga indica il metodo (INVITE), l'URI della richiesta (sip:[jdoe@example.com](mailto:jdoe@example.com)) e la versione SIP (SIP/2.0). -2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - L'intestazione Via specifica il protocollo di trasporto (UDP) e l'indirizzo del client (pc33.example.com). Il parametro "branch" è utilizzato per la rilevazione dei loop e il matching delle transazioni. -3. **Max-Forwards**: `Max-Forwards: 70` - Questo campo di intestazione limita il numero di volte in cui la richiesta può essere inoltrata dai proxy per evitare loop infiniti. -4. **To**: `To: John Doe ` - L'intestazione To specifica il destinatario della chiamata, inclusi il loro nome visualizzato (John Doe) e l'URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)). -5. **From**: `From: Jane Smith ;tag=1928301774` - L'intestazione From specifica il mittente della chiamata, inclusi il loro nome visualizzato (Jane Smith) e l'URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). Il parametro "tag" è utilizzato per identificare univocamente il ruolo del mittente nel dialogo. -6. **Call-ID**: `Call-ID: a84b4c76e66710` - L'intestazione Call-ID identifica univocamente una sessione di chiamata tra due agenti utente. -7. **CSeq**: `CSeq: 314159 INVITE` - L'intestazione CSeq contiene un numero di sequenza e il metodo utilizzato nella richiesta. È utilizzato per abbinare le risposte alle richieste e rilevare messaggi fuori ordine. -8. **Contact**: `Contact: ` - L'intestazione Contact fornisce un percorso diretto al mittente, che può essere utilizzato per richieste e risposte successive. -9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - L'intestazione User-Agent fornisce informazioni sul software o hardware del mittente, inclusi nome e versione. -10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - L'intestazione Allow elenca i metodi SIP supportati dal mittente. Questo aiuta il destinatario a capire quali metodi possono essere utilizzati durante la comunicazione. -11. **Content-Type**: `Content-Type: application/sdp` - L'intestazione Content-Type specifica il tipo di media del corpo del messaggio, in questo caso, SDP (Session Description Protocol). -12. **Content-Length**: `Content-Length: 142` - L'intestazione Content-Length indica la dimensione del corpo del messaggio in byte. -13. **Message Body**: Il corpo del messaggio contiene la descrizione della sessione SDP, che include informazioni sui tipi di media, codec e protocolli di trasporto per la sessione proposta. +1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Questa riga indica il metodo (INVITE), l'URI della richiesta (sip:[jdoe@example.com](mailto:jdoe@example.com)), e la versione SIP (SIP/2.0). +2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - L'header Via specifica il protocollo di trasporto (UDP) e l'indirizzo del client (pc33.example.com). Il parametro "branch" è usato per il rilevamento di loop e l'abbinamento delle transazioni. +3. **Max-Forwards**: `Max-Forwards: 70` - Questo campo header limita il numero di volte in cui la richiesta può essere inoltrata dai proxy per evitare loop infiniti. +4. **To**: `To: John Doe ` - L'header To specifica il destinatario della chiamata, incluso il display name (John Doe) e l'URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)). +5. **From**: `From: Jane Smith ;tag=1928301774` - L'header From specifica il mittente della chiamata, incluso il display name (Jane Smith) e l'URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). Il parametro "tag" viene usato per identificare in modo univoco il ruolo del mittente nel dialogo. +6. **Call-ID**: `Call-ID: a84b4c76e66710` - L'header Call-ID identifica in modo univoco una sessione di chiamata tra due user agent. +7. **CSeq**: `CSeq: 314159 INVITE` - L'header CSeq contiene un numero di sequenza e il metodo usato nella richiesta. Viene usato per abbinare le risposte alle richieste e rilevare messaggi fuori ordine. +8. **Contact**: `Contact: ` - L'header Contact fornisce una route diretta verso il mittente, che può essere usata per richieste e risposte successive. +9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - L'header User-Agent fornisce informazioni sul software o hardware del mittente, incluso nome e versione. +10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - L'header Allow elenca i metodi SIP supportati dal mittente. Questo aiuta il destinatario a capire quali metodi possono essere usati durante la comunicazione. +11. **Content-Type**: `Content-Type: application/sdp` - L'header Content-Type specifica il tipo di media del corpo del messaggio, in questo caso SDP (Session Description Protocol). +12. **Content-Length**: `Content-Length: 142` - L'header Content-Length indica la dimensione del corpo del messaggio in byte. +13. **Message Body**: The message body contains the SDP session description, which includes information about the media types, codecs, and transport protocols for the proposed session. - `v=0` - Versione del protocollo (0 per SDP) -- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Origine e identificatore della sessione +- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originatore e identificatore di sessione - `s=-` - Nome della sessione (un singolo trattino indica nessun nome di sessione) - `c=IN IP4 pc33.example.com` - Informazioni di connessione (tipo di rete, tipo di indirizzo e indirizzo) -- `t=0 0` - Informazioni temporali (tempi di inizio e fine, 0 0 significa che la sessione non è limitata) -- `m=audio 49170 RTP/AVP 0` - Descrizione del media (tipo di media, numero di porta, protocollo di trasporto e lista dei formati). In questo caso, specifica uno stream audio utilizzando RTP/AVP (Real-time Transport Protocol / Audio Video Profile) e formato 0 (PCMU/8000). -- `a=rtpmap:0 PCMU/8000` - Mappatura degli attributi del formato (0) al codec (PCMU) e alla sua frequenza di campionamento (8000 Hz). +- `t=0 0` - Informazioni temporali (tempi di inizio e fine, 0 0 significa che la sessione non è vincolata) +- `m=audio 49170 RTP/AVP 0` - Descrizione del media (tipo di media, numero di porta, protocollo di trasporto e lista dei formati). In questo caso, specifica uno stream audio usando RTP/AVP (Real-time Transport Protocol / Audio Video Profile) e il formato 0 (PCMU/8000). +- `a=rtpmap:0 PCMU/8000` - Attributo che mappa il formato (0) al codec (PCMU) e alla sua frequenza di clock (8000 Hz).
-### Esempio di SIP REGISTER +### SIP REGISTER Esempio -Il metodo REGISTER è utilizzato nel Session Initiation Protocol (SIP) per consentire a un agente utente (UA), come un telefono VoIP o un softphone, di **registrare la propria posizione con un server registrar SIP**. Questo processo informa il server **dove instradare le richieste SIP in arrivo destinate all'utente registrato**. Il server registrar è solitamente parte di un server proxy SIP o di un server di registrazione dedicato. +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 iniziale **REGISTER** dall'UA al server registrar: +1. Richiesta **REGISTER** iniziale dall'UA al server registrar: ```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: ;expires=3600 Expires: 3600 Content-Length: 0 ``` -Questo messaggio REGISTER iniziale viene inviato dall'UA (Alice) al server registrar. Include informazioni importanti come la durata di registrazione desiderata (Expires), l'URI SIP dell'utente (sip:[alice@example.com](mailto:alice@example.com)) e l'indirizzo di contatto dell'utente (sip:alice@192.168.1.100:5060). +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](mailto:alice@example.com)), e l'indirizzo di contatto dell'utente (sip:alice@192.168.1.100:5060). -2. **401 Unauthorized** risposta dal server registrar: -```css -cssCopy codeSIP/2.0 401 Unauthorized +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 ;tag=565656 To: Alice ;tag=7878744 @@ -156,9 +156,9 @@ 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 un'intestazione "WWW-Authenticate". Questa intestazione contiene informazioni necessarie affinché l'UA si autentichi, come il **realm di autenticazione, nonce e algoritmo**. +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. Richiesta REGISTER **con credenziali di autenticazione**: +3. REGISTER request **con credenziali di autenticazione**: ```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 ``` -L'UA invia un'altra richiesta REGISTER, questa volta includendo l'**intestazione "Authorization" con le credenziali necessarie, come il nome utente, il dominio, il nonce e un valore di risposta** calcolato utilizzando le informazioni fornite e la password dell'utente. +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. -Questo è come viene calcolata la **risposta di autorizzazione**: +Ecco come viene calcolato il **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. **Risposta di registrazione** riuscita dal server registrar: +4. **Risposta di registrazione riuscita** dal server registrar: ```yaml SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds @@ -219,13 +219,98 @@ Contact: ;expires=3600 Expires: 3600 Content-Length: 0 ``` -Dopo che il server registrar verifica le credenziali fornite, **invia una risposta "200 OK" per indicare che la registrazione è stata completata con successo**. La risposta include le informazioni di contatto registrate e il tempo di scadenza per la registrazione. A questo punto, l'agente utente (Alice) è registrato con successo con il server registrar SIP, e le richieste SIP in arrivo per Alice possono essere instradate all'indirizzo di contatto appropriato. +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. -### Esempio di Chiamata +### Call Example
-> [!NOTE] -> Non è menzionato, ma l'Utente B deve aver inviato un **messaggio REGISTER a Proxy 2** prima di poter ricevere chiamate. +> [!TIP] +> Non è menzionato, ma User B deve aver inviato un **REGISTER message to Proxy 2** prima di poter ricevere chiamate. + + +--- + +## 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: + +{{#ref}} +../README.md +{{#endref}} + +### Fingerprinting and Discovery + +- Inviare una OPTIONS request e rivedere gli header `Allow`, `Supported`, `Server` e `User-Agent` per fingerprinting di dispositivi e stack: + +```bash +# nmap NSE (UDP 5060 by default) +sudo nmap -sU -p 5060 --script sip-methods + +# Minimal raw OPTIONS over UDP +printf "OPTIONS sip: SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: ;tag=1\r\nTo: >\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: \r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 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): + +```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 definisce SHA-256 e SHA-512/256 per HTTP Digest (usato da SIP). L'adozione è disomogenea; assicurati che i tuoi strumenti gestiscano questi algoritmi quando punti a PBX moderni. + +### 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): + +```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 +``` + +### 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 {{#include ../../../banners/hacktricks-training.md}}