Comme chaque année, Intrinsec était présent à la conférence de sécurité informatique la plus attendue en France : le SSTIC. Il s’agissait de la 13e édition qui s’est tenue à Rennes.
Vous trouverez à l’adresse suivante l’ensemble des actes, présentations et vidéos de cette édition 2015 :
D’autres résumés sont disponibles sur Internet :
- Retour sur quelques conférences par XMCO
- Podcat de NoLimitSecu par Nicolas Ruff, Stéphane Sciacco et Christophe Chasseboeuf
- Le Liveblogging de n0secure
Sécurité et ingénierie (dans Chromium) — Julien Tinnès
Julien est membre de l’équipe sécurité de Chromium. Lors de cette présentation, il nous a exposé sa vision sur l’évolution de la sécurité depuis sa première conférence réalisée au SSTIC en 2005 jusqu’à ce jour. A cette époque, c’était le début de la prise de conscience des failles de sécurité (par exemple : Blaster et Sasser) et la sécurité dans l’ingénierie était très rare. Tandis qu’aujourd’hui en 2015, les vulnérabilités apparaissent en première page des journaux avec des noms « amusants » (POODLE, Heartbleed, BEAST, etc.). Par la suite, Julien nous a présenté quelques fonctionnalités sécurité implémentées sur Chromium : Privilege isolation (séparation des processus), Sandboxing et Seccomp-bpf (présenté comme un pare-feu pour noyau). A cette occasion, il présente les manières de lier ingénierie logicielle et l’ingénierie sécurité. Par exemple, la séparation des onglets dans des processus permet d’améliorer la stabilité (ingénierie logicielle) et de plus facilement introduire des mécanismes de sandboxing (ingénierie sécurité). En conclusion, le développement de Chromium pousse l’amélioration simultanée des performances et de la sécurité. Néanmoins, il reste encore des efforts à faire pour assurer un lien sécurisé entre le navigateur et l’utilisateur.
PICON : Control Flow Integrity on LLVM — Thomas Coudray, Arnaud Fontaine et Pierre Chifflier
Cette présentation ne concernait pas le PICON bière, mais un tout autre sujet qu’est le « Protect Integrity of CONtrol flow ». L’idée est de concevoir un outil permettant de limiter les possibilités d’exploitation des failles présentées par un programme en vérifiant l’intégrité de son flot d’exécution.
Les auteurs de l’outil se sont intéressés aux solutions existantes et se sont rendus compte que bien qu’intéressantes, elles n’étaient pas complètes. Chacune définissait le contrôle d’intégrité à sa manière, aucune n’implémentait tous les principes. Pour réaliser leur outil, ils sont partis sur 4 principes à respecter :
- Protéger tous les appels de fonction et les retours de fonction ;
- Protéger les branchements ;
- Détecter dès que possible si le flot d’exécution est compromis afin de terminer le programme ;
- Disposer d’informations pour une analyse forensique.
En conclusion, il ne s’agit encore que d’une preuve de concept, mais le travail accompli est prometteur. Pour tester l’outil : https://github.com/ANSSI-FR/picon
Triton : Framework d’exécution concolique — Florent Saudel et Jonathan Salwan
A la base Triton est un projet de fin d’études de Florent et Jonathan dans le cadre de leur Master. Aujourd’hui, ce projet est supervisé par le LaBRI (Laboratoire Bordelais de Recherche en Informatique) et sponsorisé par Quarkslab.
Triton est un framework d’exécution concolique. Le terme « concolique » fait référence à la combinaison de deux approches, l’exécution concrète (analyse dynamique d’un programme) et l’exécution symbolique (analyse statique).
Triton s’appuie sur l’outil Pin d’Intel, dédié à l’instrumentation de code, et étend ses fonctionnalités. Il fournit notamment :
- Un moteur d’exécution symbolique ;
- Un moteur d’analyse de teinte ;
- Une API.
Actuellement, l’outil supporte uniquement des binaires 64 bits.
L’outil est disponible sur Github : http://github.com/JonathanSalwan/Triton
REbus : Un bus de communication facilitant la coopération entre outils d’analyse de sécurité — Philippe Biondi et Xavier Mehrenberger
Comme le nom de la présentation l’indique, REbus est un outil permettant d’automatiser l’exécution d’outils d’analyse. Pourquoi avoir créé un tel outil ? La problématique est que sur certains sujets comme la reconnaissance réseau, le Threat Intelligence ou l’analyse forensique, un analyste va utiliser différents outils pour résoudre un problème. Généralement, ces analyses comportent des tâches répétitives.
L’objectif de REbus est donc de fournir un framework permettant :
- D’ajouter des fonctionnalités et des outils facilement ;
- D’automatiser les tâches répétitives ;
- De stocker les résultats intermédiaires des outils.
Afin d’atteindre ces objectifs, REbus a été conçu sous forme d’un workflow décentralisé, c’est-à-dire un workflow pour chaque outil, qui partagent un bus de communication.
REbus est disponible ici : https://bitbucket.org/iwseclabs/REbus et une démo est disponible ici : https://bitbucket.org/iwseclabs/REbus_demo
Abyme : un voyage au cœur des hyperviseurs récursifs — Benoît Morgan,Eric Alata,Guillaume Averlant,Vincent Nicomette
L’idée des auteurs est simple : est-il possible de réaliser un hyperviseur « récursif » ? Quel est l’intérêt d’un hyperviseur récursif à part pour réaliser une inception ? Cela permet notamment d’ajouter des fonctions de sécurité par niveau de virtualisation, par exemple en utilisant un hyperviseur dédié à une fonctionnalité (ex. porter un driver de carte réseau sans avoir accès au reste du système). L’architecture mise en place a été présentée, ainsi qu’une preuve de concept. En conclusion, les performances ne sont pas encore au rendez-vous.
Stratégie de défense et d’attaque : le cas des consoles de jeux — Mathieu Renard et Ryad Benadjila
Cette présentation a fait un tour d’horizon sur l’évolution de la sécurité des consoles de jeux en se concentrant sur 4 exemples :
- La PlayStation: par défaut, absence de sécurité à la conception. A partir de 1995, cette console est contrefaite en masse. Les jeux (piste d’amorçage du CD-ROM) et les consoles (BIOS) étaient zonés par région. L’absence de mécanismes de sécurité ont permis le développement rapide de modchips contournant ces restrictions.
- La Xbox: quelques idées de sécurité ont été implémentées avec notamment une chaine de démarrage de confiance, un contrôle d’accès au disque dur et une signature des binaires. Néanmoins, la limitation de la ROM de démarrage à 512 octets et les failles de sécurité identifiées dans celle-ci ont permis de briser la chaîne de confiance.
- La Xbox 360: bonne architecture logicielle et une chaîne de démarrage bien pensée. Néanmoins, une erreur d’implémentation dans l’hyperviseur permettait d’exécuter du code (la King Kong attack). Cette vulnérabilité était exploitable uniquement avec le jeu King Kong (d’où son nom), mais a été corrigée avant de devenir publique. Malheureusement, il était possible de downgrader le noyau de la console vers une version vulnérable à l’attaque.
- La PS3 : une plateforme matérielle exotique intéressante avec des protections contre les attaques DMA.
En conclusion, les failles de sécurité peuvent apparaître tant au niveau matériel que logiciel, la sécurité d’un produit doit prendre en compte l’existence de ces deux surfaces d’attaques distinctes.
Rétro-ingénierie matérielle pour les reversers logiciels : cas d’un DD externe chiffré — Joffrey Czarny, Raphaël Rigo
Le groupe Airbus a souhaité tester l’efficacité d’un disque dur chiffré. Joffrey et Raphaël nous exposent la démarche utilisée pour tester le boîtier Zalman ZM-VE400. L’idée est de s’assurer que le chiffrement mis en place est correctement implémenté et robuste. Dans le cas présenté, le boîtier utilise l’algorithme de chiffrement AES-256-XTS. Leurs études indiquent que le chiffrement est indépendant du boîtier (tout est stocké dans le disque dur), une zone est réservée à la fin du disque dur et les mises à jour du firmware sont chiffrées. Bien que les auteurs n’aient pas réussi à identifier les données présentes à la fin du disque, et donc à déjouer le mécanisme de chiffrement, cette présentation a permis d’exposer différentes techniques de test de matériel embarqué.
CLIP : une approche pragmatique pour la conception d’un OS sécurisé — Vincent Strubel
Pour ceux qui ont participé à la JSSI de cette année, cette présentation était sensiblement similaire. L’idée était de montrer le système d’exploitation Linux durci et sécurisé par l’ANSSI nommé CLIP. Cet OS n’a pas vocation à être partagé avec le grand public, mais est principalement à destination de l’Etat français et des OIV (Opérateurs d’Importance Vitale), pour une utilisation bureautique.
CLIP utilise principalement les capacités de Linux afin de cloisonner le système en différents espaces en fonction de leur sensibilité. Par exemple, un niveau haut pour les informations confidentielles et un niveau bas pour les informations publiques.
Injection de commandes vocales sur ordiphone — José Lopes Esteves
José Lopes Esteves nous a présenté un moyen d’envoyer des commandes vocales à un ordiphone. L’idée est simple, les terminaux récents sont en mesure de recevoir des commandes vocales (Siri pour Apple, « OK Google » pour Android, etc.). Pour certains appareils, il est nécessaire d’activer les commandes vocales à l’aide d’un bouton, mais pour d’autres, il suffit d’utiliser un mot clé. L’attaque nécessite que la victime utilise un casque audio, dont le câble est utilisé comme antenne radio (FM et AM). Il suffit donc d’émettre sur cette bande de fréquence et en la modulant, il est possible de générer des ondes interprétées comme des commandes vocales par l’ordiphone. La portée de l’attaque est limitée (entre 2 et 5m) en raison de la puissance nécessaire de l’émetteur.
RowHammer – Nicolas Ruff
Nicolas Ruff nous a présenté l’attaque Rowhammer réalisable sur DRAM. L’équipe ProjectZero de Google avait déjà fourni un billet détaillé sur leur blog : http://googleprojectzero.blogspot.fr/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
L’idée de l’attaque est simple, il faut effectuer des accès régulièrement à des endroits spécifiques de la mémoire afin de provoquer des bits flips sur des portions adjacentes sur les barrettes. Ainsi, l’équipe Project Zero a été en mesure d’élever les privilèges d’un utilisateur sur un système Linux en utilisant cette technique.
FlexTLS : des prototypes à l’exploitation de vulnérabilités dans TLS
FlexTLS est un outil ayant pour objectif de tester la sécurité du protocole TLS. Les motivations sont claires : durant ces quatre dernières années, plus d’une vingtaine de vulnérabilités ont été découvertes dans le protocole et ses implémentations (BEAST, CRIME, Heartbleed, FREAK, etc.).
FlexTLS se base sur une bibliothèque cryptographique nommée miTLS qui est formellement vérifiée et qui implémente TLS (www.mitls.org). L’utilisation de cet outil a permis d’identifier de nouvelles vulnérabilités sur le protocole (FREAK, SKIP et Logjam notamment).
Il est à noter qu’une présentation détaillée sur les attaques Skip, Freak et Logjam a été réalisée à l’OSSIR : http://www.ossir.org/paris/supports/2015/2015-06-09/p.pdf
