Let’s dive into VoIP protocols — Episode 2 : SIP Part 2 Version FR
Partons à l’aventure !
Article also available in English here.
Bonjour ! Cet article est la suite de l’Episode 1 : SIP Part 1.
Enregistrement avec Kamailio
Authentification
Nous allons partir du principe que nous voulons authentifier les utilisateurs de manière à avoir au moins un niveau basique de sécurité. Nous allons enregistrer Alice sur le serveur avec un mot de passe et analyser la capture réseau.
On ajoute l’utilisateur Alice avec le mot de passe “secretAlice” à la base de donnée du serveur d’enregistrement. Ensuite, on essaye d’enregistrer Alice avec le mot de passe depuis un softphone (Ekiga) sur PC-Alice, on garde la connexion active pendant une heure et on se déconnecte.
Vous pouvez télécharger le PCAP ici : https://we.tl/HOLft8MAnF
Pour explorer le PCAP vous pouvez utiliser le logiciel sur lequel je travail : PCAP-Inspector, téléchargeable gratuitement sur https://pcap-inspector.com, avec une license gratuite pour 30 jours.Il est actuellement en Beta mais possède déjà de nombreuses fonctionnalités intéressantes. Si vous n’êtes pas intéressé par ce logiciel, vous pouvez utiliser Wireshark à la place.
Premièrement, analysons le procédé d’authentification. SIP utilise une variante de HTTP Digest, si vous n’êtes pas familier avec le procédé, il fonctionne ainsi :
- D’abord, le client essaye de s’enregistrer sans authentification, le serveur lui répond 401/Unauthorized et les informations du challenge d’authentification : le royaume et le nonce. Le royaume est souvent un nom de domaine ou une IP, le nonce est une chaîne générée en hachant certains paramètres importants de l’authentification (timestamp, client_ip par exemple, cela peut varier en fonction des implémentations et configurations). Frame 3 et 4 dans le PCAP.
- Le client envoie une autre requête (Frame 5) avec la réponse au challenge :
A1 = username “:” realm “:” password
A2 = Method “:” Request-URI
response = MD5(MD5(A1) “:” nonce “:” MD5(A2))- Le serveur vérifie la réponse et authentifie le client : Frame 6.
Pour plus d’info voir : https://tools.ietf.org/html/rfc2617.
On voit que par défaut, toute les informations sont accessibles par quelqu’un qui écoute le réseau. Comme nous n’utilisons pas TLS sur la couche transport, toute les informations sont disponibles en clair.
En termes de sécurité :
Premièrement, MD5 n’est pas très robuste: si l’utilisateur utilise un mot de passe de moins de 8 caractères, un attaquant pourrait le cracker pour moins de 10 euros sur une instance de calcul dans le cloud. Il est possible de configurer Kamailio pour utiliser SHA256 plutôt que MD5 en changeant le paramètre “Algorithme” dans le module d’authentification.
Deuxièmement, Kamailio a une fenêtre d’expiration de 300s sur le nonce par défaut [doc]. Cependant, le nonce est calculé avec l’URI de la requête, le Call-ID, et l’IP source [doc]. Par conséquent, un attaquant pourrait uniquement faire une attaque en spoofant l’IP du client et envoyant exactement le même message d’enregistrement. Il pourrait par conséquent uniquement s’enregistrer avec la même paire IP/adresse SIP, ce qui, comme vous pouvez l’imaginer n’est pas très utile compte tenu du fait que le spoofing initial permet déjà à l’attaquant de recevoir les messages SIP. Il y a cependant un cas où cela permet d’effectuer une action malveillante, un attaquant pourrait prendre l’IP d’un utilisateur qui se serait connecté et déconnecté en moins de 300 secondes puis rejouer le message initial pour s’enregistrer à sa place. Cela permettrait à un attaquant de restaurer l’association IP/SIP et faire apparaître l’utilisateur comme connecté. Il pourrait ainsi recevoir les messages SIP mais pas pour autant répondre car il ne possède pas le mot de passe pour les challenges authentification. Il est possible de configurer Kamailio de manière à n’accepter les nonce qu’une seule fois pour éviter ce genre d’attaque.
Keep-Alive de l’enregistrement
Maintenant que nous avons observé le procédé d’enregistrement, intéressons nous à la façon dont le client et le serveur maintiennent celui-ci. Dans le premier message, le client envoie un paramètre de contact : “expires=3600” qui signifie que si celui-ci ne se réenregistre pas ou ne se déconnecte pas, la connexion devrait être conservée pour 1 heure puis coupée. On peut voir dans le PCAP que le client se réenregistre après 50 minutes (Frames 39–42).
En terme de sécurité :
Un attaquant pourrait détourner l’enregistrement d’un utilisateur pour une durée d’une heure en spoofant son IP. Il ne pourrait pas passer d’appels ou répondre aux requêtes SIP car il ne peut pas s’authentifier, mais les informations contenues dans les paquets reçus pourraient être utilisées dans d’autres scénarios (SE, phishing). On peut voir dans la documentation de Kamailio qu’il est possible d’influencer la valeur expiration avec 3 paramètres : default_expires (3600), min_expires(60), max_expires(0). Par défaut, il n’y a pas de valeur maximale, la définir à 3600 par exemple pourrait être un bon début pour limiter des valeurs anormalement grandes pour le client.
Déconnexion
La déconnexion est un procédé similaire à l’enregistrement pour casser les associations entre l’IP et l’adresse SIP. Il n’y a pas grand chose à ajouter.
Conclusion
Dans cette implémentation (Kamailio), le processus d’enregistrement SIP offre par défaut un niveau de sécurité satisfaisant, mais peut également être facilement renforcé si nécessaire.
Sans support TLS sur la couche transport, un attaquant capable de collecter les paquets peut espionner le processus d’enregistrement afin d’obtenir des informations sur les utilisateurs. On peut aisément imaginer qu’un attaquant puisse tirer parti des horaires de connexion et déconnexion des employés. De plus, comme nous le verrons dans le prochain article, l’identité de l’appelant peut également être obtenue par une technique d’ingénierie sociale appropriée.
Dans le prochain article de cette série, nous explorerons la mise en place de configuration d’appels entre back-to-back user agent (B2BUA) et des passerelles.
Si vous avez aimé cet article vous pouvez me suivre sur medium : Constantin VURLI, ou Twitter : @flashybowtie
