SSTIC 2016

Sécurité de l'information
SSTIC 2016

Pour sa 14e édition, le SSTIC, qui s'est tenu du 1er au 3 juin 2016 à Rennes, nous a gratifié une nouvelle fois d'un programme riche et non dénué de sujets intéressants.

Advens a eu la chance, comme chaque année, d'y être présent.

Une fois encore, le périple a débuté par la chasse aux places : premier arrivé, premier servi pour l’obtention de l’une de celles-ci parmi les 450 convoitées. Une fois nos trois places obtenues, une planification du voyage vers Rennes s’est imposée pour ces trois journées de conférences.

Parmi les nombreux sujets passionnants abordés cette année, voici quelques retours sur un extrait des conférences qui ont marqué notre attention.

 

JOUR 1 :

Conférence d'ouverture par Brad Spengler (GRSECURITY)  

La conférence d'ouverture a été animée par Brad Spengler, auteur et développeur principal du patch Grsecurity®.

Le rôle de ce patch est d'améliorer la sécurité des systèmes sous Linux au travers de nouvelles fonctionnalités ajoutées au noyau.

Dans un premier temps, Brad, nous présente les nouveautés apportées à GRSEC depuis 2012.

Les améliorations portent essentiellement sur :

Brad nous expose ensuite sa vision du monde de la sécurité d'aujourd'hui et ses espérances pour le futur.

L'orateur se montre assez critique envers les industriels du milieu. Il leur reproche de choisir la mauvaise approche, centrée sur la correction continuelle des bugs plutôt que sur l'élimination, en amont, des vulnérabilités.

Brad dénonce également la baisse de qualité des travaux menés sur la sécurité informatique dont les auteurs, selon lui, sont plus attirés par la célébrité ou l'appât du gain que par l'envie de faire progresser la sécurité, choisissent mal leurs priorités, manquent d'honnêteté intellectuelle, ou privilégient trop souvent la forme sur le fond.

 

Démarche d'analyse collaborative de codes malveillants par Stéfan Le Berre (Sogeti), Adrien Chevalier (ANSSI),Tristan Pourcelot (ANSSI)

Les intervenants nous présentent ici un outil développé pour répondre aux problématiques rencontrées dans le cadre d'analyse, au quotidien, de logiciels malveillants.

Confrontés au nombre impressionnant de malware et variantes, les analystes, qui eux sont peu nombreux, ont besoin de rationaliser leur façon de travailler, notamment dans un cadre collaboratif, afin de gagner en efficacité.

C'est dans ce contexte qu'a été développé l'outil Polichombr dont les principaux objectifs sont orientés vers la capitalisation des informations relevées et l'automatisation de tâches fastidieuses et répétitives (réduction du risque d'omission au cours de l'analyse).

Les fonctionnalités de cet outil sont :

  • Le stockage des échantillons : le logiciel stocke les exécutables au format PE, ELF, Shellcode, Office ainsi que les métadonnées associées
  • L'automatisation : Les calculs des empreintes de fichiers (MD5, SHA1, SHA256), l'extraction des métadonnées, le désassemblage du binaire, recherche de chaines de caractères,... ainsi que la catégorisation de l'échantillon sont automatisées.
  • La classification : Les auteurs ont conçu l'algorithme Machoc basé sur l'analyse des graphes de flot de contrôle des fonctions. En comparant les caractéristiques de ces graphes avec la base de connaissance alimentée par les analyses précédentes, l'algorithme détecte les similarités de l'échantillon traité avec ceux déjà connus et est donc en mesure de le catégoriser.
  • Le travail collaboratif : Le module Skelenox intégré à IDA (outil d’analyse statique de binaire) est utilisé pour synchroniser les données d'analyse entre PoliChombr et IDA
  • Stockage des résultats : les analystes peuvent partager leurs notes
  • Export des résultats : les résultats peuvent être produits sous différents formats (JSON, rapports lisibles pour le client, ...)

 

GUNPACK par Julien Lenoir (Airbus Group Innovation)

L'outil Gunpack, développé chez Airbus, est ici présenté. Gunpack analyse l'exécution d'un processus sous Windows (architecture 32 bits) et collecte les informations nécessaires à l'analyste pour comprendre le fonctionnement du packer et développer, à l'aide du langage Python, l'unpacker correspondant.

Pour ce faire, Gunpack instrumente le système d'exploitation et observe l'évolution de l'espace mémoire alloué au processus analysé (accès en lecture / écriture / exécution, génération de code dynamique).

 

Cryptanalyse en boîte noire de chiffrement propriétaire : étude de cas, par Pierre Capillon (ANSSI)

Pierre Capillon nous propose un retour d'expérience sur la démarche empirique adoptée dans le cadre de la rétro conception en boite noire d'un firmware chiffré à l'aide d'un algorithme propriétaire.

L'objectif de ces travaux réalisés en 6 semaines fut d'extraire le micrologiciel d'un système embarqué à partir d'une image chiffrée (il se rendra compte d’ailleurs que c’est plus de l’obfuscation que du chiffrement) et compressée. L'intervenant détaille ici les succès, mais aussi les échecs, rencontrés durant le processus.

La démarche présentée ici s'appuie essentiellement sur l'intuition, l'observation, la comparaison et la force brute.

L'intervenant met également en évidence le faux sentiment de sécurité procuré par ces implémentations propriétaires, présentant très souvent des faiblesses mettant en péril la sécurité des données censées être protégées.

 

Eurisko : développement d’une carte électronique sécurisée par Arnaud Ebalard, Arnaud Fontaine, David Diallo, Jean-Pierre Flori, Karim Khalfallah, Mathieu Renard et Ryad Benadjila (ANSSI)

Les auteurs nous présentent le fruit de leurs travaux menés sur la conception d'une plateforme sécurisée embarquée.

L'enjeu de ce projet était de concevoir et mettre en œuvre, par le biais d'un prototype fonctionnel, des mécanismes de protection destinés à sécuriser la chaîne de démarrage du système, mais également de capitaliser sur le fruit de ces recherches afin de développer une expertise dans ce domaine.

Les auteurs nous font ainsi part de leur retour d'expérience sur l'intégration de composants sécurisés (certification EAL5+) disponibles sur le marché dans le but de réaliser une authentification pre-boot dans une chaîne de démarrage sécurisée.

Les problématiques rencontrées dans les phases de conception matérielle et logicielle, ont été abordées.

 

Evolution et dé-évolution des systèmes multimédia embarqués par François Pollet (Thales) et Nicolas Massaviol (Toucan System)

Les intervenants évoquent la démarche adoptée et les résultats obtenus dans le cadre d'audits réalisés sur les systèmes multimédias embarqués pour des constructeurs automobiles.  

Pour cette présentation, les orateurs ont retenu deux constructeurs ayant choisi deux approches différentes dans l'intégration de ces systèmes (architecture à plat vs. architecture segmentée).

La démarche présentée se déroule essentiellement en trois grandes étapes :

  • Prise d'informations (recherche de ports de communication / backdoor matérielle, extraction des mémoires externes, analyse des fichiers de mise à jour)
  • Tentatives d'exécution de code (via des vulnérabilités liées à des défauts de mise à jour ou au manque de durcissement des systèmes)
  • Interactions avec le véhicule via le bus CAN

Ces études ont mis en évidence, dans les deux cas, trois problématiques majeures :

  • la présence de backdoor dans les systèmes, parfois à l'insu du constructeur
  • la difficulté à garantir l'intégrité des systèmes
  • le manque d'intégration de la sécurité dans le développement des systèmes

Les auteurs concluent enfin sur les défis à venir :

  • intégrer la sécurité dans un contexte de prolifération de nouvelles fonctionnalités toujours plus avancées (véhicule autonome pour 2020)
  • s'adapter à la réglementation en pleine mutation et visant à protéger les utilisateurs
  • prendre en compte les nouveaux acteurs constituant un écosystème autour de la voiture connectée (assureurs par exemple) pour lesquels des accès au véhicule doivent être ouvert

 

USBiquitous : USB Toolkit par Benoit Camredon (Airbus Group)

La prolifération de périphériques et d'interfaces USB sur tous types d'équipements utilisés au quotidien fait de cette technologie une cible de choix pour les attaquants.

De plus en plus de vulnérabilités, parfois simples à exploiter, sont découvertes. Il devient donc nécessaire de s'intéresser à la sécurité de cette technologie.

Dans ce contexte, Benoit Camredon a conçu et mis en œuvre le projet USBiquitous destiné à capturer et interagir sur les communications USB.

USBiquitous se compose d'une plateforme matérielle qui s'insère entre deux équipements (man in the middle) et d'un ensemble de scripts (framework) permettant d'analyser et /ou manipuler les communications ainsi interceptées.

L'orateur nous présente ici l'architecture et le fonctionnement de son outil ainsi que différents cas d'usages (proxy USB, pare-feu USB, keylogger, fuzzer)

 

Confusion de types en C++ par Florent Saudel (Amossys)

Florent Saudel décrit ici les méthodes d'exploitation d'une catégorie de vulnérabilités encore peu connue : la confusion de type, dont l'exploitation peut mener à l'exécution de code arbitraire.

Prenant ses origines dans la mauvaise utilisation d'opérateurs de conversion couramment utilisés en programmation orientée objet (polymorphisme).

L'orateur illustre ses propos en s'appuyant sur des cas concrets issus de vulnérabilités découvertes sur le navigateur Google Chrome lors de l'édition 2013 de la compétition Pwn2Own.

 

Composants logiciels vérifiés en F* : Poly1305 par Benjamin Beurdouche et Jean Karim Zinzindohoue (INRIA)

Jean Karim Zinzindohoue nous présente les avantages de l'utilisation du langage de programmation fonctionnelle F* (f star) dans le cadre de la vérification formelle de composants logiciels critiques.

Après avoir présenté les caractéristiques de ce langage (typage fort) et les garanties obtenues suite à son utilisation, l'orateur illustre son exposé à l'aide d'un cas concret : l'utilisation de F* dans le cadre de la vérification de l'implémentation de l'algorithme Poly1305 dans OpenSSL.

 

My friends botnet: How to use your friends to perform Cyber Int ? par Amaury Leroy (Airbus Group)

Amaury Leroy nous explique comment il a mis à profit les accès Internet de son entourage pour se constituer un botnet destiné à monitorer et indexer Internet (collecte d'éléments réseaux, surveillance de la création de noms de domaines, certificats SSL, whois ...).

Après avoir essuyé plusieurs échecs pour parvenir à son but (serveurs Amazon aux accès / nombre de requêtes limités, déni de service DNS provoqué sur les plateformes VPS offshore, lenteur du réseau Tor), l'auteur a trouvé la solution dans la mise en place de boîtiers Raspberry couplés à un système Android chez ses amis.

Celle-ci consiste à collecter les éléments de manière distribuée, depuis les accès Internet de ses proches et de consolider ces données sur une plateforme Splunk centralisée.

L'auteur a également lancé un appel aux volontaires disposant d'un accès Internet très haut débit et désireux de participer à son projet (amaury<point>leroy<at>airbus<point>com).

 

Broken Synapse, par Ivan Kwiatkowski

Dans cette présentation Ivan Kwiatkowski détaille comment il a pu obtenir un avantage tactique certain dans le jeu de stratégie en ligne Frozen Synapse.

Son approche s'est basée sur l'analyse des communications réseau (sans succès) puis sur l'analyse du moteur de jeu qui est disponible en open-source (Torque Game Engine).

Ivan a été en mesure de développer le décompilateur adéquat qui lui a permis de reconstituer le code source du jeu de manière très fidèle à l'original.

Il peut ensuite modifier ce code pour modifier son comportement (désactivation du brouillard de guerre pour voir la position des unités ennemies sur la carte).

Pour conclure, il rappelle à quel point l'envoi superflu de données secrètes par le serveur au client est une mauvaise pratique.

 

Un FizzBuzz pour le cyber par Eric Jaeger,Olivier Levillain (ANSSI)

Eric Jaeger et Olivier Levillain nous présentent un questionnaire de recrutement original qu'ils ont mis au point pour évaluer efficacement les aptitudes en sécurité des candidats à la formation "Expert en SSI".

Les questions posées, très techniques et très pointues, n'ont pas vocation à tester les connaissances ou les compétences du candidat mais plutôt à servir de base pour engager une discussion lors d'un entretien pour mieux cerner la démarche suivie par le candidat pour aborder les problèmes présentés par le questionnaire. La curiosité intellectuelle est également évaluée, notamment si le candidat a pris la peine de se documenter sur les sujets qui l'ont mis en difficulté avant d'être reçu en entretien.

 

JOUR 2 :

A first glance at the Universal second factor (U2F) protocol par Florian Maury (ANSSI) et Mickaël Bergem (Paris Tech)

La première question posée lors de cette présentation concerne l'utilité d'un nouveau protocole de double authentification : U2F. En effet, les méthodes par SMS ou OTP utilisées couramment sont vulnérables aux attaques par phishing et le jeton est stocké et transmis en clair.
U2F est conçu pour fonctionner avec plusieurs types de supports comme des tokens logiciels ou clés USB. Le protocole implémente la preuve de présence et une fonctionnalité anti-rejeu.

Le protocole nécessite un navigateur compatible et une connexion TLS. Il implémente aussi une preuve de présence de par la nécessité d'une action de l'utilisateur pour activer le token (appui sur un bouton).

En terme d'utilisation, celui-ci n'est encore que partiellement supporté du côté de chez Google puisque son implémentation dans Chrome est expérimentale et à cause de l'utilisation encore répandue des proxy interceptant en entreprise.

 

How to not break LTE crypto par Benoit Michau et Christophe Devine (ANSSI)

Cette présentation porte sur certaines vulnérabilités et sur le contournement des procédures de sécurité LTE (nom commercial 4G).

La première partie décrit le fonctionnement d'une connexion LTE. La station de base diffuse des paramètres réseau en broadcast auquel le téléphone décide de s'attacher. Le téléphone contacte ensuite le cœur de réseau pour faire une demande d'attachement (identification et capacité, c’est-à-dire algorithme supporté par le téléphone) puis trouve l'abonné et lance la procédure d'authentification via une clé symétrique. Il s'ensuit une authentification mutuelle et un partage du contexte pour les connexions à venir. Le cœur de réseau va alors établir un canal sécurisé (protocole NAS).  Une fois le canal chiffré, l'antenne relais et le téléphone peuvent établir une connexion pour permettre les différents accès et transmettre des données IP.

Sont ensuite détaillées certaines vulnérabilités identifiées :

  • Certains fabriquant acceptent le contrôle d'intégrité nul (mode spécifié mais interdit d'utilisation) mais ne permettent pas d'utiliser le protocole NAS
      > Lors d'une reconnexion le réseau n'a pas besoin de répondre au message NAS et donc peut juste envoyer un contexte nul avec un MAC nul et donc une connexion sans chiffrement
  • Obtention de paramètres ESM sans sécurité. Tant que la sécurité du NAS n'est pas activée le modem ne doit pas donner d'autres infos que ses identifiants (IMSI et TMSI). Sur certain modèles le téléphone va quand même envoyer d'autres informations (identifiants, borne à laquelle il voulait s'attacher etc.)
  • Obtention de l'IMEI sans sécurité. Avant que le protocole NAS ne soit activé on ne devrait pouvoir récupérer que l'IMSI et le TMSI. Sauf lorsqu'on passe le bit de politesse à 1. En modifiant 1 bit, le téléphone accepte d'envoyer l'IMEI.

 

Détection de signaux AIS contrefaits par Erwan Alincourt (IRENav) et Pierre-Michel Ricordel (ANSSI)

Les signaux AIS (Automatic Identification System) sont utilisés par les bateaux pour la gestion du trafic maritime. Ce protocole est utilisé à des fins d'identification, de suivi de position, de trajectoire et de vitesse des bateaux équipés (obligatoire pour les bateaux commerciaux). Le système n'a cependant pas été conçu avec la sécurité à l'esprit. La fraude est donc très fréquente avec une diffusion de fausses informations pour cacher sa position ou encore changer d'identité.

La détection de la fraude n'est pas envisageable sur la couche logique puisque le système est conçu pour lui faire confiance. Les chercheurs ont donc étudié les possibilités de détection sur la couche physique. Le principe repose sur l'analyse de deux composantes du signal :

  • La puissance du signal : à partir d'une mesure de la puissance du signal reçu, il est aisé de donner une approximation de la position puisque la puissance est relative à la distance de réception. Il est donc possible d'identifier un réémetteur car le ratio puissance / distance est alors non cohérent.
  • Forme du signal : la modulation en fréquence et en amplitude du signal permet de tracer l'identité de l'émetteur. En effet, le matériel d'émission n'étant jamais parfait, le signal est sujet à une "empreinte" liée au matériel utilisé. Ainsi, un bateau changeant d'identité sur la couche logique aura toujours la même signature hardware.

Étant donné l'absence de sécurité pour l'AIS, la principale solution consisterait en l'augmentation du coût de l'attaque.

 

Comparaisons et attaques sur le protocole HTTP2 par Georges Bossert

Georges Bossert nous présente d'abord rapidement les origines et le fonctionnement de la version 2 du protocole HTTP basé sur SPDY, un protocole développé par Google. Celui-ci est un protocole binaire presque systématiquement chiffré et qui introduit une connexion à état (contrairement à HTTP 1.1 utilisé couramment encore aujourd’hui).

Le conférencier nous expose ensuite ses recherches sur les différentes implémentations du protocole avec la comparaison des documentations et des codes source. Étant donné l'état introduit par HTTP2, il est possible de faire une empreinte de la machine d'état du serveur. Il est aussi possible de faire du fuzzing intelligent en se plaçant à un endroit précis de la machine d'état ou encore de faire de l'évasion d'IDS.

 

Textplained, hardware security insight par Olivier Thomas

Olivier Thomas nous explique ici un panorama des évolutions des techniques d’attaques sur les circuits intégrés. Le secteur étant en forte expansion notamment avec les IOTs (voitures, cartes, téléphone, montre, …), les enjeux sont de plus en plus grands. Il détaille ensuite les trois catégories d'attaques :

  • Les attaques non invasives : on regarde ce qui se passe sur le circuit (mesure de la consommation du circuit pour obtenir des informations)
      > Un peu compliqué, on injecte des fautes pour voir le comportement, pas besoin de beaucoup de matériel mais prend beaucoup de temps
      > Side channel pour extraire une clé ou une autre information, mais il faut connaitre l'algorithme, regarder la consommation etc.
  • Les attaques semi-invasives : on fait des injections via laser, ondes électromagnétiques, etc. mais sans toucher à la puce :
      > Besoin de voir les puces
      > Pour les injections de fautes laser, passé un certain nombre de degrés, le silicium devient transparent, on peut donc faire switcher un transistor par exemple
      > Création d'un logiciel pour scanner la puce et monitorer les réponses. La précision reste faible avec le laser
      > Possibilité de faire une image avec le laser de manière plus précise. Possibilité de contrôler la carte et les instructions avec le laser
      > Cependant, il est souvent compliqué de comprendre ce qu'il se passe
  • Les attaques invasives : regarder, analyser, modifier
      > Quand on coupe une puce on peut observer diverses couches
      > Les transistors sont tout en bas et au dessus se trouvent les couches de transmission
      > Il faut donc enlever les couches supérieures de la puce (non trivial)
      > Besoin de microscope électronique pour avoir des images exploitables, ce qui permet à terme de :
      - Lire les ROM
        > Identifier les 1, 0 et récupérer les blocs de bits
      - Lire les Flashs
        > Extraction de code linéaire
      - Faire du microprobing
      - Le cas du shield : si on coupe la puce elle se suicide

 

Apps vs Wild, protection d'applications en environnement hostile par Stephane Duverger (Airbus Group)

Stephane Duverger propose une solution de protection des applications contre leur environnement, en particulier du noyau du système d'exploitation sur lesquelles elles sont exécutées. La solution ne doit pas toucher au code de l'application et ne pas faire de suppositions sur le fonctionnement de l'OS. L'approche du conférencier repose sur l'utilisation de la solution de virtualisation Ramooflax (qu’il a développé et présenté à la conférence SSTIC précédemment). L'objectif est de protéger le code mais pas les données puisque les accès physiques ne sont pas gérés.

 

FDP/Winbagility - Introspection et débogage furtifs de VMs par Nicolas Couffin (DGA)

L'objectif de la solution présentée ici est de déboguer des machines virtuelles sans y apporter de modifications et sans se faire détecter par le programme malveillant analysé, dans le cadre donc d’analyses de malware. La bibliothèque utilisée est "Fast debugging protocol", intégrée à Virtualbox. Winbagility simule un noyau débuggé et va chercher les informations voulues sur le programme analysé.

 

Déverrouillage d’Android en simulant un clavier souris par Antoine Cervoise (NTT Com Security )

Antoine Cervoise nous détaille ici son approche pour déverrouiller un téléphone Android. Il utilise un Arduino branché en USB pour simuler des entrées clavier et une webcam pour détecter les changements d’affichage à l’écran et donc une éventuelle authentification. Plusieurs problèmes doivent alors être surmontés comme le maintien de la charge du téléphone ou la bonne détection d’une authentification réussie.

 

The Metabrik Platform - Développement Rapide d’Outils de Sécurité Réutilisables par Patrice Auffret

L'outil ici présenté utilise les briks Perl pour structurer et optimiser la création d'outils de sécurité. Les points suivants sont mis en place :

  • Tout se fait en ligne de commande
  • Permet la réutilisation facile de code écrit auparavant
  • La syntaxe est normalisée human readable

L'outil présente un shell avec des commandes de type UNIX, une syntaxe à la Metasploit, l'auto complétion des commandes, fichiers et variables, et enfin une gestion simple des dépendances.

 

DYODE : Do Your Own DiodE, une diode open source à moins de 200€ pour réseaux industriels par Arnaud Soullié (Solucom) et Ary Kokos

Les diodes, utilisées pour ne laisser passer l'information que dans un sens (on parle alors de guichet haut et de guichet bat), sont parfois déployées dans les systèmes industriels. Cependant, leur coût important est souvent un obstacle à leur acquisition. Les conférenciers ont travaillé à la création d'une diode bon marché qui puisse répondre aux besoin des SI industriels.

Celle-ci utilise une liaison optique pour la transmission des données. Une jonction PN empêche les électrons de circuler dans le sens inverse et permet donc de protéger les automates (envoi de fichier dans un seul sens, partage d'écran, etc.).

Les limites actuelles de la solution concernent principalement la vitesse de transfert et l’assurance de la disponibilité sur les systèmes critiques.

 

JOUR 3 :

Java Card security, Software and Combined attacks et Java Card security, Software and Combined attacks par Guillaume Bouffard, Julien Lancia et Jean Dubreuil

Ces deux présentations nous décrivent les attaques possibles sur les environnements Java Card.

Après un rappel sur le principe de fonctionnement du BCV (Bytecode Verifier), chargé de détecter les codes malveillants, les différentes attaques possibles sont présentées suite aux recherches effectuées.

Lors de cette conférence, différents type d’attaques nous sont présentées.

Les premières sont des attaques basées sur des failles exploitées dans la machine virtuelle Java Card intégrée, l’objectif étant de forcer l’exécution de code malveillant en contournant les mécanismes de protection en place (vérification de la valeur du « security context »).

Enfin, des failles présente dans le BCV Oracle sont exposées. L’exploitation de ces vulnérabilités sur des implémentation Java Card permet l’injection et l’exécution arbitraire de code malveillant illustrées lors de cette conférence.

 

Noyaux Linux durcis par Yves-Alexis Perez

L’exposé débute par une présentation de Grsecurity et des rappels sur le fonctionnement et la sécurité du noyau Linux.

Après un rappel sur les risques inhérents à des défauts de sécurisation, les éléments proposés par Grsecurity sont présentés et notamment PaX qui offre des mécanismes de protection contre les corruptions mémoire en rendant aléatoire l’espace d’adressage mémoire par exemple.

Les apports proposés par le patch grsecurity visent l’état de l’art dans la sécurisation des noyaux Linux. L’objectif est de simplifier au maximum son adoption par les administrateurs système pour une utilisation plus répandue et un gain en sécurité globale.

Des scripts sont mis à disposition pour patcher les noyaux de certaines distributions (visant les versions stables de Gentoo, Debian, …), le constat est qu’il reste encore peu utilisé dû a des restrictions parfois fortes.

 

Design de cryptographie white-box : et à la fin, c’est Kerckhoffs qui gagne par Charles Hubain et Philippe Teuwen

L’analyse porte sur les solutions « sécurisées » de cryptographie du marché. Une approche très intéressante qui ne nécessite ni connaissances des tables internes ni rétro ingénierie.

L’approche est basée sur une analyse des traces d’exécution et accès mémoire enregistrés. Via par exemple une analyse différentielle de la consommation énergétique des accès mémoire, il est possible de reconstruire le tout bit par bit.

En injectant du code d’analyse additionnel durant l’exécution du programme il devient possible d’analyser et d’observer son comportement pour enfin déduire les informations recherchées (clé secrète par exemple).

 

Windows Error Reporting par Aurélien Bordes

Windows error reporting (WER) est apparu avec Windows Vista. Lorsqu’une erreur a lieu, un rapport WER est généré et transmis à Windows via un fichier de synthèse report.wer contenant une description et deux dumps. Les rapports sont traités par Microsoft pour identifier les bugs les plus récurrents et diffuser les correctifs.

Ces rapports (wer) peuvent être accédés sur une machine, en configurant un serveur qui recevra les rapports WER et archives contenant l’ensemble des fichiers générés. Dans les spécifications du protocole utilisé on découvre la possibilité de récupérer des informations suite à chaque erreur et générer de nouveaux fichiers.

L’outil est documenté et mis à disposition, pouvant être utile dans le cadre d’analyse forensic par exemple.

 

Bypassing DMA remapping with DMA par Benoît Morgan, Eric Alata, Guillaume Averlant et Vincent Nicomette

Cette conférence traite des défauts de configuration sur les mécanismes matériels et propose une attaque d’IOMMU (input–output memory management unit). L’attaque présentée exploite une vulnérabilité dans le firmware et dans le driver de l’IOMMU qui aboutit à l’insertion en RAM d’une structure malveillante, avant le démarrage.

 

Scapy en 15 minutes par Guillaume Valadon et Pierre Lalet

Dans cette présentation, les orateurs démontrent les possibilités offertes par SCAPY et quelques exemples d’utilisation.
Le focus est fait sur les fonctionnalités suivantes :

  • Manipulation de paquets
  • Interaction avec le réseau
  • Visualisation des résultats
  • Utilisation de Scapy en tant que module Python

Les évolutions à venir ont également été présentées : support des certificats X.509 et signature de certificat, support de nouveaux OS, …

 

Plaso & Timesketch par Romain Gayon

Plaso est un outil en python qui regroupe plusieurs outils permettant de parser les événements dotés d’un timestamp et générer des entrées normalisés, triées et filtrées.

Tomesketch est un outil basé sur Elasticsearch utilisé pour la gestion des workflows dans le cadre de réponses à incident. Il permet d’annoter les évènements, de disposer de plusieurs timelines, … Enfin, c’est un outil collaboratif.

Raphaël Coumau, Auditeur Sécurité, Advens
Fabien Robitaillie, Auditeur Sécurité, Advens
Céline Dekeyser, Responsable Audit, Advens