H323 est-il mort (part 1/3) ?

introduction

Nouvel exercice sur le blog. Nous vous proposons une semaine thématique sur le sujet "H323 est-il mort ?". Le contenu restituera une recherche pratique effectuée ces dernières semaines et sera éventuellement suivie d'un document reprenant l'ensemble des posts avec des éléments complémentaires permettant de faire un premier parallèle entre H323 et SIP. Mais passons maintenant aux choses sérieuses.

Depuis que le protocole de signalisation SIP est devenu le standard en termes de signalisation pour les communications unifiées (téléphonie, visioconférences, …) le protocole H323 est décrit par beaucoup comme un dinosaure, soit un protocole obsolète et désormais en voie de disparition.

Néanmoins, l’émergence récente du protocole SIP, la maturité du H323 et son temps de vie assez important, sont des arguments qui permettent de s’interroger sur la vision binaire présentée précédemment.

Le but de cette expérimentation pratique est donc de scanner une « tranche » d’Internet suffisamment significative (0,42% pour être précis) pour pouvoir en tirer quelques conclusions quant au devenir du protocole H323, ses usages et éventuellement des questions sécuritaires qui pourraient remonter. 

vous avez dit H323 ?

Le protocole H.323 regroupe un ensemble de protocoles de communication de la voix, de l'image et de données sur IP. C'est un protocole développé par l'UIT-T. Il est dérivé du protocole H.320 utilisé sur RNIS. 

Plus qu'un protocole, H.323 ressemble davantage à une association de plusieurs protocoles différents et qui peuvent être regroupés en trois catégories :

• la signalisation
• la négociation de codec
• et le transport de l’information

Les messages de signalisation sont ceux que l’on envoie pour demander à être mis en relation avec une autre personne, et qui indiquent que la ligne est occupée, que le téléphone sonne… Cela comprend aussi les messages que l’on envoie pour signaler que tel téléphone est connecté au réseau et peut être joint de telle manière. En H.323, la signalisation s’appuie sur le protocole RAS (Registration Admission Status) pour l’enregistrement et l’authentification, et le protocole Q.931 pour l’initialisation et le contrôle d’appel.

La négociation est utilisée pour se mettre d’accord sur la façon de coder les informations qu’on va s’échanger. Il est important que les téléphones (ou systèmes) parlent un langage commun s’ils veulent se comprendre. Il serait aussi préférable, s’ils ont plusieurs alternatives de langages qu’ils utilisent le plus adapté. Il peut s’agir du codec le moins gourmand en bande passante ou de celui qui offre la meilleure qualité. Le protocole utilisé pour la négociation de codec est le H.245

Le transport de l’information s’appuie sur le protocole RTP qui transporte la voix, la vidéo ou les données numérisées par les codecs. On peut aussi utiliser les messages RTCP pour faire du contrôle de qualité, voire demander de renégocier les codecs si, par exemple, la bande passante diminue. (Source) 

méthodologie utilisée

informations généralistes

Seuls des subnets de type classe B (X.X.0.0/16) ont été utilisés. La classe A est mise de coté car beaucoup trop longue à scanner, tandis que la classe C est tout simplement trop petite.

Les subnets ont été sélectionnés en ciblant les grandes villes avec une répartition entre subnets et plaques géographiques pour éviter de trop grands déséquilibres dans les actions de scan.

Les bloques ASIE, AMERIQUE et EUROPE ont une représentation légèrement supérieure car ils semblent représenter tout simplement une part plus importante en terme d’adresses consommées. C’est en tout cas ce qu’il est apparu dans le cadre de la présente recherche.

Les scans ont été effectués de jour comme de nuit sur quelques tranches « test », ce paramètre ne semble pas influencer de manière significative les résultats.

Les informations de géolocalisation utilisées pour réaliser les statistiques présentes dans ce document ont été trouvées à partir du site suivant : http://www.geolocip.com/ 

outil utilisé

Le module « auxiliary/scanner/h323/h323_version » du framework Metasploit a été utilisé. Ce dernier permet de scanner une adresse IP ou un subnet, et d’identifier les périphériques H323 actifs, tout en remontant des informations sur le constructeur de l’équipement.

Son paramétrage a été réalisé selon la procédure présente dans les captures ci-dessous.

Remarque : le module metasploit utilisé semble plus efficace que NMAP dans la détection des périphériques propres à l’usage visioconférence. En effet, NMAP confirme la présence du service mais n’a pas été capable (dans mon cas) d’identifier le périphérique.

Etape 1 : identifier le module H323

Etape 2 : sélectionner le module H323
Etape 3 : paramétrer les optionsAttention, il peut être tentant de mettre un nombre de threads important pour gagner du temps pendant la phase de scan. J’ai personnellement rencontré des problèmes au dessus de 250 threads.

Problème 1 : Entre 250 & 300 threads, le module remonte des erreurs de type « execution expire », ce qui fausse le résultat du scan.

Problème 2 : Au-dessus de 300 threads le module crash.

Fatigué(e) ? un petit easter egg pour vous détendre.

Etape 4 : lancer le scan

Etape 5 : Les résultats d’un scan positif se présentent de la façon suivante :
Etape 6 : automatisons la chose.

Metasploit possède un module appelé msfcli. Son utilisation permet de scripter en partie l’utilisation des modules et ainsi d’enchaîner un certain nombre de tâches. La capture ci-dessous montre les étapes décrites précédemment réalisées en une ligne et permet l’enchainement des scans.

résultats du scan

informations génériques

J’ai finalement décidé d’arrêter l’opération de scan à 18 millions d’adresses. A ce stade, je ne constate plus de rupture dans les profils comme cela put être le cas au démarrage de l’expérimentation. Une éventuelle inversion des tendances demanderait de scanner 20 ou 30 millions d’adresses supplémentaires, ce qui représente à la fois de nombreux jours consacrés à cette activité pour une machine et un nombre d’heures significatif pour compiler les résultats et préparer les scans.

A ce stade, il est déjà intéressant de constater des différences significatives avec les résultats présentés par HD Moore. En effet, le nombre de périphériques H323 trouvés par ce dernier pour 3% de l’espace publique d’Internet, correspond à plus de 50% de ma projection pour l’adressage IP V4 public complet. Il eut été intéressant de connaître la méthodologie et les subnets pour comprendre d’où peut provenir une différence aussi significative. En effet, ce résultat pourrait se retrouver uniquement en considérant les zones les plus riches en termes de périphériques H323 au détriment d’une recherche homogène sur l’ensemble des groupes disponibles.

FIN DE LA PREMIERE PARTIE.

Partie 2: Le détail de l'analyse des résultats sera fourni dans un post qui paraitra le Mercredi 14 Mars.

Partie 3: Le détail des points sécurité sera fourni dans un post qui devrait paraitre le Vendredi 16 Mars.

Cedric

credit photo : © Secret Side - Fotolia.com