Compte rendu de la Journée Sécurité des Systèmes d'Information 2009

Wed 18 March 2009 by christophe

logo-ossir.png

Mardi 17 mars avait lieu à Paris la journée sécurité organisée par l'OSSIR, l'Observatoire de la Sécurité des Systèmes d'Information et des Réseaux. Julien et moi-même étions présents afin de présenter nos travaux sur les rootkits navigateurs. Voici un résumé de la journée.

Malware sur Second Life, mythe ou réalité ?

par François Paget, Senior Virus Research Engineer (McAfee Avert Labs)

François commence son exposé par une présentation générale des mondes virtuels. Il précise que Gartner prévoit qu'en 2011 80 % des internautes auront une vie dans un monde virtuel. Chaque mois, 9 millions de dollars changent de main dans ces mondes virtuels. Cependant, comme partout ailleurs, il existe différentes menaces, externes ou internes à ces mondes. François nous présente ensuite quelques attaques qu'il a pu réaliser à l'intérieur de Second Life, monde virtuel créé par Linden Lab en 2003 :

Sur Second Life, on commence par créer son avatar, l'habiller et lui ajouter des attributs. Tout est payant, et il faut donc avoir des Linden Dollars pour acheter des objets ou des caractéristiques. On peut aussi créer ses propres objets et les scripter en utilisant LSL (Linden Scripting Language) afin qu'ils s'animent lors d'un événement. Ces scripts peuvent être protégés par un mot de passe et invisibles pour un autre utilisateur qui récupérerait l'objet.

Une première application de ceci est la création d'un objet capable d'envoyer du SPAM. Ici, François a créé un objet ressemblant visuellement à un verre qui envoie un email dès qu'un joueur l'utilise. Linden Lab a limité l'utilisation de cette fonction d'envois d'emails, llEmail(), mais cette limitation peut être contournée en utilisant des threads. On a donc un objet capable d'envoyer plus ou moins anonymement des emails en masse.

Le même principe est utilisé pour lancer des attaques de type DDoS, en remplaçant la fonction llEmail() par llHTTPRequest().

François s'est ensuite attaqué, avec succès, à la création d'un ver, c'est-à-dire d'un objet qui serait capable de se dupliquer quand un utilisateur le toucherait par exemple. Linden Labs a réagit en stoppant la réplication d'un objet si celui-ci fait trop d'appels à la fonction llRezObject() utilisée ici. Cependant, cette protection est toujours contournable en utilisant un timer.

Pour créer un virus, c'est à dire un objet qui en infecterait d'autres en y injectant son script, François a utilisé la fonction llGiveInventory() qui permet de connaître l'inventaire de la personne qui récupère l'objet, et llSensor() pour rechercher des objets ou personnes dans un périmètre donné. L'infection fonctionne, le script est bien ajouté aux objets de l'utilisateur, mais une validation manuelle est nécessaire pour l'exécuter. Cette fois-ci, la protection mise en place par Linden Lab ne semble pas contournable.

François présente ensuite un outil disponible sur Internet appelé CopyBot, capable de cloner des avatars rencontrés dans le jeu. Le programme, formellement interdit dans le jeu, permet d'exporter localement l'apparence d'un joueur (vêtements, cheveux, etc.) pour pouvoir la réimporter ensuite. L'intérêt est aussi de pouvoir cloner des objets créés par des utilisateurs. La duplication des avatars permet en l'occurrence de gonfler les statistiques de trafic de certains lieux pour les faire apparaitre en tête des sites de recherche. D'après les recherches de François, cette pratique serait courante et un grand nombre d'avatars sur Second Life serait en réalité des bots.

Le Phishing est le dernier point évoqué : en faisant croire à un joueur qu'un objet va lui permettre de doubler la valeur de son portefeuille, un objet malveillant est capable d'aspirer l'intégralité du portefeuille pour envoyer l'argent récolté à l'attaquant. Lors de l'utilisation de l'objet, celui-ci va lui demander s'il peut prendre 1 Linden Dollar pour fonctionner ; si l'utilisateur accepte, alors l'intégralité de son compte est vidée automatiquement.

François conclut finalement en affirmant qu'il n'existe aucune protection à l'intérieur des univers en ligne, mis à part la récente protection de Symantec pour World of Warcraft.

Les enjeux de l'e-reputation

par Stéphane Koch, Internet Strategy Consultant (intelligentzia.net)

Stéphane Koch nous présente les risques humains liés aux réseaux sociaux et les nouveaux enjeux de la réputation qui ressort des traces qu'on laisse sur ces réseaux. Il commence par faire un état des lieux, dans lequel il rappelle que le contenu de ce qu'on appelle le Web 2.0 reste difficilement maitrisable et qu'une information se diffuse très rapidement. Ces informations peuvent, d’une façon générale, porter préjudice à une entreprise ou à un individu.

Trois facteurs principaux sont présentés comme un danger pour l’information. En premier lieu le facteur technologique : il est devenu très simple d’exfiltrer de l’information d’une entreprise (téléphones appareils photo, clés USB, etc.). En second lieu le facteur de la connaissance : quels que soient les moyens techniques mis en place, ils seront, un jour ou l’autre, mis en échec par l’évolution de l’état de l’art. En dernier lieu l’aspect humain : l’information se diffuse de façon très rapide sur le web « 2.0 », de façon déstructurée et repose sur l’émotion et non sur le fond.

L’intervenant nous explique qu’il faut une nouvelle approche pour sécuriser l’information. Cette approche est basée sur le flux d’information : son emplacement, les droits d’accès, sa méthode de stockage plutôt que sur les droits d’un utilisateur. Stéphane Koch y associe l’idée d’identité numérique.

Pour conclure sa présentation, M. Koch rappelle qu’interdire les réseaux sociaux ne sert à rien, mais qu’il faut sécuriser l’entreprise en sécurisant le facteur humain par de la sensibilisation et de la formation. Il nous met finalement en garde : contrairement à d’autres médias, les informations publiées sur le web 2.0 sont susceptibles de réapparaitre un jour ou l’autre grâce à une simple recherche sur un moteur de recherche.

Filtrer et loguer, yes we can !

par Éric Barbry, Avocat au Barreau de Paris

Maître Barbry nous présente la problématique du filtrage et du log des informations qui est une problématique de premier plan, alors que le Tribunal de Paris a décidé le 5 mars 2009 qu’une adresse IP permettait d’identifier un abonné.

Dès le début de la présentation, nous faisons face à un problème de base : celui de la définition. En effet, il n’est pas défini en termes juridiques français le log d’information. Quant au filtrage, plusieurs interprétations sont possibles. De surcroit, le filtrage et le log mis en place dans les institutions ont pour but principal le monitoring (données de trafic ou de connexion), qui n'est pas toujours en adéquation avec les besoins des juristes qui recherchent des preuves valables devant un tribunal.

Maître Barby aborde ensuite les obligations dites « évidentes » c'est-à-dire celles pour lesquelles le besoin de filtrage et de log n’est pas sujet à discussion. On peut notamment citer certaines professions comme les prestataires Telecoms, les prestataires Internet ou encore Banques/Bourses/Santé. Suivant le type de profession, le temps de conservation des données diffère. Sans compter certaines obligations particulières de filtrage du contenu, concernant la pédo-pornographie ou les jeux d’argents par exemple. Malheureusement ici encore des ambigüités subsistent, notamment concernant la définition d’un prestataire de services Internet. L’auteur cite par exemple le cas d’une banque qui a été considérée comme fournisseur d’accès Internet par un tribunal, car elle mettait à disposition de ses employés un accès Internet. Il faut donc se fier aux obligations jurisprudentielles.

La troisième partie de la présentation fait figure de mise en garde. Un employé dispose de ce qu’on appelle la « vie privée résiduelle » quand il est sur son lieu de travail et pendant ses heures de travail. Me. Barbry explique que, en accord avec la jurisprudence, la consultation des logs concernant l’employé sans sa présence ainsi que leur utilisation à son encontre est légitime. Le principe de précaution en la matière s’applique « dans le doute, protège-toi et protège les autres contre eux-mêmes », les institutions doivent mettre en place une politique de log. Il faut cependant rester vigilant : il est interdit de stocker des informations en dehors de l’Union européenne.

Dans la dernière partie de cette présentation, Maître Barbry souligne que la mise en œuvre des solutions de log peut s’avérer délicate. En effet, les institutions doivent mettre en place des chartes informant les utilisateurs des données qui sont loguées. De plus, les informations loguées ainsi que les processus de log doivent respecter la loi informatique et liberté (un utilisateur doit avoir le droit à l’oubli, certaines données personnelles ne peuvent être loguées).

En conclusion de sa présentation, l’intervenant rappelle que des textes législatifs sont en préparation et que dans la pratique la jurisprudence prévaut. D’où la nécessité de faire de la veille juridique pour être à jour concernant les nouveaux textes ou nouvelles jurisprudences.

Virtualisation et/ou Sécurité

par Nicolas RUFF, EADS-IW SE/IS

Aujourd'hui, tout le monde parle de la virtualisation, sans vraiment savoir de quoi il en retourne.

Wikipedia donne cette définition :

En informatique, on appelle virtualisation l'ensemble des techniques matérielles et/ou logicielles qui permettent de faire fonctionner sur une seule machine plusieurs systèmes d'exploitation et/ou plusieurs applications, séparément les uns des autres, comme s'ils fonctionnaient sur des machines physiques distinctes.

On a d'un côté la virtualisation applicative, pour les vieux logiciels qui ne fonctionnent plus sur les nouveaux OS ou pour les navigateurs Web qui veulent se séparer de l'OS pour le “protéger”, et de l'autre la virtualisation des systèmes d'exploitation eux-mêmes, via des logiciels comme VMware ou Hyper-V pour ne citer que les plus connus. Dans ce second cas, on parle de "Full" Virtualisation.

Autres exemples : Google NaCl (Native Client), qui permet d'exécuter du code x86 directement au sein du navigateur Web.

En réalité, la Full Virtualisation n'est pas si full que ça, les performances ne seraient pas assez importantes. Même dans VMware, si on connait le système d'exploitation invité, c'est-à-dire si on ne choisit pas Other à l'étape du choix du système d'exploitation lors de la création de la machine virtuelle, la virtualisation n'est pas complète.

Nicolas met en avant plusieurs risques rencontrés.

  • Les risques humains :

La supervision, l'administration et le monitoring ne sont plus gérés de la même manière qu'avec des serveurs physiques.L'administrateur de la machine qui héberge les machines virtuelles est administrateur de toutes les machines virtuelles.Les produits sont récents, il y a peu d'expérience des outils (le plus connu restant VMware).Par rapport à des serveurs non virtualisés, les procédures sont à revoir ou à créer (dépannage, sauvegarde, etc.)Les points de panne restent le stockage, ou les bugs relatifs au virtualiseur (par exemple le bug des licences de VMware ESX 3.5, qui s'est cru expiré et a refusé de démarrer les machines virtuelles en aout 2008).

  • Les risques sur le système invité :

Le matériel virtuel, émulé, est forcement moins performant que le matériel physique (switchs, etc.).La compromission de la machine hôte permet la compromission de tous les systèmes invités.

  • Les risques sur le système hôte :

L'hôte est un système d'exploitation “normal”, avec ses propres failles. L'hyperviseur rajoute ses propres failles éventuelles.

  • Les risques dus au matériel :

On parle ici des bugs dans les processeurs, du mode SMM, etc.

Conclusion :

Une architecture n'est jamais plus sûre après avoir été virtualisée (en partant du principe que plus de fonctionnalités = plus de failles potentielles). Il est possible de limiter la casse, mais l'impact d'un bogue logiciel est souvent catastrophique. Une architecture virtualisée ne se gère pas comme une architecture classique.

La sécurité des plates-formes ASP / SAAS

par Yann Allain, Consultant sécurité - OPALE SECURITY

Cette intervention présente les différents aspects de la sécurité liés à l’utilisation des Application Services Providers. L’auteur aborde tout d’abord les risques qui pèsent sur ces plateformes. Comme leur nom l’indique, les architectures du type « Software as a Service » sont réparties entre plusieurs entités (ou offreurs). Dès lors, la surface d’exposition s’en trouve augmentée ; de plus, puisque cette architecture se base sur des composants logiciels dépendants les uns des autres, la sécurité du tout dépend de la sécurité du maillon le plus faible de la chaîne.

Dans un second temps, M. Allain présente les avantages de telles architectures pour les DSI. On peut notamment citer les coûts et le temps de mise en œuvre réduits, une meilleure visibilité des coûts ou encore la possibilité de se soustraire à certaines obligations légales (type normes PCI-DSS laissées à la responsabilité de l’offreur). Deux questions se posent cependant pour le client : quelles données externaliser et surtout comment s’assurer de leur sécurité ?

La dernière partie de la présentation tente d’apporter une réponse à ces questions. L’auteur rappelle tout d’abord que dans 2/3 des audits réalisés sur des plateformes SAAS des faiblesses importantes ou critiques sont trouvées. Ces mauvais résultats sont le fruit, selon l’auteur, d’un manque d’expérience sur ces technologies et d’un besoin de réallocation du budget SSI concernant la sécurité.

Pour conclure, l’auteur conseille d’auditer toutes les applications mises en jeu même celles qui ne semblent pas sensibles au premier abord.

Les fonctions de hachage, un domaine à la mode

par Thomas Peyrin, Expert en cryptographie (Ingenico)

Les fonctions de hachage comptent parmi les primitives les plus importantes en cryptographie ; elles sont notamment utilisées pour l'authentification et l'intégrité des données.Thomas revient sur l'histoire des fonctions de hachage, depuis leur conception (dans les bases de données) et les concepts qu'on trouve derrière elles (les méthodes de construction) jusqu'aux attaques et leurs implications. L'exposé s'attarde principalement sur les fonctions MD et SHA, qui sont couramment utilisées. Il montre ainsi que ces fonctions ne sont plus à utiliser aujourd'hui.

Une fonction de hachage est une fonction mathématique qui fait correspondre à une entrée de taille arbitraire une sortie de taille fixe. Si on veut que la fonction de hachage soit cryptographique, il faut qu'on ne puisse pas trouver une entrée x telle que h(x) = y pour un y fixé (attaque sur la première préimage), ni une entrée x' telle que h(x') = y avec x une entrée fixée différente de x' et y son haché (attaque sur la seconde préimage), ni deux valeurs arbitraires x et x' telles que h(x) = h(x') (collision).

Il rappelle aussi que les cryptologues avaient trouvé des problèmes dans MD5 dès 1993, mais c'est seulement à la suite de la publication des travaux de chercheurs chinois en 2004 qu'on a commencé à s'inquiéter réellement. Enfin, la récente implication de MD5 dans la conception d'un faux certificat X.509 a encore rappelé qu'il ne fallait vraiment plus utiliser cette fonction.

Pour remplacer ces fonctions qui ne sont plus sûres, le NIST a lancé un concours afin de définir un nouveau standard d'ici 2010, le SHA-3. Plusieurs équipes internationales travaillent actuellement sur le sujet. Plus de détails ici.


Nous remercions chaleureusement les membres de l'OSSIR pour l'organisation de cette journée et pour nous y avoir conviés. À l'année prochaine ! (ou au SSTIC avant ...)