Récemment, des référents sécurité m’ont encore déclaré que la téléphonie ne pouvait pas être sécurisée. Cela s’appelle jeter un pavé dans la mare ! Surtout lorsque l’on jette un gant comme celui-ci à la figure de quelqu’un dont le métier est précisément d’essayer de réduire les risques sur cette technologie.
Pour essayer de démontrer que malgré une réalité qui n’est pas tendre, il y a toujours des moyens de renforcer la sécurité sur ces environnements, je vais vous proposer une série de petites vidéos retraçant les grandes étapes d’un audit (forcément catastrophique !) et les préconisations pour résoudre les points levés.
Pour notre premier rendez vous, la facilité d’accès du VLAN voix va être testée.
audit sécurité : l'accès au VLAN voix
Pour rappel, dans la plupart des installations, le téléphone IP est raccordé directement au réseau sur un port gérant les VLAN Voix et Data. Le téléphone a donc accès à ces deux VLAN, tandis que le PC branché sur ce dernier n’accède qu’à la partie data. Le but du jeu est donc d’étudier comment obtenir un accès au VLAN Voix.
Liste des outils utilisés :
- Une carte réseau supportant le multi VLAN.
L’attaque de la vidéo a été réalisée à partir d’un Mac. Certains crieront que c’est un scandale, d’autres le porteront au firmament. Personnellement, je trouve que c’est une machine avec un hardware puissant permettant d’impacter le réseau sans avoir trois PC dans mon sac. De plus, on y retrouve une base de type BSD, ce qui permet de compiler la majeure partie des scripts utiles.
Pour le reste, la virtualisation offre la possibilité de faire tourner tous les systèmes de façon fluide (le hardware, souvenez vous). Mais bon, la vraie raison c’est peut être que je suis un fan de la série millenium et que Lisbeth Salander m’inspire. Cela doit être mon coté obscur.
Mais revenons au vrai sujet, cette vidéo a donc permis de montrer plusieurs faiblesses dans la gestion de la sécurité de la téléphonie de cette installation.
les enseignements de l'audit du téléphone
Tout d’abord, le menu administrateur du téléphone n’aurait pas du être accessible depuis l’interface utilisateur. Il est évident que si l’information du VLAN n’est pas disponible, cela complique les choses. Certains pourraient répondre que des outils comme UCSniff ou VoipHopper sont là pour cela (uniquement dans un monde Cisco). C’est vrai. Néanmoins, cela demande un minimum de connaissances techniques de la part de l’attaquant, ce qui réduit le risque. Par ailleurs, il est toujours possible de configurer le VLAN à la main.
Deuxième point, le VLAN choisi pour la voix est très bas (11). Si l’attaquant ne peut utiliser un outil automatique comme ceux cités précédemment, il faudra réaliser une recherche systématique du VLAN, soit à la main, soit par script (à faire soit même, cette méthode n’ayant pas la faveur des experts publiant des outils sur Internet). Il devient alors évident que si le numéro de VLAN est 800, la méthode manuelle sera un calvaire et la méthode scriptée prendra au mieux plusieurs dizaines de minutes (expérience personnelle). La difficulté qui vient d’être ajoutée n’est en rien une charge pour l’administrateur et complique déjà les choses pour notre attaquant.
Les deux propositions ci-dessus ne portent que sur la configuration du système téléphonique et du réseau et cela quasiment sans aucune surcharge de travail des équipes devant intégrer les systèmes. Maintenant, pour ceux qui peuvent s’investir pour monter le niveau de sécurité d’un cran, il est possible d’envisager les technologies de type 802.1X. Cela permettra d’authentifier les terminaux à l’accès avant même d’ouvrir le réseau. Un moyen imparable pour bloquer les attaquants dès le départ. Mais cela est une autre histoire…
Le sujet que j’attaque avec ce post est très vaste. Il peut être l’occasion d’échanger au travers de commentaires. Je vous invite donc à indiquer des points que vous aimeriez voir traités, ou encore des expériences vécues qui me donneraient de la matière.
Cedric