Rapport Mensuel N 144

Transcription

1 Veille Technologique Sécurité Rapport Mensuel N 144 JUILLET 2010 Les informations fournies dans ce document ont été collectées et compilées à partir de sources d'origines diverses et publiquement accessibles: listes de diffusion, newsgroups, sites Web,... Ces informations sont fournies pour ce qu'elles valent sans garantie d'aucune sorte vis à vis de l'exactitude, de la précision ou de la qualité de l'information. Les URL associées à certains thèmes sont validées à la date de la rédaction du document. Dans ce numéro: La vulnérabilité.lnk L évolution de l ENISA La sécurisation des développements Windows Azure Le NIST et la sécurité des environnements virtualisés Le RFC5927 sur les attaques ICMP Les marques et les produits cités dans ce rapport sont la propriété des dépositaires respectifs. CONNECTING BUSINESS & T ECHNOLOGY CERT-DEVOTEAM Pour tous renseignements: 1, rue GALVANI Offre de veille Massy Palaiseau Informations vts-info@cert-devoteam.com CERT-DEVOTEAM - Tous droits réservés

2

3 Au sommaire de ce rapport ACTUALITES SECURITE SUR L UTILISATION DE RDMA 2 SANDISK SD-WORM 2 LA VULNÉRABILITÉ.LNK 3 ANALYSES ET COMMENTAIRES LOGICIELS THOR TGP V MAGAZINES ENISA - QUARTERLY REVIEW 7 METHODOLOGIES ET STANDARDS METHODES W3. ORG BONNES PRATIQUES DANS LE DEVELOPPEMENT D APPLICATIONS MOBILES 8 SYNTEC GUIDE CONTRACTUEL SAAS 9 RECOMMANDATIONS NIST - SP ' GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES 10 NIST - SP 'RECOMMENDATION FOR PASSWORD-BASED KEY DERIVATION - PART 1: STORAGE APPLICATIONS 11 MICROSOFT SECURISATION DES DEVELOPPEMENTS AZURE 12 NSA POLITIQUE DE RESTRICTION APPLICATIVE 13 SNAC CLOUD COMPUTING GUIDANCE 14 STANDARDS RFC ICMP ATTACKS AGAINST TCP 15 TABLEAUX DE SYNTHESE CONFERENCES USENIX 2010 ANNUAL TECHNICAL CONFERENCE 17 USENIX HOTCLOUD HITB AMSTERDAM CMU - SOUPS GUIDES CERTA NOTES ET AVIS 19 NIST ETAT DES GUIDES DE LA SERIE SPECIALE DISA GUIDES ET CHECK LISTES DE SECURISATION 21 CIS - CATALOGUE DE PROCEDURES ET DE TESTS 23 INTERNET LES DECISIONS DE L OMPI 24 STANDARDS IETF LES RFC TRAITANT DIRECTEMENT DE LA SECURITE 25 IETF LES RFC LIES A LA SECURITE 26 IETF LES NOUVEAUX DRAFTS TRAITANT DE LA SECURITE 26 IETF LES MISES A JOUR DE DRAFTS TRAITANT DE LA SECURITE 26 Veille Technologique Sécurité N 144 Page i

4

5 Le mot du rédacteur Dans un remarquable billet publié début juillet, Gary Warner, directeur de recherche à l université de Birmingham Alabama, détaille l incroyable montage mis au point par une bande d escrocs pour soutirer plus de 10 millions de dollars à quelques centaines de milliers de détenteurs de cartes de crédit depuis Le succès de l opération semble être lié à la stratégie retenue laquelle consistait à ne prélever que de très faibles sommes de 20 cents à 10 dollars sur un très grand nombre de transactions. L affaire menée devant la justice américaine la FTC (Federal Trade Commission) porte sur 1.3 million de transactions frauduleuses. Fin juillet, l équipe en charge de la sécurité chez Google a publié une intéressante prise de position sur le problème de la divulgation Disclosure d une vulnérabilité pointant du doigt les éditeurs et vendeurs qui prétextent d une divulgation responsable pour retarder le plus longtemps possible la publication d un correctif. Sans prendre position pour l une ou l autre des approches divulgation immédiate ou raisonnée les experts de Google militent en faveur de la mise en place d une période maximale de non divulgation. Au-delà d un délai 60 jours dans le cas de la politique Google et dans le cas d une vulnérabilité critique, l information sera publiée qu un correctif soit disponible ou pas. Deux jours plus tard, Microsoft annonçait à son tour la refonte de sa propre politique sans préciser toutefois aucun délai, le déclenchement d une annonce anticipée étant lié à la découverte d attaques exploitant la vulnérabilité. De son coté le fabuleux organisme de recherche à l origine de très grandes avancées dans le domaine de l informatique et des communications ces trente dernières années qu est l INRIA inaugure son laboratoire de haute sécurité LHS - dédié à la sécurité informatique. Au programme de recherche: l identification des codes malveillants, la supervision du changement dans les réseaux et la détection des vulnérabilités dans les systèmes communiquants. Notons pour terminer que la racine du DNS étant désormais signée, il peut être intéressant d activer la validation des noms de domaine. Une opération parfaitement décrite par Stéphane Bortzmeyer dans son billet Valider la racine du DNS. BERTRAND VELLE Veille Technologique Sécurité N 144 Page 1/32

6 ACTUALITES SECURITE SUR L UTILISATION DE RDMA Les enjeux économiques liés à l industrie du logiciel, et des jeux en particulier, ont conduit depuis bien longtemps les concepteurs à mettre en place divers mécanismes de protection contre la copie illicite. Ces mécanismes devront pouvoir résister le plus longtemps possible, idéalement sur toute la durée de vie du produit logiciel, à toutes les tentatives d analyse, tentatives illégales dans la majorité des pays sauf dans certaines conditions bien spécifiques, qui visent à comprendre le fonctionnement de la protection et à mettre en évidence d éventuelles vulnérabilités permettant de désactiver ou contourner celle-ci. Nombre de produits de protection contre la copie ont ainsi vu le jour allant du marquage physique du support difficilement reproductible sur la copie au déport de certaines fonctions dans un dispositif externe, dit Dongle, normalement inviolable. L expérience montre cependant que la grande majorité des dispositifs de protection finissent tôt ou tard par être désactivés ayant été bien souvent trop rapidement conçus et l attaquant ayant pour lui l indéniable avantage de disposer de beaucoup plus de temps et de ressources que l éditeur ne pourra jamais en engager. Certes des mécanismes de protection extrêmement robustes ont été conçus mais ceux-ci imposent bien souvent des contraintes non compatibles avec une diffusion à grande échelle et le faible coût du produit à protéger. Les sociétés d édition de logiciels mais aussi de produits multimédia ne sont pas les seuls usagers de tels systèmes de protection. Les auteurs de codes malveillants cherchent eux aussi à protéger leurs créations pour raisons tout aussi pragmatiques: retarder au maximum la publication d une alerte et de l antidote ad hoc par les éditeurs de produits de protection. L analyse d un code malveillant est ainsi devenue au fil du temps une opération de plus en plus complexe requérant du temps et des ressources de plus en plus importantes: outils plus ou moins spécifiques mais aussi environnements d exécution performants. Dans un billet intitulé Using RDMA during malware research, Udi Shamir chercheur au laboratoire d étude des malwares de COSEINC - aborde le problème de l analyse des codes malveillants par le constat de la relative inefficacité des approches classiques qui consistent à éliminer les protections les unes après les autres comme on pèlerait un oignon. L inefficacité se mesurant ici autant sur le plan technique qu économique au regard du temps nécessaire pour atteindre le code original. L alternative couramment utilisée consiste à charger le code dans un environnement d exécution spécifique, une machine virtuelle pour isoler celui-ci de l environnement, à lancer son exécution puis à vider la mémoire dans un fichier, une opération appelée dump mémoire. On obtiendra ainsi une image du processus, et donc du code original, débarrassé des protections installées au chargement, compression ou chiffrement des données. Cette approche ne permet toutefois pas d observer le comportement du code en temps réel, les mécanismes de protection anti-débogage étant encore présents. La lecture d un article consacré à RDMA (Remote Direct Memory Access), un mécanisme autorisant un accès direct à la mémoire physique d un système via le réseau, a conduit Udi Shamir à se poser la question de l utilisation de cette approche dans le contexte de l analyse des logiciels malveillants. Une approche dont la viabilité a pu être confirmée après que l auteur se soit délesté d une centaine de dollars pour l achat sur ebay d une carte Ethernet 10Gb supportant cette fonctionnalité. Publié le dimanche 4 juillet, l article n était plus accessible sur le site Offensive Computing trois jours après. Espérons qu il ne s agit que d un problème technique passager, et non du retrait définitif d un billet fort intéressant. L article reste cependant accessible pour l instant ici dans le cache du moteur Google. SANDISK SD-WORM Les mémoires à fusible, dites mémoires mortes avaient pour caractéristique de pouvoir conserver indéfiniment en théorie du moins les données inscrites lors de la programmation. Une technique de stockage, dite WORM (Write Once Read Many ou Ecriture une fois, Lecture multiple), qui a trouvé une réelle consécration avec l arrivée sur le marché de supports de stockage optique, dits CDROM, générés par pressage d un support maître. Une véritable révolution au regard de la capacité de stockage offerte mais aussi de la sécurité offerte par ce support, nul n étant à même de le reproduire, ou Veille Technologique Sécurité N 144 Page 2/32

7 de le modifier, à faible coût à l époque de la mise sur marché. Les grands éditeurs, SUN, IBM et HP en tête, ont très rapidement découvert l intérêt de ce support lequel permettait de tirer un trait sur les astucieuses attaques menées dans les années 80 contre les grands fournisseurs de systèmes d exploitation. Celles-ci consistaient à substituer aux bandes de mise à jour transmises par courrier des bandes identiques mais contenant un système compromis par l intégration d un cheval de Troie. Le CD-Rom devenait ainsi un support de distribution certifié, du moins jusqu à l invention des supports réinscriptibles. Cette fonctionnalité d écriture un fois et de lecture multiple bien utile pour conserver l intégrité de l information enregistrée aura ainsi disparu avec l apparition du CD-RW, puis des DVD-RW et depuis peu des disques BlueRay. Conscient de la nécessité de pouvoir proposer un support inaltérable à long terme tout en étant accessible à tous et offrant une capacité de stockage en accord avec les besoins actuels, la société SanDisk a mis au point un dispositif de stockage électronique technologie FLASH permettant de sauvegarder 1Go de données en garantissant l inaltérabilité de celles-ci. L annonce de presse publiée par SanDisk précise que ce dispositif, qui prend la forme d une carte SD, a été immédiatement adopté par les forces de l ordre japonaises pour le stockage des photos prises dans le cadre de leurs enquêtes. Le choix du format SD est loin d être anodin, celui-ci étant accepté par la grande majorité des appareils numérique semi-professionnels et professionnels. L installation d une carte SD WORM dans un appareil numérique permettra de garantir l intégrité et l indestructibilité de toutes les informations inscrites au moment de la prise de vue, l image bien entendu mais aussi les métadonnées associées dont les paramètres de prise de vue et bien souvent les coordonnées GPS du lieu photographié. Plus largement, et bien que la capacité actuellement offerte soit encore un peu faible, cette technologie trouvera probablement sa place dans tous les secteurs nécessitant la garantie qu une information stockée ne puisse plus jamais être effacée, ni modifiée: photo, mais aussi scan de documents papiers, fichiers saisis. On conservera cependant à l esprit que, s agissant d une rétention électronique de données utilisant semble-t-il la technologie Flash, le mécanisme de protection sera très probablement embarqué dans le microprocesseur assurant l interface entre le bus SD et les composants mémoires. Le niveau de sécurité réel dépendra donc de la sécurisation du code du microprocesseur - lequel pourrait bien être stocké en mémoire reprogrammable - mais aussi des fonctions de débogage ou de test en post production qui pourraient être accessibles sur le bus SD ou sur un bus interne à la carte. s-write-once-readmany- worm -sd-card--stores-images-for-up-to-100-years LA VULNERABILITE.LNK La découverte d une vulnérabilité dans la gestion des raccourcis Windows Fichiers d extension.lnk et l exploitation qui s en est suivie, aura généré un très important bruit de fond sur tous les sites traitant de sécurité. L avis de sécurité publié à ce propos par Microsoft aura ainsi fait l objet de 2 révisions en l espace de quelques jours. A l origine de ce problème, l un des nombreux mécanismes d aide à l exploitation intégrés à l interface de présentation désignée sous le terme générique de Windows Shell. Plutôt que d entrer dans les détails techniques de cette vulnérabilité identifiée par Microsoft dans son bulletin d alerte , détails disponibles sur Internet, nous nous proposons de dresser un rapide historique de l évolution de l interface graphique Windows. Notre objectif est ici d attirer l attention sur la fragilisation de cette interface par les multiples fonctionnalités qui lui ont été greffées au fil du temps pour des raisons ergonomiques mais aussi de compatibilité avec l existant. Avec la mise sur le marché de l environnement Windows 3.1, Microsoft s est trouvé confronté à l obligation de maintenir l accès aux applications MSDOS, et ceci de la manière la plus transparente possible à l usager de l environnement Windows. Microsoft a donc spécifié un format de fichier système, dit Program Information File, ou PIF, contenant toutes les informations permettant d engager l exécution d un programme MSDOS depuis l environnement Windows en modifiant si nécessaire certains paramètres d exécution. L usager pouvait ainsi lancer une application MSDOS d un simple double clic sur la représentation graphique on ne parlait pas encore d icône - du fichier.pif associé à l application cible. En mode ligne de commande, l interpréteur recherchait en priorité la présence d un fichier PIF de Veille Technologique Sécurité N 144 Page 3/32

8 même nom que l application devant être lancée, et chargeait celui-ci en lieu et place de l application quand bien même l utilisateur aurait explicitement précisé l extension de l application (.com ou.exe ). Les auteurs de codes malveillants ont à l époque très rapidement compris le parti qu ils pouvaient tirer de cette facilité, et des failles associées à diverses erreurs de conception, dont en particulier la non-prise en compte de l extension dans la recherche de l application à charger, et l existence d une stratégie de recherche spécifique (.bat puis.pif puis.com et enfin.exe si nos souvenirs sont exacts). Cette approche, s expliquant parfaitement dans le contexte de l optimisation de l ergonomie, a permis la création des virus dits compagnons prenant le nom d une application connue et s attribuant une extension plus prioritaire dans l ordre de recherche. Windows 95 aura vu l élargissement du mécanisme des fichiers.pif en autorisant la création d un lien actif ou raccourci vers une quelconque ressource du système. Il devenait ainsi possible de lancer une quelconque application MSDOS mais aussi Windows - depuis son bureau, ou de n importe quel point de l arborescence locale, par le biais d un fichier système spécifique doté de l extension.lnk, sans plus avoir à dupliquer physiquement l exécutable. Un double clic sur le nom du fichier de raccourci, ou sur sa représentation graphique désormais configurable, permettait de lancer l application référencée par le lien, ou l application associée à l extension dans le cas d un lien pointant sur un fichier de données. L interface graphique des systèmes NT4 et Windows 98 a généralisé le concept de fonctions s activant automatiquement sans aucune intervention directe de l usager, généralement à des fins d amélioration de l ergonomie de l interface graphique. Citons notamment le système des Bulles d aide ou Tooltips permettant l affichage automatique d une information contextuelle par une application active lorsque le curseur de la souris est positionné sur l icône de cette application, ou encore le mécanisme permettant à l explorateur de fichier de modifier au cas par cas le rendu des informations par le biais des informations présentes dans un fichier de configuration optionnel masqué, desktop.ini, pouvant être installé dans n importe répertoire. Autant de mécanismes qui auront fait, ou ferons, le bonheur des concepteurs de virus et autres logiciels malveillants. Les systèmes suivants auront vu la généralisation du mécanisme du raccourci aux volumes distants ou amovibles avec l ajout de nouvelles fonctionnalités déclenchées sur événements: insertion d un support amovible dans le lecteur de CD ou dans un connecteur USB, création d un partage réseau, ouverture d une connexion réseau, Ici encore autant de fonctionnalités bien pratiques à l usage quotidien mais offrant autant de possibilités d exécution non sollicitée d un code non contrôlé. Un premier pas dans la protection de l usager a été fait par Microsoft il y a seulement quelques mois avec la mise à disposition d un utilitaire permettant d invalider la fonction d activation automatique à l insertion d un support amovible, fonction dite autorun, sans plus avoir à devoir manipuler localement, ou via une politique groupe, la base de registre. Un premier pas seulement, car cette modification de configuration n invalide nullement les fonctionnalités activées sur événement. Qu un problème soit découvert dans une fonctionnalité de ce type qui permette d engager l exécution d un code tiers, sur le déclenchement d une action attachée au déplacement du curseur sur une icône par exemple, et c est l intégrité du système qui sera immédiatement mise en cause. Avec pour facteur aggravant l incapacité de l usager de parer à la menace voir même d en être simplement informé. Dans le cas de la vulnérabilité objet de l alerte Microsoft Vulnerability in Windows Shell Could Allow Remote Code Execution, le problème réside dans l absence de certaines vérifications lors du chargement de l icône associée au raccourci. Un attaquant peut alors créer de toute pièce un fichier de raccourci contenant un code malicieux (en l occurrence une ressource pointant sur une librairie dynamique, ou DLL, en lieu et place du fichier graphique de l icône) qui sera automatiquement exécuté lors du chargement de l icône pour affichage par l explorateur de fichiers (Windows Explorer) mais aussi par toute autre application offrant cette fonctionnalité pour les fichiers de raccourci: Internet Explorer, la suite Office, la messagerie Outlook et probablement bien d autres logiciels. L attaque peut être portée par le biais de multiples supports auquel l accédant aurait accès, dont bien entendu les clefs USB et disques amovibles mais aussi les partages réseaux ou WEBDAV. Deux moyens de protection peuvent être mis en place pour réduire le risque dans l attente d un correctif officiel de la part de Microsoft: - utiliser le mécanisme de restriction d exécution des applications ou Software Restriction Policy ou SRP. Ce mécanisme est parfaitement décrit dans le document Application Whitelisting using Software Restriction Policies publié par la NSA et commenté dans ce même rapport. Sa mise en œuvre dans le cas de cette faille est parfaitement documentée par Didier Stevens dans un article intitulé Mitigating.LNK Exploitation With SRP, - pour les usagers des systèmes Windows 7 et 2008, utiliser l application Microsoft AppLocker similaire à SRP mais offrant une meilleure granularité dans la configuration dont le blocage des librairies dynamiques (DLL), un must dans le cas qui nous préoccupe, - s appuyer sur une application de protection tierce assurant un filtrage des requêtes d accès aux fichiers avant que ceux-ci ne soient chargés pour exécution. Didier Stevens, toujours lui, met à disposition ARIAD, un utilitaire minimaliste s intégrant dans la chaîne des gestionnaires des périphériques de Veille Technologique Sécurité N 144 Page 4/32

9 stockage afin de contrôler les actions autorisées. Outre le fait que l auteur rappelle qu il ne peut garantir que l installation de son utilitaire ne provoquera pas de dysfonctionnement sur le système, cette solution reste insatisfaisante sur le plan des restrictions d exécution. Activée, l option interdira l accès aux fichiers ayant pour extension LNK mais aussi de la majorité des extensions usuelles, à savoir BAT, CMD, COM, CPL, DLL, EXE, OCX, PIF, SCR, SYS, VB, VBE, VBS, WSF et WSH. Acceptable dans le cas d un support amovible, cette protection s avèrera probablement trop restrictive s agissant de volumes réseaux. Note de dernière minute: Microsoft a publié un correctif temporaire qui a pour effet d interdire le chargement de l icone référencée par les fichiers.lnk et.pif. Après application du correctif, les icônes associées à ces fichiers seront remplacées par un fond blanc Veille Technologique Sécurité N 144 Page 5/32

10 ANALYSES ET COMMENTAIRES LOGICIELS THOR TGP V1.2.3 Comme Timothy Mullen le développeur l indique, l utilitaire TGP fait tout ce que fait PGP mais le fait différemment. On peut alors se poser la question de l intérêt de ce logiciel si l auteur ne précisait qu il l avait conçu avec l idée de proposer une application plus adaptée à l évolution des systèmes d information dont en particulier l informatique dans les nuages. Comme le fait remarquer l auteur de ce logiciel, la délocalisation des données et la mobilité accrue de l usager conduit à devoir envisager d oublier le concept de fichier de données pour se focaliser sur les données elles-mêmes, quitte à s appuyer sur un cadre de présentation structurant tel XML. Dans sa forme basique, TGP chiffre un flux de données fourni par l usager et retourne un container prenant la forme d une structure XML contenant toutes informations de contexte requises ainsi que les données chiffrées encodées au format base64. Il est alors possible d insérer cette structure dans n importe quel document, un mail, une page WEB Cependant, la fonctionnalité la plus intéressante est très certainement l évaluation de la qualité du mot de passe laquelle est présentée, non sous la forme d une échelle graduée comme cela est le cas avec de nombreux outils - dont le gestionnaire de mots de passe KeePass - mais sous forme numérique en indiquant une estimation du temps requis pour parcourir toutes les combinaisons possibles, en considérant un système capable de dérouler 1 milliard de tests par seconde, ou système de classe F selon la classification établie par le réseau de calcul distribué distributed.net. Le succès de cette fonctionnalité a d ailleurs conduit l auteur à la proposer indépendamment sous la forme d une application WEB permettant de valider la robustesse d un mot de passe ou d une passe-phrase. Il va de soin que l on évitera d utiliser celle-ci pour valider ses propres mots de passe s agissant d une application WEB externalisée dont rien ne permet de garantir que les données fournies ne soient pas enregistrées. Développé en environnement.net, TGP requiert la présence de la version 4 du RunTime.NET. Celui-ci 43Mo - peut être installé à partir du paquetage proposé par l auteur du logiciel, ou depuis le centre de téléchargement Microsoft, solution qu il conviendra de préférer. Nous n émettrons aucune opinion sur la qualité et la fiabilité de cet outil dont les sources ne sont pas disponibles. Veille Technologique Sécurité N 144 Page 6/32

11 MAGAZINES ENISA - QUARTERLY REVIEW Le second numéro de l année 2010 de la revue de l ENISA a été publié mi-juin. Il conserve la ligne éditoriale allégée mise en place en mars dernier à la suite de la prise de poste du nouveau directeur de l ENISA. En prenant la décision de plus faire appel aux contributions externes pour donner la parole à ses collaborateurs, la direction de l ENISA a fait un pari qu il parait difficile de tenir sur le long terme. Avec seulement quatre articles politiquement corrects par numéro sur une périodicité trimestrielle, la revue EQR risque de perdre une partie de son lectorat, celle qui, comme nous, appréciait la multiplicité des sujets traités sous différents angles de vue. Cette évolution va de pair avec celle du rôle assigné à l ENISA. Le directeur de l ENISA souligne en introduction que le rapport sur l Europe Digitale publié en mai dernier confirme l importance du rôle de son agence. D agence simplement chargée de développer la culture de la sécurité des réseaux d information en favorisant l échange des meilleures pratiques et en facilitant les contacts entres les entreprises et les institutions nationales et européennes, l ENISA est amenée à endosser un rôle plus opérationnel dans la gestion des incidents, la prévention des attaques et la lutte contre la cybercriminalité. Le directeur de l ENISA rappelle par ailleurs la décision par l agence de participer activement à la transposition par les états membres de l article 13a du nouveau paquet télécom. Inscrit au chapitre IIIa Security And Integrity Of Networks And Services de la directive 2002/21/EC, cet article impose aux Etats Membres de mettre en œuvre tous les moyens requis pour assurer la sécurité et l intégrité des services de communication mais aussi d informer les autorités de régulation nationales des autres états, et l ENISA, de toute brèche dans la sécurité ou l intégrité qui aurait un impact significatif sur le fonctionnement des services et des réseaux de communication. Mais revenons au contenu de ce numéro. Le premier article intitulé Quantum Key Distribution propose un intéressant état de l art en matière de distribution quantique de clefs de chiffrement. On appréciera particulièrement la mise au point sur ce qu est cette technologie en introduction de l article. L article suivant Who Will Patch my Mum s PC pose le problème que tous nos lecteurs auront vécus un jour, celui de la mise à jour des machines de nos proches, lesquels sont loin d être des spécialistes de la sécurité, voire de l informatique tout court. Richard Clayton, un chercheur de l université de Cambridge, s interrogeait dernièrement sur la meilleure approche pour combattre les malwares et faire le ménage sur ces millions de machines non réellement administrées pour conclure en l intérêt d une intervention indirecte de l Etat (Rapport N 143 Juin 2010). Et de fait, il ne suffira probablement pas de compter sur le taux de renouvellement des systèmes personnels pour éliminer rapidement tous les équipements compromis, ou sur le point de l être, car utilisant un système d exploitation obsolète. Peut être faudra-t-il envisager l adoption d une prime de mise à la casse, et d un système contrôle technique obligatoire pour réduire le risque dans des proportions acceptables. L article n aborde hélas nullement ces possibilités se limitant à rappeler qu il existe des systèmes de mise à jour automatique, et des outils de remédiation proposés par différents éditeurs. Certes mais encore faut-il se mettre dans la peau de l usager lambda qui a déjà bien du mal à interpréter les messages d information délivrés par les différents systèmes de protection présents sur sa machine, anti-virus, anti-phishing, contrôle parental Avec l article Toward the First Pan-European Exercise on Critical ICT Infrastructure Protection, l ENISA met en lumière l importance d une bonne préparation à la gestion d une crise. La mise en place d exercices réguliers permettra d affiner non seulement les scénarios de gestion mais aussi d établir le niveau de confiance requis entre les acteurs et de qualifier la qualité de la communication avec des entités de culture, de langue natale et de localisation géographique différente, huit pays (DK, FI, FR, HU, IT, PT, SE, UK) dans le cas de cet exercice. Tout un programme. Dernièrement, l ENISA a mis à jour son annuaire listant les entités en charge de la sécurité des réseaux et des systèmes d information dans les états membres le Who-is-Who Directory on Network and Information Security ainsi que les fiches détaillées par pays les Country Reports. Un travail laborieux mais absolument nécessaire qui nous est présenté dans le dernier article intitulé Putting together the pieces of the NIS puzzle in Europe. A Letter from the Executive Director Quantum Key Distribution Who Will Patch my Mum s PC Toward the First Pan-European Exercise on Critical ICT Infrastructure Protection ENISA s country report: Putting together the pieces of the NIS puzzle in Europe Veille Technologique Sécurité N 144 Page 7/32

12 METHODOLOGIES ET STANDARDS METHODES W3. ORG BONNES PRATIQUES DANS LE DEVELOPPEMENT D APPLICATIONS MOBILES Le 'World Wide Web Consortium' - W3C publie pour relecture et commentaires un guide à destination des concepteurs d applications Web mobiles, développeurs mais aussi graphistes ou autres acteurs intervenant dans le processus de réalisation. Diffusé au format HTML, et intitulé Mobile Web Application Best Practices, ce guide prend la forme d un inventaire détaillé des recommandations et bonnes pratiques qu il conviendra de suivre pour produire une application de qualité, fiable et sûre. Il vient compléter le guide Mobile Web Best Practices, ou MWB, publié en 2008 qui lui se focalisait sur les spécificités de la navigation depuis un dispositif mobile. La thématique de la sécurité de l environnement et des données est très (trop) rapidement abordée: - au chapitre Security & Privacy lequel conseille de ne pas utiliser la fonction JavaScript eval() sur des données au format JSON qui n auraient pas préalablement été assainies mais de plutôt s appuyer sur un interpréteur dédié, - au chapitre User Awareness and Control lequel insiste sur la nécessité d informer l usager lorsque l application doit accéder à des données privées ou de configuration de l équipement. Il est par ailleurs rappelé que les applications susceptibles d ouvrir automatiquement une session authentifiée (Automatic Sign-in) doivent offrir un mécanisme permettant à l usager de forcer la déconnexion. Le sommaire de ce document d environ 24 pages est le suivant: 1 Introduction 1.1 Purpose of the Document 1.2 Audience 1.3 Scope Best Practices Web Application Mobile Context Delivery Context 1.4 Relationship to other Best Practices and recommendations 1.5 Terminology 2 Structure of Best Practice Statements 3 Best Practice Statements 3.1 Application Data Use Cookies Sparingly Use Appropriate Client-Side Storage Technologies for Local Data Replicate Local Data 3.2 Security and privacy Do not Execute Unescaped or Untrusted JSON data 3.3 User Awareness and Control Ensure the User is Informed About Use of Personal and Device Information Enable Automatic Sign-in 3.4 Conservative use of resources Use Transfer Compression Minimize Application and Data Size Avoid Redirects Optimize Network Requests Minimize External Resources Aggregate Static Images into a Single Composite Resource (Sprites) Include Background Images Inline in CSS Style Sheets Cache Resources By Fingerprinting Resource References Cache AJAX Data Do not Send Cookie Information Unnecessarily Keep DOM Size Reasonable 3.5 User Experience Optimize For Application Start-up Time Minimize Perceived Latency Design for Multiple Interaction Methods Preserve Focus on Dynamic Page Updates Veille Technologique Sécurité N 144 Page 8/32

13 3.5.5 Use Fragment IDs to Drive Application View Make Telephone Numbers "Click-to-Call" Ensure Paragraph Text Flows Ensure Consistency Of State Between Devices Consider Mobile Specific Technologies for Initiating Web Applications Use Meta Viewport Element To Identify Desired Screen Size 3.6 Handling Variations in the Delivery Context Prefer Server-Side Detection Where Possible Use Client-Side Detection When Necessary Use Device Classification to Simplify Content Adaptation Support a non-javascript Variant if Appropriate Offer Users a Choice of Interfaces 3.7 Further Considerations Consider Use Of Canvas Element or SVG For Dynamic Graphics Inform the User About Automatic Network Access Provide Sufficient Means to Control Automatic Network Access Appendix Appendix 1: Best Practice Dependent Device Properties Appendix 2: References Appendix 3: Acknowledgments SYNTEC GUIDE CONTRACTUEL SAAS Le SYNTEC Informatique a rédigé un guide destiné aux fournisseurs et utilisateurs des offres dites de SaaS - Software as a service. Ce document de 23 pages propose un modèle de contrat spécifiquement étudié pour cette forme de prestation de service. Les engagements du fournisseur en termes de performance, de disponibilité et de sécurité du service sont négociables. Ils feront l objet d un document - engagement de service (SLA) ou charte de qualité - annexé au contrat apportant toutes les précisions techniques et quantitatives nécessaires.. Les points devant être impérativement traités à ce titre sont détaillés dans l annexe du guide. Sont par contre explicitement décrits les devoirs et obligations des deux parties en matière de gestion des données: - l article 11 détaille les engagements sur le traitement des données, - l article 12 précise les conditions permettant au client d engager un audit technique, - l article 14 stipule que le client reste propriétaire des données qu il utilise via le service. Ce dernier point apparaît être essentiel au regard des législations américaine en particulier - qui transfèrent implicitement l entière propriété des données traitées au fournisseur de service. Le GUIDE CONTRACTUEL SaaS est accessible sur le site du Syntec Informatique aux membres correspondants de cette association mais il peut également être téléchargé librement sur le site Réseaux-Télécom. La table de matière du modèle de contrat SaaS établie par le Syntec Informatique est la suivante: Art. 1 Definitions Art. 2 Objet Art. 3 Documents contractuels Art. 4 Effet, duree et reconductions Art. 5 Description des services applicatifs 5.1 Solutions applicatives 5.2 Réseau 5.3 Accès aux solutions Art. 6 Qualité des applicatifs Art. 7 Licence Art. 8 Maintenance Art. 9 Assistance technique Art.10 Formation Art.11 Traitement des données 11.1 Données personnelles 11.2 Exploitation des données 11.3 Sécurité des données Art.12 Audit technique Art.13 Conditions financières 13.1 Redevances 13.1 Modalités de paiement Veille Technologique Sécurité N 144 Page 9/32

14 13.1 Défaut de paiement Art.14 Propriété Art.15 Garantie d eviction Art.16 Responsabilité force majeure Art.17 Assurances Art.18 Résiliation Art.19 Réversibilité Art.20 Non-sollicitation de personnel Art.21 Confidentialite Art.22 Divers Annexe - Charte Qualité RECOMMANDATIONS NIST - SP ' GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES Le NIST vient de publier, pour relecture, le guide SP dit Guide to Security for Full Virtualization Technologies. Le NIST défini la virtualisation comme étant l émulation du fonctionnement d un logiciel et/ou d un matériel par un autre logiciel et la virtualisation complète, la Full Virtualization dans le jargon, comme étant l extension de ce concept à tout ou partie des composants d un système d information, à savoir l émulation du fonctionnement d un ou plusieurs systèmes d exploitation et des applications sur une plateforme matérielle pouvant elle-même être émulée. Le guide SP se focalise sur la sécurisation de cette dernière forme d émulation, la plus couramment rencontrée s agissant de systèmes de production et des services offerts par l informatique nébuleuse. Deux modèles peuvent ensuite être identifiées qui diffèrent par la présence d un système d exploitation au niveau le plus bas: le modèle hosted lorsque l environnement est hébergé par un système d exploitation, et le modèle bare metal quand le service est directement rendu par le matériel. Sans se prononcer sur l approche, le NIST rappelle qu il y a lieu de mettre en regard les indéniables avantages qu offre le principe de la virtualisation efficacité économique et opérationnelle en particulier - et les inconvénients liés à l augmentation des charges d exploitation et d administration, un facteur de surcoût non négligeable si l on tient compte des contrôles de sécurité additionnels imposé par l architecture. Le NIST considère que la sécurisation d un environnement virtualisé serveur ou poste de travail passe par l application des quatre règles suivantes: 1- Sécuriser tous les éléments de la solution en maintenant leur sécurité, 2- Restreindre et protéger les accès administratifs à la solution, 3- S assurer que l hyperviseur le code minimaliste assurant l émulation - est correctement sécurisé, 4- Etudier avec soin la sécurité de la solution avant même de l installer, de la configurer et de la déployer. Quatre règles triviales mais dont la mise en pratique, qui n est déjà pas évidente au sein d une architecture classique, a bien peu de chance d être facilitée dans le contexte d une technologie offrant une souplesse incomparable en matière de reconfiguration et de réorganisation. Le sommaire de ce guide de 35 pages est le suivant: 1. Introduction 2. Introduction to Full Virtualization 2.1 Motivations for Full Virtualization 2.2 Types of Full Virtualization 2.3 Virtualizing Hardware Virtualized Networking Virtualized Storage Guest OS Images 2.4 Full Virtualization Use Cases Server Virtualization Veille Technologique Sécurité N 144 Page 10/32

15 2.4.2 Desktop Virtualization 3. Virtualization Security Overview 3.1 Guest OS Isolation 3.2 Guest OS Monitoring 3.3 Image and Snapshot Management 4. Security Recommendations for Virtualization Components 4.1 Hypervisor Security 4.2 Guest OS Security 4.3 Virtualized Infrastructure Security 4.4 Desktop Virtualization Security 5. Secure Virtualization Planning and Deployment 5.1 Initiation 5.2 Planning and Design 5.3 Implementation 5.4 Operations and Maintenance 5.5 Disposition NIST - SP 'RECOMMENDATION FOR PASSWORD-BASED KEY DERIVATION - PART 1: STORAGE APPLICATIONS Publiée pour commentaire par le NIST, cette très courte recommandation - 18 pages - traite de l art de générer, à partir d une information secrète ou mot de passe choisi par l usager, une clef de chiffrement qui respectera les exigences applicables en matière de cryptographie. Une opération plus compliquée qu il peut y paraître en première approche. Il s agit en effet de transformer dériver sans le jargon - une information de longueur quelconque, et contenant généralement beaucoup de redondance, en une succession de bits la plus aléatoire possible et dont la longueur est imposée par l algorithme de chiffrement utilisé. Une telle transformation est rendue absolument nécessaire par l inaptitude de l être humain à mémoriser une importante séquence aléatoire à 512 bits voir plus quand bien même celle-ci serait exprimée en code hexadécimal, un encodage relativement efficace utilisant les chiffres de 0 à 9, et les lettres de A à F. Les fonctions assurant cette transformation, dites PBKDF ou Password-Based Key Derivation Functions, sont désormais utilisées dans tous les équipements de communication ou applications offrant une fonction de chiffrement: périphériques WiFi ou Bluetooth pour les équipements les plus classiques mais aussi les applications de messagerie ou de sécurisation des données dont, par exemple, le célèbre utilitaire de chiffrement TrueCrypt. De la qualité de cette fonction de transformation dépendra la résistance de la protection aux attaques en force: que la fonction n introduise pas assez d entropie dans la séquence générée, en fixant par exemple la valeur de certains bits, et l espace des clefs à parcourir en sera d autant réduit. La recommandation SP officialise l utilisation de l algorithme PBKDF2 spécifié en 2000 par la société RSA, algorithme détaillé dans le RFC2898 PKCS #5: Password-based Cryptography Specification version 2.0. Elle en diffère par l autorisation d utiliser n importe quelle fonction pseudo-aléatoire, ou PRF, ayant été approuvée par le NIST quand la spécification initiale imposait l utilisation de l algorithme SHA-1 lequel doit désormais être considéré comme obsolète au regard des attaques connues. Dernièrement, l annonce de l échec du FBI dans le déchiffrement du contenu de disques durs chiffrés avec TrueCrypt a mis en exergue l importance du choix d une bonne clef de chiffrement, et dans ce cas précis, de l algorithme de dérivation, lequel se trouve justement être PBKDF2. John Leyden auteur d un excellent article dans le quotidien The Register concluait à ce propos avec justesse: that case is an illustration of how care in choosing secure (hard-to-guess) passwords and applying encryption techniques to avoid leaving file fragments that could aid code breakers are more important in maintaining security than the algorithm a code maker chooses. Le sommaire du SP est le suivant: 1. Introduction 2. Authority 3. Definitions, Acronyms and Symbols 3.1 Definitions 3.2 Acronyms 3.3 Symbols 4. General Discussion Veille Technologique Sécurité N 144 Page 11/32

16 5. Password-Based Key Derivation Functions 5.1 The Salt (S) 5.2 The Iteration Count (C) 5.3 PBKDF Specification 5.4 Using the Derived Master Key to Protect Data 6 References Appendix A Security Considerations A.1 User-Selected Passwords A.2 Selection of the PBKDF A.2.1 Length of the Salt A.2.2 Iteration Count A.3 Protection of DPK MICROSOFT SECURISATION DES DEVELOPPEMENTS AZURE Microsoft vient de mettre à disposition le guide Security Best Practices for Developing Windows Azure Applications. Ce document de 26 pages au format docx liste les bonnes pratiques et recommandations permettant de développer une application Windows Azure dans les meilleures conditions de sécurité. Par application Windows Azure on entendra une application Windows conçue pour tirer parti de l environnement d hébergement, de services et d exécution d applications délocalisées du même nom. On appréciera particulièrement les annexes B et C. L annexe B, intitulée Windows Azure Deployment Security Threat Matrix propose un inventaire des différentes menaces, et des contre-mesures susceptibles d être mises en place lorsque cela est possible. Sont ainsi indiqués pour chacune des 36 menaces identifiées et organisées en 6 catégories - usurpation, falsification, répudiation, fuite d information, déni de service et élévation de privilèges: l emplacement de la contre-mesure dans l architecture, la nature de la contre-mesure proposée par la plateforme, la nature de la contre-mesure devant être intégrée à l application, et enfin, une indication de l incidence du choix de la technologie sur le niveau de risque. Un code de couleur permet de caractériser la nature de la mesure: transparente à l utilisateur, fournie par l infrastructure et devant être explicitement activée, devant être traitée dans le code de l utilisateur, planifiée mais non encore implémentée et transparente à l utilisateur, planifiée mais non encore implémentée et devant être activée par l utilisateur. L annexe C, Excerpt from the Windows Azure Partial Trust Policy Reference liste les grandes différences existant entre la politique de gestion des autorisations implémentée en environnement ASP.NET et celle proposée en environnement Windows Azure. Le sommaire de ce document de 26 pages est le suivant: Executive Summary Intended Audience Overview Of Windows AZURE Security-Related Platform Services Identity Management And Access Control Windows Identity Foundation Active Directory Federation Services 2.0 Windows AZURE Platform Appfabric Access Control Service Designing More Secure Windows AZURE Services Windows Azure Service-Layer Security Considerations Namespace Configuration Issues Data Security Handling Secret Information Auditing And Logging Request Throttling / Input Sanitization Windows Azure Platform- & Infrastructure-Layer Security Protections Port scanning/ service enumeration Denial of service Spoofing Eavesdropping / packet sniffing Multi-tenant hosting and side-channel attacks External verification Runtime security: role separation and process privileges in full trust vs. Windows AZURE partial trust Putting It All Together: Creating More Secure Windows Azure Applications Isolate web roles & separate duties of individual roles in order to maximize the use of AZURE partial trust. Use the gatekeeper design pattern to separate role duties and isolate privileged access Use multiple storage keys to restrict access to privileged information Applying SDL Practices To Windows Azure Applications Veille Technologique Sécurité N 144 Page 12/32

17 Security education and awareness Secure development practices on the windows azure platform Verification and release Conclusion Additional Resources Appendix A: Glossary Appendix B: Windows Azure Deployment Security Threat Matrix Appendix C: Excerpt From The Windows Azure Partial Trust Policy Reference Appendix D: Using SDL-Approved Cryptography In Windows Azure Applications NSA POLITIQUE DE RESTRICTION APPLICATIVE La division IAD (Information Assurance Directorate) de la célèbre NSA vient de publier un dossier de 23 pages expliquant comment mettre en œuvre le mécanisme de restriction d accès aux applications Windows, dit Software Restriction Policies ou SRP. Disponible sous Windows XP et Server 2003, ce mécanisme peut-être configuré localement - stratégie de sécurité locale sur un système XP ou globalement via une politique de groupe pour les systèmes Server Il est ainsi possible de mettre en place efficacement, mais aussi rapidement, une stratégie de protection permettant de restreindre la capacité de propagation d une menace en contrôlant explicitement les applications autorisées à s exécuter. Face à la menace croissante des malwares, et à la difficulté rencontrée pour contenir ceux-ci aux frontières d un système d information de plus en plus ouvert, la NSA considère que la stratégie de la défense en profondeur permet toujours d obtenir un excellent niveau de protection. La mise en place d une liste des applications autorisées liste blanche - permet de dresser une ligne de défense qui ne se substituera pas aux autres barrières de sécurité mais viendra les épauler. Pour que cette approche soit réellement efficace: - l exécution de toutes les applications doit pouvoir être interdite par défaut, - les utilisateurs ne doivent pas pouvoir exécuter une application située dans leur répertoire de travail, - les utilisateurs ne doivent pas pouvoir disposer de privilèges administrateurs. Le mécanisme SRP, intégré au système Windows depuis la version XP, respecte ces trois contraintes permettant non seulement de lister explicitement les applications autorisées à s exécuter mais aussi les librairies dynamiques, DLL dans le jargon, pouvant être chargées par ces applications. Le guide Application Whitelisting using Software Restriction Policies détaille la procédure à suivre pour activer le mécanisme de protection et installer les configurations recommandées par l IAD et le SNAC. Trois cas particuliers, trois exceptions à la règle devrait-on dire, sont traités en annexe: exécution depuis un support CD/DVD, exécution depuis un répertoire partagé et exécution depuis un répertoire accessible en écriture par l usager. Les scripts développés par le DoD pour faciliter la mise en œuvre de cette stratégie dont en particulier l inscription de la liste des applications autorisées pour chaque usager - sont par ailleurs mis à disposition dans un fichier d archive librement téléchargeable. L utilisation de ces scripts n est pas documentée mais les paramètres devant être modifiés pour s adapter à l environnement cible sont regroupés en tête de chaque fichier, et commentés. Aucune liste blanche n est proposée par défaut. Le SNAC suggère d établir celle-ci à partir d un inventaire des applications exécutées sur les serveurs du domaine. Le mécanisme de restriction sera ensuite activé sur une liste réduite qui sera mise à jour au fur et à mesure des demandes. Une approche très classique bien plus facile à mettre en œuvre dans une organisation par nature sensibilisée à la sécurité que dans les structures civiles. Le sommaire de ce document de 23 pages est le suivant: Introduction About this Guide Related Tools Known Issues Implementation Audit the Domain to Determine which Applications are Running Configure SRP to Run in Whitelisting Mode Create SRP Rules for Authorized Applications Test SRP Test Allowed and Disallowed Paths Troubleshoot Rules Deploy SRP throughout the Organizational Unit Hierarchy Monitor SRP Appendix A: Allow Execution from CD and DVD Drives Veille Technologique Sécurité N 144 Page 13/32

18 Appendix B: Allow Execution from Shared Folders Appendix C: Allow Execution from a User Writable Path Appendix D: SRP Known Issues and Workarounds SNAC CLOUD COMPUTING GUIDANCE Le centre de gestion et de réponse aux incidents de la NSA le SNAC ou Systems and Network Attack Center vient de mettre en ligne un court mémo 8 pages consacré à l Informatique Nébuleuse. Gageons que la NSA s est très rapidement intéressée à cette nouvelle vision de l organisation des infrastructures de gestion de l information, et aux capacités de traitement instantanément mobilisables qu elle offre. Cet opuscule est d ailleurs daté du 18 décembre Après une courte présentation des différentes formes d interaction et de service proposées par cette approche application, plateforme ou infrastructure le SNAC aborde le problème de fond de l informatique nébuleuse: le transfert du risque, et de la confiance, hors du périmètre contrôlé et contrôlable par l organisation, en particulier s agissant de ressources fournies par, et à travers Internet. Le SNAC attire l attention sur les points qu il conviendra de traiter avant de prendre la décision de migrer tout ou partie de son système d information dans les nuages: - Trust Boundary: jusqu où s étend la confiance que l on peut accorder au fournisseur, celui-ci pouvant parfaitement lui-même s appuyer sur des services nébuleux fournis par des tiers, - Access Control: comment le contrôle d accès est-il maintenu à travers les services nébuleux, et qu elle est le niveau d isolement des usagers, - Incident Handling: quelles sont les responsabilités des fournisseurs quand un incident de sécurité est identifié, ou une vulnérabilité détectée, - the ilities : le fournisseur offre-t-il le niveau de service requis en terme de fiabilité (reliability), disponibilité (availability) et qualité (quality). Le SNAC imagine le cas de figure d une injonction du FBI conduisant à la saisie d équipements mutualisés dans un Datacenter, - Data backup: les sauvegardes des données et des fichiers de configuration sont-elles sous la responsabilité du fournisseur ou de l utilisateur, - Data purging: est-il possible de s assurer que les données détruites le sont effectivement sans qu aucune trace ne subsiste dans la nébuleuse et dans les sauvegardes, - Security management: quel est le responsable de la gestion de la sécurité s agissant d une infrastructure tierce complexe mélangeant équipements réseaux, systèmes d exploitation, application et outils, - Provider s pedigree: comment le fournisseur a-t-il, par le passé, géré les problématiques de sécurité, de gestion des incidents et de disponibilité, - Data rights: quelles sont les droits attachés aux données résidant dans les nuages. Le SNAC précise que certains contrats de service transfèrent tous les droits au fournisseur pour une durée illimitée, - Accreditation: les exigences relatives à certaines accréditations ou obligations légales interdiction de transfert ou de stockage de certaines données hors frontières - peuvent-elles être assurées, - Business Continuity: que ce passera-t-il pour les données, mais aussi pour les applications de traitement éventuellement associées, si le fournisseur se déclare en faillite ou cesse ses activités. Les contre-mesures susceptibles de limiter certains risques sont listées qui vont d une utilisation réduite, et strictement réglementée des services nébuleux jusqu à l utilisation de services privés comprendre n utilisant aucun service publique rendu sur Internet. Le SNAC termine sa présentation en recommandant la lecture du guide Security Guidelines for Critical Areas of Focus in Cloud Computing publié par la Cloud Security Alliance. Le sommaire de ce court mémo de 8 pages est le suivant: Cloud Technology Introduction Veille Technologique Sécurité N 144 Page 14/32

19 Information Assurance Concerns Countermeasures Information Assurance Opportunities In Closing References STANDARDS RFC ICMP ATTACKS AGAINST TCP Edité par Fernando Gont de l université de technologie national UTN de Buenos Aires, le RFC5927 ICMP Attacks Against TCP s intéresse aux attaques susceptibles d être portées par le protocole ICMP (Internet Control Message Protocol) qu il s agisse de la version attachée au protocole IPV4 spécifiée par le RFC792 ou de la version spécifique au protocole IP V6 spécifiée par le RFC4443. Ce protocole est bien connu des administrateurs et exploitants mais aussi des internautes qui l utilisent sans le savoir à travers la célèbre commande ping laquelle permet de vérifier la connectivité entre deux équipements et d obtenir une mesure du temps de propagation d un paquet. Encore ne s agit-il ici que d un cas très particulier d utilisation, le rôle du protocole ICMP étant de fournir le service de notification d erreur nécessaire au bon fonctionnement du réseau IP, et des protocoles de niveau supérieur, TCP et UDP. Qu une destination ne puisse être atteinte, ou qu un service ne soit pas accessible, et un message de notification au format ICMP sera transmis à destination de l émetteur dans un paquet IP. Les données techniques contenues dans ce message permettront d informer l émetteur de la nature et de l origine du problème, facilitant ainsi la gestion des erreurs au sein du réseau. Les concepteurs du protocole ont prévu que celui-ci puisse aussi fournir un service de signalisation activable sans aucun contrôle d aucune sorte par n importe quel équipement du réseau. L envoi d un paquet contenant une requête ICMP à destination d un équipement identifié par son adresse IP provoquera en retour la transmission d un message contenant les données techniques demandées, ou la notification d une erreur. La spécification de la version 4 du protocole ICMP définie ainsi quelques 18 messages de contrôle dont 6 messages de requête parmi lesquels le célèbre ICMP ECHO REQUEST utilisé par la commande ping. La mise à disposition d un mécanisme de requête permettant d obtenir différentes données techniques sur un équipement distant ainsi que l absence de mécanisme de contrôle de l utilisation s est avérée poser un vrai problème de sécurité quand, de réseau communautaire ouvert animé par le monde de la recherche universitaire, Internet est devenu le réseau de communication mondial que l on connait. Les erreurs de conception qui ne posaient guère de problème dans un environnement de confiance sont devenues rédhibitoires. Celles-ci permettaient par exemple de cartographier un réseau distant, d obtenir des bribes d information en provenance de la mémoire de l équipement dans certains messages, le buffer de données n étant pas vidé entre deux utilisations pour des raisons d optimisation de la performance, de saturer un équipement en le bombardant de requêtes ou encore d exploiter quelques débordements de buffer. Autant d atteintes à la sécurité et à la fiabilité inimaginables à la haute époque où un bogue de programmation ne pouvait provoquer d autres choses qu un dysfonctionnement de l application. Les préconisations de sécurité ont alors très rapidement conduit à limiter au maximum l usage du protocole ICMP. Autorisé dans le réseau privé il est difficile de se passer d un outil de gestion aussi pratique le protocole ICMP s est vu filtré autant que peut se faire sur les équipements de raccordement à l Internet complexifiant la tâche des équipes en charge de la gestion opérationnelle des réseaux. L état de l art en matière de sécurité du protocole ICMP proposé par le RFC5927 vient à point rétablir les faits, en particulier s agissant d ICMPv6 quand le protocole IPv6 est en passe d être adopté par tous les grands fournisseurs d accès et les grands consommateurs de connectivité. Dans son billet ICMP attacks against TCP, Stéphane Bortzmeyer, encore lui, propose une excellente relecture commentée d un document de fond et de référence. Nous recommandons la lecture de ce billet à tous nos lecteurs qui seraient rebutés par le format des publications de l IETF. Le sommaire de cette étude de 36 pages est le suivant: Veille Technologique Sécurité N 144 Page 15/32

20 1. Introduction 2. Background 2.1 The Internet Control Message Protocol (ICMP) ICMP for IP version 4 (ICMPv4) ICMP for IP version 6 (ICMPv6) 2.2 Handling of ICMP Error Messages. 2.3 Handling of ICMP Error Messages in the Context of IPsec 3. Constraints in the Possible Solutions 4. General Counter-Measures against ICMP Attacks 4.1 TCP Sequence Number Checking 4.2 Port Randomization 4.3 Filtering ICMP Error Messages Based on the ICMP Payload 5. Blind Connection-Reset Attack 5.1 Description 5.2 Attack-Specific Counter-Measures 6. Blind Throughput-Reduction Attack 6.1 Description 6.2 Attack-Specific Counter-Measures 7. Blind Performance-Degrading Attack 7.1 Description 7.2 Attack-Specific Counter-Measures 7.3 The Counter-Measure for the PMTUD Attack in Action Normal Operation for Bulk Transfers Operation during Path-MTU Changes Idle Connection Being Attacked Active Connection Being Attacked after Discovery of the Path-MTU TCP Peer Attacked when Sending Small Packets Just after the Three-Way Handshake 7.4 Pseudo-Code for the Counter-Measure for the Blind Performance-Degrading Attack 8. Security Considerations 9. Acknowledgements 10. References Veille Technologique Sécurité N 144 Page 16/32