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 fraiche.

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