SIP (Session Initiation Protocol)

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

• Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !

• Obtenez le swag officiel PEASS & HackTricks

• Découvrez La famille PEASS, notre collection exclusive de NFT

• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez-nous sur Twitter 🐦 @carlospolopm.

• Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud dépôts GitHub.

Informations de base

Le SIP (Session Initiation Protocol) est un protocole de signalisation et de contrôle d'appel largement utilisé pour établir, modifier et terminer des sessions multimédias, y compris la voix, la vidéo et la messagerie instantanée, sur des réseaux IP. Développé par le Groupe de travail d'ingénierie de l'Internet (IETF), le SIP est défini dans le RFC 3261 et est devenu la norme de facto pour la VoIP et les communications unifiées.

Certaines caractéristiques clés du SIP comprennent :

1. Protocole basé sur le texte : Le SIP est un protocole basé sur le texte, ce qui le rend lisible par l'homme et plus facile à déboguer. Il est basé sur un modèle de requête-réponse, similaire à HTTP, et utilise des méthodes telles que INVITE, ACK, BYE et CANCEL pour contrôler les sessions d'appel.

2. Scalabilité et flexibilité : Le SIP est hautement scalable et peut être utilisé dans des déploiements à petite échelle ainsi que dans des environnements d'entreprise de grande envergure et de qualité opérateur. Il peut être facilement étendu avec de nouvelles fonctionnalités, le rendant adaptable à divers cas d'utilisation et exigences.

3. Interopérabilité : L'adoption généralisée du SIP et sa normalisation garantissent une meilleure interopérabilité entre différents appareils, applications et fournisseurs de services, favorisant une communication transparente sur différentes plateformes.

4. Conception modulaire : Le SIP fonctionne avec d'autres protocoles comme le RTP (Real-time Transport Protocol) pour la transmission multimédia et le SDP (Session Description Protocol) pour décrire les sessions multimédias. Cette conception modulaire permet une plus grande flexibilité et compatibilité avec différents types de médias et codecs.

5. Serveurs proxy et de redirection : Le SIP peut utiliser des serveurs proxy et de redirection pour faciliter le routage des appels et fournir des fonctionnalités avancées telles que le renvoi d'appels, le transfert d'appels et les services de messagerie vocale.

6. Présence et messagerie instantanée : Le SIP n'est pas limité à la communication vocale et vidéo. Il prend également en charge la présence et la messagerie instantanée, permettant une large gamme d'applications de communication unifiée.

Malgré ses nombreux avantages, le SIP peut être complexe à configurer et à gérer, en particulier lorsqu'il s'agit de problèmes de traversée NAT et de pare-feu. Cependant, sa polyvalence, sa scalabilité et son soutien étendu dans l'industrie en font un choix populaire pour la VoIP et la communication multimédia.

Méthodes SIP

Les méthodes SIP de base définies dans le RFC 3261 comprennent :

1. INVITE : Utilisé pour initier une nouvelle session (appel) ou modifier une session existante. La méthode INVITE transporte la description de la session (généralement en utilisant SDP) pour informer le destinataire des détails de la session proposée, tels que les types de médias, les codecs et les protocoles de transport.

2. ACK : Envoyé pour confirmer la réception d'une réponse finale à une demande INVITE. La méthode ACK garantit la fiabilité des transactions INVITE en fournissant un accusé de réception de bout en bout.

3. BYE : Utilisé pour mettre fin à une session établie (appel). La méthode BYE est envoyée par l'une ou l'autre des parties de la session pour indiquer qu'elles souhaitent mettre fin à la communication.

4. CANCEL : Envoyé pour annuler une demande INVITE en attente avant l'établissement de la session. La méthode CANCEL permet à l'expéditeur d'annuler une transaction INVITE s'il change d'avis ou s'il n'y a pas de réponse du destinataire.

5. OPTIONS : Utilisé pour interroger les capacités d'un serveur SIP ou d'un agent utilisateur. La méthode OPTIONS peut être envoyée pour demander des informations sur les méthodes prises en charge, les types de médias ou d'autres extensions sans établir réellement une session.

6. REGISTER : Utilisé par un agent utilisateur pour enregistrer son emplacement actuel auprès d'un serveur d'enregistrement SIP. La méthode REGISTER aide à maintenir une correspondance à jour entre l'URI SIP d'un utilisateur et son adresse IP actuelle, permettant le routage et la livraison des appels.

Notez que pour appeler quelqu'un, il n'est pas nécessaire d'utiliser le REGISTER pour quoi que ce soit. Cependant, il est possible qu'en vue d'effectuer un INVITE, l'appelant doit s'authentifier d'abord ou il recevra une réponse 401 Unauthorized.

En plus de ces méthodes de base, il existe plusieurs méthodes d'extension SIP définies dans d'autres RFC, telles que :

1. SUBSCRIBE : Définie dans le RFC 6665, la méthode SUBSCRIBE est utilisée pour demander des notifications sur l'état d'une ressource spécifique, telle que la présence d'un utilisateur ou l'état d'un appel.

2. NOTIFY : Également définie dans le RFC 6665, la méthode NOTIFY est envoyée par un serveur pour informer un agent utilisateur abonné des changements dans l'état d'une ressource surveillée.

3. REFER : Définie dans le RFC 3515, la méthode REFER est utilisée pour demander que le destinataire effectue un transfert ou fasse référence à un tiers. Cela est généralement utilisé pour les scénarios de transfert d'appel.

4. MESSAGE : Définie dans le RFC 3428, la méthode MESSAGE est utilisée pour envoyer des messages instantanés entre des agents utilisateurs SIP, permettant une communication basée sur du texte dans le cadre du SIP.

5. UPDATE : Définie dans le RFC 3311, la méthode UPDATE permet de modifier une session sans affecter l'état du dialogue existant. Cela est utile pour mettre à jour les paramètres de session, tels que les codecs ou les types de médias, pendant un appel en cours.

6. PUBLISH : Définie dans le RFC 3903, la méthode PUBLISH est utilisée par un agent utilisateur pour publier des informations sur l'état d'un événement à un serveur, le rendant disponible à d'autres parties intéressées.

Codes de réponse SIP

• 1xx (Réponses provisoires) : Ces réponses indiquent que la demande a été reçue et que le serveur continue de la traiter.

  • 100 Trying : La demande a été reçue, et le serveur y travaille.

  • 180 Ringing : Le destinataire est alerté et prendra l'appel.

  • 183 Session Progress : Fournit des informations sur l'avancement de l'appel.

• 2xx (Réponses réussies) : Ces réponses indiquent que la demande a été reçue, comprise et acceptée avec succès.

  • 200 OK : La demande a réussi, et le serveur l'a exécutée.

  • 202 Accepted : La demande a été acceptée pour traitement, mais n'a pas encore été complétée.

• 3xx (Réponses de redirection) : Ces réponses indiquent qu'une action supplémentaire est nécessaire pour répondre à la demande, généralement en contactant une ressource alternative.

  • 300 Multiple Choices : Il y a plusieurs options disponibles, et l'utilisateur ou le client doit en choisir une.

  • 301 Moved Permanently : La ressource demandée a reçu un nouvel URI permanent.

  • 302 Moved Temporarily : La ressource demandée est temporairement disponible à un URI différent.

  • 305 Use Proxy : La demande doit être envoyée à un proxy spécifié.

• 4xx (Réponses d'erreur client) : Ces réponses indiquent que la demande contient une mauvaise syntaxe ou ne peut pas être satisfaite par le serveur.

  • 400 Bad Request : La demande était mal formée ou invalide.

  • 401 Unauthorized : La demande nécessite une authentification utilisateur.

  • 403 Forbidden : Le serveur a compris la demande mais refuse de la satisfaire.

  • 404 Not Found : La ressource demandée n'a pas été trouvée sur le serveur.

  • 408 Request Timeout : Le serveur n'a pas reçu une demande complète dans le délai qu'il était prêt à attendre.

  • 486 Busy Here : Le destinataire est actuellement occupé et incapable de prendre l'appel.

• 5xx (Réponses d'erreur serveur) : Ces réponses indiquent que le serveur n'a pas pu satisfaire une demande valide.

  • 500 Internal Server Error : Le serveur a rencontré une erreur lors du traitement de la demande.

  • 501 Not Implemented : Le serveur ne prend pas en charge la fonctionnalité requise pour répondre à la demande.

  • 503 Service Unavailable : Le serveur est actuellement incapable de traiter la demande en raison de travaux de maintenance ou de surcharge.

• 6xx (Réponses d'échec global) : Ces réponses indiquent que la demande ne peut être satisfaite par aucun serveur.

  • 600 Busy Everywhere : Toutes les destinations possibles pour l'appel sont occupées.

  • 603 Decline : Le destinataire ne souhaite pas participer à l'appel.

  • 604 Does Not Exist Anywhere : La ressource demandée n'est disponible nulle part dans le réseau.

Exemples

Exemple d'INVITE SIP

INVITE sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:[e-mail]>
From: Jane Smith <sip:[e-mail]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[e-mail]>
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

Explication de chaque paramètre

1. Request-Line: INVITE sip:[e-mail] SIP/2.0 - Cette ligne indique la méthode (INVITE), l'URI de la requête (sip:[e-mail]), et la version SIP (SIP/2.0).

2. Via: Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds - L'en-tête Via spécifie le protocole de transport (UDP) et l'adresse du client (pc33.example.com). Le paramètre "branch" est utilisé pour la détection de boucle et la correspondance de transaction.

3. Max-Forwards: Max-Forwards: 70 - Ce champ d'en-tête limite le nombre de fois que la requête peut être transmise par des proxies pour éviter les boucles infinies.

4. To: To: John Doe <sip:[e-mail]> - L'en-tête To spécifie le destinataire de l'appel, y compris son nom d'affichage (John Doe) et l'URI SIP (sip:[e-mail]).

5. From: From: Jane Smith <sip:[e-mail]>;tag=1928301774 - L'en-tête From spécifie l'expéditeur de l'appel, y compris son nom d'affichage (Jane Smith) et l'URI SIP (sip:[e-mail]). Le paramètre "tag" est utilisé pour identifier de manière unique le rôle de l'expéditeur dans le dialogue.

6. Call-ID: Call-ID: a84b4c76e66710 - L'en-tête Call-ID identifie de manière unique une session d'appel entre deux agents utilisateurs.

7. CSeq: CSeq: 314159 INVITE - L'en-tête CSeq contient un numéro de séquence et la méthode utilisée dans la requête. Il est utilisé pour faire correspondre les réponses aux requêtes et détecter les messages désordonnés.

8. Contact: Contact: <sip:[e-mail]> - L'en-tête Contact fournit une route directe vers l'expéditeur, qui peut être utilisée pour les requêtes et réponses ultérieures.

9. User-Agent: User-Agent: ExampleSIPClient/1.0 - L'en-tête User-Agent fournit des informations sur le logiciel ou le matériel de l'expéditeur, y compris son nom et sa version.

10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - L'en-tête Allow répertorie les méthodes SIP prises en charge par l'expéditeur. Cela aide le destinataire à comprendre quelles méthodes peuvent être utilisées pendant la communication.

11. Content-Type: Content-Type: application/sdp - L'en-tête Content-Type spécifie le type de média du corps du message, dans ce cas, SDP (Session Description Protocol).

12. Content-Length: Content-Length: 142 - L'en-tête Content-Length indique la taille du corps du message en octets.

13. Corps du message: Le corps du message contient la description de session SDP, qui inclut des informations sur les types de médias, les codecs et les protocoles de transport pour la session proposée.

• v=0 - Version du protocole (0 pour SDP)

• o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com - Originateur et identifiant de session

• s=- - Nom de session (un simple tiret indique qu'il n'y a pas de nom de session)

• c=IN IP4 pc33.example.com - Informations de connexion (type de réseau, type d'adresse et adresse)

• t=0 0 - Informations de synchronisation (heures de début et de fin, 0 0 signifie que la session n'est pas bornée)

• m=audio 49170 RTP/AVP 0 - Description des médias (type de média, numéro de port, protocole de transport et liste de formats). Dans ce cas, il spécifie un flux audio utilisant RTP/AVP (Real-time Transport Protocol / Audio Video Profile) et le format 0 (PCMU/8000).

• a=rtpmap:0 PCMU/8000 - Attribut faisant correspondre le format (0) au codec (PCMU) et à sa fréquence d'horloge (8000 Hz).

Exemple d'enregistrement SIP

La méthode REGISTER est utilisée dans le protocole d'initiation de session (SIP) pour permettre à un agent utilisateur (UA), tel qu'un téléphone VoIP ou un softphone, de enregistrer son emplacement auprès d'un serveur registraire SIP. Ce processus permet au serveur de savoir où router les demandes SIP entrantes destinées à l'utilisateur enregistré. Le serveur registraire fait généralement partie d'un serveur proxy SIP ou d'un serveur d'enregistrement dédié.

Voici un exemple détaillé des messages SIP impliqués dans un processus d'authentification REGISTER :

1. Requête REGISTER initiale de l'UA au serveur registraire :

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:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>
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

Le message REGISTER initial est envoyé par l'UA (Alice) au serveur de registre. Il inclut des informations importantes telles que la durée d'enregistrement souhaitée (Expires), l'URI SIP de l'utilisateur (sip:[e-mail]), et l'adresse de contact de l'utilisateur (sip:alice@192.168.1.100:5060).

1. Réponse 401 Unauthorized du serveur de registre :

cssCopy codeSIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>;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

Le serveur de registre répond avec un message "401 Unauthorized", qui inclut un en-tête "WWW-Authenticate". Cet en-tête contient les informations nécessaires pour que l'UA s'authentifie, telles que le domaine d'authentification, le nonce et l'algorithme.

1. Requête REGISTER avec des identifiants d'authentification:

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:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>
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

Le UA envoie une autre demande REGISTER, cette fois en incluant l'en-tête "Authorization" avec les informations d'identification nécessaires, telles que le nom d'utilisateur, le royaume, le nonce et une valeur de réponse calculée en utilisant les informations fournies et le mot de passe de l'utilisateur.

Voici comment le réponse d'autorisation est calculée :

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}")

1. Réponse d'inscription réussie du serveur de registre :

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:[e-mail]>;tag=565656
To: Alice <sip:[e-mail]>;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

Après que le serveur d'enregistrement vérifie les informations d'identification fournies, il envoie une réponse "200 OK" pour indiquer que l'enregistrement a réussi. La réponse inclut les informations de contact enregistrées et l'heure d'expiration de l'enregistrement. À ce stade, l'agent utilisateur (Alice) est enregistré avec succès auprès du serveur d'enregistrement SIP, et les demandes SIP entrantes pour Alice peuvent être acheminées vers l'adresse de contact appropriée.

Exemple d'appel

Il n'est pas mentionné, mais l'Utilisateur B doit avoir envoyé un message REGISTER à Proxy 2 avant de pouvoir recevoir des appels.