SIP (Session Initiation Protocol)

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

Informations de base

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édia, y compris la voix, la vidéo et la messagerie instantanée, sur les réseaux IP. Développé par l’Internet Engineering Task Force (IETF), SIP est défini dans RFC 3261 et est devenu le standard de facto pour la VoIP et les communications unifiées.

Parmi les principales caractéristiques de SIP :

1. Protocole textuel : SIP est un protocole textuel, ce qui le rend lisible par l’humain et plus facile à déboguer. Il est basé sur un modèle requête-réponse, similaire à HTTP, et utilise des méthodes comme INVITE, ACK, BYE et CANCEL pour contrôler les sessions d’appel.
2. Évolutivité et flexibilité : SIP est hautement évolutif et peut être utilisé dans des déploiements de petite taille ainsi que dans des environnements d’entreprise et de niveau 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 et la normalisation de SIP assurent une meilleure interopérabilité entre différents appareils, applications et fournisseurs de services, favorisant une communication sans couture entre différentes plateformes.
4. Conception modulaire : SIP fonctionne avec d’autres protocoles comme RTP (Real-time Transport Protocol) pour la transmission des médias et SDP (Session Description Protocol) pour décrire les sessions multimédia. 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 : SIP peut utiliser des serveurs proxy et de redirection pour faciliter le routage des appels et fournir des fonctionnalités avancées comme le renvoi d’appel, le transfert d’appel et la messagerie vocale.
6. Présence et messagerie instantanée : SIP ne se limite pas à la communication voix 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, SIP peut être complexe à configurer et à gérer, en particulier lorsqu’il s’agit de la traversal NAT et des problèmes de pare-feu. Cependant, sa polyvalence, son évolutivité et son large support industriel 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 RFC 3261 incluent :

1. INVITE : Utilisé pour initier une nouvelle session (appel) ou modifier une session existante. La méthode INVITE transporte la description de session (généralement en utilisant SDP) pour informer le destinataire des détails de la session proposée, comme 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 requête INVITE. La méthode ACK assure la fiabilité des transactions INVITE en fournissant une reconnaissance de bout en bout.
3. BYE : Utilisé pour terminer 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 un INVITE en attente avant l’établissement de la session. La méthode CANCEL permet à l’expéditeur d’abandonner une transaction INVITE s’il change d’avis ou si le destinataire ne répond pas.
5. OPTIONS : Utilisé pour interroger les capacités d’un serveur SIP ou d’un user agent. 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 de session.
6. REGISTER : Utilisé par un user agent pour enregistrer sa localisation actuelle auprès d’un serveur registrar 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 délivrance des appels.

Warning

Notez que pour appeler quelqu’un il n’est pas nécessaire d’utiliser REGISTER pour quoi que ce soit.
Cependant, il est possible que, pour effectuer un INVITE, l’appelant doive d’abord s’authentifier ou qu’il reçoive 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 RFC 6665, la méthode SUBSCRIBE est utilisée pour demander des notifications sur l’état d’une ressource spécifique, comme la présence d’un utilisateur ou l’état d’un appel.
2. NOTIFY : Également définie dans RFC 6665, la méthode NOTIFY est envoyée par un serveur pour informer un user agent abonné des changements d’état d’une ressource surveillée.
3. REFER : Définie dans RFC 3515, la méthode REFER est utilisée pour demander au destinataire d’effectuer un transfert ou de référer à un tiers. Elle est typiquement utilisée pour des scénarios de transfert d’appel.
4. MESSAGE : Définie dans RFC 3428, la méthode MESSAGE est utilisée pour envoyer des messages instantanés entre user agents SIP, permettant la communication textuelle au sein du framework SIP.
5. UPDATE : Définie dans RFC 3311, la méthode UPDATE permet de modifier une session sans affecter l’état du dialog existant. Cela est utile pour mettre à jour des paramètres de session, comme les codecs ou les types de médias, pendant un appel en cours.
6. PUBLISH : Définie dans RFC 3903, la méthode PUBLISH est utilisée par un user agent pour publier des informations d’état d’événement sur un serveur, les rendant disponibles à d’autres parties intéressées.

Codes de réponse SIP

• 1xx (Réponses provisoires) : Ces réponses indiquent que la requête a été reçue et que le serveur continue de la traiter.
• 100 Trying : La requête a été reçue et le serveur est en train de la traiter.
• 180 Ringing : Le correspondant est en train d’être alerté et va prendre l’appel.
• 183 Session Progress : Fournit des informations sur la progression de l’appel.
• 2xx (Réponses réussies) : Ces réponses indiquent que la requête a été reçue, comprise et acceptée avec succès.
• 200 OK : La requête a réussi et le serveur l’a exécutée.
• 202 Accepted : La requête a été acceptée pour traitement, mais elle n’est pas encore terminée.
• 3xx (Réponses de redirection) : Ces réponses indiquent qu’une action supplémentaire est requise pour satisfaire la requête, typiquement en contactant une ressource alternative.
• 300 Multiple Choices : Il existe plusieurs options disponibles et l’utilisateur ou le client doit en choisir une.
• 301 Moved Permanently : La ressource demandée s’est vue attribuer une nouvelle URI permanente.
• 302 Moved Temporarily : La ressource demandée est temporairement disponible à une URI différente.
• 305 Use Proxy : La requête doit être envoyée à un proxy spécifié.
• 4xx (Erreurs client) : Ces réponses indiquent que la requête contient une mauvaise syntaxe ou ne peut pas être satisfaite par le serveur.
• 400 Bad Request : La requête était mal formée ou invalide.
• 401 Unauthorized : La requête nécessite une authentification de l’utilisateur.
• 403 Forbidden : Le serveur a compris la requête mais refuse de l’exécuter.
• 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 requête complète dans le délai qu’il était prêt à attendre.
• 486 Busy Here : Le correspondant est actuellement occupé et ne peut pas prendre l’appel.
• 5xx (Erreurs serveur) : Ces réponses indiquent que le serveur n’a pas pu satisfaire une requête valide.
• 500 Internal Server Error : Le serveur a rencontré une erreur lors du traitement de la requête.
• 501 Not Implemented : Le serveur ne prend pas en charge la fonctionnalité requise pour exécuter la requête.
• 503 Service Unavailable : Le serveur est actuellement incapable de traiter la requête en raison de maintenance ou de surcharge.
• 6xx (Échecs globaux) : Ces réponses indiquent que la requête ne peut être satisfaite par aucun serveur.
• 600 Busy Everywhere : Toutes les destinations possibles pour l’appel sont occupées.
• 603 Decline : Le correspondant 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 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

Exemple de REGISTER SIP

La méthode REGISTER est utilisée dans le Session Initiation Protocol (SIP) pour permettre à un user agent (UA), tel qu’un téléphone VoIP ou un softphone, de s’enregistrer auprès d’un SIP registrar server. Ce processus permet au serveur de savoir où acheminer les requêtes SIP entrantes destinées à l’utilisateur enregistré. Le serveur registrar fait généralement partie d’un SIP proxy server 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 initiale REGISTER du user agent (UA) vers le serveur 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

Ce message initial REGISTER est envoyé par l’UA (Alice) au serveur d’enregistrement. Il contient des informations importantes telles que la durée d’enregistrement souhaitée (Expires), le SIP URI de l’utilisateur (sip:alice@example.com), et l’adresse de contact de l’utilisateur (sip:alice@192.168.1.100:5060).

2. 401 Unauthorized réponse du serveur d’enregistrement :

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

Le serveur d’enregistrement répond par un message “401 Unauthorized”, qui inclut un en-tête “WWW-Authenticate”. Cet en-tête contient les informations requises pour que l’UA s’authentifie, telles que le realm d’authentification, le nonce et l’algorithme.

3. 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: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

L’UA envoie une autre requête REGISTER, cette fois en incluant l’en-tête “Authorization” avec les identifiants nécessaires, tels que le username, realm, nonce, et une valeur response calculée en utilisant les informations fournies et le mot de passe de l’utilisateur.

Voici comment la Authorization response 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}")

4. Réponse d’enregistrement réussie du serveur d’enregistrement:

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

Après que le serveur registrar ait vérifié les identifiants fournis, 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 la durée d’expiration de l’enregistrement. À ce stade, l’agent utilisateur (Alice) est correctement enregistré auprès du serveur registrar SIP, et les requêtes SIP entrantes destinées à Alice peuvent être acheminées vers l’adresse de contact appropriée.

Exemple d’appel

Tip

Ce n’est pas mentionné, mais User B doit avoir envoyé un REGISTER message à Proxy 2 avant de pouvoir recevoir des appels.

SIP Sécurité et Pentesting Notes

Cette section apporte des conseils pratiques, spécifiques au protocole, sans dupliquer les recommandations générales VoIP. Pour la méthodologie d’attaque VoIP de bout en bout, les outils et les scénarios, voir :

Pentesting VoIP

Empreinte et découverte

• Envoyez une requête OPTIONS et examinez les en-têtes Allow, Supported, Server et User-Agent pour profiler les appareils et les 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

Comportement d’énumération des noms d’utilisateur/extensions

• L’énumération abuse généralement des différences entre 401/407 et 404/403 sur REGISTER/INVITE. Durcissez les serveurs pour qu’ils répondent de manière uniforme.
• Asterisk chan_sip : définissez alwaysauthreject=yes (général) pour éviter de divulguer des utilisateurs valides. Dans les versions récentes d’Asterisk (PJSIP), les appels guests sont désactivés sauf si un endpoint anonymous est défini et un comportement similaire de “always auth reject” est par défaut ; appliquez néanmoins des ACL réseau et fail2ban à la périphérie.

SIP Digest Authentication: algorithms and cracking

• SIP utilise couramment un auth de type HTTP-Digest. Historiquement MD5 (et MD5-sess) sont répandus ; les stacks plus récents supportent SHA-256 et SHA-512/256 selon RFC 8760. Préférez ces algorithmes plus forts dans les déploiements modernes et désactivez MD5 quand c’est possible.
• Le cracking hors ligne depuis un pcap est trivial pour les digests MD5. Après avoir extrait le challenge/response, vous pouvez utiliser 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

Note

RFC 8760 définit SHA-256 et SHA-512/256 pour HTTP Digest (utilisé par SIP). L’adoption est inégale ; assurez-vous que vos outils gèrent ces algorithmes lorsque vous ciblez des PBX modernes.

SIP sur TLS (SIPS) et sur WebSockets

• Chiffrement du signaling :
• Les URI sips: et TCP/TLS sont typiquement sur le port 5061. Vérifiez la validation des certificats sur les endpoints ; beaucoup acceptent des certificats auto-signés ou wildcard, permettant des MitM dans des déploiements faibles.
• Les softphones WebRTC utilisent souvent SIP over WebSocket selon RFC 7118 (ws:// ou wss://). Si le PBX expose WSS, testez l’authentification et le CORS, et assurez-vous que des limites de taux sont appliquées également sur la couche HTTP frontale.

Vérifications rapides DoS (niveau protocole)

• Le flooding d’INVITE, REGISTER ou de messages malformés peut épuiser le traitement des transactions.
• Exemple simple de limitation de débit pour 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

CVE récentes et pertinentes des stacks SIP à surveiller (Asterisk PJSIP)

• CVE-2024-35190 (publié le 17 mai 2024) : dans certaines versions d’Asterisk, res_pjsip_endpoint_identifier_ip pouvait mal identifier des requêtes SIP non autorisées comme un endpoint local, pouvant potentiellement permettre des actions non autorisées ou une exposition d’informations. Corrigé dans les versions 18.23.1, 20.8.1 et 21.3.1. Validez la version de votre PBX lors des tests et signalez de manière responsable.

Checklist de durcissement (spécifique SIP)

• Préférez TLS pour le signaling et SRTP/DTLS-SRTP pour les médias ; désactivez le cleartext lorsque c’est possible.
• Imposer des mots de passe forts et des algorithmes de digest robustes (SHA-256/512-256 lorsqu’ils sont supportés ; éviter MD5).
• Pour Asterisk :
• chan_sip : alwaysauthreject=yes, allowguest=no, ACL CIDR permit/deny par endpoint.
• PJSIP : ne créez pas d’endpoint anonymous sauf si nécessaire ; appliquez acl/media_acl par endpoint ; activez fail2ban ou équivalent.
• Masquage de la topologie sur les proxies SIP (par ex., outbound proxy/edge SBC) to reduce information leakage.
• Traitement strict des OPTIONS et limites de taux ; désactivez les méthodes inutilisées (par ex., MESSAGE, PUBLISH) si elles ne sont pas requises.

Références

• RFC 8760 – Utilisation de SHA-256 et SHA-512/256 pour HTTP Digest (s’applique aussi à SIP Digest) : 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

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.