François Goffinet

François Goffinet

Enregistrement Register

1. Introduction à la méthode REGISTER

Les transactions non-INVITE dont la requête REGISTER n’utilisent pas de ACK. Ce sont de simples interactions demande-réponse. Source : RFC 3261 17.1.2.1 Overview of the non-INVITE Transaction

SIP offre une capacité de localisation. Si un utilisateur veut initier une session avec un autre utilisateur, SIP doit découvrir le ou les hôtes auxquels l’utilisateur de destination est couramment joignable. Ce processus de découverte est fréquemment accompli par les éléments de réseau SIP tels que des serveurs mandataires et les serveurs de redirection qui sont chargés de recevoir une demande, de déterminer où l’envoyer sur la base de la connaissance de la localisation de l’utilisateur, et ensuite de l’y envoyer. Pour ce faire, les éléments de réseau SIP consultent un service abstrait connu sous le nom de service de localisation, qui fournit les liens d’adresse pour un domaine particulier. Ces liens d’adresse transposent un URI SIP ou SIPS entrant, sip:bob@biloxi.com, par exemple, en un ou plusieurs URI qui sont en quelque sorte “plus proches” de l’utilisateur désiré, sip:bob@engineering.biloxi.com, par exemple. Finalement, un mandataire va consulter un service de localisation qui fait correspondre un URI reçu à l’agent ou aux agents d’utilisateur dans lesquels le receveur désiré résident actuellement.

L’enregistrement crée des liens dans un service de localisation pour un domaine particulier qui associe un URI AOR avec une ou plusieurs adresses de contact. Et donc, lorsqu’un mandataire pour ce domaine reçoit une requête dont le “Request-URI” correspond à l’AOR, le mandataire va transmettre la demande aux adresses de contact enregistrées à cette AOR.

L’enregistrement a pour conséquence l’envoi d’une requête REGISTER à un type particulier d’UAS connu sous le nom de REGISTRAR. Un REGISTRAR agit comme extrémité frontale du service de localisation pour un domaine, lisant et écrivant les transpositions sur la base du contenu des demandes REGISTER. Ce service de localisation est alors normalement consulté par un serveur mandataire qui est chargé d’acheminer les demandes pour ce domaine. Dans un contexte avec un PABX ou un fournisseur de service, c’est tout simplement le serveur de téléphonie (Mandataire ou B2BUA) qui remplit ce rôle.

Source : RFC 3261, 10.1. Registrations, Overview

2. REGISTER simple (sans authentification)

Entre l’UAC 172.16.98.182 et l’UAS 172.16.98.102, REGISTER simple (sans authentification).

REGISTER simple (sans authentification)

Source : https://www.cloudshark.org/captures/de9c2cf75368

REGISTER sip:domain.xyz SIP/2.0
Via: SIP/2.0/UDP 172.16.98.182:5060;rport;branch=z9hG4bK1013779528
From: <sip:telephone1@domain.xyz>;tag=1182049044
To: <sip:telephone1@domain.xyz>
Call-ID: 1077245679
CSeq: 1 REGISTER
Contact: <sip:telephone1@172.16.98.182;line=f0d50acfece3520>
Max-Forwards: 70
User-Agent: Linphone/3.6.1 (eXosip2/4.0.0)
Expires: 3600
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.98.182:5060;rport=5060;branch=z9hG4bK1013779528
Contact: <sip:telephone1@172.16.98.182;line=f0d50acfece3520>;expires=3600
To: <sip:telephone1@domain.xyz>;tag=2021e220
From: <sip:telephone1@domain.xyz>;tag=1182049044
Call-ID: 1077245679
CSeq: 1 REGISTER
User-Agent: repro 1.9.7
Content-Length: 0

3. Annuler un REGISTER

Normalement, les données d’enregistrement sont abandonnées tant qu’il n’y a pas eu de rafraîchissement. Pour annuler explicitement un enregistrement, une nouvelle requête REGISTER avec un champ Expires: 0 dans :

REGISTER sip:domain.xyz SIP/2.0
Via: SIP/2.0/UDP 172.16.98.182:5060;rport;branch=z9hG4bK410623604
From: <sip:telephone1@domain.xyz>;tag=1182049044
To: <sip:telephone1@domain.xyz>
Call-ID: 1077245679
CSeq: 2 REGISTER
Contact: <sip:telephone1@172.16.98.182;line=f0d50acfece3520>
Max-Forwards: 70
User-Agent: Linphone/3.6.1 (eXosip2/4.0.0)
Expires: 0
Content-Length: 0

Note : si le champ Expires était absent, l’effet de “dés-enregistrement” serait identique. Si le champs Expires utilisé peut être celui de l’en-tête, l’information pourrait se trouver comme paramètre du champ Contact.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.98.182:5060;rport=5060;branch=z9hG4bK410623604
To: <sip:telephone1@domain.xyz>;tag=09697f6c
From: <sip:telephone1@domain.xyz>;tag=1182049044
Call-ID: 1077245679
CSeq: 2 REGISTER
User-Agent: repro 1.9.7
Content-Length: 0

4. REGISTER avec Authentification MD5

Le RFC 3261 recommande que les requêtes SIP soient authentifiées comme indiqué dans le RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication).

Entre l’UAC 172.16.98.1 et 172.16.98.101.

REGISTER avec Authentification MD5

Source : https://www.cloudshark.org/captures/423ab1d45e27

Il s’agit d’un dialogue qui est en 4 échanges initialement :

  • REGISTER
  • 401 Unauthorized
  • REGISTER
  • 200 OK

4.1. Procédure REGISTER avec Authentification MD5

Un première requête est envoyée dans un même dialogue dans une première tentative sans authentification.

REGISTER sip:172.16.98.101;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.16.98.1:42952;branch=z9hG4bK-d8754z-531c0fb072273b86-1---d8754z-
Max-Forwards: 70
Contact: <sip:telephone1@172.16.98.1:42952;rinstance=564a2ed14798bc07;transport=UDP>
To: <sip:telephone1@172.16.98.101;transport=UDP>
From: <sip:telephone1@172.16.98.101;transport=UDP>;tag=0976af15
Call-ID: MzlhNDk0Nzg0MjE0MTEyNzRlM2VhNGYyYjgzYzc0MzA.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
User-Agent: Z 3.3.21933 r21903
Allow-Events: presence, kpml
Content-Length: 0

Le serveur REGISTRAR répond avec une réponse d’erreur 401 Unauthorized qui indique un champ nécessaire à l’authentification, ici une authentification MD5 :

WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="26235be0"

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.16.98.1:42952;branch=z9hG4bK-d8754z-531c0fb072273b86-1---d8754z-;received=172.16.98.1
From: <sip:telephone1@172.16.98.101;transport=UDP>;tag=0976af15
To: <sip:telephone1@172.16.98.101;transport=UDP>;tag=as108b6b97
Call-ID: MzlhNDk0Nzg0MjE0MTEyNzRlM2VhNGYyYjgzYzc0MzA.
CSeq: 1 REGISTER
Server: Asterisk PBX 11.7.0~dfsg-1ubuntu1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="26235be0"
Content-Length: 0

Une seconde requête (voir Cseq: 2) fournit les paramètres adéquat :

Authorization: Digest username="telephone1",realm="asterisk",nonce="26235be0",uri="sip:172.16.98.101;transport=UDP",response="f76185db0be3a8ba2494f5fc4ea99eed",algorithm=MD5

REGISTER sip:172.16.98.101;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.16.98.1:42952;branch=z9hG4bK-d8754z-8de228c832cb6988-1---d8754z-
Max-Forwards: 70
Contact: <sip:telephone1@172.16.98.1:42952;rinstance=564a2ed14798bc07;transport=UDP>
To: <sip:telephone1@172.16.98.101;transport=UDP>
From: <sip:telephone1@172.16.98.101;transport=UDP>;tag=0976af15
Call-ID: MzlhNDk0Nzg0MjE0MTEyNzRlM2VhNGYyYjgzYzc0MzA.
CSeq: 2 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
User-Agent: Z 3.3.21933 r21903
Authorization: Digest username="telephone1",realm="asterisk",nonce="26235be0",uri="sip:172.16.98.101;transport=UDP",response="f76185db0be3a8ba2494f5fc4ea99eed",algorithm=MD5
Allow-Events: presence, kpml
Content-Length: 0

Le challenge est accepté car le serveur est capable d’obtenir le même résultat sans échanger de mot de passe.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.98.1:42952;branch=z9hG4bK-d8754z-8de228c832cb6988-1---d8754z-;received=172.16.98.1
From: <sip:telephone1@172.16.98.101;transport=UDP>;tag=0976af15
To: <sip:telephone1@172.16.98.101;transport=UDP>;tag=as108b6b97
Call-ID: MzlhNDk0Nzg0MjE0MTEyNzRlM2VhNGYyYjgzYzc0MzA.
CSeq: 2 REGISTER
Server: Asterisk PBX 11.7.0~dfsg-1ubuntu1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Expires: 3600
Contact: <sip:telephone1@172.16.98.1:42952;rinstance=564a2ed14798bc07;transport=UDP>;expires=3600
Date: Wed, 11 May 2016 11:55:19 GMT
Content-Length: 0

4.2. Démonstration du challenge

Le détail de la procédure d’authentification peut se comprendre à partir de la page Wikipedia Méthode « Digest », Authentification HTTP, mais le script bash démontre mieux la procédure de génération du “Digest” (calculé avec MD5) à partir d’un challenge étant donné qu’ils connaissent tous les deux le secret1 :

#!/bin/bash
# Exemple de calcul d'une réponse d'authentification "Digest"

# Mise en variables des informations issues de la réponse 401 au premier REGISTER
# qui seront reprise dans le second REGISTER
realm="asterisk"
echo "realm: $realm"
nonce="26235be0"
echo "nonce: $nonce"

# Mise en variables récupérées du second REGISTER
uri="sip:172.16.98.101;transport=UDP"
echo "uri: $uri"
username="telephone1" # This is what the user enters
echo "username: $username"
method="REGISTER"
echo "method: $method"

# Enfin le mot de passe qui est connu des deux,
# qui est censé être utilisé par le client
# et qui n'est pas transmit lors de l'échange
password="1111"
echo "Le mot de passe utilisé ne sera pas affiché pour la démo"

# Calcul du premier Digest ha1 en MD5
ha1=`echo -n $username":"$realm":"$password | md5`
echo "ha1: $ha1"

# Calcul du second Digest ha2 en MD5
ha2=`echo -n $method":"$uri | md5`
echo "ha2: $ha2"

# Le Digest de ha1, du nonce et de ha5 sera la réponse attendue
response=`echo -n $ha1":"$nonce":"$ha2 | md5`
echo "response: $response"

En l’absence du mot de passe, soit uniquement avec la seconde requête REGISTER avec une valeur CSeq: 2 REGISTER, on a suffisamment d’éléments pour tenter de le retrouver avec un dictionnaire ou en “brute force”. Il suffira de comparer le résultat d’une tentative de calcul avec la valeur response acceptée par le serveur

5. REGISTER avec utilisateur erroné

Dans cette exemple, l’UA tente de s’authentifier sous un nom d’utilisateur (telephone0) inexistant sur le serveur SIP. Le message d’erreur est “403 Forbidden”.

Source : https://www.cloudshark.org/captures/10222a758905

6. REGISTER avec mot de passe erroné

Dans cette exemple, l’UA tente de s’authentifier avec un mot de passe erroné. Le message d’erreur est aussi dans ce cas “403 Forbidden”.

Source : https://www.cloudshark.org/captures/784f68cbb09a

7. Découverte de mots de passe

Un outil comme sipdump permettra de capturer le trafic intéressant de la seconde requête REGISTER et d’en extraire les informations utiles. Son outil complémentaire est sipcrack qui permet de tenter des mots de passe à partir d’un dictionnaire.

Voir le chapitre Sécurité VoIP / SIP.

  1. dtob.py: Digest to Basic authentication; A simple example of a authentication ‘downgrade’ attack ↩

Vous pourriez aimer aussi

Asterisk Avancé

8 minutes de lecture

Voici une dernnière étape qui propose de s’interfacer avec des bases de données et d’exploiter l’API d’Asterisk, de procéder aux sauvegardes et à la mise à jour d’Asterisk. Enfin, le propos s’intéresse au “Text-to-speech”.

Asterisk intermédiaire

14 minutes de lecture

On trouvera ici une seconde étape pratique dans l’étude d’Asterisk : interactivité, connectivité externe, boites vocales, sécurité du trafic sont au menu de cet exercice.

Asterisk Concepts de bases

32 minutes de lecture

Ce chapitre est un exercice complet d’installation et de configuration d’un central téléphonique IP (IP PBX) simple avec Asterisk. Il permet de s’initier rapidement à la programmation et à la manipulation du logiciel, à manipuler les comptes SIP et le plan d’appel (dialplan).

Asterisk Core PABX

24 minutes de lecture

Voici une introduction au logiciel de téléphonie Asterisk.