Christophe Berger

RRABBIDS, un système de détection d’intrusion pour les applications Ruby on Rails

Par Éric Totel, Loic Le Henaff et Romaric Ludinard

Après une belle soirée de Social Event en plein cœur  de Rennes, à la Halle Martenot sur la place des Lices, la journée de vendredi propose des sujets variés, entre techniques, juridique et éthique.

Romaric Ludinard de SUPELEC Rennes présente un framework de détection d’intrusion pour les applications Ruby On Rails.

Cet IDS applicatif ne s’attache pas à analyser les erreurs dans les flots d’exécution, mais plutôt à détecter les incohérences dans les données manipulées.

Il traite le problème par une approche comportementale, qui est plus souple que la détection par signature. En effet, les signatures nécessitent la mise à jour régulière, et ainsi une veille sur les attaques possibles. Dans le cas présent, le code est instrumenté afin de détecter les incohérences dans les données.

L’orateur donne l’exemple d’un paramètre “nom d’utilisateur” qui ne correspondrait pas au nom d’utilisateur effectif après authentification, problème typique d’injection SQL. La démonstration montre bien les alertes produites par le framework lorsque le nom d’utilisateur stocké en session est vérifié par rapport au paramètre envoyé par le visiteur.

Le framework semble intéressant dans la mesure où il ne demande aucune modification de code, l’analyse est réalisée à partir d’un module RoR qui peut être utilisé lors de la phase de tests fonctionnels pour ainsi pouvoir générer un code instrumenté à utiliser en production.

La présentation a toutefois manqué de détails sur l’impact en termes de performances sur le code généré.

Usages offensifs de XSLT

Par Nicolas Gregoire

La matinée s’est poursuivie sur une présentation des usages offensifs de XSLT par Nicolas Grégoire de la société Agarri.

Ce dernier rappelle que le XSL est un véritable langage de programmation permettant de mettre en forme des données décrites à l’aide de XML. À la différence du CSS qui ne permet que de donner des instructions de mise en forme, XSL peut charger des extensions et exécuter des fonctions. Ainsi, il a conduit une étude des différentes bibliothèques permettant de manipuler du XML/XSL afin d’étudier l’étendue de leurs possibilités.

Ses résultats sont édifiants et montrent aux pentesteurs les possibilités que ces applications réservent pour la compromission d’un système, qu’il soit applicatif serveur ou navigateur. En effet, les navigateurs embarquent tous des bibliothèques de transformations XML qui sont elles aussi potentiellement vulnérables.

L’étude a donc fait une cartographie des extensions dangereuses dans les moteurs XSLT et s’est attachée à identifier les moteurs vulnérables et conclut sur une note plutôt positive.

Ainsi, l’auteur rappelle qu’une configuration à l’état de l’art est rarement vulnérable et qu’il est possible d’utiliser XSLT de manière sécurisée sur toute plateforme.

Il appartient aux éditeurs de pratiquer la défense en profondeur afin de sécuriser toutes les couches applicatives, mais également aux clients d’auditer toutes les briques des applications critiques et d’influencer les éditeurs pour qu’ils fournissent des correctifs.

Faille de sécurité ou défaut de sécurité

Par Eric Barbry

Eric Barbry du cabinet Alain Bensoussant Avocats revient sur un sujet qui touche tous les responsables sécurité, les risques liés aux failles et défauts de sécurité. En effet, même si la législation n’est pas encore claire, elle évolue. Aujourd’hui la loi se dirige vers un texte moins dur que le projet présenté lors du SSTIC 2010, les notifications ne sont plus obligatoires dans tous les cas : la CNIL peut accepter un plan de mesures et dispenser de notification. Cette mesure parait injuste pour les victimes, souvent les clients, mais est explicable économiquement : une entreprise victime de fuites de données personnelles en subit déjà de lourdes conséquences, une obligation de notifier atteindrait encore plus l’image de celle-ci. En France la loi a choisi l’économie plutôt que l’étique.

Dans tous les cas, il est difficile d’évaluer les responsabilités entre faille inconnue ou défaut connu et exploité alors que des mesures auraient pu être mises en place.

Cette présentation montre l’intérêt d’un expert juridique qui puisse prendre en charge la gestion de ces aspects. Il convient d’analyser les risques portés par son système d’information et de savoir réagir en cas de problème. Mais également de prendre des mesures : posséder une assurance adaptée et effectuer des campagnes de sensibilisations permettent de limiter les conséquences pour l’entreprise.

La CNIL reste disponible pour toute demande et même si certaines choses ne sont pas normalisées, une demande d’avis en amont peut aider à définir sa politique.

Typologie des attaques contre nos libertés online

Jérémie Zimmermann

Jérémy Zimmerman entre ensuite en scène pour une présentation sans support, mais très vivante et pleine de convictions. Il milite avec la Quadrature du Net pour le droit à la liberté sur l’Internet, liberté d’innovation, d’invention et d’expression. Il s’insurge contre les lois et accords internationaux qui sont décidés par les gouvernements à l’aide de campagnes jouant sur les peurs, l’émotion et l’inconscient collectif. Il met en garde l’auditoire face à ces traités décidés en contournant les voies démocratiques et rappelle qu’il est du devoir de chacun d’avoir une vision critique sur ce que présentent les médias de masse.

Cette présentation très politique est atypique au SSTIC. Même si l’intervenant ne convainc pas l’ensemble de l’amphithéâtre, cette présentation permet d’aborder des aspects différents de la sécurité.

Système de stockage en ligne de photos avec confidentialité des données personnelles

Luis Montalvo

Technicolor Rennes démarre l’après-midi par une présentation sur le stockage de photos en ligne respectant la confidentialité des données. Les fonctionnalités présentées font néanmoins penser à un intérêt plus grand pour la protection des droits d’auteur que pour la simple confidentialité des données des utilisateurs.

Il semble que les techniques présentées pour garantir la recherche de contenu similaire sans donner accès au contenu lui-même soient déjà utilisées sur les plus grandes plateformes de partage de documents.

Cette présentation a le mérite de montrer de manière simple et didactique les techniques mises en oeuvre, mais ne semble pas apporter de grande nouveauté. Technicolor confirme donc sa position dans le domaine des services aux entreprises des arts en fournissant des techniques permettant aux hébergeurs d’optimiser leur volume de stockage tout en fournissant un service de recherche de contenu similaire et une certaine confidentialité aux utilisateurs des plateformes de partage.

Un framework de fuzzing pour cartes à puce: application aux protocoles EMV

Julien Lancia

Julien Lancia (SERMA Technologies) achève cette journée en présentant un framework de fuzzing pour cartes à puces. Le fuzzing est utilisé pour tester l’implémentation de certains protocoles sur carte à puce. Ceux-ci fonctionnent par états, mais sont constitués de commandes simples et courtes. Ainsi, le fuzzing semble tout à fait adapté dans ce contexte. La mise en oeuvre de ce framework est néanmoins complexe dans la mesure où une implémentation de référence doit être fournie.

Les tests peuvent ainsi prendre beaucoup de temps à être mis en oeuvre. Ensuite, le caractère aléatoire des tests peut provoquer la destruction de nombreuses cartes. Ce framework est donc tout à fait adapté à une activité de vérification d’implémentation, mais très peu dans le cadre de recherche de vulnérabilité sur un produit particulier en mode “boite noire”.

Sécurité ?

Hervé Schauer

Hervé Schauer conclut cette édition 2011 par un état de la sécurité des systèmes d’informations en termes d’image et de fonctionnement. Il revient sur la difficile, mais nécessaire indépendance de l’auditeur par rapport à l’audité, mais insiste sur une condition essentielle : l’implication de l’état par l’intermédiaire de lois, de moyens, mais surtout d’évangélisation.

Yann Ciret

Attaques DMA peer-to-peer et contre-mesures

Par Fernand Lone-Sang (et Loïc Duflot, Vincent Nicomette, Yves Deswarte)

Cette présentation met en forme les possibilités d’extraction de mémoire à partir d’un périphérique interne en Firewire, sur un environnement Linux 64bits, dont le noyau a été  recompilé afin de retirer les protections mémoire (sur /dev/mem).

Il faut bien noter que malgré la prouesse technique qui a permis d’extraire les données de la carte graphique en les dupliquant sur un autre écran, les possibilités d’exploitation dans un cadre réel ne sont pas facilement réalisables.

En effet, les noyaux actuels sont patchés et il est nécessaire d’accéder physiquement à l’intérieur de la machine si celle-ci ne dispose pas de port Firewire, tout en sachant que l’accès mémoire dépend du type de chipsets (Lakeport, Eaglelake, Tylersburg…).

Il est tout de même intéressant de constater que cette analyse met en avant les possibilités d’accès mémoire en terme hardware, sachant que les éléments techniques étudiés ne sont pas beaucoup documentés.

Des contre-mesures ont été énumérées :

• I/O MMU (In/Out Memory Management Unit) : permet l’isolation entre les régions de mémoire des contrôleurs :
  • Restreint l’accès des contrôleurs à leurs domaines respectifs, et est  implémenté au sein du northbridge dans les chipsets Intel ;
  • Certains chipsets AMD intègrent un I/O MMU dans le southbridge.
  • Access control services (ACS) : définissent des points de contrôle sur les bus d’E/S qui sont apparus récemment dans des chipsets Intel x58, désactivés par défaut. Leur activation peut interférer avec certains pilotes de périphériques.

Adresse de l’outil python qui permet l’extraction de la mémoire du GPU et sa duplication vers un autre écran : http://ark.intel.com/#codenamesall.

Sticky fingers & KBC Custom Shop

Par Alexandre Gazet, ESEC Sogeti

La conférence commence par une présentation sur les problématiques de sécurisation du BIOS, ou l’auteur démontre tout au long de son discours les mécanismes mis en place afin de générer le mot de passe de récupération du BIOS de sa machine :

• présence sur Internet de générateur de mots de passe maître à partir du numéro de série de la machine ;
• lien avec le contrôleur du clavier KBC<->SMM (interaction et communication) ;
• présence d’une interface au niveau du contrôleur clavier avec qui on peut communiquer ;
• complexité du fonctionnement pouvant provenir d’une volonté de ralentir l’analyse ?

Après cette démonstration, l’orateur conclu : « Un mot de passe BIOS pour protéger le BIOS et le disque est inutile. »

La suite de la présentation bifurque vers le fonctionnement du clavier et de la mise à jour de son micro logiciel.

L’auteur présente un outil codé en Ruby permettant de communiquer avec le contrôleur clavier et d’effectuer un débridage de celui-ci : après modification du micro logiciel, accès complet à la mémoire RAM et ROM.

Il est donc possible d’implémenter un keylogger matériel simplement en modifiant le micro logiciel du clavier, ce qui est indétectable mais tout de même très complexe à mettre en œuvre.

Virtualisation d’un poste physique depuis le boot

Par Stéphane Duverger, EADS Innovation Works

L’auteur présente le développement d’un environnement de virtualisation nommé Ramooflax (License GPL v2), permettant d’effectuer du débogage temps réel sur un système d’exploitation ou ses composants.

L’objectif de ce travail est d’avoir des méthodes d’observation du fonctionnement d’un OS et d’interagir directement avec les processus en cours (démonstration en direct avec IDA).

Afin de mener à bien ce développement, l’auteur met en avant la difficulté d’exploitation des fonctionnalités de virtualisation des processeurs Intel et AMD et le peu de documentation sur le sujet.

Le produit développé fonctionne exclusivement sous processeur AMD, après un démarrage avec une clé USB de boot et n’est donc pas compatible avec les fonctions de virtualisation AMD/Intel, de plus, il nécessite une machine très performante.

Enfin, l’analyse a permis de mettre en évidence que la gestion des interruptions matérielles et  mode réel étaient beaucoup moins restrictives sous les systèmes AMD.

L’USB2 a été choisi comme solution de communication à distance en raison de son fonctionnement standard, la partie réseau n’étant à ce jour pas prévue. Le tout est intégré dans un Framework python simple d’utilisation.

Attacking and Fixing PKCS#11 Security Tokens with Tookan

Par Graham Steel

Les diapositives sont en anglais, mais Graham fait l’effort de faire la présentation en français. Après les présentations précédentes et le résultat du challenge, cette présentation parait simple ou du moins plus compréhensible.

Cela commence par un rappel de comment fonctionne une clé USB PKCS#11, en précisant que sur environ 400 pages du standard, la sécurité occupe 1,5 page.

Ensuite il présente son outil Tookan qui permet de tester l’implémentation PKCS#11 des différents tokens. Il teste en envoyant différentes combinaisons de fonctions pour voir comment l’appareil réagit (reverse engineering). Il cherche notamment la politique des attributs et les templates des informations qui peuvent être envoyés. Graham précise que le logo a été fait par sa femme et qu’il a l’obligation de l’utiliser dans toutes ses présentations. Cela provoque une ovation de la salle.

La seconde démonstration (recherche d’une attaque) est plus longue que la première. Malgré la protection supplémentaire ajoutée, une nouvelle attaque est trouvée. Comme quoi ce qui paraissait simple à protéger ne l’est pas. Une nouvelle attaque de profondeur 4 est encore trouvée après modification de la configuration.

Le conférencier ne manque pas d’humour et évoque que certaines clés testées ont été trouvées dans la rue. Un transparent donne un certain nombre de clés avec les attaques trouvées dessus. Peu de clés ne sont pas attaquables.

Graham nous indique qu’un appareil permettant de lire des clés RSA coûte dans les 300$. Bonjour l’actualité.

La présentation se termine en précisant que les résultats ont été dévoilés en novembre 2010. Les fabricants avaient été contactés 5 mois avant, mais la plupart des réponses obtenues ont été décevantes.

Cette présentation est en tête à l’applaudimètre à la fin de cette matinée. C’est surtout la première qui a un impact sur la vie réelle et qui est “facilement” exploitable. Les impressions sur Twitter sont très bonnes.

Peut-on éteindre Internet

Par Stéphane Bortzmeyer, AFNIC

Par ce titre, Stéphane Bortzmeyer entend rendre indisponible totalement Internet dans le monde entier. Il rappelle qu’il n’y a pas eu d’interruption, même d’une milliseconde, du service de résolution de nom de l’AFNIC depuis ses débuts.

Beaucoup d’exemples d’annonce catastrophique sont ensuite donnés. Ils font d’ailleurs bien rire l’amphi et provoquent un pic d’activité sur Twitter.

L’orateur évoque le fait que c’est, soit disant, toujours un méchant qui prévoit un mauvais coup et pense donc à arrêter Internet. Il donne alors le contre exemple clin d’oeil de la femme de ménage qui conduit une pelleteuse arrachant des fibres optiques. Cet exemple met en évidence des problèmes de redondance, avec toutes les fibres optiques de plusieurs opérateurs passant dans une seule tranchée.

Alors existe-t-il des attaques permettant de couper Internet ?

• Les attaques physiques ne sont pas faisables à distance, sont coûteuses en mains d’oeuvre et réparables.
• Les failles sur les différents routeurs semblent plus intéressantes, mais posent un problème : comment propager des virus sans couper Internet alors que le but est de couper Internet ? Si la faille est dans un protocole, c’est mieux.
• Le déni de service (dDoS) est moins compliqué à mettre en place et surtout il n’existe pas vraiment de solution contre ce genre d’attaque. Problème : tout le monde en est conscient et donc les services les plus sensibles sont les mieux protégés.
• Autre possibilité : être président et demander la coupure auprès des opérateurs télécoms.

Si on passe du côté des gentils, est-il possible d’améliorer les choses ?

Il y a tout d’abord la mauvaise solution qui est de vouloir refaire Internet.

Puis viennent les bonnes solutions :

• Mettre en place une redondance physique réelle.
• Ecrire des logiciels sans bogues ou à minima avec moins de bogues, quitte à trouver un compromis entre fonctionnalités et sécurité.
• Améliorer la coordination des acteurs qui ne disposent pas, aujourd’hui, de canal de communication officiel (Twitter a ses limites).
• Mener des actions politiques pour empêcher les gouvernements de créer des SPOF (single point of failure).

La conférence se termine dans une ambiance plus sérieuse que son départ tonitruant. La conclusion est qu’il n’est pas vraiment possible de couper tout l’Internet, même si beaucoup d’axes d’amélioration existent.

Architectures DNS sécurisées

Par Guillaume Valadon et Yves-Alexis Perez, ANSSI

Rappel que DNS est plus compliqué qu’il n’y parait puisqu’il définit aussi le format des requêtes et réponses. Le présentateur profite de la définition de « pub » pour faire sa publicité comme quoi l’ANSSI recrute et provoque ainsi des applaudissements dans la salle.

Viennent ensuite les explications des différences entre les infrastructures de clés X.509 (utilisées avec TLS) et DNSSEC.

La conférence se poursuit avec NSEC3 qui doit améliorer DNSSEC en interdisant les requêtes pour énumérer la zone et en utilisant des hash pour remplacer les noms. La salle se trouve plongée dans le calme. Cela doit être du fait que les explications sont un peu plus compliquées et surtout effectuées à un rythme beaucoup plus soutenu. Cela se vérifie sur Twitter.

Changement d’interlocuteur. Le débit ne faiblit pas. C’est le tour de TSIG, un complément de DNSSEC qui va protéger le lien (authentification du serveur). Cela revient à l’identification des transactions par l’ajout d’un motif d’intégrité aux messages (calcul d’un HMAC). Nouvelle démo avec une requête DNS qui retourne encore l’information que l’ANSSI recrute. Cela réveille un peu la salle.

DNSCurve est ensuite évoqué pour protéger les messages DNS (intégrité, confidentialité). Il se positionne entre le client et le serveur cache DNS.

Enfin est évoquée la possibilité de faire de la résolution de nom à l’aide d’un annuaire LDAP (contexte : intranet, réseau fortement maîtrisé, plate-forme GNU).

Conclusion : DNSSEC est une solution efficace pour protéger les enregistrements, mais complexifie la gestion d’une zone (renouvellement des clés et signatures).

En pratique, seule la solution TSIG/libnss est utilisable sous Linux. Des proxy DNS locaux sont envisageables pour les autres OS.

Les questions mettent en avant le problème de compromission d’une clé et aussi du problème de cache en cas de changement de fournisseur d’accès et donc d’adresses IP. Il apparait qu’il n’existe pas de réponse claire à ces problématiques aujourd’hui.

Fin des conférences

Les conférences sont donc terminées pour aujourd’hui, mais pas la journée puisque le social event nous attend dans la soirée. Ce sera l’occasion de découvrir un autre visage du SSTIC pour les nouveaux participants…

Réalisé par Nicolas Hanteville et Yann Ciret

Gulzhan Zhussipaliyeva

Après un (dur) réveil à 5h du matin et 4 heures de route, nous y sommes enfin. Rennes nous accueille avec un beau soleil et les organisateurs avec du café et des croissants. Cela nous réveille tout de suite et met d’attaque pour cette édition 2011 du SSTIC.

Thoughts on Client Systems Security

Par Joanna Rutkowska

Après une très brève inauguration de la nouvelle édition du symposium, la parole est donnée au premier invité ou plutôt une première invitée : Joanna Rutkowska.

La présentation se déroule en anglais et commence par l’explication de l’importance de la sécurité du système client, le comparant aux yeux et les empreintes digitales de l’utilisateur : les OS des clients peuvent voir ce que les clients voient et peuvent se faire passer pour les clients.

Plusieurs approches sont alors présentées pour sécuriser le poste client : la sécurité réactive, la sécurité par isolation et la sûreté des langages.

L’auteur explique son approche d’isolation entre les applications, entre l’application et le système d’exploitation et propose d’isoler les différents composants d’une application grâce à l’IOMMU et la virtualisation.

La présentation s’est conclue par une présentation de Qubes, le système d’exploitation Open Source  sur lequel travaille Joanna Rutkowska avec ses collègues et qui implémente la plupart des idées énoncées dans la présentation.

BitLocker

Par Aurélien Bordes

La deuxième présentation est celle d’Aurélien Bordes sur la solution de chiffrement de disque dur Bitlocker de Windows. Le rythme de la présentation est très soutenu. Il nous introduit très rapidement à la technologie et explique comment elle s’intègre au système. Il nous présente encore plus rapidement son fonctionnement : la clé FVEK (Full Volume Encryption Key) participant directement au chiffrement des disques est chiffrée par la clé VMK (volume master key) ; la clé VMK elle-même peut être protégée par plusieurs moyens : utilisation d’un secret ou une bi-clé, utilisation du module TPM (permettant la vérification de l’intégrité du système au démarrage) ou de sa combinaison avec un secret.

Il déroule ensuite la liste des différentes menaces possibles sur un ordinateur chiffré avec Bitlocker. Les scénarios d’attaques sont les suivants : attaque en un temps avec un ordinateur éteint, avec un ordinateur allumé et verrouillé, ordinateur allumé et non verrouillé, attaque en deux temps (faisant référence à un des sujets d’actualité, le présentateur nous donne l’exemple d’une femme de ménage d’un hôtel ayant accès à la machine d’un client à plusieurs reprises).

En conclusion, l’orateur nous synthétise les points positifs et les points négatifs de la solution. Bitlocker est une solution stable et bien intégrée au système, elle protège efficacement contre la perte d’une machine. Mais elle n’est pas disponible dans les versions  professionnelles de Windows 7 et la mise en œuvre du module TPM n’est pas efficace en mode d’utilisation seul sans secret fourni par l’utilisateur.

La présentation, bien qu’abordant un sujet connu, a permis de faire un bon état de l’art de la solution.

Silverlight ou comment surfer à travers .NET

Par Thomas Caplin

La matinée s’est poursuivie avec la présentation de Thomas Caplin sur l’exploitation d’une faille du framework .NET via le plugin Silverlight.

Le framework .NET est un ensemble de technologies Microsoft permettant une portabilité plus facile des applications sur Internet, le présentateur nous explique son fonctionnement et son architecture.

Dans la deuxième partie de la présentation, un focus est effectué sur la vulnérabilité en question qui a pu être exploitée sur Silverlight. Il s’agit de la vulnérabilité CVE-2010-1898. Le problème se situe au niveau de la machine virtuelle qui ne gère pas correctement la création des pointeurs sur les méthodes virtuelles, cela permet une exécution de code arbitraire à un attaquant.

Cette vulnérabilité a été corrigée en août 2010 et c’est justement ce correctif qui a permis à l’auteur de remonter à l’origine de la faille et les moyens de son exploitation. Il partage avec nous son analyse de la vulnérabilité. Le problème venant d’un décalage de pointeur, il est possible d’accéder en lecture et  en écriture dans la mémoire. Ainsi, il est possible d’enregistrer un shellcode à la place du stub d’un Thread qui se trouve dans une zone exécutable. Cela permet à l’attaquant l’exécution de son code arbitraire à la place du code initial.

Afin d’exploiter cette vulnérabilité, le présentateur a choisi d’utiliser Silverlight, le plugin Web en .NET, un équivalent de Flash player chez Microsoft. Son choix a été basé sur le fait que Silverlight est exécuté côté client sur sa machine virtuelle .NET et qu’il donne des possibilités d’attaques à travers des différents navigateurs de l’utilisateur que ce soit IE, Firefox ou Chrome. Le prérequis pour cette attaque étant d’avoir un site Internet contenant l’application Silverlight malicieuse.

Cette exploitation de vulnérabilité est très stable et permet une surface d’attaque assez grande. Elle démontre que le Flash Player n’est pas le seul plugin à risque. Mais cette vulnérabilité étant corrigée, il est difficile de l’exploiter aujourd’hui.

XSSF : démontrer le danger des XSS

Par Ludovic Courgnaud

La dernière présentation de la matinée est celle de Ludovic Courgnaud, dont le but est de démontrer à travers son Framework d’attaque XSSF qu’une attaque XSS ne se résume pas qu’à un vol de session.

La présentation commence par un rapide rappel de XSS et du fait que les risques d’attaques XSS ne sont malheureusement pas toujours clairement expliqués. Le but de cette communication est justement de démonter ces risques avec un nouveau Framework d’attaque XSSF.

Le présentateur fait une parenthèse sur la problématique de SOP (Same Origin Policy), la mesure de sécurité intégrée dans le navigateur qui limite le transfert de données entre deux domaines. L’auteur explique qu’il est possible de le contourner via l’utilisation entre autres d’un iFrame pour récupérer les données vers le navigateur et les envoyer depuis le navigateur. De plus, le support du HTML5 par les nouveaux navigateurs donne la possibilité de contourner cette protection.

Ludovic Courgnaud présente son outil XSSF qui est un projet Open Source pouvant être utilisé avec Metasploit  et qui permet le développement et l’exécution d’exploits contre des machines distantes. Il passe ensuite à sa démonstration.

La démonstration qui suit la présentation de l’outil est effectuée en exploitant la faille présente sur le site du SSTIC.

Le présentateur développe ensuite sur les moyens de protection contre les attaques XSS tels que l’utilisation des bloqueurs XSS, la configuration des règles de web application firewall, l’utilisation des les filtres XSS, JavaScript Sandboxing, etc. Mais il conclut finalement qu’il n’existe pas de  solution miracle côté client, mais qu’il est important de sensibiliser les développeurs, filtrer toutes les saisies des utilisateurs et mettre en place des protections intégrées dans les navigateurs.

Rainbow Tables probabilistes

Par Alain Schneider

La première présentation de l’après-midi était celle d’Alain Schneider sur les Rainbow Tables Probabilistes pour le cassage des mots de passe. Ayant consulté l’article en amont (contenant des formules avec des chaines Markov), nous attendions avec appréhension cette présentation. Pour notre grand soulagement, l’auteur en très bon pédagogue a su nous expliquer de manière claire et simple la méthode dont la performance est assez impressionnante.

La présentation commence avec un rappel de ce qui est un mot de passe faible : c’est un mot de passe court, dérivé d’un dictionnaire ou statistiquement probable. « Statistiquement probable » veut dire que la probabilité de transition d’une lettre de l’alphabet à une autre dans le mot de passe est assez élevée. L’approche permettant de découvrir les mots de passe statistiquement probables a été implémentée dans John The Ripper, elle s’appelle l’approche « de Markov ».

S’en suit la présentation du mécanisme de Rainbow Tables qui permet le stockage des associations mot de passe /hashs pré-calculés dans une table. Ainsi, il est plus facile de rechercher rapidement le hash dans la table afin de retrouver le mot de passe correspondant en clair.

Nous arrivons ensuite au sujet principal de la présentation : les Rainbow Tables basées sur des espaces de Markov avec ses problématiques de numérotation des mots de passe de Markov  et la génération des Rainbows Tables avec une GPU. Toutes ces problématiques résolues, les résultats obtenus sont assez parlants. Dans le contexte d’un temps restreint, les performances obtenues par une Rainbow Markovienne de 1Go dépassent  très nettement celles des Rainbows Tables classiques de 10Go.

En ce qui concerne les contre-mesures, le présentateur nous conseille d’utiliser des mots longs avec des caractères exotiques, de les générer de préférence aléatoirement et les faire auditer.

Memory Eye

Par Yoann Guillot

L’après-midi s’enchaîne avec la présentation de Yoann Guillot sur l’outil Memory Eye, permettant l’analyse de la zone de mémoire dynamique pour éviter la technique d’analyse de code trop compliquée.

L’orateur nous explique l’organisation de la mémoire en général et sa structure sous GNU/Linux et Windows XP. Nous avons ensuite droit à une démonstration du fonctionnement de l’outil  sur un jeu nommé « Dwarf Fortress », un jeu ayant lieu dans un monde médiéval fantastique avec des nains en personnages principaux. Ce jeu n’est pas Open Source et il intéresse une grande communauté de hackers qui essayent d’analyser sa structure. La démonstration ayant rencontré quelques problèmes, les spectateurs commencent à s’impatienter. Heureusement, l’orateur a un bon sens d’humour. Le principe de la démonstration est la suivante : le présentateur donne un nom à un nain dans le jeu, il recherche ensuite cette variable dans la mémoire, il tente d’identifier les listes chaînées et les tableaux correspondants à cette donnée,  il retrouve ainsi la structure du chunk et la chaîne contenant le nom du nain. En changeant les données d’un chunk, le nain change de place dans le jeu…

L’avantage de cette technique par rapport à l’analyse de code d’un programme, c’est qu’elle permet de gérer les données bien différenciées, sans essayer de retrouver l’architecture des programmes et de ce fait mieux gérer les mises à jour.

Attaque d’implémentations cryptographiques par canaux cachés

Par Philippe Nguyen

La présentation suivante est celle de Philippe Nguyen sur une nouvelle approche d’attaque de carte à puces. Durant la pause, le présentateur installe son oscilloscope suscitant ainsi la curiosité du public resté dans la salle.

Dès le début, il commence par une démonstration d’une attaque par « canaux cachés » lui permettant de récupérer les clés utilisées pour une opération de chiffrement via un enregistrement électromagnétique. En effet, il nous explique que la consommation du courant durant cette opération (transitions binaires) dépend de la valeur des données utilisées.

Une des approches pour répondre à ce problème est l’utilisation de la technologie appelée WDDL,  qui consomme une quantité fixe d’énergie pour chaque transition permettant ainsi avoir une consommation électrique constante indépendamment du signal, évitant ainsi la fuite de données. Economiquement parlant, il s’avère que cette approche ne peut pour le moment être rentable qu’au niveau des équipements très sensibles, par exemple dans le domaine militaire.

Sécurité du système Android

Par Nicolas RUFF

La dernière présentation était celle de Nicolas Ruff, dont l’arrivée était impatiemment attendue par les habitués du SSTIC. Tout d’abord, il nous explique la raison du changement du titre de sa présentation. Si initialement elle s’appelait « Sécurité du système Android », et puis devenue juste « Android »,  c’est parce qu’il a été abordé par plusieurs personnes étant inquiètes d’éventuel manque de contenu sur le sujet. Et en effet, après une brève introduction sur le système Android, les attaques fusent :

• Le fait que les applications sont signées ne juge pas de leur sécurité, vu que les certificats autosignés sont acceptés et qu’ils sont facilement révocables en cas de (non) besoin.
• Les permissions « sensibles » données aux applications doivent être approuvées par l’utilisateur, or elles sont souvent insécables et irrévocables.
• En ce qui concerne l’utilisation des identifiants uniques pour chaque application, ils ne sont pas garants d’un bon cloisonnement au niveau sécurité.

A part ces points, il existe un nombre important de failles système, logiques, au niveau du modèle de sécurité, de bugs applicatifs, de vulnérabilités liées aux virus/malwares, etc. Les slides contiennent beaucoup d’exemples et de liens à consulter.

Le présentateur a dû noter néanmoins, pour les raisons d’objectivité, que la protection des répertoires system, /mnt/asec est assez bonne, ainsi que le système gère bien les mises à jour OTA.

Nicolas Ruff termine sa présentation avec un extrait de DailyDave sur les smartphones et les bonnes pratiques de sécurité liées à l’utilisation des smartphones.

Gulzhan Zhussipaliyeva

Le 16 mars 2010, le site Internet de la SNCF annonçait l’explosion d’un TGV faisant une centaine de morts et plus encore de blessés. La catastrophe n’a heureusement jamais eu lieu, s’agissant simplement d’une erreur d’administration du site. En effet, ce message, lié à un exercice de gestion de crise, n’aurait jamais dû être diffusé sur le site officiel de la SNCF.

La cause de cette erreur est relativement simple, une personne a émis cette information sur le site public de la société, au lieu de réaliser l’opération sur un site dédié dit de « test ». En effet, dans les entreprises, les applications sont répliquées dans plusieurs environnements (pour le développement, les tests, la validation, etc.).

La SNCF n’a eu à déplorer aucune conséquence lourde, mais cet exemple n’est pas un cas isolé et les impacts financiers et d’image des erreurs semblables à celle-ci peuvent être bien plus importants.

Mais alors quels peuvent être les moyens pour se protéger de ces défaillances de la machine humaine qui sont souvent liées à des facteurs tels que le stress, la fatigue, la routine ? A ce jour, plusieurs approches tentent de répondre à ce risque :

• Différentiation des accès ;
• Différentiation visuelle ;
• Confirmation des actions ;
• Approche organisationnelle.

L’évitement du risque par la séparation des équipes de production / hors production et le cloisonnement complet des environnements, ne seront pas étudiés compte tenu des impacts financiers et organisationnels majeurs qu’ils engendrent.

Lire la suite de l’article »