Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Sécurité de la téléphonie - reconnaissance du VLAN voix

Sécurité de la téléphonie - reconnaissance du VLAN voix
2012-02-062013-02-28sériesfr
Ce post fait suite à un premier article paru en Novembre 2011. Un auditeur avait alors commencé son travail sur une installation de téléphonie Cisco. Une première étape avait été victorieusement franchie avec l'accès au VLAN voix pour le PC de ce dernier. Ce premier pas franchi, il...
Publié le 6 Février 2012 par Cedric Baillet dans séries
sécurité de la téléphonie - reconnaissance du VLAN voix

Ce post fait suite à un premier article paru en novembre 2011. Un auditeur avait alors commencé son travail sur une installation de téléphonie Cisco. Une première étape avait été victorieusement franchie avec l’accès au VLAN voix pour le PC de ce dernier.

Ce premier pas franchi, il s’agit maintenant de voir comment cet accès va pouvoir être exploité pour récupérer le maximum d’informations.

opération commando

Pour cela, nous allons utiliser un nouvel outil créé pour cette occasion. Pourquoi un nouveau script alors que de nombreux outils de qualité existent déjà me demanderont certains ? Une bonne question qui, je crois, a également une bonne réponse : les outils existant ne sont pas forcément adaptés aux infrastructures de téléphonie d’entreprise et ne tirent donc pas parti de toutes les surfaces d’exploitation disponibles.

Un point de vue révolutionnaire, anarchiste, mégalo, ou tout simplement manquant de recul… mais qui me semble malgré tout défendable pour deux raisons :

  • Il y a effectivement des surfaces d’exploitation laissées en jachères.
  • Le monde des outils destinés à tester la ToIP n’est pas extrêmement actif et cela permettra peut être d’apporter une petite brise fraîche.

Je vous propose donc, dans la vidéo qui va suivre, d’utiliser ISME (IP Phone Scanning Made Easy) pour tenter de récupérer des informations sur l’infrastructure sur laquelle le PC est connecté et nous permettre ainsi de poursuivre l’audit de cet environnement.

du concept à la pratique

Regardez la vidéo directement en suivant ce lien (ou sur YouTube aussi)

L'outil utilisé dans la vidéo est ISME (IP Phone Scanning Made Easy). Le bilan de cette première étape est donc le suivant :

  • Connaissance des téléphones actifs,
  • Connaissance des modèles présents,
  • Identification de plusieurs serveurs de l’infrastructure centrale,
  • Récupération des fichiers de configurations,
  • Des informations complémentaires sur les téléphones…

Un premier bilan plutôt intéressant qui va permettre soit de s’orienter vers des attaques à destination des périphériques utilisateurs, soit au contraire de pousser les investigations en direction de l’infrastructure centrale maintenant que nous avons des points d’entrée.

des enseignements ?

Le premier est malheureusement un constat. Le serveur web des téléphones permet d’accéder aux fonctions offertes par les scripts XML. Il est donc difficile de le désactiver sans réduire les fonctions offertes à l’utilisateur. La fuite d’informations provoquée par cet élément actif ne peut donc pas être jugulée de façon binaire.

Néanmoins, si des mécanismes de filtrage avaient été mis en œuvre, il est probable que cette reconnaissance aurait pu être partiellement bloquée. Mettre en œuvre une ACL au niveau du VLAN voix est désormais beaucoup moins impactant pour les performances avec les châssis modernes. C’est un moyen simple qui permet par exemple, de limiter l’accès au port 80/443 des téléphones aux seuls administrateurs ou serveurs.

En effet, pourquoi un téléphone aurait-il besoin d’interroger l’un de ses comparses ? Si l’on considère une installation classique, deux téléphones ne devraient avoir à s’échanger que des flux RTP (flux media), la signalisation, les flux XML ou SOAP étant dirigés vers les serveurs.

Pour finir, j’avoue bien volontiers avoir osé écorner le St Graal en considérant que NMAP n’est pas optimum pour toutes les taches. Néanmoins, je reste persuadé qu’il manque aujourd’hui des outils clairement dédiés à la téléphonie qui pourraient aller beaucoup plus loin que ce que nous connaissons (plein de nouveaux scripts NSE pour NMAP ?).

Liste des outils depuis le début de la série (et oui, deux posts c'est le début d'une série non ?) :

  • Une carte réseau supportant le VLAN voix,
  • Wireshark (sniffer),
  • IP Phone scanning made easy (ISME).

Cedric

Crédit photo : © Galina Vdovenko - Fotolia.com

3 Commentaires

  • 5 Juin 2012
    2012-06-05
    par
    Verif
    Bonjour, est ce possible de créer deux vlan Voice(dédiés à la voix sur IP) dans un même site, je veux dire est qu'il existe des switch qui peuvent gérer deux vlan différents dédiés à la VoIP, et y a t il un intérêt particulier de faire ceci.
    Merci
  • 22 Mars 2012
    2012-06-05
    par
    Il faut considérer deux types de clients. Généralement les clients sensibles à la sécurité (souvent des grands comptes, mais pas seulement) demandent la mise en oeuvre d'une DMZ spécifique aux communications sur IP. Les clients plus bas de marché travaillent plus souvent dans un mode à plat. Cela fonctionne mais n'est pas correct en terme de sécurité. En se placant dans le premier cas, les flux Http/xml circulent entre IP Phones et serveurs. En aucun cas entre deux IP Phones. Il faut donc effectivemet ouvrir ce flux spécifiquement. Et il y en a encore bien d'autres ... un post est trop petit pour pouvoir être exhaustif.
  • 22 Mars 2012
    2012-06-05
    par
    Laurent Bonny
    Concernant le fait de bloquer au niveau d'ACL certains ports afin d'empecher les postes de faire autre chose que du RTP et du SIP je suis globalement d'accord, si ce n'est que le PBX est bien souvent lui aussi dans ce VLAN Voix. C'est sûr il pourrait être mis dans une DMZ, mais en pratique ce n'est pas le cas. Certains PBX echangent avec leurs postes au travers de flux http et d'XML, donc je ne suis pas sûr que l'on puisse bloquer tous ces flux.

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage