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...
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é
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
(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 (?)
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
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
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
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...
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
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
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
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 !
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
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
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 »
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
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)
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
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)
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.
/ 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é
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...
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
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
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
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)
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
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
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 ?
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
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
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 !
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...
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
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)
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
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 !
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
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
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 !
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)
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
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
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
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
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
0xd012
oracle4engineer
fullkaiten
knih
yoshimi0227
shotatsuge
hayama17
kaminashi
gotok365
syucream
stefafafan
yuya4
iotcomjpadmin
axbom
szymonslowik
csswizardry
rakko
vanstee
tanoku
marktimemedia
moore
skipperchong
427marketing
addyosmani
elsirapls
