La JSSI 2009 ("Journée de la Sécurité des Systèmes d'Information" - organisée par l'association OSSIR) s'est déroulée le 17 mars 2009 à Paris. Le Cert-IST a assisté à cette conférence qui a réuni une centaine de participants autour du thème : "Les nouveaux visages de l'insécurité informatique". Les sujets abordés couvraient des domaines très étendus tel que la sécurité des solutions SAAS (Software As A Service), la gestion de la réputation dans un environnement ouvert et communicant Web 2.0, ou la sécurité des mondes virtuels.

Globalement, les sujet abordés étaient denses, et le rythme des présentations très soutenu, ce qui a fait de cette journée SSI un moment très intéressant.

Ce compte-rendu ne présente pas le détail technique de chacune des présentations et s'attache surtout à exposer les idées directrices relevées par le Cert-IST. Les supports présentés seront disponibles sous peu sur le site officiel de la JSSI-2009.

Malware sur Second Life, mythe ou réalité ? (F. Paget - McAfee)

L'orateur explique que sa présentation complète celle, plus générale, qu'il avait faite en 2008 à l'EICAR. Cette fois il s'est intéressé à étudier si il était possible de transposer dans les mondes virtuels les malwares déjà connus dans "la vraie vie".

Comme on peut s'y attendre, la réponse est "oui", et plusieurs programmes de démonstration ont été présentés pour l'illustrer :

• Le verre spammeur : Il s'agit d'un verre virtuel qui, s'il est ramassé par un avatar (un personnage représentant un utilisateur) dans un monde virtuel, se met à envoyer du spam dans le monde réel. Il s'agit donc de l'illustration d'un Cheval de Troie adapté aux mondes virtuels qui transporte une action malfaisante (spam) interagissant avec le monde extérieur.
• Le ver : Pour démontrer la possibilité d'un code autoreproducteur dans un monde virtuel, l'orateur a développé un objet virtuel qui se démultiplie (il se clone) dès qu'il est touché par un avatar.
• Le virus : De même il est possible d'imaginer des objets malicieux qui tenteraient d'infecter d'autres objets du monde virtuels.  Les prototypes actuels dans cette catégorie nécessitent cependant la collaboration (involontaire) des avatars et il ne semble pas encore possible d'avoir un code infectant totalement autonome.
• Le vol et le phishing : Le dernier prototype démontre qu'il serait possible de voler l'argent virtuel que transporte un avatar en ayant recours à des techniques d'ingénierie sociale.

Globalement, les recherches effectuées montrent que les mondes virtuels ne sont pas à l'abri des malfaisances virales bien connues dans le monde réel.

Les enjeux de l'e-reputation (S. Koch - Intelligentzia.net)

L'entreprise est depuis toujours exposée à des risques :

• d'atteinte à son image (perte de réputation),
• de fuite de données.

Cependant ce phénomène est désormais très largement amplifié avec les nouveaux outils du Web 2.0 (forum, blogs et réseaux sociaux). Ces outils sont largement présents sur Internet et ils sont utilisés par un nombre croissant d'employés d'entreprises. En postant un message dans un blog ou sur un forum, un employé peut nuire à la réputation de son entreprise ou transmettre des informations sensibles. L'orateur a mis en évidence l'opposition qui existe de facto entre le monde "fermé" de l'entreprise et le monde "libre" sur Internet. Quand il navigue sur Internet l'employé se trouve plongé dans un environnement totalement différent de celui de l'entreprise, et il peut y adopter des attitudes complètement irrationnelles par rapport à son attitude au sein de l'entreprise.

L'orateur a donné de nombreux exemples des risques informationnels  sur Internet ("profiling", désinformation) et mis en avant que les internautes :

• ont souvent un comportement de consommateur plutôt que d'utilisateur raisonnable. Pour avoir accès à ce qu'il veut le consommateur est prêt à accepter des clauses déraisonnables (comme d'abandonner à Facebook tout droit de propriété sur ce qu'il publie dans l'environnement Facebook).
• n'ont pas conscience que leurs publications peuvent avoir une large audience et qu'une fois publiée l'information n'est plus maitrisable.

Plutôt que d'interdire  l'utilisation de ces outils, l'orateur recommande des actions de sensibilisation et d'éducation sur le bon usage du web 2.0.

Filtrer et loguer, yes we can ! (E. Barbry – Avocat)

Cette présentation a pour objectif de répondre à la question : une entreprise a-t-elle le droit de filtrer et de "logguer" (journaliser) les communications informatiques.

L'orateur décrit le référentiel juridique applicable et met en évidence qu'il n'y a pas de réponse claire dans le droit applicable français. Par exemple les décrets devant préciser les modalités techniques d'application de la LCEN (Loi pour la Confiance dans l'Economie Numérique) publiée en 2004 ne sont toujours pas disponibles.

Malgré ce flou juridique l'orateur dit qu'il est impératif de filtrer et de journaliser, parce que ne pas le faire sera considéré comme une négligence de la part de l'entreprise. Il recommande donc de décrire dans des chartes internes à l'entreprise les règles d'utilisation autorisées (règles de bon usage) ainsi que les règles de filtrage et de journalisation. Il est important que ces chartes soient en phase avec l'actualité en intégrant les problèmes contemporains  (mobilité des utilisateurs, web 2.0, …). Il propose un modèle de charte appelé "4G" qui développe les chartes suivant 4 axes d'analyses. On se reportera aux supports de présentation pour plus de détails.

Si le discours ici n'est pas totalement nouveau (cf. la présentation [2] mentionnée dans le  compte-rendu Cert-IST pour la JSSI 2007), il est intéressant de noter que :

• Le discours est désormais très clairement "Une entreprise doit impérativement mettre en place une politique claire de filtrage et de journalisation".
• Il apparaît maintenant de nouvelles préoccupations, comme celle du maintien des preuves (quelles mesures doivent être prises pour garantir l'intégrité des indices collectés).

Virtualisation et sécurité (N. Ruff - EADS)

La présentation s'est intéressée essentiellement à la sécurité des environnements VMware. Selon une étude publiée en 2009 par Forrester, VMware est en effet largement en tête en termes de parts de marché (98%) devant Microsoft, et Citrix/Xen. Il semble également être l'environnement le plus mûre par sa stabilité et sa fiabilité. L'orateur a présenté une analyse des différents types de failles que l'on peut rencontrer dans un environnement virtualisé. Nous ne reprenons pas ces aspects et nous nous focaliserons sur les messages qui nous paraissent les plus importants.

L'environnement est le plus le plus gros facteur de risque.

La majorité des problèmes qui peuvent survenir dans un projet de virtualisation sont les risques "environnementaux" induits par cette migration. Par exemple :

• les outils de supervision existant peuvent ne pas marcher correctement pour un environnement virtualisé,
• les procédures existantes (sauvegardes, plan de reprise, etc…) doivent être adaptées,
• l'administrateur du serveur hébergeant les systèmes virtualisés devient un super-utilisateur qui contrôle l'ensemble de tous les serveurs,

Nota : L'orateur désigne ces risques sous la catégorie "risques humains", mais nous avons adopté ici le terme plus large de "risques environnementaux".

Cet aspect environnemental est très important et ne doit pas être négligé. Plusieurs guides de migration existent pour prendre en compte ces aspects (par exemple les guides du NIST ou les cours dispensés par VMware).

 La virtualisation introduit une ressource critique : le serveur hôte

Quand beaucoup de serveurs sont virtualisés sur un même système hôte, ce dernier devient une ressource critique puisque son arrêt entraine une indisponibilité de tous les systèmes hébergés. La moindre intervention sur le site hôte (par exemple pour l'application d'un correctif de sécurité) devient alors risquée (impact possible sur la disponibilité).

Le niveau de sécurité d'un environnement virtualisé est forcement plus faible que celui de systèmes physiques autonomes.

D'un point de vue technique l'environnement virtualisé introduit une couche d'abstraction supplémentaire : le système hôte qui héberge les serveurs virtualisés. Cette couche induit des vulnérabilités potentielles qui diminuent le niveau de sécurité théorique d'un environnement virtualisé. Une architecture virtualisée ne peut donc pas (d'un point de vue technique) être plus sûre qu'un système natif.

La sécurité des plates-formes ASP / SAAS (Y. Allain - opale-security.com)

Cette présentation s'est intéressée au niveau de sécurité des solutions SAAS ("Software As A Service"), également désignées sous le terme de ASP ("Application Service Provider"). Le principe d'une solution SAAS est que le service rendu à l'entreprise n'est plus hébergé in-situ : il est disponible au travers d'une interface web sur le site du fournisseur.

L'orateur indique que le niveau de sécurité des solutions SAAS n'est pas toujours satisfaisant mais que ce type de solution correspond à un véritable besoin pour beaucoup d'entreprises. Refuser en bloc le SAAS (du fait de ses lacunes en sécurité) n'est donc probablement pas approprié. En particulier certains services n'existent aujourd'hui de façon satisfaisante qu'en mode SAAS (l'orateur donne comme exemple le cas de la gestion de trésorerie dans un contexte multinational et la gestion des forces de vente). Il convient donc d'adopter une approche pour maitriser le risque lié à l'utilisation de ce type de solution.

Le retour d'expérience de l'orateur sur ce domaine est qu'il faut :

• Etre pragmatique.
• Travailler en transparence.
• Prévoir des clauses juridiques.
• Faire des tests d'intrusion.

Le constat sur le terrain est que les 2 tiers des applications SAAS qui ont été analysées présentaient des défauts significatifs de sécurité. En particulier :

• Les fonctions de sécurité proposées sont souvent faibles. Par exemple le contrôle d'accès est couramment fait au moyen d'un simple couple "Login/Password". Or cette méthode d’authentification est en décalage avec le niveau de sécurité que l'on met généralement en place pour un accès distant aux ressources de l'entreprise ("token" d'authentification fort couramment utilisé pour les accès VPN).
• Les fournisseurs ont assez souvent une faible culture sécurité.
• L'effort du fournisseur en terme de sécurité est souvent concentré sur la sécurité de l'infrastructure (mise en place d'équipement pour renforcer la sécurité) alors qu'il existe parfois de gros défauts applicatifs (vulnérabilité dans le service web). Un transfert d'une partie de cet effort vers la sécurité applicative est largement souhaitable.

 Les rootkits navigateurs (C. Devaux et J. Lenoir – Sogeti)

Nota : Ce sujet sur les rootkits a également été présenté à Hack.Lu 2008 et aux TechDays 2009 de Microsoft.

 Il s'agit de la présentation de travaux réalisés par le pôle R&D de Sogeti ESEC. L'objectif de l'étude était d'analyser la possibilité d'insérer un rootkit au sein d'un navigateur web. Deux maquettes opérationnelles ont été développées comme démonstrations:

• un rootkit pour Firefox. Il s'agit d'une extension malicieuse (fichier ".xpi") que l'utilisateur installe par mégarde (attaque par ingénierie sociale). Cette extension se rend invisible puis utilise les primitives disponibles sous Firefox (XPCOM) pour voler les mots de passes et les cookies, ou dialogue avec Internet via un code Javascript standard (XMLHttpRequest) .
  Ce rootkit met en évidence un défaut majeur de Firefox : aucun mécanisme n'existe actuellement pour limiter les actions que peut entreprendre une extension malicieuse. Nota : En 2006, le Cert-IST a publié un article à propos du danger que représentent les extensions Firefox. 
• un rootkit pour Internet Explorer. Ce rootkit utilise des techniques d'injection de code classiques pour installer le code malicieux au sein d'Internet Explorer. La possibilité de développer ce rootkit sous forme d'un BHO (Browser Helper Object) a en effet été écartée car ce mécanisme ne disposait pas des facilités requises. Aspect intéressant, ce rootkit pour Internet Explorer crée un onglet caché qui lui permet de réaliser facilement les actions dont il a besoin et de corrompre les caches internes d’IE pour augmenter les privilèges de cet onglet.

Nota : La démonstration du rootkit pour IE a été réalisée sous Windows XP, et non sous Vista (qui dispose de fonctions de sécurité supplémentaires comme le "mode protégé").

Les fonctions de hachage, un domaine à la mode (T. Peyrin - ingenico.com)

Cette présentation très technique explique de façon détaillée les fonctions de hachage (du défunt MD4 jusqu'au futur SHA-3) et retrace l'histoire de leurs vulnérabilités.

Le présentateur explique en particulier que tous ces algorithmes sont basés sur une architecture commune, ce qui pourrait expliquer que ces algorithmes aient pu être "cassés" (au moins en théorie) en chaine à partir de 2004 (voir à ce sujet l'article "<!--[if gte vml 1]>