JCSI 2008 - Sécurité de la voix sur IP

Transcript

1. research & development Sécurité de la voix sur IP Journée Cryptographie et Sécurité de l'Information 8 février 2008 Laurent BUTTI France Télécom R&D -- Orange Labs
2. p 2 diffusion libre Qui suis-je ? D'où viens-je ?  Expert senior en sécurité à France Télécom R&D / Orange Labs  Sécurité des réseaux  Laboratoire Sécurité des Services et Réseaux  Sites de Caen et Issy-les-Moulineaux  ~ 50 ingénieurs  ~ 10 doctorants  De très nombreux domaines couverts  IPv4, IPv6, 2G/3G, Wi-Fi, WiMAX...  Cryptographie, paiement, PKI...  Audits de sécurité, recherche de vulnérabilités, conseil, normalisation...
3. p 3 diffusion libre A propos de la présentation  La voix sur IP est un sujet très vaste...  Focalisation sur le contexte « opérateur »  Portrait de la sécurité des principales technologies de ToIP  Avec une approche globale de la sécurité
4. p 4 diffusion libre Agenda  Le tournant vers tout-IP et la convergence fixe-mobile  Les principales technologies de convergence fixe-mobile  Description de la technologie Unlicensed Mobile Access (UMA)  Description de la technologie Session Initiation Protocol (SIP)  Principes de sécurité de ces technologies  Conclusions
5. p 5 diffusion libre Quelques chiffres...  Données issues de l'ARCEP  http://www.arcep.fr/index.php?id=9540
6. p 6 diffusion libre Contexte  Recherche de nouveaux usages (et donc de services)  Messagerie unifiée  Messages multimédias  Softphones  Convergence des équipements  PDAs, téléphones, lecteurs multimédias...  Nouveaux acteurs privilégiant les solutions « IP »  Moins coûteuses au déploiement (?)  Moins coûteuses à l'appel (?)  Moins propriétaires (?)  Déjà disponibles, adaptables et le plus souvent avec des licences Libres (?)
7. p 7 diffusion libre Fixed Mobile Convergence (FMC)  Mutualiser les accès et services (fixes et mobiles) sur un même terminal (mobile !)  Messagerie unifiée  Facture unique, numéro unique  De nombreuses opportunités techniques pour les opérateurs  Il est difficile de savoir quelles technologies seront dominantes  Aujourd'hui, un support naturel est le Wi-Fi  Ubiquité de la technologie  Bas coûts
8. p 8 diffusion libre Fixed Mobile Convergence (FMC)  De nombreuses technologies sont possibles  Extension de la couverture radioélectrique GSM / UMTS • PicoCell et FemtoCell  Unlicensed Mobile Access (UMA)  Session Initiation Protocol (SIP)  Technologies propriétaires  Les buts sont (toujours) les mêmes  Apport de nouveaux services (source de revenus)  Réduction des coûts de déploiement et d'exploitation  Extension de la couverture radioélectrique  Unicité du terminal
9. p 9 diffusion libre Fixed Mobile Convergence (FMC)  Next Generation Network (NGN)  A Next Generation Network (NGN) is a packet-based network able to provide services including Telecommunication Services and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. It offers unrestricted access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users. Source : International Telecommunication Union  Quels que soient les supports réseaux  Fixe, mobile et sans-fil  Interconnexions avec le réseau téléphonique standard  Par l'intermédiaire de passerelles
10. p 10 diffusion libre Fixed Mobile Convergence (FMC)  IP Multimedia Subsystem (IMS)  Architecture fonctionnelle pour unifier les modes mobile et Internet  Intégré dans la 3GPP Release 5  Utilisation autant que possible des protocoles IETF • SIP  Le tournant des telcos vers le tout-IP est bien entamé  Reste à bien le négocier...
11. p 11 diffusion libre Fixed Mobile Convergence (FMC)  Premiers tests opérationnels au Danemark (1999)  Offre « Duet » de TDC  Messagerie unifiée pour GSM / {PSTN | ISDN}  Première offre commerciale (2005)  Offre « BT Fusion » : téléphone bi-mode Bluetooth / GSM • Technologie UMA au-dessus de Bluetooth  Démocratisation en cours en France  Après le « Triple-Play », le « Quadruple-Play » ?  Technologie GSM / UMA • Offre UNiK d'Orange  Technologie GSM / Wi-Fi+SIP • Offres TWIN de Neuf Cegetel et FreeBox de Free
12. p 12 diffusion libre Fixed Mobile Convergence (FMC)  De nombreuses contraintes techniques  Besoin de technologies Wi-Fi à basse consommation • « Always-On » pour la téléphonie  Nécessité de réaliser le « handover » inter-technologies • GSM / Wi-Fi+SIP et GSM / UMA  Nécessité d'une qualité voix au moins équivalente au GSM
13. p 13 diffusion libre Autres technologies...  Skype Phone  Première version publique (bêta) en 2003  Appels entre usagers Skype gratuitement  Appels vers lignes téléphoniques fixes et cellulaires pour un coût  GPhone / Android  The Open Handset Alliance, a group of more than 30 technology and mobile companies, is developing Android: the first complete, open, and free mobile platform. Source : Google
14. p 14 diffusion libre La sécurité... Oui, mais à quel prix ?  La sécurité sur la voix sur IP impose des  Contraintes de temps réel  Contraintes de pertes de paquets et de routage IP  Contraintes de ressenti utilisateur (délais d'établissement, gigue...)  Contraintes d'interception légale  Contraintes de législation sur la cryptographie selon les pays  Contraintes de législation sur la disponibilité des appels d'urgence  Contraintes de législation sur la localisation des appels d'urgence  Sécuriser la voix sur IP n'est pas trivial  Ne revient pas (forcément) à sécuriser IP !
15. p 15 diffusion libre Unlicensed Mobile Access  Technologie d'extension des services GSM/GPRS  Aussi appelée Generic Access Network (GAN)  Spécifiée par un groupe d'opérateurs et constructeurs • http://www.umatechnology.org/participants/index.htm  Spécifications initiales en septembre 2004  Encapsulation de certains protocoles GSM/GPRS au-dessus du protocole IP depuis le réseau du client vers le coeur de réseau de l'opérateur  Avantages de la technologie  Utilisation d'une bande de fréquence sans licence  Extension de la couverture radio GSM/GPRS sans coûts d'infrastructure  Potentiellement à coûts plus bas
16. p 16 diffusion libre Unlicensed Mobile Access
17. p 17 diffusion libre Unlicensed Mobile Access Source : UMA Forum
18. p 18 diffusion libre Unlicensed Mobile Access Source : UMA Specifications
19. p 19 diffusion libre Unlicensed Mobile Access  IKEv2 pour l'authentification et la création des SA IPsec  Authentification de l'UMA Network Controller (UNC) par certificat  Authentification de l'utilisateur et du réseau par EAP-SIM/AKA  IPsec entre le terminal et l'UNC  Couche de sécurité indépendante de la couche réseau
20. p 20 diffusion libre Unlicensed Mobile Access  Up CS Domain Signaling Protocol Architecture Source : UMA Specifications
21. p 21 diffusion libre Unlicensed Mobile Access  Up CS Domain Voice Bearer Protocol Architecture Source : UMA Specifications
22. p 22 diffusion libre Unlicensed Mobile Access  Couches de sécurité Source : UMA Specifications
23. p 23 diffusion libre  Authentification Source : UMA Specifications UMA
24. p 24 diffusion libre Unlicensed Mobile Access  La sécurité est assurée à plusieurs niveaux  Sécurité de la couche réseau (e.g. Wi-Fi avec WPA/WPA2)  Optionnelle  Authentification robuste grâce à IKEv2 avec EAP  Authentification de l'UNC par certificat  Authentification de l'utilisateur et du réseau par EAP-SIM/AKA  Confidentialité et intégrité des communications  Grâce à IPsec et des profils de confidentialité robustes (AES et 3DES)  Attention au mode « NULL encryption »
25. p 25 diffusion libre Protocoles « Voice over IP »  Deux grandes familles  Protocoles de signalisation  Protocoles de transport des données (audio et/ou vidéo)  Le protocole de signalisation  Permet l'établissement de la communication (appel, rejet...)  Mise en place de la communication pour le protocole de transport des données
26. p 26 diffusion libre Protocoles « Voice over IP »  H.323 de l'ITU-T  Première version publiée en novembre 1996  Ensemble de protocoles pour l'établissement de sessions audio-vidéo sur un réseau de type paquet  Session Initiation Protocol (SIP) de l'IETF  Premier RFC 2543 (mars 1999)  Révisé en RFC 3261 (juin 2002)  SIP is an application-layer control that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls  Autres  MGCP (IETF), SCCP (a.k.a. Skinny de Cisco), IAX/IAX2 (Asterisk)
27. p 27 diffusion libre H.323 vs. SIP  H.323 est aujourd'hui très déployé  Historiquement le premier disponible  Spécifié par l'ITU-T donc privilégié par les opérateurs historiques  SIP prend le dessus sur les déploiement récents et futurs  Comparaison exhaustive en terme de protocole  http://www.packetizer.com/ipmc/h323_vs_sip/  La suite de la présentation se focalisera uniquement sur SIP
28. p 28 diffusion libre Session Initiation Protocol  Protocole texte basé sur l'UTF-8 (RFC 2279)  Un message SIP est une requête ou une réponse  Format de message SIP generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line  Spécification très proche de HTTP/1.1 (RFC 2616)
29. p 29 diffusion libre Session Initiation Protocol  Exemples de paquets SIP Source : RFC 3261 Requête INVITE Requête REGISTER Source : RFC 3261
30. p 30 diffusion libre Session Initiation Protocol  Architecture Source : RFC 3261
31. p 31 diffusion libre Session Initiation Protocol  Ne pas confondre sécurisation de SIP et sécurisation des flux médias (RTP)  Extrait de la RFC 3261 (chapitre 26)  SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial. Security solutions are needed that are deployable today, without extensive coordination, in a wide variety of environments and usages. In order to meet these diverse needs, several distinct mechanisms applicable to different aspects and usages of SIP will be required.
32. p 32 diffusion libre Session Initiation Protocol  Authentification username / password via « Digest » (RFC 2617)  Challenge – Response avec la fonction de hachage MD5 • Grâce au challenge, pas de précalcul possible lors d'une interception uniquement passive (pas de choix du challenge par l'attaquant) • Grâce au challenge, pas d'attaque par rejeu H(A1) = MD5(username:realm:password) H(A2) = MD5(METHOD:request-URI) response = MD5(H(A1):nonce:H(A2))  Les principes de sécurité « classiques » doivent être respectés  Mot de passe robuste : réduction des risques • Devrait être provisionné par l'opérateur SIP selon sa politique de sécurité
33. p 33 diffusion libre Session Initiation Protocol  Le transport n'assure ni chiffrement ni d'intégrité (UDP)  Susceptibilité d'écoute de la signalisation  Chiffrement et intégrité des en-têtes SIP possible (en théorie)  Grâce à des extensions S/MIME  Grâce au protocole TLS (et passage en TCP)  Compliqué et peu supporté : en pratique très peu utilisé !  Nécessite une PKI...
34. p 34 diffusion libre Real-time Transport Protocol  Protocole de transport de données  Premier RFC 1889 (janvier 1999)  Révisé en RFC 3550 (juillet 2003)  Norme composée de deux protocoles  Real-time Protocol pour le transport de données (RTP)  Real-time Control Protocol pour les informations de contrôle sur le flux (RTCP)  Pas de confidentialité ni d'intégrité des communications
35. p 35 diffusion libre Pile de protocoles IP UDP TCP/UDP SIP SDP RTP Codecs audio Codecs vidéo RTCP
36. p 36 diffusion libre Secure RTP  RFC 3711 (mars 2004)  Apporte  Confidentialité  Authentification des messages  Protection anti-rejeu  En se basant sur du matériel cryptographique déjà disponible  Dérivation de clés de session en fonction d'une clé maître
37. p 37 diffusion libre Secure RTP  Nécessité en premier lieu d'établir une clé maître  Grâce à un protocole tiers (hors SRTP)  Plusieurs protocoles existent  SDES • Session Description Protocol (SDP), Security Descriptions for Media Streams – RFC 4568 (juillet 2006)  MIKEY • Multimedia Internet KEYing – RFC 3830 (août 2004)  ZRTP • Media Path Key Agreement for Secure RTP – draft-zimmermann-avt-zrtp-04 (juillet 2007)  D'autres sont propriétaires
38. p 38 diffusion libre SDES  Nouveaux attributs SIP pour véhiculer les informations de sécurité  Qui seront alors utilisées par SRTP...  Mais ce transport de clé n'est pas protégé  Utilisation de S/MIME ou TLS nécessaire  En pratique, la solution la plus utilisable à court terme  Présente chez plusieurs constructeurs (avec TLS)
39. p 39 diffusion libre MIKEY  Trois modes  Secret partagé (PSK)  Clé publique  Diffie-Hellman authentifié  Le premier mode est « partagé » et « fixe »  N'apporte pas un niveau de sécurité suffisant • Toute compromission du secret met en péril la sécurité  Les deux derniers nécessitent une PKI  Très lourd en pratique pour déploiement
40. p 40 diffusion libre ZRTP  Media Path Key Agreement for Secure RTP (draft)  http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-04  Objectif de simplicité et de décorrélation des messages SIP  Négociation des clés pour SRTP  Diffie-Hellman  Pas besoin d'information d'authentification préalable • Pas de secret partagé, pas de PKI  Mécanisme anti-MitM  Repose sur un Short Authentication String (SAS)  Calcul cryptographique réalisé sur les deux parties  Vérification orale par les utilisateurs de ce SAS
41. p 41 diffusion libre Pile de protocoles IP UDP SIP SDES SDP MIKEY UDP RTP RTCP ZRTP SRTP SRTCP TCP TLS
42. p 42 diffusion libre En résumé sur les protocoles VoIP  Au niveau technique  La protection de la signalisation est réalisable aujourd'hui  La protection des communications est réalisable selon les méthodes de négociation des clés  Au niveau pratique, de nombreuses contraintes  Support par les constructeurs  Coûts de déploiement et de maintenance  Impacts sur les performances ?  Développements et architectures complexes (PKI)  Interception légale, quid du chiffrement ?
43. p 43 diffusion libre PSTN vs. VoIP  Dans le cas d'une communication VoIP au-dessus du Wi-Fi dans sa zone (à la maison)  Les communications sur le Wi-Fi sont protégées par les mécanismes de sécurité WPA/WPA2 • Chiffrement robuste (TKIP/CCMP), authentification robuste si la passphrase est robuste  Ensuite la confidentialité est équivalente au RTC • VoIP chiffrée rajouterait une étape au-dessus de celle actuelle...  Les principales différences résident dans  La protection de l'infrastructure VoIP qui est plus « exposée »  La sécurité des équipements VoIP
44. p 44 diffusion libre De la complexité des standards...  Une brève analyse quantitative...  Working Group SIP (http://tools.ietf.org/wg/sip/)  RFC 3261 : 265 pages  48 RFCs, 29 drafts actifs, 38 drafts non-WG, 29 drafts expirés !!!  Mais il existe aussi d'autres WGs : p2psip, siping
45. p 45 diffusion libre Un petit constat...  Asterisk – PBX IP Open Source  Mot clé « asterisk » sur http://cve.mitre.org  38 entrées très variées sur Asterisk (et certains dérivés) • Buffer overflows • Format strings • Directory traversals • SQL injections • XSS  Développer sans erreurs est difficile surtout si c'est complexe  Plan, Do, Check, Act !
46. p 46 diffusion libre Failles logicielles  Toutes connues dans l'état de l'art  Suffirait-il d'appliquer des règles et de s'y tenir ?  Oui : code développé par des connaisseurs, code revu par des experts externes, tests de robustesse fonctionnelle et d'injection de faute... • DJBDNS, OpenBSD (même si parfois...), Postfix...  Mais : prend du temps et des compétences, i.e. ça coûte cher !  Les problèmes classiques resurgissent toujours  Les solutions techniques sont toujours les mêmes  Les processus de gestion des vulnérabilités diffèrent • Contacts avec le constructeur, rapidité des corrections, disclosure...
47. p 47 diffusion libre Failles dans les parsers  Tout ce qui analyse de la VoIP (SIP, RTP...)  Pare-feux, IDS/IPS, softphones, hardphones, proxies, registrars, analyseurs réseau...  Les protocoles sont complexes et donc difficiles à implanter  Nombreuses failles parfois très difficiles à découvrir • Bien entendu, les conditions qui déclenchent la faille ne sont pas « normales »  Voir http://cve.mitre.org  Beaucoup de failles sur les « INVITE » • Car c'est l'état « accessible »  Encore peu de failles découvertes dans les états supérieurs • Complexité du protocole au niveau de la gestion des états
48. p 48 diffusion libre Exemple d'une vulnérabilité SIP  CVE-2007-2293  Multiple stack-based buffer overflows in the process_sdp function in chan_sip.c of the SIP channel T.38 SDP parser in Asterisk before 1.4.3 allow remote attackers to execute arbitrary code via a long (1) T38FaxRateManagement or (2) T38FaxUdpEC SDP parameter in an SIP message, as demonstrated using SIP INVITE. else if ((sscanf(a, "T38FaxRateManagement:%s", s) == 1)) { found = 1; ... else if ((sscanf(a, "T38FaxRateManagement:%s", s) == 1)) { found = 1;  Vulnérabilité découverte en mars 2007, publiée en juillet 2007  Mais était présente depuis très longtemps • D'où l'intérêt de faire de la recherche en vulnérabilités : en découvrir le plus possible pour les rendre publiques (i.e. les corriger)
49. p 49 diffusion libre Recherche de vulnérabilités  Reverse engineering  Nécessite des compétences pointues et beaucoup de temps  Certains environnements sont difficiles (embarqué, pas de symboles...)  Audit de code source  Nécessite d'avoir le code source  Peut-être aussi très complexe  Injecter des données et étudier le comportement de l'application  Fonctionne aussi bien en boite noire qu'en boite blanche  Tests facilement rejouables à volonté  Permet de se focaliser sur les tests les plus pertinents
50. p 50 diffusion libre Recherche de vulnérabilités  Vulnérabilité découverte ET publiée = 1 vulnérabilité de moins !  Processus d'amélioration !  Ne pas oublier le business autour des vulnérabilités  Vulnérabilité découverte par une personne externe • Revente de la vulnérabilité à des personnes malveillantes pour exploitation • Revente de la vulnérabilité à une société tierce pour communication avec l'éditeur de logiciel (intermédiaire) • Communication avec l'éditeur de logiciel pour correction et publication commune • La garder pour soi  D'où l'intérêt de faire de la recherche en vulnérabilités  Trouver les failles avant que les personnes malveillantes y aient accès !
51. p 51 diffusion libre Fuzzing  Fuzzing : terme difficilement traduisible !  Fuzz testing or fuzzing is a software testing technique that provides random data ("fuzz") to the inputs of a program. If the program fails (for example, by crashing, or by failing built-in code assertions), the defects can be noted. Source : Wikipedia.org  Fuzz testing or Fuzzing is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion. Source : OWASP  Technique de tests logiciels visant à découvrir des erreurs d'implantation logicielle  Le domaine existe depuis 1989 (Barton Miller) mais s'est largement démocratisé depuis 3 ans
52. p 52 diffusion libre Fuzzing  Le fuzzing a une approche meilleur rapport qualité / prix  Le fuzzing a tendance à découvrir des erreurs d'implantation logicielle simples  Le fuzzing doit être suffisamment « intelligent » pour chercher aux endroits les plus pertinents  Pour une efficacité accrue il faut connaître l'implantation logicielle à tester • Complètement aléatoire => moins de chances de succès  Attention ! Le fuzzing n'est pas une assurance qualité !  Ne permet pas d'assurer l'absence d'erreurs d'implantation
53. p 53 diffusion libre Fuzzing  De nombreux fuzzers existent  Certains sont génériques (frameworks) • Sulley Fuzzing Framework, SPIKE, PeachFuzz, ...  La plupart sont spécialisés  Le fuzzing a connu, connaît et connaîtra de grands succès  Les premières failles dans les drivers 802.11  La plupart des failles dans les piles SIP  Les failles sur le parsing Javascript des navigateurs (jsfunfuzz)  Peut être très efficace avec quelque chose de très basique !  Selon les cas, un simple fuzzer de 10 lignes peut trouver des vulnérabilités critiques si l'on cherche au bon endroit !
54. p 54 diffusion libre Fuzzing VoIP (SIP, RTP, ...)  Le protocole SIP est propice aux erreurs d'implantation logicielle  Très nombreuses extensions  Protocole texte avec tout ce que ça implique • strcpy(), sscanf(), sprintf()...  Manque plus qu'à les découvrir !  En fonction des spécifications il faut réaliser des outils de fuzzing SIP • Erreurs de parsing (tests des fonctions de parsing des différentes options SIP) • Erreurs protocolaires (tests de la machine à état) • Robustesse (flots de requêtes)
55. p 55 diffusion libre Fuzzing VoIP (SIP, RTP, ...)  Malgré tout, un fuzzer VoIP complet est complexe à développer  Définition de la campagne de tests  Gestion des états  Instrumentation du client VoIP (passage des appels) pour fuzzing client  Test de validité de fonctionnement (détection des bugs)  Aussi bien sur SIP (et ses extensions) que sur RTP (et les codecs)  Ne pas oublier qu'il faut analyser les dysfonctionnements !  Très coûteux en temps et compétences
56. p 56 diffusion libre En bref, changement radical...  Le monde de l'Internet change la donne  Disponibilité d'outils d'attaques sur Internet • Contrairement au RTC  Compétences plus facilement accessibles • Les attaques sont souvent publiées et disponibles  Disponibilité des piles SIP et autres • Contrairement au GSM (quoique... cf. GNUradio)  Terminaux ouverts • Contrairement au terminaux mobiles classiques  Le challenge est donc de maintenir un bon niveau de sécurité  Lors du passage d'un monde fermé à un monde ouvert
57. p 57 diffusion libre Principe de précaution  Amélioration de la sécurité de nos Offres VoIP  Développement de compétences sur les protocoles VoIP  Développement d'architectures de tests logiciels • Fonctionnels • Protocolaires • Par injection de fautes (fuzzing)  Audits de sécurité d'infrastructures VoIP
58. p 58 diffusion libre Anecdote...  Ouragan Katrina (2005)  De nombreuses infrastructures ont été coupées • Notamment le Government Emergency Telecommunications Service (GETS)  Quelques infrastructures Internet ont été disponibles  Dont des réseaux hot spots Wi-Fi • « T-Mobile Provides Free Wifi to Hurricane Katrina’s Victims »  Possibilité de communications (en VoIP !)  La robustesse des infrastructures Internet est un atout majeur pour la VoIP
59. p 59 diffusion libre Conclusions  Le passage à un monde ouvert rend plus difficile la sécurisation globale de l'infrastructure opérateur  La sécurisation de SIP/RTP est possible mais complexe  La technologie UMA permet à l'opérateur de migrer avec le moins de risques vers la convergence  Mais la VoIP promet de nouveaux usages et services ainsi qu'une flexibilité certaine (rajout de nouveaux services aisé)  La conception d'une architecture de VoIP doit prendre en compte les éléments de sécurité classiques ET spécifiques VoIP
60. p 60 diffusion libre Remerciements  Franck Veysset et Michaël Sanchez
61. p 61 diffusion libre Références  Nicolas Dubee, SSTIC 2007, « La VoIP, une opportunité pour la sécurité ? »