Symposium sur la sécurité des technologies de l'information et des communications

Thoughts on Client Systems Security

BitLocker est une solution de chiffrement de disque dur apparue avec Windows Vista et disponible sur les éditions haut de gamme de ce système (professionnelle, intégrale ou entreprise pour Vista et intégrale ou entreprise pour Seven). Fonctionnellement, BitLocker permet le chiffrement « intégral » de volumes, que ce soit celui du système d’exploitation ou ceux de volumes de données supplémentaires.

Cet article se propose d’étudier en détail le fonctionnement de BitLocker. L’étude sera menée sur un système Windows 7 32 bits édition intégrale. Même si un certain nombre de points peuvent différer par rapport à un système Vista ou 64 bits, le fonctionnement global reste identique.

Silverlight est développé en .NET, il repose donc sur le framework Microsoft éponyme mais il embarque en plus sa propre machine virtuelle et son propre modèle de sécurité.

En conséquence, sa surface d’attaque est assez large :

• le framework .NET lui-même ;
• le coeur de Silverlight ;
• les bibliothèques natives Windows utilisées par Silverlight.

Une attaque se réalise comme avec les modèles de sécurité classiques des plugins et navigateurs Web, côté client : un site Web malicieux profite d’une vulnérabilité pour héberger une application Silverlight malicieuse et compromettre ainsi tous les clients qui se connectent sur le site en ayant un framework Microsoft .NET ou un plugin Silverlight vulnérables. Dans une première partie, nous introduirons le modèle de sécurité de Silverlight, ainsi que les différentes couches sur lesquelles l’application repose afin d’identifier les diverses sources d’attaques potentielles. Ensuite, nous étudierons une vulnérabilité du framework .NET impactant directement Silverlight. Il s’agit du CVE-2010-1898. Ce type de vulnérabilité étant spécifique à la machine virtuelle Microsoft, nous expliquerons à l’assistance l’origine de cette vulnérabilité ainsi que son danger.

Dans une troisième partie, nous montrerons comment exploiter une vulnérabilité de ce type. Nous avons écrit un exploit permettant l’exécution de code sur la machine, et nous verrons que les protections

Les attaques de type XSS (Cross-Site Scripting) demeurent encore parmi les plus rencontrées sur les applications web. Une question est alors soulevée : cette faille, souvent négligée et incomprise permet-elle vraiment de réaliser des attaques dangereuses ?

C'est ce que veut montrer cette communication au travers d'un nouveau Framework d'attaque : XSSF. L'outil, directement intégré au Framework Metasploit, permet l'exploitation de victimes à large échelle.

La sensibilisation par la démonstration : toute la devise de XSSF, qui prouvera qu'une attaque par un Cross-Site Scripting ne s'arrête pas forcément à un vol de cookie de session...

De nos jours il est possible de trouver sur le net des rainbow tables, fruits de longs travaux collaboratifs, qui pèsent plusieurs centaines de Go et décrivent des espaces pouvant aller jusqu'à toutes les combinaisons possibles de caractères ascii de longueur 1 à 8. Ces tables "classiques" ont pour principal inconvénient que les espaces de mots de passe parcourus grandissent de façon exponentielle avec la longueur des mots de passe recherchés et qu'atteindre les 9 caractères est, à l'heure d'aujourd'hui, hautement improbable. Ainsi les tables basées sur des dictionnaires et celles dites "hybrides" sont apparues dès 2007 et 2008. Ces deux approches visent à réduire la taille de l'espaces de mots de passe candidats tout en conservant un taux de succès élevé. Ces variations sont actuellement, à notre connaissance, les seules implémentations publiques qui tentent d'améliorer la pertinence des espaces couverts par des rainbow tables. La littérature propose pourtant d'autres axes d'améliorations, notamment statistiques, qui sont très prometteurs. Nous présentons l'une de ces techniques dans cet article et nous en évaluons l'intérêt à travers une preuve de concept. De plus, un outil original implémentant ce mécanisme de rainbow tables statistique est décrit. Les résultats expérimentaux obtenus avec cet outil sont exposés et montrent qu'avec une table de 6Go le taux de succès est équivalent à une table classique de 4,5To. Des résultats supérieurs, obtenus avec une table statistique de 500Go, sont également exposés.

Presentation d'un outil d'analyse de la memoire dynamique (heap) d'un programme, sans s'interesser au code assembleur.

Demonstration sur un jeu de simulation, Dwarf Fortress, ou l'on retrouve les caracteristiques d'un personnage en recherchant son nom en memoire et en remontant les pointeurs, a partir de quoi on retrouve ses coordonnees, etc.

Dans la course entre la lance et le bouclier, les algorithmes de chiffrement actuels, utilisés avec des clés raisonnablement longues, sont, semble-t-il, suffisamment robustes vis-à-vis des méthodes de cryptanalyse connues. Les implémentations de ces algorithmes peuvent, en revanche, être sujette à des vulnérabilités.

Ces chiffrements fonctionnent de façon satisfaisante de Château Fort à Château Fort. Mais si un attaquant réussit à percevoir et à exploiter des informations sur ce qui se passe durant le processus de création du message chiffré (i.e. dans la "salle du chiffre"), il peut aller jusqu’à acquérir la connaissance des clés de chiffrement. On parle d'attaque par canaux cachés.

Nous verrons un exemple d'une telle attaque sur un crypto-processeur et comment on peut construire un framework général pour l'observation et l’évaluation de telles vulnérabilités.

Le système d'exploitation Android connait un succès croissant auprès des développeurs d'applications embarquées (de type smartphones, mais également tablettes, téléviseurs connectés, et pourquoi pas demain réfrigérateurs, etc.).

Ce succès commercial s'accompagne d'un nombre croissant de publications autour de la sécurité du produit ... ainsi que d'un nombre croissant d'incidents de sécurité. En 2010, on peut citer par exemple la publication de l'application PhoneCreeper ou du "bot" Geinimi.

Cette présentation se propose de réaliser un tour d'horizon des attaques connues contre le système Android, ainsi que des faiblesses intrinsèques héritées la structure du marché de la téléphonie mobile.

Il propose également une méthodologie d'audit d'applications Android et de systèmes compromis, au travers d'exemples concrets.

Au cours des sept dernières années, les attaques perpétrées depuis des contrôleurs d'entrée-sortie (cartes réseaux, contrôleurs FireWire, par exemple) ont connu un intérêt grandissant. On ne dénombre plus les preuves de concept d'escalade de privilège abusant du mécanisme d'accès direct à la mémoire (DMA) permettant à un contrôleur de lire ou de modifier le contenu de la mémoire principale de la machine cible. Cette classe d'attaques reste pourtant encore méconnue à ce jour.

La présente étude se concentre principalement sur l'exploitation du mécanisme DMA dans l'architecture matérielle Intel PC. Nous explorons l'idée d'utiliser le DMA autrement que comme moyen de corruption de la mémoire principale. Nous nous intéressons particulièrement à l'usage du DMA comme vecteur d'attaque sur d'autres contrôleurs d'entrée-sortie. Nous détaillons dans quelles mesures ces attaques sont possibles sur les chipsets actuels et nous illustrons notre propos par la preuve de concept d'une attaque sur une carte graphique. Finalement, nous discutons des différentes mesures existantes permettant de limiter l'impact de telles attaques.

L'analyse de certaines fonctions du BIOS comme la vérification du mot de passe, nous amène sur la piste d'un composant matériel souvent ignoré: le contrôleur clavier (KBC pour keyboard controller, ou EC pour embedded controller). Ce composant est une unité de calcul autonome, dotée de son propre processeur, indépendant du processeur principal de la machine. Nous étudierons les différentes interactions de ce composant avec le reste du système, en particulier l'impact en terme de sécurité de la compromission du composant par un attaquant.

Nous présentons un outil libre de virtualisation. Cet outil prend la forme d'un noyau de système d'exploitation minimaliste faisant office d'hyperviseur et d'un client distant permettant un accès haut niveau aux fonctionnalités implémentées par l'hyperviseur.

L'architecture de cet outil facilite la mise en place de manière totalement transparente d'un environnement d'analyse de systèmes d'exploitation puissant, isolé, flexible et avant tout indépendant de toute couche logicielle.

La cible principale de l'outil concerne des systèmes d'exploitation installés et déjà fonctionnels sur machines de type IA-32 disposant des extensions de virtualisation matérielle.

Présentation des résultats du challenge SSTIC 2011

Nous montrons comment extraire des clés cryptographiques sensibles à partir d'appareils de sécurité cryptographique variés en exploitant des vulnérabilités dans leurs API (conformes à la norme RSA PKCS #11). Les attaques sont effectuées par Tookan, un logiciel que nous avons développé, qui opère une ingénierie inverse sur l'appareil de test pour en déduire ses fonctionnalités, construit un modèle de son API pour un model-checker, et enfin exécute les attaques trouvées par le model-checker directement sur l'appareil pour confirmer l'existence de failles. Nous décrivons le fonctionnement de Tookan et les résultats de nos tests sur 18 appareils disponibles dans le commerce : 10 ont été vulnérables aux attaques, tandis que les 8 autres n'offraient que des fonctionnalités fortement restreintes. Une des attaques trouvées par le model-checker n'avait jamais été publiée. Nous montrons comment Tookan peut être utilisé pour vérifier des configurations sûres, et nous proposons une configuration sécurisée que nous avons mise en œuvre dans une rustine pour un simulateur logiciel d'un appareil. Il s'agit de la première configuration publiée qui n'exige pas l'ajout de nouveaux mécanismes au standard PKCS #11. Nous commentons sur les leçons pour l'avenir des API de gestion des clés.

Depuis un ou deux ans, la question « Une extinction complète (ou quasi-complète) de l'Internet est-elle possible ? » revient souvent. Cette question est parfois posée pour le cas où un État souhaiterait priver d'Internet ses citoyens (cas du projet « Kill switch » aux États-Unis ou bien de la coupure de quatre jours de l'Égypte en janvier 2011). Mais elle est aussi d'actualité pour le cas où un groupe de craqueurs souhaiterait arrêter l'Internet, dans le cadre d'un conflit plus classique, ou bien simplement pour s'amuser. Au vu de certains cas comme la crise de l'attribut 99 de BGP en août 2010, certains se demandent même si une simple panne involontaire pourrait obtenir le même résultat.

Alors, l'Internet est-il réellement invulnérable à toute attaque, comme le veut la légende de sa résistance aux bombes nucléaires ? Ou bien est-il ultra-fragile ? Peut-il être éteint par une panne, par l'action d'une poignée de bricoleurs, ou par celle d'un État déterminé à la civiliser ? Qu'est-ce qui explique la résistance dont il a fait preuve jusqu'à présent ?

Et, s'il n'est pas invulnérable, qu'est-ce qui peut être fait pour améliorer sa résistance ? Des projets comme ceux de l'ENISA au niveau européen, ou de l'ANSSI au niveau français sont-ils pertinents ?

L'exposé couvrira donc une analyse de la vulnérabilité de l'Internet, une explication de ses mécanismes de défense, un examen des faiblesses et un tour des remèdes.

Le protocole DNS est primordial au bon fonctionnement de l'Internet. C'est l'un des éléments clés des communications actuelles. Depuis sa création en 1983 par la RFC883, le protocole n'a cessé d'évoluer afin de palier ses différentes limitations. L'objectif de cet article est double. Tout d'abord, il fait le point sur les problèmes et faiblesses connus de l'architecture DNS comme l'empoisonnement de cache, la corruption de trafic. Dans un second temps, il présente différentes solutions permettant de s'en prémunir. Afin d'illustrer ces solutions, des exemples concrets de configuration sont donnés.

Plus spécifiquement, nous cherchons ici à décrire différentes possibilités pour sécuriser les enregistrements de bout en bout entre un serveur DNS autoritaire et le client final, protéger les échanges en confidentialité et finalement assurer la disponibilité de l'architecture DNS.

Cet article est notamment l'occasion de présenter les avantages et les inconvénients des protocoles DNSSEC et DNSCurve. L'article se focalise sur le protocole DNS mais pas sur d'autres mécanismes de protection comme chroot, la descente de privilège ou bien encore les vues.

Deux solutions originales (l'une pour la protection du dernier lien, l'autre pour un système de résolution de nom dans un segment intranet maîtrisé) sont enfin présentées à titre d'expérimentation.

RRABBIDS (Ruby on RAils Behavior Based Intrusion Detection System) est un système de détection d'intrusion au niveau applicatif pour des applications Web écrites avec le framework Ruby on Rails. Le but de cet IDS est de fournir un outil de détection des attaques contre les données dans le cadre d'applications Web. Cet IDS comportemental se fonde sur l'apprentissage d'invariants dynamiques pendant une phase d'observation du comportement normal de l'application pour définir son profil de référence. Dans une deuxième phase, ce profil est utilisé pour vérifier à l'exécution que le comportement normal de l'application est respecté, en instrumentant automatiquement l'application Web. Les premiers résultats sont encourageants et montrent que des classes d'attaques classiques contre les données (telles que des injections SQL, ou des modifications de paramètres de requêtes) sont détectées par les mécanismes mis en place.

Problématique : Les applications de haut niveau utilisent de nombreux composants de base riches en fonctionnalités, comme les moteurs XSLT. L'absence de maîtrise de chacun de ces composants, et donc l'absence de maîtrise globale du code utilisé dans l'application, peut engendrer des problématiques de sécurité.

Hypothèse générale : On s'attend à ce qu'une étude méthodique à approche ascendante permette de mettre en évidence des vulnérabilités à impact élevé dans différentes applications mettant en œuvre des moteurs XSLT.

On a beaucoup parlé du cas Playstation mais aussi de pas mal d'affaires récentes où des "pirates" auraient "pénétré" des systèmes "sécurisés"... A lire les articles, chroniques et autres blogs on distingue mal s'il s'agit de "failles de sécurité" ou de "défaut de sécurité". Or sur un plan juridique les deux termes ne sont pas synonymes et emportent des conséquences juridiques bien différentes. Me Barbry se propose, à travers ce cas pratique, d'évoquer le régime juridique de ces deux concepts et d'évoquer les nouvelles contraintes issues du projet d'ordonnance relative aux communications électroniques qui devrait être prochainement adopté.

Intérêts privés et politiques tentent d'influer sur l'infrastructure même d'Internet, son universalité et par extension la liberté de communication des individus. Censure des contenus et restrictions d'accès avancent désormais vers le cœur du réseau en faisant notamment pression sur les intermédiaires techniques.

Cette session se prêtera à l'analyse forensique de ces attaques contre les libertés individuelles sur Internet en se posant les questions suivantes : Qui sont les attaquants ? Quels sont les vecteurs d'attaque ? Quelles sont les "payloads" de ces attaques ? Quelles contremesures et bonnes pratiques adopter pour protéger Internet et nos libertés ? Des solutions techniques seront-elles suffisantes ?

Trolls bienvenus.

Dans un système de stockage-en-ligne de photos, le fournisseur de service de stockage cherche à optimiser son volume de stockage et l'utilisateur cherche à garder ses données personnelles confidentielles. Ces deux intérêts peuvent entrer en conflit. En effet, si les utilisateurs confient leurs collections de photos en clair au fournisseur du service de stockage, celui-ci peut identifier les images identiques et n'en stocker qu'une seule copie, et ceci quels que soient les propriétaires de photos identiques; en revanche, la confidentialité des données personnelles est compromise. Cependant, si les utilisateurs du service de stockage chiffrent leurs images avant de les envoyer au fournisseur du service, celui-ci ne peut plus identifier les images identiques si celles-ci ont été chiffrées avec des clefs différentes. Dans cette contribution, nous proposons un système de stockage-en-ligne qui réconcilie ces deux intérêts en apparence conflictuels. Le fournisseur du service de stockage-en-ligne a la capacité d'identifier non seulement les images identiques mais aussi les images similaires, même si elles sont chiffrées avec des clefs différentes, sans compromettre la confidentialité des données personnelles.

Les cartes à puce constituent des plateformes pour lesquels la sécurité est un enjeu majeur, c'est pourquoi elles offrent des mécanismes de protection avancés au niveau matériel. Cependant, la sécurité globale de ces plateformes peut être mise en défaut par une vulnérabilité au niveau applicatif. Ce papier présente notre framework de fuzzing pour cartes à puce qui permet de tester en profondeur les implémentations de protocoles dédiés aux cartes à puce et d'identifier les vulnérabilités présentes dans ces implémentations. A l'aide de notre framework, nous avons implémenté deux fuzzers pour les protocoles de paiement sécurisé par cartes à puce les plus répandus dans le monde. Les résultats obtenus par fuzzing sur des cartes à puce du marché démontrent l'adéquation de l'approche de test par fuzzing au domaine des cartes à puce.

.