B5 D4 CD 01

Scurit des architectures de e e Convergence Fixe-Mobile
Laurent Butti laurent.butti(@)orange-ftgroup.com

Orange Labs Laboratoire Security and Trusted Transactions 38-40 Rue du Gnral Leclerc e e 92794 Issy-les-Moulineaux Cedex 9 - France
Rsum Le monde de la tlphonie est en pleine rvolution et la Convergence Fixe-Mobile e e ee e (FMC) appara aujourdhui incontournable. Cette profonde mutation est entreprise par de t nombreux acteurs du monde des tlcommunications et repose notamment sur des normes ee spcies par le 3rd Generation Partnership Project (3GPP). Les mcanismes de scurit e e e e e prsents dans ces normes sont pour la plupart issus de protocoles normaliss par lInternet e e Engineering Task Force (IETF) tels que Internet Key Exchange v2 (IKEv2) [1], Extensible Authentication Protocol (EAP) [2], IPsec [3] et Transport Layer Security (TLS) [4]. Ces briques sont la cl de vo te de lacc`s des utilisateurs ` ces architectures. Laudit de ces e u e a architectures est ncessaire et passe par le dveloppement doutils de fuzzing permettant e e lvaluation de la qualit des implmentations1 . Le dveloppement de ces outils nous a permis de e e e e dcouvrir certaines vulnrabilits dans des implmentations propritaires et donc de contribuer e e e e e a lamlioration de la scurit des architectures bases sur ces implmentations. ` e e e e e
Introduction
Les rseaux radiolectriques destins aux communications personnelles et profese e e sionnelles sont en perptuelle mutation. Cest avec la commercialisation de Radiocom e 2000 [6] ` la n des annes 80 que les premi`res notions de tlphonie cellulaire2 a e e ee sont apparues. Au dbut des annes 90, la technologie Global System for Mobile e e Communications (GSM) sest rapidement impose3 et compte aujourdhui plus de e trois milliards dutilisateurs a travers le monde. Les technologies cellulaires ont ensuite ` rajout du transport de donnes et ont largement volu grce a des normes comme e e e e a ` le General Packet Radio Service (GPRS) et lUniversal Mobile Telecommunications System (UMTS). En parall`le de cette volution des technologies radiolectriques ` e e e a courte distance de type Bluetooth [9] ou Wi-Fi [10] rajoutent une nouvelle saveur ` a
1
Ladoption du terme implmenter par la commission gnrale de terminologie et de nologie a t e e e e e e publie au journal ociel le 20 avril 2007 [5] (source : Wikipedia). e le terme provient du fait que lmission est ralise sur une zone de couverture bien dlimite appele une e e e e e e cellule. bien quentre temps nous avions cherch notre tribu avec Tatoo [7] et Bi-Bop [8]. e
230
Scurit des architectures de Convergence Fixe-Mobile e e
la gamme des technologies dacc`s radiolectriques. Nul doute quelles ne seront pas e e les derni`res avec larrive des WiMAX [11,12], Long Term Evolution (LTE) [13] et e e consorts4 . . . Vint enn le dsir de rassembler, de trouver une technologie dacc`s commune, e e mais indpendante de la couche sous-jacente, ou tout du moins dtre capable de e e se mouvoir entre les technologies pour bncier en permanence du meilleur acc`s e e e possible pour tous les services, que ce soit pour de la voix ou des donnes. Le terme e Convergence Fixe-Mobile fait partie de cette mouvance, de cette volont de fdrer e e e les technologies dacc`s. e Apr`s une br`ve introduction aux rseaux cellulaires et les problmatiques de e e e e scurit intrins`ques ` ces derniers, larticle prsentera les principales possibilits e e e a e e oertes aux oprateurs de tlphonie mobile (et aux nouveaux acteurs) pour dployer e ee e des architectures de Convergence Fixe-Mobile. Nous prsenterons direntes architece e tures contribuant a la Convergence Fixe-Mobile que sont lUnlicensed Mobile Access ` (UMA), lInterworking Wireless Local Area Network (I-WLAN) et lIP Multimedia Subsystem (IMS). Ces architectures sont pour la plupart normalises par le 3rd Gene eration Partnership Project (3GPP) qui dnit alors (entre autres) les mcanismes e e de scurit mis en uvre dans ces rseaux. Nous dtaillerons dans un premier temps e e e e ces mcanismes de scurit et le niveau de scurit attendu de ces derniers. e e e e e Enn, nous aborderons les eorts raliss dans notre entit pour valuer la scurit e e e e e e de ces nouvelles architectures aussi bien sur le plan fonctionnel quau niveau des implmentations logicielles. En particulier, nous dtaillerons les outils de recherche e e de vulnrabilit par fuzzing qui ont t dvelopps dans ce but ainsi que quelques e e ee e e rsultats pratiques. e Note 1. Lensemble Convergence Fixe-Mobile pourrait sappeler aussi Convergence Fixe-Mobile-Internet. Note 2. Le terme anglais fuzzing est dicilement traduisible, nous lutiliserons souvent en tant que mot et verbe.
Introduction aux architectures de Convergence Fixe-Mobile
Le succ`s de la tlphonie mobile nest plus ` dmontrer comme en tmoignent e ee a e e 5 des taux de pntration de march suprieurs ` 100% dans certains pays comme e e e e a
4
beaucoup de candidats (comme par exemple iBurst normalis sous lIEEE 802.20) mais peu dlus. Et e e dire que des publications parlent aussi de dbits de plus de 10Gb/s [14]. . . e Le taux de pntration est obtenu en divisant le nombre total de clients ou le nombre de clients actifs par e e la population considre (source : ARCEP). e e
L. Butti
231
Singapour. En France, selon les chires de lARCEP, un chire de plus de 90% est avanc [15]. Cette volution a t rapide et mondiale comme latteste une publication e e ee rcente de lUnion Internationale des Tlcommunications (ITU) [16]. Par consquent, e ee e lutilisateur se retrouve dans une situation tr`s courante qui est de disposer de e plusieurs numros de tlphone, de plusieurs terminaux (mobiles ou xes) et de e ee plusieurs abonnements. De la mme mani`re nous assistons a une multiplication des e e ` possibilits de communication que ce soit par de la messagerie classique ou par des e outils de prsence comme la messagerie instantane. Rajoutons encore une connexion e e a Internet par la ligne xe (xDSL, bre. . .) et il alors comprhensible que lutilisateur ` e nal ait un souhait de convergence, ` savoir de disposer dune solution capable de a fdrer plusieurs rseaux an daccder ` ses services de mani`re transparente et e e e e a e ergonomique. Bien entendu, les oprateurs connaissent ces besoins et voient dans e la Convergence Fixe-Mobile un moyen ecace dagrger de nombreux abonnements e historiquement dirents (voix xe, voix cellulaire, donnes) an de proposer le e e meilleur service. Cest en partant de ce constat que les technologies de Convergence Fixe-Mobile sont apparues, elles ont pour but dapporter la connexion aux services oprateurs de mani`re unie ` lutilisateur nal. e e e a
Fig. 1. Taux de pntration de la tlphonie mobile au niveau mondial (source : ITU) e e ee Les notions de convergence ne sont pas nouvelles et sont originellement apparues au Danemark lors de la premi`re ore commerciale dunication de la messagerie e (mobile et xe) en 1997. Aujourdhui la mouvance se concentre sur la rutilisation des e rseaux radiolectriques locaux Wi-Fi qui se sont largement dmocratiss aussi bien e e e e dans le monde rsidentiel que le monde entreprise. Certaines bandes de frquence e e 6 des rseaux Wi-Fi peuvent tre non licencies comme la bande 2,4 GHz qui est e e e
6
bien que soumises a approbation par lARCEP en France. `
232
utilise dans les normes IEEE 802.11b, IEEE 802.11g et IEEE 802.11n. Des ores de e convergence apparaissent donc et permettent la rutilisation de ces rseaux Wi-Fi e e en tant que nouveau moyen dacc`s pour de la tlphonie mobile. Les technologies e ee utilises ensuite pour le transport de la voix peuvent tre tr`s direntes entre elles, e e e e mais les impratifs restent les mmes : arriver ` fdrer les acc`s, orir une mme e e a e e e e qualit de service (qualit ressentie) et la possibilit du passage dun rseau a lautre e e e e ` de mani`re non perceptible par lutilisateur (aussi appel seamless handover ). e e Cela permet aussi en pratique dans le cadre dun terminal bi-mode GSM/Wi-Fi daugmenter ostensiblement la couverture rseau dans des zones parfois diciles ` e a couvrir avec ecacit (comme lintrieur des btiments). e e a
Aperu de la scurit des architectures GSM c e e
Cette partie na pas pour but dtre exhaustive a la vue de labondante littrature e ` e sur le sujet. Toutefois, il est bon de rappeler certaines problmatiques de scurit qui e e e ont t prises en compte dans une norme qui a maintenant presque vingt ans. ee 3.1 Authentication
Lauthentication 2G (utilise dans les rseaux GSM) est base sur un protocole e e e de type challenge response ainsi que sur des algorithmes de cryptographie a cl secr`te. ` e e La cl secr`te se retrouve ` la fois stocke dans le rseau de loprateur7 et ct e e a e e e oe utilisateur8 dans un Subscriber Identity Module (SIM) qui est une carte ` puce. Il a faut considrer que lenvironnement de lutilisateur nal nest pas un environnement e de conance donc la cl secr`te est stocke dans une zone dont le but est de rsister a e e e e ` 9 lextraction . Cest une proprit importante qui a jou un rle majeur dans le niveau ee e o de scurit et donc la prennit de ces architectures. e e e e Une autre remarque importante relative ` lauthentication GSM est que seule a une authentication du client est ralise : ceci laisse en thorie la porte ouverte10 e e e ` des attaques de lhomme du milieu. Cependant, de part le co t lev des staa u e e tions de base GSM (Base Transceiver Station, BTS) ou de solutions commerciales ddis ` linterception, lattaque nest possible quavec des moyens nanciers assez e e a consquents11 . e
7 8 9 10 11
normalement peu enclin aux attaques du moins depuis lextrieur. e qui lui est bien plus propice aux attaques. que ce soit par des moyens logiques ou physiques. en particulier pour de la voie radiolectrique. e bien entendu, tout est relatif. . .
L. Butti 3.2 Condentialit des communications e
233
En plus du mode pas de chirement A5/0, trois autres modes de chirement existent et prsentent des niveaux de robustesse bien dirents12 . Le mode A5/2 e e prsente des faiblesses intrins`ques13 et napporte pas de scurit en soit, par contre, e e e e le mode A5/1 est bien plus robuste. Cependant, ce dernier est tout ` fait accessible a pour peu que lattaquant ait ` sa disposition susamment de moyens nanciers. a Les premi`res publications thoriques en ciphertext-only datent de 2003 [17] et les e e premi`res publications dimplmentations de ces attaques datent de 2008 [18]. Enn, e e le mode A5/3 [19] est quant ` lui une adaptation de KASUMI [20] qui est utilis a e dans les communications mobiles de troisi`me gnration. Ce mode est de plus en e e e plus souvent support dans les implmentations des tlphones GSM. e e ee 3.3 Des initiatives pratiques
Larrive des Software Radio comme le Universal Software Radio Peripheral [21] e et les initiatives associes comme GNUradio [22] laissent entrebiller la porte ` des e a a attaques sur le chirement ralisables avec des moyens nanciers acceptables. Ces e outils permettent de traiter la couche physique au niveau logiciel et donc de pouvoir (en thorie) dmoduler les signaux radiolectriques. Bien entendu, cela ncessite un e e e e travail considrable et des connaissances pointues en traitement du signal mais il faut e aussi matrialiser toutes les couches suprieures (et machines a tat arentes) en se e e è e basant sur les normes GSM qui sont (heureusement) publiques.
Fig. 2. Ettus USRP2 (source : Ettus Research LLC Bas sur ce type de matriel, un nouveau projet est n rcemment, le projet e e e e OpenBTS [23,24], qui propose de matrialiser linterface Um [25] qui est linterface e
12
13
en pratique, le mode A5/2 est une version export destine aux pays autres que lEurope et les e Etats-Unis. lire volontaires.
234
radio entre le mobile (Mobile Station, MS) et la station de base GSM. Nul doute que toutes ces initiatives sont voues ` se dmocratiser dans un futur proche. e a e
3.4
Conclusions
Malgr certaines faiblesses universellement reconnues, les architectures GSM nont e pas t aectes par le potentiel de fraude. La technologie est reconnue comme able ee e et est considre de conance par ses utilisateurs. Ce standard est toujours largement ee utilis a travers le monde ce qui est un rel succ`s pour une technologie dune vingtaine e` e e dannes. e
Exigences de scurit e e
Nous prsentons ici quelques exigences de scurit dans le dploiement de technoloe e e e gies dacc`s oprateur. Ces exigences permettront au lecteur de prendre conscience e e des dicults auxquelles font face les oprateurs an de maintenir un service optimum e e en fonction de lhostilit de lenvironnement. Bien entendu, ces exigences de scurit e e e peuvent tre remplies par une ou un ensemble de fonctionnalits. e e Les exigences peuvent tre fonctionnelles comme par exemple : e protection de lidentit des utilisateurs, e protection des communications utilisateurs, garantie de lacc`s au rseau si couverture, e e garantie de lacc`s aux appels durgence, e garantie dune facturation able, garantie de la protection des donnes oprateurs. e e Et (en partie) assures par des mesures techniques : e protection de la signalisation, protection du transport des donnes, e authentication des utilisateurs et du rseau de loprateur, e e rsistance des quipements de loprateur dposs dans des environnements e e e e e physiques non srs u Les lments ci-dessus ne sont pas exhaustifs, le lecteur intress pourra se rfrer ee e e ee au standard 3GPP TS 33.102 [26] pour une vision ` la fois plus compl`te et plus a e prcise. e
L. Butti
235
Architectures de Convergence Fixe-Mobile
Nous prsentons ici les direntes architectures de Convergence Fixe-Mobile en e e se focalisant sur les mcanismes de scurit prsents. Nous verrons que des ides et e e e e e briques communes se dgagent sur lesquelles nous pourrons alors nous focaliser. e 5.1 Unlicensed Mobile Access
Les spcications UMA ont t initialement dveloppes par un groupe doprateurs e ee e e e et de constructeurs, ces premi`res spcications sont apparues en septembre 2004. e e Ensuite, ces spcications ont t intgres dans un groupe de travail du 3GPP en e ee e e tant que Generic Access to A/Gb interfaces . En avril 2005, des spcications plus e avances ont t publies sous la dnomination Generic Access Network (GAN) . e ee e e Cet acronyme souvent utilis en normalisation reprsente donc la technologie UMA. e e Fin 2007, la norme a encore volu pour intgrer le support des interfaces 3G qui peut e e e alors tre utilis que ce soit en tant que terminal nal (lutilisateur) ou point dacc`s e e e (extension de couverture GSM/UMTS aussi appele FemtoCell), ces fonctionnalits e e sont dcrites dans la release 8 de GAN. e Les spcications originelles UMA couvraient les besoins de handover entre e les technologies GSM et Wi-Fi/Bluetooth. Le but du jeu tait de pouvoir raliser e e du seamless handover entre ces direntes technologies tout en maintenant un e niveau de scurit au moins quivalent14 . Nous avons donc aaire ` des terminaux e e e a bi-mode GSM/Wi-Fi qui pourront recevoir/tablir des appels tlphoniques soit par le e ee rseau 2G directement (GSM) soit en passant par le rseau Wi-Fi (tout en terminant e e dans le rseau 2G). Il est donc ncessaire davoir une infrastructure qui permette e e linterconnexion entre le monde Internet et le monde 2G, ce que propose UMA. En ce qui concerne le transport des donnes autres que la voix, le protocole UMA dans sa e version initiale est capable de transporter des communications vers le coeur de rseau e GPRS. De rcentes volutions au 3GPP int`grent aussi les aspects 3G, la norme est e e e alors appele UMA-3G. e Sur le plan scurit, la norme UMA repose sur le protocole IKEv2 et les protocoles e e dauthentication EAP-SIM ou EAP-AKA pour authentier les utilisateurs et le rseau . En eet, le rseau est compos de plusieurs lments intressants ` e e e ee e a authentier : le rseau coeur de loprateur (reprsent par le couple Home Locae e e e tion Register, HLR, et lAuthentication Center, AuC) et la passerelle de scurit e e frontale IKEv2 (Security Gateway, SeGW). Ensuite, grce aux associations de scurit a e e pralablement ngocies par IKEv2, une session IPsec permet alors dassurer la e e e
14
par rapport aux attaques pratiques.
236
Fig. 3. Architecture Unlicensed Mobile Access (source : UMA Forum)
Fig. 4. Architecture Generic Access Network (source : 3GPP)
L. Butti
237
scurit des communications transmises entre le terminal UMA et cette passerelle. Les e e communications UMA pourront alors transiter de mani`re sre entre le terminal UMA e u et un quipement situ derri`re15 la passerelle IKEv2, lUMA Network Controller e e e (UNC). La signalisation et les communications GSM/GPRS sont alors transportes e (ou gres) via le protocole UMA a travers lUNC vers le coeur de rseau GSM/GPRS ee ` e de loprateur. e Larticle ntant pas ddi sur la scurit dUMA, mais sur la scurit de certaines e e e e e e e briques communes a toutes les technologies de Convergence Fixe-Mobile, nous invitons ` le lecteur a consulter les articles Convergence Fixe-Mobile : UMA (Unlicensed Mobile ` Access) sur le devant de la sc`ne ? [27] et Implications of Unlicensed Mobile Access e (UMA) for GSM security [28] pour comprendre les principaux impacts (sur le plan scurit) a retenir sur les problmatiques de lintroduction de la technologie UMA. e e ` e
Fig. 5. Historique UMA (source : UMA Forum)
5.2
Interworking-WLAN
Les aspects inter-fonctionnement avec les rseaux WLAN ont t intgrs a partir e ee e e ` de la 3GPP release 6 publie en 2004. Lutilisation des protocoles dauthentication e EAP-SIM et EAP-AKA est ncessaire dans les environnements orients 3GPP qui e e sont destins au monde oprateur. Les dtails de larchitecture sont dcrits dans le e e e e standard 3GPP TS 23.234 [29]. Pour plus de prcisions, le lecteur intress pourra se rfrer ` la description e e e ee a des fonctionnalits scurit supportes dans I-WLAN via le standard 3GPP TS e e e e 33.234 [30].
15
au niveau fonctionnel, car physiquement un mme quipement peut faire oce de passerelle de scurit e e e e IKEv2 et de contrleur UMA. o
238
Fig. 6. Architecture Interworking-WLAN (source : 3GPP) 5.3 IP Multimedia Subsystem
La technologie IMS est originellement issue dun forum dindustriels cre en ee 1999 qui avait pour but de raliser la convergence de services mobiles/laires voix e et multimdia. Leurs travaux ont ensuite t repris par le 3GPP et intgrs dans la e ee e e release 5 publie en 2002 lorsque le protocole Session Initiation Protocol (SIP) [31] a e t rajout. Ce protocole joue un rle cl dans IMS car il permet la signalisation des ee e o e sessions multimdia. Un des principes de larchitecture IMS est de sparer la couche e e transport de la couche des services, et dutiliser la couche de transport pour des fonctions de contrle, de signalisation et de qualit de service associe a lapplication o e e ` dsire. Le but de lIMS est de fournir une infrastructure unique pour tous les services e e multimdia quels que soient les rseaux dacc`s. e e e Par rapport aux architectures UMA et I-WLAN, larchitecture IMS se distingue par le rle de reprsentation de la couche haute des architectures dacc`s qui seront o e e dployes. e e Sur les aspects scurit, IMS repose a la fois sur la scurit des couches dacc`s et e e ` e e e des mcanismes de scurit prsents pour scuriser les transactions SIP et le transport e e e e e mdia via RTP. Dans cet article, nous naborderons pas ces problmatiques et nous e e traiterons uniquement la partie acc`s. e 5.4 Autres alternatives
Dautres technologies peuvent contribuer ou se rattacher a la famille des architec` tures de Convergence Fixe-Mobile. Nous les citons dans cet article pour convaincre
L. Butti
239
Fig. 7. Architecture IP Multimedia Subsystem (source : 3GPP)
240
le lecteur que la multiplication des acc`s rend le monde des tlcommunications en e ee pleine eervescence. FemtoCell Cette technologie permet dapporter de la couverture de 2G/3G dans des petites zones diciles ` couvrir (ou non couvertes) en particulier ` lintrieur a a e de btiments ou en sous-sols. Bien entendu le concept est extensible ` volont a a e et il est possible dtendre des rseaux GPRS, WiMAX ou autres. . . Tout nest e e quune question de dnomination. Une forte contrainte en scurit est de pouvoir e e e rattacher cet quipement au rseau coeur de loprateur mais depuis un rseau e e e e considr comme ntant pas de conance (car prsent dans des milieux rsidentiels ee e e e ou entreprise). Certes lors des dploiements des cellules 2G/3G les bornes pouvaient e tre attaques physiquement mais dans le cadre des FemtoCell cela est tout de e e mme bien plus facile car lquipement est facilement accessible physiquement (car e e localise chez le client). e Sur le plan scurit, les solutions de raccordement de la FemtoCell au coeur de e e rseau de loprateur peuvent tre multiples. Cela peut aller de la simple authenticae e e tion par secret partag avec le protocole IKEv1 ` lutilisation du protocole IKEv2 e a avec une authentication EAP-SIM ou EAP-AKA (et donc utilisation de crdences e de type SIM ou USIM). Bien entendu, la FemtoCell a en pratique un acc`s rseau IP e e vers une passerelle de loprateur an de sy rattacher. e Nous retrouvons ici toutes les problmatiques classiques en scurit syst`me e e e e lorsque lquipement est positionn dans un endroit non cloisonn physiquement. Il e e e faut donc sassurer quil nest pas possible de rcuprer facilement une version en e e clair du rmware ou dautres informations sensibles contenues dans cet quipement, e typiquement lorsque cela est le cas, les crdences dauthentication. e
La cl de vo te de la scurit de ces architectures : lacc`s e u e e e
Ces architectures mettent en jeu de nombreux protocoles et cet article na pas la prtention de tous les analyser en profondeur sachant que la littrature est partice e uli`rement abondante sur la plupart des protocoles mis en jeu (Wi-Fi, SIP. . .). e La majorit de ces architectures reposent sur un lment essentiel et commun : la e ee technologie dacc`s. En eet, elles sont indpendantes des mcanismes de scurit de e e e e e la couche liaison et reposent sur le protocole IKEv2 aid du protocole de transport e dauthentication EAP. Le protocole IKEv2 a pour but (dans le cadre de ces architectures) de transporter de mani`re sre les changes EAP et de crer des associations e u e e de scurit (Security Association, SA) qui seront utilises pour tablir un tunnel IPsec e e e e entre le client et la passerelle de scurit appartenant a loprateur. e e ` e
L. Butti
241
Fig. 8. Architecture FemtoCell (source : 3GPP) Lobjectif est de se reposer sur un protocole reconnu comme s r16 (IPsec) an u 17 dassurer une protection des communications entre le client et le rseau de loprateur. e e Le principe tant quil est (en priorit) primordial de se protger contre les attaquants e e e non authentis. Bien entendu, cela ne signie pas que les attaques issues dutilisateurs e authentis sont a ngliger ! e ` e Nous dtaillerons dans les chapitres suivants nos travaux sur la recherche de e vulnrabilits dans les implmentations IKEv2 et EAP qui font partie de la surface e e e dattaque atteignable (accessible de tout utilisateur non authenti). e
Eorts raliss sur le plan scurit e e e e
Ce chapitre prsente les principaux axes sur lesquels nous agissons pour apprhender e e au mieux la scurit des architectures de Convergence Fixe-Mobile. Une attention e e toute particuli`re est faite sur lapproche audit et recherche de vulnrabilits qui sont e e e primordiales pour sassurer dune amlioration du niveau de scurit ` la fois sur le e e ea plan ingnierie ou implmentation. e e 7.1 Suivi de standardisation
Le suivi de la standardisation et en particulier du groupe SA3 [34] du 3GPP est indispensable pour anticiper les problmatiques de scurit durant la conception des e e e
16 17
si bien utilis. . . e contre les attaques dcoute passive, dcoute active, de rejeu, dattaques sur lintgrit, dattaques sur e e e e lauthenticit. . . e
242
normes. Un suivi attentif permet aussi de conna certains risques inhrents aux tre e technologies normalises ou en cours de normalisation an dtre en avance de phase e e an dmettre les recommandations techniques adquates lors du dploiement de ces e e e technologies. Par ailleurs, aujourdhui toutes les technologies ont tendance a interagir ` entre elles, comme par lexemple la rutilisation de protocoles issus de lIETF dans e des normes IEEE, une participation ` chacun de ces corps de normalisation permet a alors dapprhender au mieux les problmatiques de scurit. e e e e 7.2 Ingnierie darchitecture rseau e e
Lingnierie des ux rseau joue un rle primordial dans le niveau de scurit de e e o e e toute architecture. Ceci est encore plus vrai dans les architectures de Convergence Fixe-Mobile o` les utilisateurs authentis ne devront avoir acc`s qu` certaines u e e a ressources rseaux ou aux applications. Tout ceci ne peut tre ralis quapr`s une e e e e e comprhension claire des pr-requis de service teinte de principes forts sur le plan de e e e la scurit rseau. e e e Cela a aussi son importance dans laccessibilit des failles de scurit au niveau des e e e implmentations. En eet, lexemple le plus simple est de constater que de nombreuses e failles de scurit sont prsentes dans des syst`mes informatiques mais quelles ne sont e e e e pas atteignables du fait de la prsence de r`gles de ltrage adquates que ce soit en e e e priphrie du syst`me informatique vulnrable ou sur ce dernier. Ceci est capital dans e e e e toute architecture dploye, tre capable de rduire un risque initialement fort grce e e e e a ` une mesure prventive (et non corrective, en particulier lorsque malheureusement a e la correction tarde a venir. . .). ` 7.3 Audits de scurit e e
Que ce soit par des valuations de produits ou des audits sur des architectures e dployes en validation il est ncessaire de relever les probl`mes de scurit le plus e e e e e e en amont possible. Ce nest qu` lpreuve du feu que le niveau de scurit dun a e e e quipement ou dune architecture augmente sensiblement. Il faut bien se rappeler que e trouver des vulnrabilits permet surtout de les faire corriger avant quelles ne soient e e exploites silencieusement (ou pas). e Lors des audits (bien que cela soit souvent la slipfest18 [32]) il est souvent ncessaire de rappeler les bases classiques du durcissement de la conguration des e syst`mes dexploitation et applications internes. Laudit de scurit permet aussi e e e davoir une vue extrieure et objective an davoir des retours sur des points qui e
18
comme diraient certains coll`gues. e
L. Butti
243
nauraient pas t imagins par les concepteurs de lquipement ou de larchitecture. ee e e Mme si laudit nest pas la solution miracle, il fait partie du processus damlioration e e continue19 . 7.4 Mise en place dinfrastructures de tests scurit e e
En parall`le des audits de scurit instantans sur des quipements ou architectures, e e e e e il est ncessaire de dployer des plates-formes de validation sur lesquelles les tests e e classiques fonctionnels seront raliss, mais aussi les tests spciques sur les aspects e e e scurit. Ce type de dmarche en amont rduit fortement les risques lorsquelle est e e e e correctement applique. Le principal inconvnient de cette mthode est de mobiliser e e e plus de ressources au niveau des auditeurs scurit car ces derniers ralisent alors e e e un travail ressemblant ` un processus de validation. Ceci est malgr tout un mal a e ncessaire a la vue de la foison des technologies a auditer en termes de Convergence e ` ` Fixe-Mobile. 7.5 Dveloppement de nouveaux outils e
Qui dit nouveaux standards dit nouveaux outils. Il nest pas concevable de pouvoir auditer ces nouvelles architectures sans outils appropris. Les protocoles IKEv2 et e EAP ne sont pas encore courants dans lexprience de lauditeur au mme titre que e e les implmentations audites. Raison de plus pour dvelopper des outils permettant e e e une valuation de la qualit des implmentations de ces protocoles mais aussi doutils e e e permettant de se faire passer pour un terminal mobile. Les premiers outils permettront (ventuellement) de dcouvrir des erreurs dimplmentations logicielle tandis que les e e e seconds permettront de raliser des tests de visibilit (plus classiques) grce ` un e e a a portable tout outill20 . e
Recherche de vulnrabilits dans les implmentations par e e e techniques de fuzzing
Le sujet de la scurit des architectures de Convergence Fixe-Mobile est extrmement e e e large, nous nous focalisons dans cet article que sur la recherche de vulnrabilits dans e e les implmentations IKEv2, EAP et ses mthodes associes (EAP-SIM et EAP-AKA) e e e par techniques de fuzzing.
19 20
pour peu que les recommandations soient appliques dans la mesure du possible. e ce qui est bien plus pratique et ecace que depuis un terminal mobile.
244 8.1
Scurit des architectures de Convergence Fixe-Mobile e e Historique du fuzzing
Le fuzzing qui est la contraction de fuzz et de testing est un terme issu des travaux de Barton Miller lorsquil faisait tester des applications Unix ` ses a tudiants [35]. Ses travaux, qui datent de 1989, ont montr que de nombreuses failles e e de scurit pouvaient tre dcouvertes par des techniques simples dinjection de fautes. e e e e Pour notre culture, lorigine mme du mot fuzz provient du bruit mis par des e e caract`res alatoires sur une ligne tlphonique [36]. Aujourdhui, le fuzzing fait partie e e ee de larsenal classique du chercheur de failles de scurit. e e 8.2 Dnitions du fuzzing e
Parmi de tr`s nombreuses dnitions du fuzzing, nous avons choisi de retenir les e e trois suivantes : e Wikipedia Le fuzzing est une technique pour tester des logiciels. Lide est dinjecter des donnes alatoires dans les entres dun programme. Si le e e e programme choue (par exemple en plantant ou en gnrant une erreur), alors e e e il y a des dfauts ` corriger. e a Open Web Application Security Project (OWASP) Le Fuzz testing ou fuzzing est une technique de tests logiciels en boite noire, qui consiste ` dcouvrir des a e erreurs dimplmentation logicielle en utilisant de linjection de donnes mal e e formes, et ce de mani`re automatise. e e e Whatis.com Le Fuzz testing ou fuzzing est une technique de tests logiciels utilise pour dcouvrir des erreurs de dveloppement ou des faiblesses dans des e e e logiciels, syst`mes dexploitation ou rseaux en injectant de nombreuses entres e e e alatoires dans le syst`me an quil sarrte. Si une vulnrabilit est dcouverte, e e e e e e un outil appel fuzzer, permet dindiquer les causes potentielles de larrt du e e syst`me. e Nous constatons ci-dessus que ces dnitions ne sont pas forcment en accord les e e unes avec les autres. Par exemple, la dnition de Whatis.com sugg`re quune erreur e e de dveloppement entra forcment un arrt de lapplication teste. De la mme e ne e e e e mani`re, la dnition de lOWASP sugg`re que les donnes injectes sont forcment e e e e e e mal formes, ce qui nest pas obligatoire en pratique pour dcouvrir des vulnrabilits. e e e e Il faut bien prciser ce qui est entendu par donnes mal formes , est-ce par e e e rapport a une spcication (ou a une norme) ou est-ce par rapport a limplmentation ` e ` ` e de cette spcication ? Ceci pour rappeler que le fuzzing vise ` trouver des erreurs e a dimplmentations logicielles et non ` dcouvrir des vulnrabilits thoriques dans e a e e e e des spcications. e
L. Butti
245
Par consquent, en seorant de synthtiser au mieux les dnitions ci-dessus, e c e e notre conclusion est que le fuzzing est une technique de recherche derreurs dimplmentation logicielle par injection de donnes invalides. Dans cette dnition, le e e e caract`re invalide de ces donnes est bien entendu relatif a limplmentation logicielle e e ` e teste, i.e. trouver les tests les plus pertinents susceptibles de dcouvrir des erreurs e e dimplmentation classiques (dbordement de tampon, bogue de chane de format. . .). e e La composante alatoire est souvent cite dans les dnitions du fuzzing, cependant e e e elle nest pas en pratique obligatoire pour raliser du fuzzing. . . e Nous invitons le lecteur ` se rfrer ` larticle recherche de vulnrabilits dans a ee a e e les drivers 802.11 par techniques de fuzzing publi a SSTIC en 2007 [37] et au dossier e` fuzzing du magazine MISCMAG de septembre 2008 [38] pour de plus amples informations. 8.3 Pourquoi avoir choisi le fuzzing ?
La recherche de failles de scurit se repose gnralement sur trois principales e e e e techniques : la rtro-ingnierie qui consiste a tudier le code bas niveau et trouver des erreurs e e è dimplmentation logicielle en ayant acc`s au code apr`s compilation, e e e è laudit de code source qui consiste a tudier le code avant compilation et trouver des erreurs dimplmentation logicielle, e linjection de donnes invalides (le fuzzing). e Dans notre cas, la question du choix de telle ou telle technique ne se pose mme e pas car nous ne disposons pas dacc`s facile aux applications testes (pas de code e e source, pas de dbogage, obligations lgales ou contractuelles. . .). Nous sommes dans e e le cas de la boite noire o` le fuzzing est rellement pertinent. u e 8.4 Etat de lart des outils de fuzzing IKEv2 et EAP
Ce chapitre prsente les outils de fuzzing commerciaux ou Open Source qui sont e capables de raliser du fuzzing dimplmentations IKEv2, EAP ou mthodes EAP. e e e Nous avons dlibrment cart de cette section tous les fuzzers gnriques qui, par e ee e e e e exemple, op`rent par mutations de donnes valides. e e ` Fuzzing IKEv2 A notre connaissance le seul outil disponible est la suite DEFENSICS de Codenomicon [39]. Il sagit dun fuzzer spcique21 . Nous allons donc tudier e e un domaine o` peu de publications sont disponibles. u
21
dvelopp pour fuzzer un protocole particulier et non un fuzzer par mutations qui est bien plus gnrique. e e e e
246
` Fuzzing EAP et mthodes EAP A notre connaissance le seul outil disponible e est la suite DEFENSICS de Codenomicon qui permet de fuzzer des implmentations e EAP, EAP-MD5 [40], EAP-GTC [41] et EAP-MSCHAPV2 [42]. La contrainte semble22 tre que limplmentation EAP fuzze doit tre un quipement supportant e e e e e IEEE 802.1X (point dacc`s 802.11 ou un commutateur 802.3) [50], limplmentation e e EAP dans RADIUS ntant alors pas fuzze directement23 (mais ` travers le relais e e a dauthentication qui est soit le point dacc`s soit le commutateur). e 8.5 Etat de lart des vulnrabilits sur les implmentations IKEv2, e e e EAP et mthodes EAP e
Pour raliser cette recherche, nous nous sommes bass sur la base Common Vule e nerabilities and Exposures [43] qui rfrence lensemble des vulnrabilits publiques. ee e e Il est bon aussi de rappeler que de nombreuses vulnrabilits sont corriges e e e silencieusement dans des produits commerciaux mais aussi (et de mani`re plus e tonnante) dans des logiciels Open Source. En eet, la position de Linus Torvalds e sur la gestion des failles de scurit dans le noyau Linux avait dclench de grandes e e e e discussions rcemment [44] et permet de se rendre compte que de nombreux erreurs de e programmation ne sont pas rfrences en tant que vulnrabilits alors quils peuvent ee e e e entra ner un dni de service par un tiers, ou encore, et que dautres vulnrabilits e e e sont rfrences en tant que vulnrabilit de type dni de service alors que lexcution ee e e e e e de code arbitraire aura t dmontre. Nous prcisons donc ici que ne sont discutes ee e e e e que des vulnrabilits publiques et rfrences en tant que telles, par dnition, les e e ee e e vulnrabilits prives ne sont pas connues du grand public. e e e Dans les tableaux suivants nous utiliserons les termes usits dans la norme IEEE e 802.1X qui dnit trois entits : le supplicant (assimil au client), lauthenticator e e e (assimil au relais de lauthentication) et le serveur dauthentication (serveur e Authentication Authorization Accounting, AAA, qui est gnralement un serveur e e Remote Authentication Dial-In User Service, RADIUS [61], plus rarement un serveur Diameter [62]). Ces termes sont parfaitement transposables au protocole IKEv2 car dans le cadre de lutilisation dauthentication EAP nous avons aussi aaire ` une a architecture avec ces trois entits fonctionnelles. e Vulnrabilits dimplmentations IKEv2 Dans le tableau 1 nous constatons e e e quune seule vulnrabilit sur des implmentations IKEv2 a t publie. Elle est e e e ee e
22 23
nayant pas eu acc`s a loutil, nous basons notre analyse sur le descriptif de la solution sur leur site Web. e ` ceci a des implications fortes car lquipement relayant les paquets EAP eectue gnralement un e e e traitement de ces derniers et peut alors ne pas transmettre les paquets fuzzs ce qui fausse les rsultats e e du fuzzing de limplmentation EAP dans le serveur RADIUS. e
L. Butti Tab. 1. Vulnrabilits dimplmentations IKEv2 e e e

CVE-ID Cible Description
247
CVE-2008-4551 Authenticator strongSwan 4.2.6 and earlier allows remote attackers to cause a denial of service (daemon crash) via an IKE SA INIT message with a large number of NULL values in a Key Exchange payload, which triggers a NULL pointer dereference for the return value of the mpz export function in the GNU Multiprecision Library (GMP).
dclenchable au tout dbut des changes IKE i.e. lors de la rception dun paquet e e e e IKE SA INIT dont un champ nomm Key Exchange contient une valeur particuli`re e e ` noter que cette vulnrabilit a t dcouverte par (champ Die-Hellman a zro) [45]. A ` e e e ee e la socit Mu Dynamics, spcialise dans la scurit et le fuzzing, donc probablement ee e e e e dcouverte par fuzzing (cette vulnrabilit est trouvable par fuzzing par mutations, e e e ce qui serait en adquation avec le fait quils se sont spcialiss dans le fuzzing par e e e mutations) [46].
Tab. 2. Vulnrabilits dimplmentations EAP e e e

CVE-ID Cible Description CVE-2008-5563 Authenticator Aruba Mobility Controller 2.4.8.x-FIPS, 2.5.x, 3.1.x, 3.2.x, 3.3.1.x, and 3.3.2.x allows remote attackers to cause a denial of service (device crash) via a malformed Extensible Authentication Protocol (EAP) frame. CVE-2008-2441 AAA Cisco Secure ACS 3.x before 3.3(4) Build 12 patch 7, 4.0.x, 4.1.x before 4.1(4) Build 13 Patch 11, and 4.2.x before 4.2(0) Build 124 Patch 4 does not properly handle an EAP Response packet in which the value of the length eld exceeds the actual packet length, which allows remote authenticated users to cause a denial of service (CSRadius and CSAuth service crash) or possibly execute arbitrary code via a crafted RADIUS (1) EAP-Response/Identity, (2) EAP-Response/MD5, or (3) EAP-Response/TLS Message Attribute packet. CVE-2007-5651 Authenticator Unspecied vulnerability in the Extensible Authentication Protocol (EAP) implementation in Cisco IOS 12.3 and 12.4 on Cisco Access Points and 1310 Wireless Bridges (Wireless EAP devices), IOS 12.1 and 12.2 on Cisco switches (Wired EAP devices), and CatOS 6.x through 8.x on Cisco switches allows remote attackers to cause a denial of service (device reload) via a crafted EAP Response Identity packet.
Vulnrabilits dimplmentations EAP Dans le tableau 2 nous constatons que e e e trois vulnrabilits ont t publies sur des implmentations dEAP dont une dans e e ee e e un serveur RADIUS commercial et deux autres sur les implmentations EAP dans e
248
les authenticators. La vulnrabilit CVE-2007-5651 [47] a t dcouverte par nouse e ee e mmes en 2007 lors de travaux prliminaires sur le fuzzing dimplmentations EAP e e e dans les authenticators et la vulnrabilit CVE-2008-2441 [48] a t dcouverte par e e ee e nous-mmes en 2008 durant nos investigations sur le fuzzing dimplmentations EAP e e dans les serveurs RADIUS. Vulnrabilits dimplmentations de mthodes EAP Dans le tableau 3 nous e e e e constatons que seules trois vulnrabilits (CVE-2004-1459, CVE-2006-1354 et CVEe e 2007-2028) semblent trouvables par fuzzing, les autres tant relatives a une mauvaise e ` conception comme par exemple labsence de validation de certicat lors dauthentication utilisant ces mcanismes. Par ailleurs, il est important de souligner quaucune e vulnrabilit nest publie sur des implmentations dEAP-SIM ou EAP-AKA dans e e e e des serveurs RADIUS quils soient commerciaux ou Open Source.
9
9.1
Recherche de vulnrabilits dans les implmentations e e e IKEv2

Contexte et enjeux
Ce protocole est (lorsque la passerelle est correctement congure) le seul visible e depuis tout utilisateur non authenti. Il est donc extrmement critique que ces e e implmentations soient robustes car toute faille de scurit prsente dans la passerelle e e e e IKEv2 peut entra ner un dni de service dterministe ou de lexcution arbitraire de e e e code a distance. La redondance des passerelles aidant, nous pouvons alors faire face a ` ` 24 un eet domino lors dune attaque visant une implmentation particuli`re dune e e pile IKEv2. Certes, en cas de dcouverte dune vulnrabilit sur une implmentation IKEv2, e e e e il est peu probable quil soit faisable en pratique dtudier lexploitabilit25 dans e e le cas dimplmentations propritaires o` il nest pas possible de faire autre chose e e u quune analyse en boite noire. Cela ne prjuge en rien de lexploitabilit, seulement, les e e conditions techniques rendent tr`s dicile linvestigation pour un attaquant externe e nayant aucun acc`s a lquipement (pas de dbogage. . .). e ` e e En ce qui concerne les failles dans les implmentations EAP et mthodes EAP, e e cela est dirent car les serveurs RADIUS sont des logiciels fonctionnant sur des e syst`mes dexploitation standards et ouverts. La prsence dune faille de scurit sur e e e e
24
25
la solution avec plusieurs implmentations dditeurs dirents serait une option technique mais en e e e pratique elle est rarement envisage pour des raisons conomiques ou contractuelles. e e dans le sens excution de code arbitraire. e
L. Butti
249
Tab. 3. Vulnrabilits dimplmentations de mthodes EAP e e e e

CVE-ID Cible Description CVE-2008-1114 Supplicant Vocera Communications wireless handsets, when using Protected Extensible Authentication Protocol (PEAP), do not validate server certicates, which allows remote wireless access points to steal hashed passwords and conduct man-in-the-middle (MITM) attacks. CVE-2008-1113 Supplicant Cisco Unied Wireless IP Phone 7921, when using Protected Extensible Authentication Protocol (PEAP), does not validate server certicates, which allows remote wireless access points to steal hashed passwords and conduct man-in-the-middle (MITM) attacks. CVE-2007-2028 AAA Memory leak in freeRADIUS 1.1.5 and earlier allows remote attackers to cause a denial of service (memory consumption) via a large number of EAP-TTLS tunnel connections using malformed Diameter format attributes, which causes the authentication request to be rejected but does not reclaim VALUE PAIR data structures. CVE-2007-1068 Supplicant The (1) TTLS CHAP, (2) TTLS MSCHAP, (3) TTLS MSCHAPv2, (4) TTLS PAP, (5) MD5, (6) GTC, (7) LEAP, (8) PEAP MSCHAPv2, (9) PEAP GTC, and (10) FAST authentication methods in Cisco Secure Services Client (CSSC) 4.x, Trust Agent 1.x and 2.x, Cisco Security Agent (CSA) 5.0 and 5.1 (when a vulnerable Trust Agent has been deployed), and the Meetinghouse AEGIS SecureConnect Client store transmitted authentication credentials in plaintext log les, which allows local users to obtain sensitive information by reading these les, aka CSCsg34423. CVE-2006-1354 AAA Unspecied vulnerability in FreeRADIUS 1.0.0 up to 1.1.0 allows remote attackers to bypass authentication or cause a denial of service (server crash) via Insucient input validation in the EAP-MSCHAPv2 state machine module. CVE-2004-1459 AAA Cisco Secure Access Control Server (ACS) 3.2, when congured as a Light Extensible Authentication Protocol (LEAP) RADIUS proxy, allows remote attackers to cause a denial of service (device crash) via certain LEAP authentication requests. CVE-2004-1099 AAA Cisco Secure Access Control Server for Windows (ACS Windows) and Cisco Secure Access Control Server Solution Engine (ACS Solution Engine) 3.3.1, when the EAP-TLS protocol is enabled, does not properly handle expired or untrusted certicates, which allows remote attackers to bypass authentication and gain unauthorized access via a cryptographically correct certicate with valid elds such as the username. CVE-2003-1096 AAA The Cisco LEAP challenge/response authentication mechanism uses passwords in a way that is susceptible to dictionary attacks, which makes it easier for remote attackers to gain privileges via brute force password guessing attacks.
250
ces implmentations est plus critique par rapport aux impacts si lexploitabilit est e e dmontre. Par ailleurs, le canal de communication naturel avec lattaquant semble e e tre la rutilisation du canal utilis pour lauthentication EAP, mme sil faut e e e e reconna que cela est techniquement dicile [49]. tre 9.2 Description du protocole IKEv2
Ce protocole permet ltablissement dassociations de scurit qui seront alors e e e utilises par la pile IPsec an dapporter la scurit des communications entre un e e e point (dans notre cas, le client nal) et un point xe (dans notre cas, la passerelle de scurit, la Security Gateway) comme cela est montr dans la gure 9. e e e
+ -+ -+ -+ -+ -+ + -+ -+ -+ -+ -+ ~! ~! IPsec ~! ~! ~! Protected ! tunnel ~! Tunnel ~! ~! Endpoint ~! < - - - - - - - - - - - - - - - - - - - - - - - - >! Endpoint ~! < - - ~! ~! ~! ~! + -+ -+ -+ -+ -+ + -+ -+ -+ -+ -+
Protected Subnet and / or Internet
Fig. 9. Architecture Endpoint - Security Gateway IKEv2 (source : RFC 4306) Cest ce type darchitecture qui est utilise aussi bien dans le cadre de terminaux e mobiles que de FemtoCells. Le rseau protg tant alors la plate-forme dacc`s qui e e ee e sera elle-mme connecte ensuite au coeur de rseau de loprateur mobile. e e e e Le protocole IKEv2 suit un schma de requte/rponse au-dessus du protocole e e e UDP o` la rponse joue un rle dacquittement des requtes. Dans la gure 10, nous u e o e avons le premier change de donnes entre le client (initiator ) et la Security Gateway e e (responder ). Cet change de donnes est transport dans des messages de type e e e IKE SA INIT qui transportent SAi1, KEi et Ni dans le sens initiator vers responder et SAr1, KEr et Nr dans le sens responder vers initiator. Les champs SA*1 transportent les informations relatives a la cration de lassociation de scurit IKE SA, les champs ` e e e KE* transportent les informations relatives pour raliser le Die-Hellman [52] et les e champs N* transportent un ala. e Avec la russite de la premi`re phase IKE SA INIT tout un ensemble dalgorithmes e e de scurit auront t ngocis ainsi quun ensemble de cls auront t drives, ce e e ee e e e ee e e qui permettra alors de transporter de mani`re scurise les prochains contenus IKEv2. e e e En particulier, lors de lutilisation du protocole EAP pour authentier le rseau et le e terminal, ces changes seront alors protgs comme cela est dcrit dans la gure 11 e e e e
L. Butti
251
Initiator ----------HDR , SAi1 , KEi , Ni
Responder ------------> <-HDR , SAr1 , KEr , Nr , [ CERTREQ ]
Fig. 10. Phase initiale IKEv2 (source : RFC 4306) via lacronyme SK. Toute cette phase est dcrite dans la section 2.16 de la RFC 4306 e (IKEv2).
Initiator ----------HDR , SAi1 , KEi , Ni
Responder ------------> <-HDR , SAr1 , KEr , Nr , [ CERTREQ ]
HDR , SK { IDi , [ CERTREQ ,] [ IDr ,] SAi2 , TSi , TSr } --> <-HDR , SK { IDr , [ CERT ,] AUTH , EAP }
HDR , SK { EAP }
--> <-HDR , SK { EAP ( success ) }
HDR , SK { AUTH }
--> <-HDR , SK { AUTH , SAr2 , TSi , TSr }
Fig. 11. Phase comp`te IKEv2 avec EAP (source : RFC 4306) e Le champ optionnel CERTREQ montre quil est possible dauthentier la Security Gateway grce ` un syst`me de certication o` la Security Gateway prsente son a a e u e certicat au client qui alors sera capable de le valider si bien s r il a toutes les u informations ncessaires pour ce faire (avec entre autres le certicat de lautorit e e de certication). Cette information est tr`s importante pour lauditeur scurit : il e e e vriera que la fonctionnalit est bien active et quelle est bien utilise (dans notre e e e e cas, que le client IKEv2 valide bien le certicat prsent par la passerelle IKEv2) car e e lexprience montre que de nombreux syst`mes similaires senss vrier la validit e e e e e des certicats ne le font visiblement pas [53,54].
252 9.3 Choix techniques
Conditions techniques Elles dnissent les choix techniques qui seront raliss. e e e Le protocole IKEv2 est complexe dans la gnration des paquets (avec beaucoup e e de charges sous forme de liste cha ees) et utilise d`s les premiers changes des n e e mcanismes cryptographiques pour chirer les autres messages. Or, dans le fuzzing, il e est intressant daller le plus loin possible dans les parties de limplmentation qui e e seront utilises lors des changes. En consquence, si lobjectif est darriver a fuzzer le e e e ` contenu des messages IKE AUTH alors un processus de fuzzing par mutations ne sera pas pertinent car les paquets chirs ne seront plus int`gres si des modications par e e mutations auront t eectues (et donc le paquet sera normalement rejet et son ee e e contenu non analys par limplmentation). Ces constatations permettent de sorienter e e vers la gnration de tests par modlisation de protocole qui semble pertinent dans le e e e cas de IKEv2. Une autre condition technique est lobligation de raliser les tests en boite noire. En e eet, pour des raisons techniques il ne nous est pas possible dtudier le comportement e de la cible en tant en local sur le syst`me audit (grce par exemple a lattachement e e e a ` dun dbogueur). Par consquent, ceci a aussi un impact fort sur les choix techniques e e car il faudra dnir un test permettant de savoir si limplmentation se comporte de e e mani`re non conforme apr`s un ou un ensemble de tests. e e ` noter aussi que nous avons choisi de dvelopper un fuzzer dimplmentations A e e serveurs IKEv2. Nous considrons que les risques sont bien moins importants sur e les implmentations clientes IKEv2 car les impacts (gravit) sont plus faibles pour e e loprateur mais cela nenl`ve rien ` lintrt technique car il appara probable de e e a ee t trouver des choses intressantes pour ceux qui auront la volont de rechercher dans e e cette voie. Base technique Tous nos dveloppements sont bass sur des briques issues de loutil e e Sulley Fuzzing Framework [55] qui est ` notre avis le fuzzer Open Source le plus a abouti lorsquil sagit de fuzzer des protocoles rseau par modlisation de protocole. e e Cet outil est dvelopp en langage Python ce qui ore a la fois une grande souplesse e e ` et puissance dutilisation. Nous invitons (encore une fois !) le lecteur ` se rfrer au a ee dossier fuzzing du magazine MISCMAG de septembre 2008 qui prsente un article e complet sur le fonctionnement et lutilisation de Sulley. Gnration des tests Nous nous reposons sur un syst`me de gnration de tests e e e e e par modlisation du protocole. Il a donc fallu dcrire compl`tement les charges e e e contenues dans les trames IKE SA INIT et IKE AUTH. Ce protocole est complexe dans
L. Butti
253
sa construction en comparaison avec dautres protocoles bien plus simples a modliser ` e comme FTP ou HTTP. Dans la gure 12 nous montrons un exemple de spcication e de la modlisation dun champ Key Exchange grce a des primitives de Sulley comme e a ` s short() et s random() qui permettront alors de fuzzer ces champs grce aux a heuristiques de Sulley.
def k e y _ e x c h a n g e _ p a y l o a d ( next_payload = None ) : Key Exchange Payload name = Key Exchange if s_block_start ( name ) : payl oad_head er ( name , next_payload ) Payload Header s_short (0 x0e , endian = > , fuzzable = True ) Group Number s_static ( \ x00 \ x00 ) Reserved s_random ( PAD * 256 , 0 , 100 , name = Key Exchange Data ) ( DH value ) s_block_end ()
# # DH # # Data
Fig. 12. Exemple de dnition dun champ de type Key Exchange e
Gestion des tats Pour le premier tat, lenvoi de paquets IKE SA INIT ne pose e e pas de probl`me particulier. Par contre, la principale problmatique est de pouvoir e e crer des paquets IKE AUTH valides i.e. qui utilisent lassociation de scurit qui aura e e e t ngocie dans les changes prcdents. Une premi`re ide consiste ` dvelopper ee e e e e e e e a e une pile IKEv2 de zro (de prfrence en Python de mani`re a lintgrer directement e ee e ` e avec Sulley) mais cette option sav`re tr`s coteuse en temps de dveloppement. La e e u e deuxi`me approche (plus facile, mais moins intgre) consiste ` modier un client e e e a IKEv2 Open Source de mani`re ` lui faire faire le travail et ` lui faire passer le e a a test niveau contenu du paquet IKE AUTH an quil puisse le chirer avec la SA quil aura pralablement ngocie. Nous avons donc dvelopp une modication de loutil e e e e e Racoon2 [51] (implmentation IKEv2 sous *nix) qui permet de recevoir puis denvoyer e les tests IKE AUTH gnrs par Sulley apr`s avoir ngoci la premi`re phase IKEv2 e ee e e e e avec la passerelle de scurit. e e Par consquent, notre fuzzer est capable de fuzzer la premi`re tape du protocole e e e ainsi que la deuxi`me. Un fuzzer plus ecace aurait t capable daller fuzzer les e ee
254
autres tats du protocole, ce sera certainement une des prochaines amliorations de e e ce fuzzer. Dtection de dysfonctionnement Larchitecture de fuzzing tant en boite noire, e e la seule solution est dinterroger limplmentation IKEv2 serveur an dobserver son e comportement face ` des stimuli dont la rponse est connue. Le protocole IKEv2 a e fonctionnant au-dessus du protocole UDP (non connect), il est ncessaire denvoyer e e un stimulus qui sera compris par limplmentation IKEv2 audite. Ce stimulus sera e e lanc avant chaque test de fuzzing pour valider que limplmentation IKEv2 audite e e e est active avant le passage des tests unitaires, et apr`s chaque test de fuzzing an e de valider que limplmentation IKEv2 audite est toujours active. Ceci est valable e e en particulier pour la phase IKE SA INIT. Concernant la phase IKE AUTH, cest plus compliqu car limplmentation IKEv2 a des mcanismes de vrication de connections e e e e IKEv2 ` moiti ouvertes (car elles ne sont pas refermes par le fuzzer). En eet, a e e apr`s lenvoi dans un certain laps de temps de plusieurs requtes invalides, le serveur e e demande un cookie ` chaque nouvelle requte IKE SA INIT. Le fuzzer vrie donc a e e que Racoon2 a russi a envoyer une requte IKE SA INIT contenant un cookie valide. e ` e Une erreur est leve si cela nest pas le cas. e 9.4 Retour dexprience e
Tab. 4. Rsultats fuzzing dimplmentations IKEv2 e e

Implmentation e StrongSWAN 4.2.6 Implmentation 1 Version 1 e Implmentation 1 Version 2 e Implmentation 2 e Implmentation 3 e Implmentation 4 e Racoon2 OpenIKEv2 IKE SA INIT IKE AUTH 1 Plusieurs 0 0 0 0 ` A faire ` A faire 0 Plusieurs 0 0 0 0 ` A faire ` A faire
Rsultats Dans le tableau 4, nous prsentons le nombre de tests de fuzzing dclenchant e e e entra nant un dysfonctionnement de la part de limplmentation IKEv2 value. A e e e ` noter que plusieurs tests peuvent dclencher une seule et mme vulnrabilit. Aue e e e jourdhui, seule une investigation manuelle permet de raliser cette analyse car les e moyens techniques sont limits en boite noire. e
L. Butti
255
` A noter que pour retrouver la vulnrabilit sur StrongSWAN 4.2.6, cela ntait e e e pas possible dans la version initiale du fuzzer qui avait t dveloppe. En eet, dans ee e e la gure 12, nous constatons lutilisation de la primitive s random() qui comme son nom lindique renvoie une cha de caract`res alatoire pour chaque test de fuzzing. ne e e Or, la vulnrabilit est dclenche par une chane bien spcique, a savoir, lorsquelle e e e e e ` est nulle. Il eut t possible de modier le mod`le pour retrouver cette vulnrabilit, ee e e e cependant, il est apparu plus gnrique de modier Sulley an dintgrer des valeurs e e e particuli`res dans la primitive s random(). e Note 3. Ces rsultats sont incomplets dans la version actuelle de cet article, nous e esprons pouvoir fournir des rsultats plus consquents lors de la prsentation et dans e e e e la version lectronique de larticle qui sera publie sur le site de la confrence. e e e Limitations Un fuzzer, mme volu, prsente gnralement un ensemble de limitae e e e e e tions. Les principales limitations de ce fuzzer sont : les champs fuzzs le sont de mani`re squentielle (pas de fuzzing de plusieurs e e e champs a fuzzer sur un mme test), ` e tous les tats du protocole IKEv2 ne sont pas atteints, e limplmentation de la machine ` tat elle-mme nest pas fuzze, e ae e e e e la dtection de dysfonctionnement est perfectible et il serait intressant danalyser les remontes derreurs renvoyes par des messages de notication IKEv2 e e avec le champ Notify, la dicult de corrler les tests dclenchant une vulnrabilit a la vulnrabilit e e e e e` e e elle-mme, e les vulnrabilits dclenches par une suite de tests sont diciles a analyser et e e e e ` rejouer. Malgr ces limitations, le fuzzer a permis de redcouvrir une vulnrabilit publique e e e e (CVE-2008-4551) et de trouver plusieurs autres vulnrabilits dans une implmentation e e e propritaire. Cette implmentation propritaire a t corrige an de ne plus prsenter e e e ee e e les vulnrabilits qui avaient t dcouvertes prcdemment. e e ee e e e
10
10.1
Recherche de vulnrabilits dans les implmentations e e e EAP, EAP-SIM et EAP-AKA

Contexte et enjeux
Les implmentations de ces protocoles sont aussi accessibles dans les premiers e changes a tout utilisateur non authenti. Les erreurs dimplmentation peuvent se e ` e e
256
retrouver a la fois sur la passerelle IKEv2 qui doit transmettre les paquets EAP dans ` des champs du protocole AAA (RADIUS ou Diameter) et sur le serveur AAA qui doit implmenter le protocole EAP et la (ou les) mthode(s) obligatoire(s) pour faire e e fonctionner larchitecture. La encore, toute faille de scurit prsente dans un de ces lments peut entraner e e e ee ` noter un dni de service dterministe ou de lexcution de code arbitraire a distance. A e e e ` que les investigations sur lexploitabilit dune ventuelle faille de scurit dcouverte e e e e e sont dans ce cas plus faciles car les serveurs RADIUS peuvent fonctionner sur des syst`mes tels que des Microsoft Windows ou des *nix classiques. e
10.2
Description des protocoles EAP, EAP-SIM et EAP-AKA
Le protocole EAP avait t initialement conu pour le protocole Point-to-Point ee c Protocol (PPP). Cest un protocole de transport dauthentication qui propose de se reposer sur des mthodes dauthentication qui peuvent tre extrmement e e e varies : EAP-MD5, EAP-TLS [56], EAP-SIM. . . Ce protocole a t une premi`re fois e ee e intgr dans la norme IEEE 802.1X en 2001 et a ensuite rejoint IEEE 802.11i [57] e e via une adaptation de IEEE 802.1X. Ce nest qu` partir de la dmocratisation des a e rseaux Wi-Fi quEAP est devenu ` la mode car il est aujourdhui utilis PPP, e a e 802.1X, 802.11i, 802.16e, IKEv2, SIP. . . Les mthodes EAP-SIM et EAP-AKA permettent de rutiliser les crdences e e e dauthentication 2G et 3G indpendamment de la couche de transport sous-jacente e (par exemple 802.1X ou IKEv2) car la couche intermdiaire est le protocole EAP (ce e qui est visible de la partie mthodes EAP). Ceci est un grand avantage en termes de e souplesse et exibilit dutilisation, cest certainement une des raisons du succ`s de e e ce protocole. Les mthodes EAP-SIM et EAP-AKA permettent toutes les deux une e authentication mutuelle du client (la possession dune carte SIM/USIM et du bon ` code PIN) et du rseau (la possession dun secret dans une base centrale). A noter e que lauthentication GSM ` lorigine ne permet pas lauthentication du rseau a e alors que lauthentication par la mthode EAP-SIM le permet. Ceci est un lment e ee capital dans lutilisation de ces technologies au-dessus de rseaux Wi-Fi (o` raliser e u e des attaques de type homme du milieu ne requiert pas dquipements coteux). e u Les changes EAP-SIM sont dcrits dans la gure 13 et les changes EAP-AKA e e e sont dcrits dans la gure 14. Nous constatons dans ces changes lutilisation dalas e e e AT NONCE MT et AT RAND pour EAP-SIM qui sont utiliss pour raliser lauthentication e e mutuelle, et lutilisation dun ala AT RAND et dun jeton dauthentication rseau e e AT AUTN pour EAP-AKA qui sont aussi utiliss pour lauthentication mutuelle. e
L. Butti
257
Peer Authenticator | EAP - Request / Identity | | < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| | | | EAP - Response / Identity | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >| | | | EAP - Request / SIM / Start ( A T_ V ER SI ON _ LI ST ) | | < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| | | | EAP - Response / SIM / Start ( AT_NONCE_MT , A T _ S E L E C T E D _ V E R S I O N ) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >| | | | EAP - Request / SIM / Challenge ( AT_RAND , AT_MAC ) | | < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ | | Peer runs GSM algorithms , verifies | | | AT_MAC and derives session keys | | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ | | EAP - Response / SIM / Challenge ( AT_MAC ) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >| | | | EAP - Success | | < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| | |
Fig. 13. Authentication EAP-SIM compl`te (source : RFC 4186) e
258
Peer Authenticator | EAP - Request / Identity | | < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| | | | EAP - Response / Identity | | ( Includes user s NAI ) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >| | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ | | Server runs AKA algorithms , | | | generates RAND and AUTN . | | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ | EAP - Request / AKA - Challenge | | ( AT_RAND , AT_AUTN , AT_MAC ) | | < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ | | Peer runs AKA algorithms , | | | verifies AUTN and MAC , derives RES | | | and session key | | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ | | EAP - Response / AKA - Challenge | | ( AT_RES , AT_MAC ) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >| | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ | | Server checks the given RES , | | | and MAC and finds them correct .| | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ | EAP - Success | | < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
Fig. 14. Authentication EAP-AKA compl`te (source : RFC 4187) e
L. Butti 10.3 Choix techniques
259
Conditions techniques Elles dnissent les choix techniques qui seront raliss. e e e Dans ce cas, nous nous sommes xs la possibilit de raliser les tests soit en boite noire, e e e soit en ayant acc`s a la machine hbergeant le serveur RADIUS. Par consquent, nous e ` e e avons implment deux mthodes direntes pour dtecter des dysfonctionnements. e e e e e Concernant le choix entre la gnration des tests par mutations ou par modlisation e e e de protocole, nous avons opt pour la seconde car certains champs cryptographiques e sont utiliss dans les paquets que nous devons envoyer et il est fort probable que ces e champs soient vris avant toute analyse de la smantique des champs EAP fuzzs. e e e e ` A noter aussi que nous avons choisi de dvelopper un fuzzer dimplmentations e e serveurs EAP/EAP-SIM/EAP-AKA. Nous considrons que les risques sont bien e moins importants sur les implmentations clientes IKEv2 car les impacts (gravit) e e sont plus faibles pour loprateur mais cela nenl`ve rien ` lintrt technique car il e e a ee apparat probable de trouver des choses intressantes pour ceux qui auront la volont e e de rechercher dans cette voie. Les implmentations EAP des serveurs RADIUS sont atteignables en tant que e client IKEv2 (ou 802.1X dans le cas du Wi-Fi). La premi`re ide aurait t de e e ee dvelopper un fuzzer EAP au-dessus de protocoles comme IKEv2 et 802.1X, mais e cela a un impact fort sur la prcision des rsultats : llment relais (aussi appel e e ee e lauthenticator) peut eectuer des traitements et donc ne pas transmettre les paquets EAP fuzzs vers limplmentation EAP ` fuzzer. Nous avons donc opt pour une e e a e autre solution, a savoir, agir en tant que client RADIUS directement et donc acter a ` ` la fois en tant que client EAP/EAP-SIM/EAP-AKA au-dessus de RADIUS plutt o quIKEv2 ou 802.1X. e e e Base technique De la mme mani`re que pour la partie sur le fuzzing dimplmentations IKEv2, tous nos dveloppements sont bass sur des briques issues de loutil e e Sulley Fuzzing Framework. Gnration des tests Nous nous reposons sur un syst`me de gnration de tests par e e e e e modlisation du protocole. Il a donc fallu dcrire compl`tement les charges contenues e e e dans les trames issues des protocoles EAP, EAP-SIM et EAP-AKA. Ces protocoles sont bien moins complexes que le protocole IKEv2 dans la construction des messages et prsentent comme avantages (pour le dveloppeur du fuzzer) de ne pas chirer e e le contenu des paquets. Nous avons d aussi modliser lintgration des paquets u e e EAP dans les attributs RADIUS correspondants et les intgrer au niveau RADIUS e (utilisation de mcanismes cryptographiques par secret partag entre le client et le e e
260
serveur). Dans les gures 15 et 16 nous montrons un exemple de spcication de e la modlisation dun en-tte EAP et EAP-Identity grce ` des primitives de Sulley e e a a comme s size() et s string() qui permettront alors de fuzzer ces champs grce a aux heuristiques de Sulley. Nous avons dcrit un ensemble dattributs EAP qui sont e ncessaires par rapport ` ce qui est dcrit dans les RFC 4186 et RFC 4187. e a e
def EAP_begin ( block , code , identifier , type , subtype = None ) : " " " Debut de chaque bloc EAP " " " s_byte ( code , fuzzable = False ) s_byte ( identifier , fuzzable = False ) s_size ( block , length =2 , endian = > , fuzzable = True ) s_byte ( type , fuzzable = False ) if subtype : s_byte ( subtype , fuzzable = False ) s_short (0 x0000 , fuzzable = False ) # # # # Code Identifier Length Type
# Subtype # Reserved
Fig. 15. Exemple de dnition dun champ de type en-tte EAP e e
s_initialize ( " Identity " ) if s_block_start ( " n o _ e n c o d e r _ I d e n t i t y " , encoder = eap . radi us_encod er ) : if s_block_start ( " truncate " , truncate = True ) : if s_block_start ( " Identity " , truncate = True ) : EAP_begin ( " Identity " , RESPONSE , 0 , IDENTITY ) # Header EAP s_string ( USERNAME , fuzzable = True ) s_block_end () s_block_end () s_block_end () # Identity
Fig. 16. Exemple de dnition dun champ de type EAP-Response/Identity e
Gestion des tats Nous nous reposons sur les standards IETF an de dcrire les e e tats atteignables par un client qui naurait pas de crdences dauthentication. Tous e e les tats sont atteignables car la vrication de lauthentication du client (par le e e serveur que ce soit en EAP-SIM ou EAP-AKA) est eectue dans le dernier envoi de e paquet EAP-Response. Ceci est tr`s important pour essayer datteindre un maximum e de parties du code de limplmentation du serveur RADIUS. e
L. Butti
261
s_initialize ( " SIM / Challenge " ) if s_block_start ( " no_encod er_SIM / Challenge " , encoder = eap . rad ius_enco der ) : if s_block_start ( " truncate " , truncate = True ) : if s_block_start ( " SIM / Challenge " ) : EAP_begin ( " SIM / Challenge " , RESPONSE , 1 , EAP_SIM , CHALLENGE ) # Header EAP SIM_attribute ( " AT_MAC " , " \ x00 " * 18) SIM_attribute ( " AT_IV " , " \ x00 " * 20 , reserved = True ) SIM_attribute ( " AT_RESULT_IND " , " " , reserved = True ) SIM_attribute ( " AT_ENCR_DATA " , " \ x00 " * 20 , reserved = True ) SIM_attribute ( " AT_PADDING " , " " ) s_block_end () s_block_end () s_block_end () # # # # # AT_MAC AT_IV AT_RESULT_IND AT_ENCR_DATA AT_PADDING
Fig. 17. Exemple de dnition dun champ de type EAP-Response/SIM/Challenge e
e e Dtection de dysfonctionnement Mme si nous privilgions le mode boite noire, e le fait que les serveurs RADIUS soient utilisables sur des syst`mes dexploitation e relativement ouverts , il est possible dutiliser les fonctions de Sulley pour attacher un dbogueur (dans notre cas PyDBG qui fait partie de la suite PaiMei [58]) au processus e qui sera audit. Nous avons donc ` la fois dvelopp une technique de dtection e a e e e derreur dimplmentation par envoi de stimulus sur la pile EAP distante (au-dessus e de RADIUS) et rutilis les fonctions de Sulley pour ventuellement attacher un e e e dbogueur lorsque cela est possible. e Le premier mode est ncessaire en boite noire et peut prsenter un probl`me e e e lorsque le processus est redmarr automatiquement en cas de plantage tandis que le e e deuxi`me mode est bien plus able et prcis car il remontera des informations sur le e e plantage grce au dbogueur. a e
10.4
Retour dexprience e
Tab. 5. Rsultats fuzzing dimplmentations EAP/EAP-SIM/EAP-AKA e e

Implmentation e EAP EAP-SIM EAP-AKA N/A 0 0 0 N/A ` A faire ` A faire N/A Cisco Secure ACS 4.1 Plusieurs dizaines Implmentation 1 e 0 Implmentation 2 e 0 FreeRADIUS 0
262
Rsultats Dans le tableau 5, nous prsentons le nombre de tests de fuzzing dclenchant e e e entra nant un dysfonctionnement de la part de limplmentation IKEv2 value. A e e e ` noter que plusieurs tests peuvent dclencher une seule et mme vulnrabilit. Dans e e e e le cas de la vulnrabilit dcouverte (CVE-2008-2441) il sagit dune seule et mme e e e e vulnrabilit dclenche par plusieurs tests de fuzzing. Ceci a pu tre identi grce a e e e e e e a ` une analyse par les rsultats de PyDBG et par une analyse des paquets mis (longueur e e avertie dans le champ longueur du paquet EAP). e Note 4. Ces rsultats sont incomplets dans la version actuelle de cet article, nous esprons pouvoir fournir des rsultats plus consquents lors de la prsentation et dans e e e e la version lectronique de larticle qui sera publie sur le site de la confrence. e e e Limitations Un fuzzer, mme volu, prsente gnralement un ensemble de limitae e e e e e tions. Les principales limitations de ce fuzzer sont : les champs fuzzs le sont de mani`re squentielle (pas de fuzzing de plusieurs e e e champs a fuzzer sur un mme test), ` e e e tous les tats du protocole EAP-AKA ne sont pas atteints (ncessitent des aspects cryptographiques), limplmentation de la machine a tat elle-mme nest pas fuzze, e è e e e e e e e` e e la dicult de corrler les tests dclenchant une vulnrabilit a la vulnrabilit elle-mme, e les vulnrabilits dclenches par une suite de tests sont diciles a analyser et e e e e ` rejouer. Malgr ces limitations, le fuzzer a permis de dcouvrir une vulnrabilit sur une e e e e implmentation EAP dun serveur RADIUS (CVE-2008-2441). e
11
Conclusions
Nous nous sommes eorcs dans cet article de prsenter quelques problmatiques e e e de scurit des architectures de Convergence Fixe-Mobile. Nous avons choisi de e e nous orienter vers la recherche de vulnrabilits dans les implmentations IKEv2 e e e et EAP/EAP-SIM/EAP-AKA dans lespoir de trouver des vulnrabilits en amont e e an de les faire corriger au plus vite par les constructeurs concerns. Les rsultats e e montrent, que malgr la thorique profondeur des fuzzers dvelopps, nous navons e e e e pas eu les rsultats habituels du fuzzing. En eet, pour ceux qui se rappellent du e fuzzing de drivers 802.11 ou autres (comme par exemple les lecteurs multimdia), e il susait de chercher un peu pour trouver rapidement des vulnrabilits (qui plus e e est intressantes26 ). Nous serions tent darmer que ces implmentations qui sont e e e
26
potentiellement exploitables.
L. Butti
263
relatives ` des produits scurit (et donc dvelopps par des socits vendant des a e e e e ee produits de scurit) sont peut-tre mieux dvelopps que les autres (ou pas !). e e e e e Sur la partie IKEv2, nous avons trouv plusieurs vulnrabilits (au minimum deux e e e vulnrabilits direntes) sur une seule implmentation parmi un total de cinq e e e e implmentations testes. Sur la partie EAP, nous avons trouv une seule vulnrabilit e e e e e sur quatre implmentations testes. Le bilan prouve le bon fonctionnement du fuzzer e e mais laisse toutefois un peu sur sa faim. . . Nous allons continuer a amliorer certaines ` e parties de nos fuzzers en particulier sur les ots de connexions, la machine a tats et è la dtection de dysfonctionnements, et dans tous les cas, seul lavenir nous dira si e nous avions raison ou pas !
12
Remerciements
Nous tenons a remercier Gabriel Campana pour ses recherches sur le fuzzing et ses ` dveloppements sur le sujet, Maryline Maknavicius pour avoir jou le rle de relecteur e e o SSTIC, Franck Veysset et Sbastien Nguyen Ngoc pour leurs relectures attentives. e
13
Aide nanci`re e
Ces travaux ont fait lobjet dune aide nanci`re de lAgence Nationale de la e Recherche (ANR) via le projet Future Internet Vulnerability Assessment, Monitoring and Prevention (VAMPIRE) ayant comme rfrence ANR-08-VERS-017 [63]. ee
Rfrences ee
1. RFC 4306, Internet Key Exchange (IKEv2) Protocol, http://tools.ietf.org/rfc/rfc4306.txt, 2005. 2. RFC 3748, Extensible Authentication Protocol (EAP), http://tools.ietf.org/rfc/rfc3748.txt, 2004. 3. RFC 2401, Security Architecture for the Internet Protocol, http://tools.ietf.org/html/rfc2401, 1998. 4. RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2, http://tools.ietf.org/html/rfc5246, 2008. 5. Journal ociel du 20 avril 2007, Implmenter, e http://www.journal-officiel.gouv.fr/verifier/getpdf.php?fic=../publication/2007/0420/joe_ 20070420_0093_0084.pdf.sig, 2007. 6. Radiocom 2000, http://fr.wikipedia.org/wiki/Radiocom_2000. 7. Tatoo, Tatoo : votre tribu garde le contact avec vous. , http://fr.wikipedia.org/wiki/Pager. 8. Bi-Bop, Bi-Bop, http://fr.wikipedia.org/wiki/Bibop. 9. Bluetooth, Bluetooth Special Interest Group, http://www.bluetooth.org.
264
10. IEEE 802.11, Local and Metropolitan Area Networks, Specic Requirements, Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications, http://standards.ieee.org/ getieee802/download/802.11-2007.pdf, 1997-2007. 11. IEEE 802.16-2004, IEEE Standard for Local and metropolitan area networks Part 16 : Air Interface for Fixed Broadband Wireless Access Systems, http://standards.ieee.org/getieee802/download/802. 16-2004.pdf, 2004. 12. IEEE 802.16e-2005, IEEE Standard for Local and metropolitan area networks Part 16 : Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands, http://standards.ieee. org/getieee802/download/802.16e-2005.pdf, 2005. 13. LTE, Long Term Evolution, http://www.3gpp.org/article/lte. 14. IPHOBAC, Integrated Photonic mm-Wave Functions for Broadband Connectivity, http://www. iphobac-survey.org. 15. ARCEP, Suivi des Indicateurs Mobiles, http://www.arcep.fr/fileadmin/reprise/\observatoire/ obs-mobile/2008/t4-2008/sim-t4-2008.pdf. 16. Union Internationale des Tlcommunications, Un nouvel indice UIT de dveloppement des TIC : comee e paraison entre 154 pays, http://www.itu.int/newsroom/press_releases/2009/07-fr.html, 2009. 17. Barkan, Elad ; Eli Biham ; Nathan Keller, Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication, http://cryptome.org/gsm-crack-bbk.pdf, 2003. 18. David Hulton, Intercepting shmoocon-Feb08-gsm.pdf, 2008. GSM Trac, http://blog.washingtonpost.com/securityfix/
19. 3GPP, Specication of the A5/3 Encryption Algorithms for GSM and ECSD, and the GEA3 Encryption Algorithm for GPRS ; Document 1 : A5/3 and GEA3 Specications., http://www.gsmworld.com/documents/a5_3_and_gea3_specifications.pdf. 20. ETSI, Universal Mobile Telecommunications System (UMTS) ; Specication of the 3GPP condentiality and integrity algorithms ; Document 2 : Kasumi specication, http://www.etsi.org/website/document/algorithms/ts_135202v070000p.pdf. 21. Ettus Research LLC, Universal Software Radio Peripheral, http://www.ettus.com. 22. The GNU Software Radio, GNU Radio, http://www.gnuradio.org. 23. Kestrel Signal Processing, Inc., The OpenBTS Project, http://openbts.sourceforge.net/. 24. Kestrel Signal Processing, Inc., The OpenBTS Project Wiki, http://gnuradio.org/trac/wiki/OpenBTS. 25. Wikipedia, Um interface, http://en.wikipedia.org/wiki/Um_Interface 26. 3GPP TS 33.102, 3G Security ; Security Architecture, http://www.3gpp.org/ftp/Specs/archive/33_series/33.102/33102-820.zip, 2008. 27. Natacha Mach et Franck Veysset, Convergence Fixe-Mobile : UMA (Unlicensed Mobile Access) sur le devant de la sc`ne ?, http://ed-diamond.com/feuille_misc31/index.html, 2007. e 28. Sandro Grech et Pasi Eronen, Implications of Unlicensed Mobile Access (UMA) for GSM security, http://ieeexplore.ieee.org/iel5/10695/33755/01607554.pdf, 2005. 29. 3GPP TS 23.234, 3GPP system to Wireless Local Area Network (WLAN) interworking ; System description (Release 8), http://www.3gpp.org/ftp/Specs/archive/23_series/\23.234/23234-800.zip, 2008. 30. 3GPP TS 33.234, 3G Security ; Wireless Local Area Network (WLAN) interworking security (Release 8), http://www.3gpp.org/ftp/Specs/archive/33_series/\33.234/33234-810.zip, 2008. 31. RFC 3261, SIP : Session Initiation Protocol, http://tools.ietf.org/html/rfc3261, 2222.
L. Butti
265
32. Yoann Guillot et Julien Tinn`s, System Level Intrusion Prevention System Evaluation Suite and Toolkit, e http://slipfest.cr0.org, 2006. 33. RFC 2409, The Internet Key Exchange (IKE), http://tools.ietf.org/rfc/rfc2409.txt, 1998. 34. 3GPP, 3GPP Service and Systems WG3 : Security, http://www.3gpp.org/SA3. 35. Barton Miller, Fuzz Testing of Application Reliability, http://pages.cs.wisc.edu/~bart/fuzz, 19882008. 36. Gadi Evron, the origin of the word fuzzing, http://lists.virus.org/fuzzing-0703/msg00014.html. e e e 37. Laurent Butti et Julien Tinn`s, Recherche de vulnrabilits dans les drivers 802.11 par techniques de fuzzing, http://actes.sstic.org/SSTIC07/WiFi_Fuzzing/, 2007. 38. MISCMAG 39, Dossier fuzzing, http://ed-diamond.com/feuille_misc39/index.html, 2008. 39. Codenomicon, DEFENSICS, http://www.codenomicon.com. 40. RFC 3748, Extensible Authentication Protocol (EAP), MD5-Challenge, http://tools.ietf.org/html/ rfc3748, 2004. 41. RFC 3748, Extensible Authentication Protocol (EAP), Generic Token Card, http://tools.ietf.org/ html/rfc3748, 2004. 42. Draft eap-mschapv2, Microsoft EAP CHAP draft-kamath-pppext-eap-mschapv2-02, 2007. Extensions, http://tools.ietf.org/html/
43. The MITRE Corporation, Common Vulnerabilities and Exposures, http://cve.mitre.org. 44. Cdric Blancher, Une faille est un bug comme les autres (ou presque). . . , e http://sid.rstack.org/blog/index.php/284-une-faille-est-un-bug-comme-les-autres-ou-presque, 2008. 45. CVE-2008-4551, xes a potential DoS attack if a DH value of zero gets processed, http://wiki.strongswan.org/browser/trunk/src/libstrongswan/plugins/gmp/gmp_diffie_ hellman.c?rev=4345. 46. Mu Dynamics, Mu Dynamics discovers, remediates leading Open Source VPN vulnerability : StrongSwan IKEv2 Denial-of-Service, http://www.mudynamics.com/news/press/pr091908.html. 47. Beno Stopin et Laurent Butti, Unspecied vulnerability in the Extensible Authentication Protocol (EAP) t implementation in Cisco IOS. . . , http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5651. 48. Gabriel Campana et Laurent Butti, Cisco Secure ACS 3.x. . . does not properly handle an EAP Response packet in which the value of the length eld exceeds the actual packet length. . . , http://cve.mitre.org/ cgi-bin/cvename.cgi?name=CVE-2008-2441. 49. Cdric Blancher et Simon Marchal, Packin the PMK, e e http://sid.rstack.org/pres/0810_BACon_WPA2_en.pdf, 2008. 50. IEEE 802.1X-2004, EEE Standard for Local and metropolitan area networks : Port-Based Network Access Control, http://standards.ieee.org/getieee802/download/802.1X-2004.pdf, 2004. 51. The Racoon2 Project, Raccon2, http://www.racoon2.wide.ad.jp/w/. 52. Wikipedia, Echange de cls Die-Hellman, http://fr.wikipedia.org/wiki/echange_de_cles_ e Diffie-Hellman. 53. CVE-2008-1113, Cisco and Vocera wireless LAN VoIP devices dont check certicates, http://cve. mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1113, 2008. 54. CVE-2008-1114, Cisco and Vocera wireless LAN VoIP devices dont check certicates, http://cve. mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1114, 2008. 55. Pedram Amini, Sulley Fuzzing Framework, http://code.google.com/p/sulley/.
266
56. RFC 5216, The EAP-TLS Authentication Protocol, http://tools.ietf.org/html/rfc5216, 2008. 57. IEEE 802.11i, Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specications Amendment 6 : Medium Access Control (MAC) Security Enhancements , http://standards. ieee.org/getieee802/download/802.11i-2004.pdf, 2004. 58. Pedram Amini, PaiMei, http ://code.google.com/p/paimei/. 59. RFC 4186, Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM), http://tools.ietf.org/rfc/rfc4186.txt, 2006. 60. RFC 4187, Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), http://tools.ietf.org/rfc/rfc4187.txt, 2006. 61. RFC 2865, Remote Authentication Dial In User Service (RADIUS), http://tools.ietf.org/rfc/ rfc2865.txt, 2000. 62. RFC 3588, Diameter Base Protocol, http://tools.ietf.org/rfc/rfc3588.txt, 2003. 63. VAMPIRE, Future Internet Vulnerability Assessment, Monitoring and Prevention, http://vampire. gforge.inria.fr/, 2008-2011.

B5 D4 CD 01

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

B5 D4 CD 01

Transféré par

Droits d'auteur :

Formats disponibles

Scurit des architectures de e e Convergence Fixe-Mobile

Laurent Butti laurent.butti(@)orange-ftgroup.com

Scurit des architectures de Convergence Fixe-Mobile e e

Introduction aux architectures de Convergence Fixe-Mobile

bien que soumises a approbation par lARCEP en France. `

Scurit des architectures de Convergence Fixe-Mobile e e

Aperu de la scurit des architectures GSM c e e

L. Butti 3.2 Condentialit des communications e

Scurit des architectures de Convergence Fixe-Mobile e e

Architectures de Convergence Fixe-Mobile

par rapport aux attaques pratiques.

Scurit des architectures de Convergence Fixe-Mobile e e

Fig. 3. Architecture Unlicensed Mobile Access (source : UMA Forum)

Fig. 4. Architecture Generic Access Network (source : 3GPP)

Fig. 5. Historique UMA (source : UMA Forum)

Scurit des architectures de Convergence Fixe-Mobile e e

Fig. 6. Architecture Interworking-WLAN (source : 3GPP) 5.3 IP Multimedia Subsystem

Fig. 7. Architecture IP Multimedia Subsystem (source : 3GPP)

Scurit des architectures de Convergence Fixe-Mobile e e

La cl de vo te de la scurit de ces architectures : lacc`s e u e e e

Eorts raliss sur le plan scurit e e e e

Scurit des architectures de Convergence Fixe-Mobile e e

comme diraient certains coll`gues. e

Recherche de vulnrabilits dans les implmentations par e e e techniques de fuzzing

Scurit des architectures de Convergence Fixe-Mobile e e Historique du fuzzing

Scurit des architectures de Convergence Fixe-Mobile e e

L. Butti Tab. 1. Vulnrabilits dimplmentations IKEv2 e e e

Tab. 2. Vulnrabilits dimplmentations EAP e e e

Scurit des architectures de Convergence Fixe-Mobile e e

Recherche de vulnrabilits dans les implmentations e e e IKEv2

Tab. 3. Vulnrabilits dimplmentations de mthodes EAP e e e e

Scurit des architectures de Convergence Fixe-Mobile e e

+ -+ -+ -+ -+ -+ + -+ -+ -+ -+ -+ ~! ~! IPsec ~! ~! ~! Protected ! tunnel ~! Tunnel ~! ~! Endpoint ~! < - - - - - - - - - - - - - - - - - - - - - - - - >! Endpoint ~! < - - ~! ~! ~! ~! + -+ -+ -+ -+ -+ + -+ -+ -+ -+ -+

Protected Subnet and / or Internet

Initiator ----------HDR , SAi1 , KEi , Ni

Responder ------------> <-HDR , SAr1 , KEr , Nr , [ CERTREQ ]

Initiator ----------HDR , SAi1 , KEi , Ni

Responder ------------> <-HDR , SAr1 , KEr , Nr , [ CERTREQ ]

--> <-HDR , SK { EAP ( success ) }

--> <-HDR , SK { AUTH , SAr2 , TSi , TSr }

252 9.3 Choix techniques

Scurit des architectures de Convergence Fixe-Mobile e e

Fig. 12. Exemple de dnition dun champ de type Key Exchange e

Scurit des architectures de Convergence Fixe-Mobile e e

Tab. 4. Rsultats fuzzing dimplmentations IKEv2 e e

Recherche de vulnrabilits dans les implmentations e e e EAP, EAP-SIM et EAP-AKA

Scurit des architectures de Convergence Fixe-Mobile e e

Description des protocoles EAP, EAP-SIM et EAP-AKA

Fig. 13. Authentication EAP-SIM compl`te (source : RFC 4186) e

Scurit des architectures de Convergence Fixe-Mobile e e

Fig. 14. Authentication EAP-AKA compl`te (source : RFC 4187) e

L. Butti 10.3 Choix techniques

Scurit des architectures de Convergence Fixe-Mobile e e

Fig. 15. Exemple de dnition dun champ de type en-tte EAP e e

Fig. 16. Exemple de dnition dun champ de type EAP-Response/Identity e

Fig. 17. Exemple de dnition dun champ de type EAP-Response/SIM/Challenge e

Tab. 5. Rsultats fuzzing dimplmentations EAP/EAP-SIM/EAP-AKA e e

Scurit des architectures de Convergence Fixe-Mobile e e

Scurit des architectures de Convergence Fixe-Mobile e e

Scurit des architectures de Convergence Fixe-Mobile e e

Vous aimerez peut-être aussi