MISC N 16

Scurit de la Voix sur IP

Pierre BETOUIN - cole suprieure d'informatique, d'lectronique et d'automatique (ESIEA) pierre.betouin@security-labs.org Patrick CHAMBET - Consultant Senior, EdelWeb - Groupe ON-X http://www.edelweb.fr - http://www.chambet.com - patrick@chambet.com Nicolas FISCHBACH, Senior Manager, Network Engineering Security, COLT Telecom nico@securite.org - http://www.securite.org

Introduction
La voix sur IP est dj, ou va devenir, un projet stratgique en 2005 pour bon nombre dentreprises et doprateurs. Pour lutilisateur elle permet uniquement de tlphoner moindre cot via l'Internet, la voix restant une forme de communication bien plus conviviale que le courrier lectronique ou les formes de messageries instantanes. Pour lentreprise et les oprateurs ce facteur cot de la communication est important, mais le dploiement de rseaux privs virtuels MPLS, l'introduction de la qualit de service dans les rseaux (QoS), la convergence voix-donnes (CTI), les divers projets de consolidation des deux dernires annes, l'arrive des autocommutateurs IP, la disponibilit de postes tlphoniques intgrant des fonctionnalits de plus en plus avances sont des facteurs tout au moins aussi dterminants. Des tudes rcentes montrent que la scurit de la VoIP est un lment cl pour les dcideurs, mais les dploiements observs ont malheureusement tendance montrer le contraire. Aprs avoir prsent les principaux protocoles lis la voix sur IP et avoir prsent les rudiments de la scurisation des diffrents quipements nous allons dtailler diffrentes attaques et quels ajouts scurit peuvent limiter leur impact. Pour finir nous discuterons de linterception de trafic et prsenterons deux volutions rcentes de la VoIP.

Les diffrents protocoles

Nous allons nous intresser tout particulirement aux solutions de voix sur IP qui reposent sur les protocoles SIP [2] (signalisation et contrle) et RTP [12] (transport de la voix). Il nous semble important de rappeler quune solution complte repose sur un large nombre de protocoles et que H.323, qui nest ici que cit, est encore prsent dans bon nombre de dploiements.

SIP
SIP (Session Initiation Protocol) est le standard IETF pour la signalisation (tablissement, terminaison, redirection, relayage, etc) de communications multimdias interactives. Ce protocole est de nos jours celui qui est dploy couramment. Le format est proche dune adresse de messagerie: sip:nico@securite.org avec une syntaxe proche de celle d'HTTP. SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) est une extension de SIP dont le but est de supporter les messageries instantanes. Le projet PROTOS [16] sest intress SIP, et comme pour SNMP, a trouv un nombre important dimplmentations qui ne passaient pas le batch de tests sans se planter ou redmarrer. Cela concerne aussi bien les tlphones que les relais SIP et les quipements de scurit. Le SIP proxy joue le rle de relais et fait suivre une requte SIP au prochain serveur. Le SIP redirect server renvoie une rponse au client contenant le prochain serveur contacter. Le SIP registrar enregistre le lien entre ladresse IP et ladresse SIP. Comme pour IPsec, des solutions alternatives ont d tre dveloppes pour grer les contraintes introduites par la traduction dadresses (NAT).

Exemple de session SIP

Mthode INVITE Principe Dbute une communication SIP. Cration du Call-ID et ventuellement du tag sur le champ From.

Mthode REGISTER ACK

Principe Enregistre un utilisateur auprs d'un noeud VoIP (non utilis en communication directe entre 2 clients). Confirmation de l'tablissement de la session SIP. Call-ID identique celui du paquet INVITE associ. Ajout ventuel du tag sur le champ To du paquet INVITE relatif. Met fin la communication. Mme Call-ID que paquets prcdents. Idem si utilisation des tags. Annule un SIP INVITE (appel). Mme Call-ID ventuellement tag du champ From du SIP INVITE. les et

BYE CANCEL

Principales mthodes SIP

H.323
H.323 [14] a t le premier protocole dvelopp pour permettre des communications multimdias. SIP est son concurrent. H.323 est relativement complexe et SIP tente de simplifier les changes en utilisant une smantique proche de HTTP. H.235 [13] dfinit certains mcanismes de scurit (authentification et chiffrement).

Les protocoles secondaires

Le service DNS est utilis pour fournir des services dannuaire et de localisation. TFTP et HTTP sont utiliss par les tlphones et diffrents autres lments pour tlcharger leur configuration. ENUM permet de lier des adresses SIP via DNS aux numros de tlphone au format E.164.

Scurit des quipements

Les offres commerciales de VoIP ncessitent des serveurs et des applicatifs pour fonctionner. Nous allons prendre lexemple dune infrastructure Cisco et dtailler les besoins de scurit sur les diffrents quipements.

Serveurs Windows
Les applicatifs Cisco sont hbergs sur des serveurs Windows. Ces serveurs sont bien souvent installs par dfaut et laisss en ltat. Il est donc ncessaire de commencer par scuriser lOS de ces serveurs (voir MISC No 2 et [9]). Les points suivants sont particulirement surveiller, notamment sur les serveurs prWindows 2003 : filtrer les ports accessibles sur les serveurs depuis le rseau des utilisateurs, au niveau des routeurs ; dsinstaller ou stopper les services inutiles ; mettre jour le serveur avec les derniers correctifs de scurit ; interdire les connexions NetBIOS anonymes ; appliquer des permissions daccs strictes sur le systme de fichiers et la base de registre ; activer laudit de scurit et configurer des journaux de grande taille ; installer IIS (ncessaire pour le Call Manager par exemple) de manire scurise (voir MISC No 1 et [10]).

Lapplication Cisco Call Manager utilisant galement une base de donnes SQL Server, il est trs important de scuriser particulirement celui-ci. Pour cela, les recommandations principales sont les suivantes : appliquer les derniers correctifs de scurit de SQL Server ; faire tourner les services de SQL Server sous des comptes spcifiques, non administrateurs ; attribuer un mot de passe robuste au compte sa ; supprimer les bases par dfaut ; si possible (en fonction des applications), crer des utilisateurs spciaux, voire nominatifs et leur attribuer des mots de passe non triviaux ; appliquer des permissions daccs sur les objets de SQL Server (tables, procdures stockes, etc) en fonction des utilisateurs ; supprimer les procdures stockes par dfaut si elles ne sont pas utilises.

A noter que, sans scurisation particulire, il est possible deffectuer un transfert de zone DNS du domaine interne utilis par dfaut (avvid.com). On y trouve galement la liste des services et des ports utiliss par les applicatifs de gestion VoIP :
[[123.123.123.123]]
avvid.com. SOA unity01.avvid.com admin. (26 900 600 86400 3600) avvid.com. A 123.123.123.123 avvid.com. NS unity01.avvid.com _kerberos._tcp.default-first-site-name._sites.dc._msdcs SRV priority=0, unity01.avvid.com

[] Il convient donc dinterdire le transfert de zone au niveau des serveurs DNS internes.

Serveurs *nix
En ce qui concerne la scurisation des serveurs Unix, il est recommand dappliquer les recommandations gnrales suivantes, en fonction des applicatifs VoIP hbergs : minimisation du systme (dsinstallation des dmons et serveurs inutiles) ; appliquer les derniers correctifs de scurit de lOS ; crer des comptes spcifiques et leur attribuer des mots de passe robustes ; chrooter (mise en "cage") les applicatifs et les faire tourner sous des comptes non privilgis ; appliquer les derniers correctifs de scurit des applicatifs ; activer les logs (journalisation) au maximum.

Des informations sur la scurisation dAsterisk par exemple, un PBX logiciel tournant sur Unix, se trouvent ici : [17].

Tlphones
Le tlphone peut se prsenter sous deux formes : soit un tlphone classique, soit un tlphone logiciel qui sexcute sur lordinateur de lutilisateur. En terminologie SIP cest un UA (User Agent). Au niveau des tlphones IP, laccs la partie protge par HTTP Basic Authentication se fait en clair :

http://IP-Phone/CGI/

Si le mot de passe est le mme sur tous les tlphones, nimporte qui peut excuter des commandes de configuration sur lensemble des tlphones. Il est bien sr recommand de mettre jour le firmware des tlphones IP, et de dsactiver les interfaces de gestion du type HTTP et telnet des tlphones IP (cela peut tre fait depuis lapplication Cisco Call Manager, que nous tudierons plus loin). Signalons quil est possible deffectuer un dni de service sur un tlphone IP par lintermdiaire de lapplication Cisco Call Manager 3.x. En effet, celle-ci gre le profil des utilisateurs, qui sont tlchargs sur les tlphones IP lorsque les utilisateurs se loguent dessus. En dpassant largement la limite de 99 services tlphoniques IP par tlphone (en dveloppant par exemple un script qui cre plus de 1000 services dans lapplication Call Manager), le profil de lutilisateur devient inutilisable sur un tlphone IP : on ne peut plus ni se loguer sur un tlphone ni se dloguer, et celui-ci devient inutilisable (plus de tonalit). Il est ncessaire de lteindre et de le rallumer, aprs avoir corrig le profil utilisateur dans le Call Manager.

Autres quipements
Certains constructeurs proposent des quipements propritaires pour grer la VoIP. Cisco propose par exemple les passerelles voix-donnes VG 200 et VG 248, fonctionnant sous IOS, le systme dexploitation des routeurs Cisco. Il est frquent de rencontrer le service telnet ouvert sur de tels quipements. Il est donc fortement recommand de ne pas laisser linterface dadministration des quipements accessible depuis lensemble du rseau local. De plus, tant donn les possibilits dinterception des connexions, mme travers le switch (cf. plus loin dans cet article), il est fortement dconseill dutiliser un protocole dadministration non chiffr. Nous vous recommandons dactiver les fonctionnalits de scurit prsentes dans IOS et CatOS (voir MISC 1 ou [15]).

Applicatifs
Les applications de gestion du rseau VoIP sont bien souvent des applications Web, et, comme telles, elles sont sensibles aux attaques classiques contre ce type dapplications (voir Linux Mag HS No 12 et [11]). Il est donc ncessaire de prendre un soin particulier leur scurisation, dautant plus que certaines dentre elles ont besoin dtre accessibles depuis une grande partie du rseau local, voire depuis lInternet ! Le Call Manager, par exemple, fournit des fonctions de base de gestion des appels, des utilisateurs et des configurations, mais galement des fonctionnalits avances comme la confrence, les botes vocales, etc. Il peut tre vu comme un IP PBX. A ne pas confondre avec des PBX traditionnels (pas de VoIP) que lon peut administrer distance via une connexion TCP/IP (qui remplace la connexion locale ou de tlmaintenance via un modem). Lapplication Unity, quant elle, est lapplicatif permettant davoir une messagerie vocale VoIP.

Lauthentification lors des accs au Call Manager 3.x se fait par lintermdiaire de formulaires HTML :
http://CallMgr/CCMUser/logon.asp http://CallMgr/CCMAdmin/logon.asp http://CallMgr/CCMCIP/authenticate.asp http://CallMgr/ma/desktop/maLogin.jsp

De mme, lauthentification pour laccs lapplication Cisco IP Manager Assistant (IPMA) se fait laide dun formulaire HTML et dune applet Java. Dans tous les cas (accs utilisateurs et accs administrateur), le trafic rseau transite en clair. Il est facile, par une attaque ARP sur les commutateurs (voir plus loin), de capturer le trafic afin de rcuprer le mot de passe de ladministrateur lorsquil se connecte. Il est donc indispensable de forcer lutilisation de SSL pour accder aux pages HTML dauthentification applicative. Dautre part, les donnes saisies par lutilisateur dans les formulaires HTML de lapplication ne sont contrles que ct client (par des scripts JavaScript), ce qui est lerreur classique : elles ne sont pas contrles nouveau ct serveur. Il est donc facile pour un attaquant doutrepasser les contrles afin dentrer des donnes dangereuses dans lapplication (code HTML, scripts, injection SQL, etc). Des applications directes de ce type de vulnrabilit sont par exemple les suivantes : Dni de service sur les tlphones IP (voir plus haut) ; Cross Site Scripting (XSS) : voir figure ci-dessous.

Lexemple ci-dessus montre quil est possible de rcuprer le cookie dauthentification dun utilisateur. Ce cookie est suffisant pour accder lapplication sa place. Dautres recommandations, plus classiques, sont galement prendre en compte lors de linstallation des applications de gestion VoIP : configurer le Call Manager, IIS et/ou TomCat afin de ne pas afficher des messages derreur dtaills pouvant fournir des informations prcieuses un attaquant ; supprimer les rpertoires par dfaut et tous les rpertoires et fichiers inutiles ; installer un filtre dURLs (de type URLScan) afin dinterdire les attaques classiques sur les URLs et les caractres spciaux ; etc (voir [11]).

Il faut galement savoir que laccs lannuaire dentreprise est en libre accs par dfaut, aussi bien partir des tlphones IP que de tout navigateur Web : il est possible de faire des recherches et de consulter lensemble de lannuaire laide de requtes de la forme :
http://CallMgr/CCMCIP/xmldirectorylist.asp?l=A&f=&start=1

Le rsultat donne les informations suivantes :

<CiscoIPPhoneDirectory> <Prompt>Records 1 to 32 of 1254</Prompt> <DirectoryEntry> <Name>Glloq, Alain</Name> <Telephone>12345</Telephone> </DirectoryEntry> [...] </CiscoIPPhoneDirectory>

De mme, un accs LDAP anonyme aux serveurs applicatifs rvle le contenu de lannuaire :
ld = ldap_open("123.123.123.123", 389); Expanding base 'DC=avvid,DC=com'... Result <0>: (null) Matched DNs: Getting 1 entries: >> Dn: DC=avvid; DC=com; 1> masteredBy: CN=NTDS Settings,CN=UNITY01,CN=Servers,CN=DefaultFirst-Site-Name, CN=Sites,CN=Configuration,DC=avvid,DC=com; [] 1> fSMORoleOwner: CN=NTDS Settings,CN=UNITY01,CN=Servers,CN=DefaultFirst-Site-Name, CN=Sites,CN=Configuration,DC=avvid,DC=com; 1> gPLink: [LDAP://CN={31B2F340-016D-11D2-945F00C04FB984F9},CN=Policies,CN=System, DC=avvid,DC=com;0]; []

Attaques locales
Les attaques tudies ici sont des attaques locales, au niveau du LAN principalement. Elles ont t testes sur des quipements Cisco IP Phone et leur infrastructure (quipements, serveurs et applicatifs). Des vulnrabilits graves ont t mises en lumire et exploites, allant dun simple dni de service sur les quipements (tlphones et serveurs) au dtournement de flux audio conduisant lcoute de nimporte quelle conversation sur le rseau, en passant par la rcupration dinformations confidentielles et la facturation dappels dautres personnes.

Utilisation frauduleuse des postes tlphoniques

Bien que la configuration locale des tlphones IP puisse tre modifie par lutilisateur (en utilisant le code de dverrouillage **# par exemple sur les Cisco IP Phones), il est difficile deffectuer une attaque partir des postes tlphoniques IP. En effet, la plupart des paramtres ne sont pas modifiables localement. Seule une reconfiguration des interfaces du tlphone est possible.

tanchit des rseaux voix / donnes

LIP Phone de Cisco, par exemple, intgre deux interfaces rseau et un switch interne, sparant le flux voix et le flux donnes dans deux VLANs diffrents. Dans lutilisation normale dun IP Phone Cisco, lordinateur de lutilisateur est connect sur

la prise de donnes de son IP Phone, celui-ci tant lui-mme connect au rseau local de lentreprise :

LAN Poste de travail Tlphone IP

Tentatives de franchissement donnes vers voix

Dans la configuration ci-dessus, le franchissement donnes vers voix est impossible, car lIP Phone procde un filtrage du VLAN voix. Cependant, pour accder au flux voix, il suffit de brancher un ordinateur directement sur la prise murale, avec des outils appropris pour se placer sur le VLAN voix (par exemple noyau Linux avec extension protocole 802.1Q).

Tentatives de franchissement voix vers donnes

Le franchissement voix vers donnes na pas vritablement de sens dans la mesure o le flux de donnes nest pas protg par un VLAN spcifique. On accde donc aux mmes informations, que lon soit branch dun ct ou de lautre de lIP Phone. Bien sr, le franchissement voix vers donnes nest pas possible depuis le seul poste tlphonique.

Attaque des flux VoIP

Le flux voix VoIP utilise deux types de canaux de communication, lun de contrle, lautre de donnes. Le canal de contrle utilise le protocole Cisco Skinny sur les ports TCP 2000-2002. Chaque tlphone IP tablit une connexion TCP avec le serveur hbergeant le Call Manager 3.x sur le port 2000. Cette connexion est garde active grce lmission de KeepAlive toutes les 30 secondes. Les caractristiques importantes dun point de vue scurit sont les suivantes : le canal de contrle est connect en permanence ; la connexion est initialise par le poste IP-phone ; les actions Skinny sont transmises en clair.

Le canal de donnes sert faire transiter les donnes audio des communications. Il utilise un driv du protocole RTSP : il sagit de paquets UDP envoys sur des ports dynamiquement ngocis travers le canal de contrle.

Une communication classique comporte deux flux voix simultans, ayant un dbit de 50 paquets par seconde chacun. Chaque paquet est compos dun en-tte de 54 octets (en-tte UDP + entte RTSP) puis de 160 octets de donnes audio encodes en u-law 8bits, 8kHz. Les caractristiques importantes dun point de vue scurit sont les suivantes : les ports UDP sont ngocis dynamiquement au travers du canal de contrle ; les paquets sont numrots squentiellement dans lentte RTSP ; le flux audio est compress mais non chiffr ; labsence de flux est autorise et est synonyme de silence dans la communication tlphonique.

Insertion de paquets dans un flux VoIP

Si on est en mesure dintercepter le flux dun tlphone IP, il est possible dinsrer des paquets dans le canal de contrle ou dans le canal de donnes, avec des rsultats trs diffrents. Les attaques suivantes ont t rellement effectues au cours de tests dintrusion.

Insertion dun paquet remplaant un autre paquet de mme taille dans le canal de contrle
Lorsquil est possible de prdire lmission dun vnement particulier dans le canal de contrle par lutilisateur dun tlphone IP, il suffit denvoyer, avec une trs lgre anticipation (quelques centimes de seconde), un autre paquet qui sera pris en compte la place du paquet prdit. La substitution dun paquet conduit aux rsultats suivants selon les cas : simuler lappui dune touche du pav numrique du tlphone, pour modifier la vole le numro compos par lutilisateur du tlphone (ou bien lenregistrer afin despionner les numros composs), ou deffectuer des choix sa place lors de la consultation dun serveur vocal, par exemple ; envoyer un faux paquet de type OpenReceivedChannelAck, juste avant lmission du vritable paquet, contenant un mauvais numro de port UDP pour spcifier le canal de donne : lutilisateur lgitime nentendra alors que du silence dans son combin.

Insertion dun paquet quelconque dans le canal de contrle

Dans certains cas, on ne peut de prdire avec certitude le prochain paquet mis sur le canal de contrle par le Call Manager et reu par le tlphone phone IP (ou vice versa). Cependant, il est toujours possible denvoyer un paquet qui sera pris en compte par le tlphone IP (un signal de sonnerie occupe par exemple). Mais dans ce cas, les numros de squence TCP tant errons, le tlphone plantera quelques secondes plus tard, lors de lmission du paquet suivant.

Dni de service gnralis

Nous avons vu quil suffit denvoyer un paquet TCP de taille quelconque, mais dot dun numro de squence correctement choisi, un tlphone pour le rendre inutilisable jusqu son extinction manuelle. Il est donc facile deffectuer un dni de service gnralis sur lensemble du rseau VoIP. Le scnario suivant pourrait par exemple tre mis en uvre : 1- coute passive des broadcasts mis par les tlphones IP au moment de leur dmarrage ; 2- identification dun tlphone IP en train de booter ; 3- coute passive de ce tlphone, laide de ARP spoofing, le temps de rcuprer la squence TCP (30 secondes suffisent en gnral) ; 4- envoi dun paquet TCP au tlphone IP, mettant celui-ci hors service. Le rseau tlphonique entier serait alors hors service, pendant tout le temps que durerait lattaque : linstant ou un tlphone serait redmarr manuellement, lattaque le mettrait nouveau hors service de manire quasi immdiate. La localisation de lorigine dune attaque de ce type risquerait dtre longue et difficile. Nous verrons les parades ce type dattaque au paragraphe sur les recommandations.

Dtournement du trafic VoIP

En supposant que le LAN est commut, il est ncessaire de recourir la technique dARP spoofing pour intercepter le trafic associ un tlphone IP. Cette technique consiste envoyer sur le rseau Ethernet des paquets ARP forgs annonant que ladresse MAC possdant ladresse IP cible est celle de notre carte rseau, et non celle de la machine cible relle. Le rsultat est que les paquets IP sont envoys vers notre machine, et non plus vers la machine lgitime. Nous pourrons alors rerouter le trafic reu vers la machine cible, ou bien le faire disparatre. Dans le cas de la VoIP, le but est : - de se faire passer pour le serveur Call Manager, la passerelle voix-donnes VG200 ou un autre tlphone IP distant vis--vis du tlphone IP couter ; - de se faire passer pour le tlphone IP couter vis--vis du Call Manager, de la passerelle VG200 ou du tlphone IP distant. La figure ci-dessous illustre ce mcanisme :

Tlphone IP 1

Pirate

Tlphone IP 2

LAN

Trajet du flux voix sans (vert) et avec (rouge) dtournement de trafic

Dans cette configuration, tout flux reu ou mis par le tlphone IP de la victime passe par lordinateur de lattaquant. Celui-ci peut alors enregistrer la conversation, la modifier la vole ou la renvoyer vers dautres postes. Il est tout fait possible dcouter un numro de tlphone particulier. En fonction de ce numro, on localise le tlphone IP correspondant en se connectant successivement tous les tlphones pour accder son interface web et rcuprer le numro. Une recherche complte sur un rseau de taille importante ne dure que quelques minutes. Une fois le tlphone IP cible identifi (par son adresse IP), on se met en coute et on attend ltablissement dune communication. A ce moment, lARP spoofing est lanc afin dintercepter le flux voix. Ce flux tant rcupr de manire transparente, le processus est indtectable par les utilisateurs espionns. Lassemblage des paquets audio ne pose en gnral pas de problme pour reconstituer la conversation dorigine. Bien souvent, il suffit dadditionner le signal circulant dans un sens et dans lautre pour reconstituer la bande son de la conversation entre les deux protagonistes, quils soient tous deux situs dans lentreprise ou que lun dentre eux seulement sy trouve. Lcoute tlphonique est donc possible large chelle sur un rseau local VoIP. Il suffit de se connecter une prise rseau pour couter lintgralit des communications mises ou reues.

Attaques gnriques
Anonymat
Dans la majorit des changes informatiques, les diffrentes adresses des correspondants (Mails, IPs, FQDN...) ne sont pas des facteurs dterminants, au contraire du contenu des transactions.

Pour la VoIP, les adresses directes sont au premier plan, au mme titre que les numros de tlphones RTC, d'o l'apparition de la fonction numro cach et de la liste rouge ! L'anonymat des correspondants n'est pas forcment simple mettre en uvre car il devient difficile de filtrer le trafic et de cohabiter avec des rgles strictes de filtrage. Les relais SIP permettent d'assurer l'anonymat des utilisateurs, dans une certaine mesure (car limits des plages dadresses la plupart du temps), en se rfrant au Call-ID qui doit tre prsent dans tous les paquets de la mme transactions pour qu'ils soient recevables. En revanche, les dnis de service (par envoi continu de SIP INVITE par exemple) sont alors plus difficiles contrer. L'anonymat ne peut donc pas tre assur dans le cas d'une communication VoIP directe sans proxy entre 2 clients.

Spoofing
Dans un paquet SIP, les identifiants d'une communication lorsqu'elle est tablie sont le Call-ID, et les tags des champs From et To s'ils sont utiliss. Les 3 principaux types de spoofing sur le protocole SIP s'effectuent avec des paquets SIP INVITE, BYE et CANCEL (cf. Figure 5). Le premier est trivial mettre en oeuvre en LAN comme sur Internet en forgeant un paquet SIP INVITE (avec des champs Call-ID, From, To, et Cseq adquats). L'hte distant sonnera mais la conversation ne pourra s'tablir que si le tag du champ To est identique celui retourn par l'appel lorsqu'il accepte l'appel. Malheureusement, de nombreuses implmentations de SIP n'utilisent pas les tags et sont donc vulnrables ces attaques, mme lorsque l'attaquant nest pas en mesure de renifler le trafic. Dans le paquet SIP le champ From est suivi d'un tag. Lors de la rception du SIP INVITE, l'appel ajoutera galement son tag alatoire et toutes les communications suivantes devront inclure ces 2 tags respectifs sur From et To. La probabilit de russite pour falsifier les 2 paquets suivants est quasiment nulle sans coute du trafic si l'ala du Call-ID et des tags sont corrects. Dans le cas d'un LAN o il est possible dcouter le trafic rseau, et donc de rcuprer les Call-IDs, From, To, et les tags s'ils sont utiliss, tous les types d'attaques sont envisageables, du MITM au DoS en passant par une coute passive temps rel des conversations ou une modification la vole des paquets. Seule la voix pourrait alors faire dfaut... !

Et sur Internet ?
Comme nous lavons vu, bon nombre dattaques se font grce de lARP spoofing ou du DNS spoofing. Lattaque ARP nest pas trs raliste sur lInternet et cest pourquoi linterception de la communication se fera plutt en utilisant dautres moyens. La proximit (au sens rseau) du pirate et de la source ou de la destination est un facteur cl pour faciliter lattaque et lcoute. Lattaque la plus commune reste le dni de service (mutualis) lencontre du lien daccs lInternet ou de la passerelle VoIP-PSTN/LAN. Toujours aussi simple mettre en uvre et complexe filtrer et tracer.

En ce moment, de petits malins recherchent activement ce genre de plates-formes VoIP-PSTN connectes lInternet et mal configures : cela leur permet de terminer gratuitement leur communication VoIP via lInternet sur le rseau tlphonique commut dans diffrents pays

"Ajouts" et recommandations scurit

RTP (Real Time Transport Protocol) encode, transporte et dcode la voix. La qualit du flux tant essentielle dans le domaine de la VoIP, tant sur le plan de la vitesse que sur la qualit, le compromis scurit/utilisation est donc essentiel : dbit, qualit de la voix, temps d'tablissement des communications, etc. Certaines solutions classiques ne sont donc pas viables et le meilleur compromis se dtermine au cas par cas selon le nombre de clients, les dbits souhaits, le niveau de scurit requis, la vitesse du mdia utilis, les types de donnes Les contraintes d'intgrit, de confidentialit et d'authenticit ne tenaient pas une place de choix dans les premires solutions et les protocoles clefs ne disposaient d'aucune protection fiable (SIP, RTP, RTCP, ...). Les problmes s'accentuaient avec l'utilisation massive d'UDP pour acclrer les changes, entre autres avec les problmes vidents de spoofing. La VoIP permet de remplacer la totalit des lignes RTC classiques (avec l'utilisation de PABX-IP), et c'est alors que la scurit de l'architecture est rentre dans le cahier des charges. Plusieurs protocoles sont apparus avec notamment les quivalents chiffrs de RTP et RTCP : SRTP et SRTCP [1] (respectivement Secure Real-Time Transport Protocol et Secure Real-Time Transport Control Protocol). Les paquets SRTP se diffrencient des paquets RTP par 3 champs : un champ additionnel pour le type d'algorithme utilis : Authentification tag ; un deuxime contenant diffrentes informations sur la clef : Master Key Identifier (MKI) ; et bien sr un payload chiffr. SRTP et SRTCP ont t dvelopps dans un souci de performances, le but tant de scuriser au maximum les changes moindre cot en minimisant la surcharge lie au chiffrement du payload.
... Synchronization Source (SSRC) identifier Contributing Source (CSRC) identifiers RTP extension PAYLOAD (CHIFFR) MKI Authentification tag

Paquet SRTP

Comme le montre la figure, seul le payload est chiffr dans un paquet SRTP, ce qui ne permet donc pas d'assurer 100% l'intgrit des paquets transmis : l'en-tte du paquet SRTP pourrait tre modifi, voire les champs optionnels MKI ou Authentification tag. Quand SRTP est utilis conjointement avec SIP [2], le droulement chronologique des transactions est le suivant : Appelant : tablissement de la communication (ringing) avec un paquet SIP INVITE. accord du tiers distant avec une rponse 200 (OK). Appel : Appelant : paquet SIP de type ACK pour confirmer la rception du paquet prcdent et tablir la session SIP. Le schma d'tablissement ressemble trangement une ouverture de session TCP... Une fois la communication tablie, et si les deux participants se sont pralablement mis d'accord sur l'algorithme de chiffrement utilis, alors la communication scurise est tablie. Dans le cas contraire, si une ngociation des clefs est ncessaire, un protocole de gestion des clefs s'impose sur le mme principe, par exemple, quIKE pour IPSec. C'est dans ce but que MiKEY [3] (Multimdia Internet Keyring) a t dvelopp : il s'agit d'un protocole rcent ltat de draft et encore trs rarement implment. MiKEY est encapsul dans les paquets SIP et permet d'utiliser : un secret commun (PSK pour Pre-Shared Key), gnralement sous forme de mot de passe ; des protocoles Diffie-Hellman dchange de cls ; une PKI. Cette dernire alternative n'a pas encore t implmente et ses performances globales sont trs controverses lheure actuelle. MiKEY, tout comme SRTP/SRTCP, tente de minimiser les cots et les impacts de la protection. Il doit assurer une scurit optimale des transactions de clefs sans affecter de faon significative la rapidit des changes. Le projet minisip [4], bien qu'encore trop jeune pour tre utilis en production, est l'un des plus avancs dans ce domaine lheure actuelle. Il s'agit d'un client implmentant MiKEY et SRTP avec au choix une authentification PSK ou Diffie-Hellman. Il supporte galement lutilisation de TLS pour scuriser les changes SIP. MiKEY s'encapsule dans SIP avec le champ a=key-mgmy qui permet d'assurer l'authentification qui permettra de faire transiter un flux SRTP par la suite avec des algorithmes et des clefs adquats :
INVITE sip:lolo@rstack.org;user=phone SIP/2.0 From: <sip:mp@domain.org;user=phone>;tag=1017556314 To: <sip:lolo@rstack.org;user=phone> Call-ID: 1664131130@rstack.org CSeq: 101 INVITE Contact: <sip:mp@rstack.org:5060;user=phone;transport=UDP>;expires=900 Content-Type: application/sdp

INVITE sip:lolo@rstack.org;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.0.1:5060 [] m=audio 32945 RTP/AVP 0 97 a=key-mgmt:mikey AQAFgAAAAsAxNbayXB+WngBEH () jPANqgLOmmfPvB+/f56vA== a=rtpmap:0 PCMU/8000/1 a=rtpmap:97 iLBC

Paquet SIP INVITE + MiKEY

En utilisant des relais SIP, lorsque mp@rstack.org cherche contacter lolo@rstack.org, le relais sortant effectue une requte DNS de type SRV pour connatre l'IP du serveur SIP distant, par exemple celle de sip.domaine.org. Cette requte est une cible idale pour un pirate, par exemple via une attaque de spoofing sur le DNS ID ou de cache poisoning[5] afin de renvoyer ladresse dun proxy SIP quil contrle. L'utilisation de DNSSEC pourrait donc tre envisage ce niveau. Comme nous lavons vu, MiKEY repose sur SIP : toute attaque sur ce dernier remet donc en cause la scurit. Il est indispensable de veiller l'intgrit et l'authenticit des paquets SIP. La ncessit pour certains intermdiaires d'accder, voire de modifier des portions de paquets (proxies, registrars, redirecteurs...) rendent la tche dlicate. Minisip propose lutilisation de TLS pour limiter ces risques. La figure 3 reprsente une solution scurise d'architecture de VoIP, mais il en existe bien sr beaucoup d'autres. Minisip permet de tester cette solution dans son intgralit. Pour plus de dtails, vous pouvez consulter [6].

Solution scurise, galement celle retenue par le projet minisip...

La VoIP faisant appel de nombreux processus (SIP, DNS, SRTP, voire SRTCP pour le contrle du flux SRTP : CODECs, timing, etc.), il est indispensable de scuriser chaque tape de la communication. Les nombreuses contraintes imposes par cette

technologie ne facilitent pas la tche : il est aussi parfois ncessaire de traverser des pare-feux, de fonctionner avec des translations d'adresses (NAT), et certains choix sont alors limits.

Tunnel IPsec
Les diffrentes solutions de tunneling prsentent toutes des avantages et des inconvnients pour la VoIP avec ses nombreuses exigences. IPSec, qui travaille sur la couche rseau, permet d'assurer une plus grande fiabilit des informations. Notons par exemple que le problme des en-ttes SRTP modifiables n'est plus un souci ici. Cependant, le cot de cette solution est parfois considrable, tant sur le plan des ressources matrielles que sur le trafic rseau. IKE (Internet Key Exchange) permet alors de remplacer MiKEY et d'assurer la gestion des clefs pour l'ensemble des communications VoIP. La surcharge engendre par IPSec peut tre minimise en configurant le tunnel pour traiter uniquement les flux de voix sur IP (pour des machines/protocoles fixs).Un atout intressant est la possibilit d'utiliser la totalit des soft phones disponibles puisqu'ils n'ont plus grer la scurit des changes (via SRTP/MiKEY...). UDP limite les types de tunnels utilisables, notamment SSL ou SSH, mme s'il reste possible d'utiliser vtun (ou un quivalent) pour faire de l'UDP over TCP, mais les performances deviendraient rapidement mdiocres ! Pour rsumer : les tunnels simplifient le dploiement de la VoIP scurise, mais ne peuvent pas tre employs sur de larges infrastructures ou sur des soft phones peu puissants.

Filtrage rseau
Comme nous lavons vu plus haut, les serveurs de gestion VoIP (surtout installs par dfaut) ont un nombre de ports ouverts par dfaut trs consquent. Il est donc fortement recommand de filtrer les ports accessibles sur les serveurs depuis le rseau des utilisateurs, au niveau des routeurs. Pour cela, il peut tre utile de placer les serveurs sur un sous-rseau ddi. Il convient de lister les services et les ports associs qui doivent tre pris en considration lors de limplmentation dune politique de filtrage sur un rseau VoIP. Certains protocoles sont propritaires (ex : Cisco Skinny) et dautres ne font pas bon mnage avec du filtrage sans tat (non-stateful) ou si des relais applicatifs, qui savent dcoder le protocole, ne sont pas prsents (ALGs Application Level Gateways). Attention, bon nombre de pare-feux se limitent grer louverture de ports en fonction des communications et ninspectent pas les flux (au niveau protocolaire ie. AGLs). De plus cet lment additionnel risque dintroduire un dlai ainsi quune gigue, cest pourquoi ils sont absents dans bien des dploiements.

IDS
Il nest pas trs courant de trouver des outils de dtection dintrusion pour des solutions de voix sur IP. La quantit de faux positifs dus lobservation du flux RTP pourrait tre plus que consquente. Bien quelle permette de dtecter des dnis de service par exemple, la dtection dintrusion se ramne souvent de la dtection de fraude.

Recommandations
Les principales recommandations permettant de se protger contre prcdentes sont les suivantes: les attaques

verrouiller les adresses MAC / adresses IP par port dans les commutateurs traverss par du flux VoIP (cela peut tre relativement simple lorsque les tlphones IP ne se dplacent jamais) ; utiliser IPSec entre les quipements VoIP ; mettre jour les applicatifs et les firmwares des quipements VoIP ; activer le chiffrement des communications VoIP ; utiliser lauthentification des quipements VoIP ; activer au mieux les fonctions de scurit offertes par les quipements de linfrastructure VoIP utilise et qui ne seraient pas actives par dfaut.

En ce qui concerne larchitecture Cisco, la nouvelle version du Call Manager (4.x) introduit des amliorations notables en matire de scurit : signature du code des firmwares et vrification lors du tlchargement sur les IP Phones ; authentification rciproque des IP Phones et des serveurs Call Manager par certificats (un certificat unique est install dorigine dans chaque IP Phone, et une Certificate Trust List ou CTL est utilise) ; authentification de la signalisation (TLS est utilis afin de vrifier que les paquets de signalisation nont pas t modifis) ; chiffrement des communications ( laide du protocole SRTP, qui utilise des cls asymtriques pour chiffrer et authentifier les paquets de donnes audio) ; possibilit de dsactiver certaines fonctionnalits des IP Phones (dsactivation du port de connexion au PC, dsactivation du broadcast de ladresse ARP du tlphone au dmarrage, dsactivation de laccs au VLAN voix, dsactivation de laccs certaines pages de configuration et de statistiques).

Il est donc fortement recommand de migrer une architecture CCM 3.x en version 4.x.

Interception lgale de trafic

Linterception lgale de trafic est une fonction/interface qui est prsente dans la majorit des rseaux tlphoniques (fixes et cellulaires). Pour linstant cette obligation lgale est encore au stade de discussions dans beaucoup de pays et les autorits de rgulations ont des ides assez divergentes : voir [18] et [19]. Une anecdote assez intressante : un nombre consquent de personnes pensent que les agences de renseignement doivent avoir de plus en plus de mal intercepter les communications vu le nombre de mdias et la quantit dinformations. Un commentaire dun haut responsable dune telle agence suggre tout le contraire : en effet, avant , il fallait numriser toutes ces informations pour devoir les traiter, aujourdhui cette tape consquente se fait aux extrmits ce qui leur simplifie largement la tche

Les rseaux de tlphonie classiques

A titre de comparaison, nous allons discuter, sans entrer dans les dtails, de la scurit des rseaux tlphoniques plus classiques.

PSTN/POTS
Le rseau tlphonique filiaire (PSTN/POTS Public Switched Telephone Network/Plain Old Telephone System) transporte voix et donnes. A la diffrence dun rseau VoIP, o les quipements qui grent les communications sont souvent dans le mme rseau et accessibles, cela nest pas le cas dans le RTC (SS7 et le switch par exemple). Il est bien connu que la majorit des tlphones sans fil analogiques peuvent tre couts, mais que la distance est limite quelques centaines de mtres. Les tlphones sans fil du type DECT peuvent chiffrer la communication.

GSM
Le rseau cellulaire (GSM Global System for Mobile Communications), la diffrence dun rseau sans fil de type 802.11, ne permet pas dcouter facilement une communication. En revanche, les communications ne sont chiffres quentre le tlphone de lutilisateur et la station laquelle il est rattach. Ce nest pas un chiffrement de bout en bout entre lappelant et lappel, mais des solutions existent qui emploient par exemple le mode donnes pour transporter de la voix chiffre. Un changement majeur est apparu ces dernires annes avec le dploiement des rseaux de troisime gnration (GPRS et UTMS) : les tlphones ne sont plus des grille-pains mais sont livrs avec un systme dexploitation, Java, une pile TCP/IP, etc De plus, ils sont connects en permanence au rseau et disposent dune adresse IP.

Skype
Skype [7] est un logiciel rcent dvelopp par lquipe de KaZaA qui innove dans la VoIP en proposant un systme reposant sur le principe du P2P (peer-to-peer) via le rseau FastTrack. Les clients sinterrogent pour connatre les rseaux de contacts et ainsi communiquer directement entre eux. Skype ne demande aucune configuration particulire sur les quipements du rseau puisquil ncessite uniquement des connections TCP sortantes vers les ports 80 ou 443, par exemple. Il gre galement les relais HTTP classiques. En mode PC-to-PC, la communication est chiffre en AES (Advanced Encryption Standard) 256 bits entre les clients. Reste dterminer le niveau de confiance que lon peut accorder un algorithme dont on ne matrise pas limplmentation : le code source nest pas disponible ! Les clefs AES sont ngocies en utilisant RSA (1536 bits 2048 bits). SkypeOut, qui permet de contacter le rseau RTC, ne chiffre pas les changes : il aurait pu tre possible cependant de le faire jusquau PABX-IP distant Skype semble offrir une belle perspective la VoIP sur Internet pour un usage personnel. Les contraintes de scurit ont t prises en compte, ce qui est souvent rare

dans ce type de projets. En revanche, lopacit de Skype sur les protocoles quil utilise ou sur son fonctionnement le rend difficile utiliser dans un contexte professionnel, surtout si la confidentialit est au centre des proccupations. Dautres projets, comme SIPshare [18], sintressent par exemple lutilisation de SIP dans un rseau P2P.

VoWLAN
VoWLAN, comme son nom l'indique, n'est rien d'autre que de la VoIP applique sur des rseaux sans fil. Elle offre encore de nouvelles perspectives, notamment avec l'utilisation de PDAs ou de tlphones SIP compatibles WLAN. La qualit peut alors largement dpasser celle des tlphones portables cellulaires et il est possible de couvrir de grandes distances avec plusieurs AP en roaming. Le protocole IAPP (Inter Access Point Protocol) assure la normalisation de cette technologie pour passer d'AP en AP de faon transparente. En revanche, l'utilisation du Wifi pose certains problmes, notamment sur les questions de dbit et de scurit... Des CODECs appropris sont ncessaires (PCM, GSM, ) pour assurer une qualit minimale sur une bande passante rduite, en fonctions de diffrents critres, dont la compression, les dlais (tablissement, latence...), et la qualit (coute, cho, pertes, ...). La scurit du rseau Wifi doit tre assure au pralable (cf. [8]) tout en garantissant un dbit minimum afin d'viter les surcharges lies la scurisation du rseau sans fil (WEP/WPA, IPSec, tunnels, etc.). La VoWLAN prsente tous les enjeux de scurit de la VoIP auxquels viennent s'ajouter ceux des rseaux sans fil.

Conclusion
Nous avons couvert le sujet de la voix sur IP dun point de vue technique et nous pensons quaujourdhui une solution de voix sur IP peut-tre scurise un niveau acceptable. Un projet de voix sur IP est complexe, car il nexiste pas de solution gnrique, et une tude au cas par cas s'impose avant la mise en oeuvre de cette technologie. Le facteur scurit doit tre pris en compte avant mme la phase de conception en posant les bonnes questions aux vendeurs que vous tes en train de slectionner. La convergence des deux rseaux (informatique et tlphonie) change la donne pour la partie voix. Il convient de dfinir clairement quel dpartement est responsable de la scurit des parties et de lensemble, ce qui bien trop souvent nest pas fait.

Rfrences

[1] RFC 3711 : SRTP et SRTCP [2] RFC 3261 : SIP [3] RFC (draft) MiKEY - draft-ietf-msec-mikey-08.txt [4] minisip- Soft phone SIP/MiKEY - http://www.minisip.org [5] Failles intrinsques du protocole DNS - http://betouin.securitylabs.org/Article_DNS_PBT.pdf [6] Secure Mobile Voice over IP - ftp://ftp.it.kth.se/Reports/DEGREE-PROJECTREPORTS/030626-Israel_Abad_Caballero-final-report.pdf [7] Skype - http://www.skype.com [8] La scurit des rseaux 802.11 : quoi de neuf depuis un an ? - MISC n12 [9] Scurisation de Windows NT/2000/XP/2003 http://www.chambet.com/publications/sec-win2k/ [10] Scurisation dIIS - http://www.chambet.com/publications/iis-security/ [11] Vulnrabilits et scurisation des applications Web http://www.chambet.com/publications/sec-web-apps/ [12] RFC 1189 : RTP [13] H.235 : http://www.javvin.com/protocolH235.html [14] H.323 : http://www.h323forum.org/papers/ [15] Scurisation des routeurs et des commutateurs Cisco http://www.miscmag.com/articles/index.php3?page=214 [16] PROTOS SIP - http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/ [17] http://www.voip-info.org/wiki-Asterisk+security [18] CALEA - http://www.fcc.gov/calea/ [19] ETSI and LI - http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-eofetsi.pdf [20] SIPshare - http://www.research.earthlink.net/p2p/