Mardi 3 juin 2008 - Jour 0

Comme d'habitude, le SSTIC a commencé pour moi la veille, à mon retour de Syscan Hong Kong[1]. Train attrapé à Montparnasse sur le coup des 17h pour un arrivée sur place deux heures plus tard. Chambre d'hôtel prise, c'est le sempiternel rendez-vous sur la terrasse du Surcouf, face à la gare, où on retrouve les habitués des lieux. À 20h, déplacement vers le restaurant dans lequel se tient le dîner des speakers. Ambiance sympathique et propice à un déplacement de l'esprit festif vers d'autres endroits auxquels je ne me rendrai pas. Dodo tôt, bizarrement, je semble avoir quelque sommeil à rattraper...


Mercredi 4 juin 2008 - Jour 1

Update 4 juin au soir : maintenant que j'ai pu lire les articles que je voulais lire à tête reposée et partagé mes avis avec d'autres, j'ai procédé quelques mises à jour...

Le truc du premier jour, c'est l'accueil des participants qui met les organisateurs à l'épreuve de la foule. Et malgré les craintes avouées la veille, ça semble s'être plutôt bien passé. Et puis c'est le remplissage de la salle qui laissera cependant quelques-uns sur les marches et, sur le coup des 10h, le discours d'accueil du président, avant de laisser sa place à la keynote de Marcus Ranum.

  • "Sécurité : anatomie d'un désastre annoncé", par Marcus Ranum. Je dois avouer que j'ai eu un peu de mal à suivre. Globalement, l'auteur s'essaye à expliquer les désastres informatiques en les calquant sur un processus classique. Faute à des mauvaises idées qui font leur chemin au travers d'une hiérarchie et arrivent à terme faute d'opposition efficace ou d'écoute éclairée, faute à une divergence entre la réalité et les attentes de la direction ou des clients, etc. Excellents exemples. Maintenant que j'ai lu l'article, j'ai tilté sur le fil directeur. Comme le titre l'indique, il s'agit de tout ce qui tourne autour de ce qu'il appelle le désastre informatique : sa genèse, sa réalisation, la gestion du désastre. Le fait que le risk management ou la législation ne font que retarder les choses.L'idée forte qui me reste à l'esprit et à laquelle j'adhère complètement est le gouffre entre la réalité et la perception de la réalité, ou les attentes, et la nécessité de combler ce trou pour casser le cercle vicieux évoqué précédemment. Le constat est dur, très pessismiste. Je ne le suis pas autant. Le manque d'expérience probablement. Bref, excellente keynote qui mérite d'autant plus qu'elle a demandé un effort considérable de la part de l'orateur qui l'a faite entièrement en français. Et non, je ne pense pas que son français ait été incompréhensible, mais hésitant, ce qui à mon sens a nuit à son exposé. J'aurais préféré qu'il fasse son intervention en anglais : ça lui aurait donné, je pense, une toute autre dimension. Mais encore une fois, ça n'enlève rien à la performance.
  • "Identification et exploitation des failles humaines par les prédateurs informationnels : un risque sous-estimé par les entreprises ?", par Michel Iwochewitsch. Un discours intéressant sur les failles humaines et les outils pour les exploiter. En général, les présentations qui touchent au social engineering reste relativement flou en terme de définition des outils, des méthodes, brefs des leviers qu'on peut actionner pour exploiter un être humain. Le discours ressemble beaucoup à l'article qu'il a publié dans MISC 36. Il nous parle d'heuristiques, de biais cognitifs, de perception, de profil de personnalité. Tout ça pour nous montrer combien l'être humain peut se montrer prévisible dès lors qu'on le caresse dans le sens du poil, qu'on le place en situation de stress, etc. C'est une entrée en matière très intéressante, avec pleins de pistes pour approfondir. La lecture des slides et de l'article semblent indispensables dans la mesure où il n'a passé l'intégralité du ses transparents. À méditer.
  • "Activation des cartes à puce sans contact à l'insu du porteur" présenté par Christophe Mourtel et co-écrit avec Pierre Girard et Carine Boursier. Présentation non pas sur les RFID au sens strict, mais bien sur des cartes à puce qui seront activées par un champ magnétique. Distrinction importante puisque les problèmes de sécurité associés sont, évidemment oserais-je dire, assez différents. Ça commence par une description de l'architecture, du fonctionnement, les contraintes de fonctionnement et les applications d'une carte à puce sans contact. En particulier, objet de la présentation, les stades pendant lesquels un attaquant peut extraire de l'information, ainsi que le type d'information : identificateur, famille de carte et d'applications installées qui permettront une traçabilité et une sélection de la cible plus ou moins ciblées. Côté attaques, il différencie dans le monde des cartes à puce les attaques passives (failles logiciels, side channels) des attaques actives (injection de fautes, attaque du composant). Pour les cartes sans contact plus spécifiquement, on pensera à l'écoute des échanges, le traçage du porteur, activation et scan de la carte par un lecteur malicieux, relais des échanges entre deux attaquants pour utiliser la carte à longue distance ou faire un MiM. Il va finir par quelques attaques sur des prototypes ou des produits du marché, avec des morceaux déjà présentatés par Gildas Avoine au SSTIC 2006 : sniffing, copie et réutilisation d'une carte, augmentation de la portée d'attaque, attaque en relais et combinaison des deux, falsification de passeports, sniff de RFID, etc. Les solutions les plus simples tournent autour de mécanismes implicant l'utilisateur, comme un bouton à presser, la fourniture d'une donnée imprimée sur la carte, d'autres veulent vérifier la réelle proximité du lecteur et de la carte avec des capteurs par exemple. Un dernier point sur NFC qui permettra par exemple d'utiliser un téléphone GSM comme carte à puce sans contact, avec une première attaque publiée la semaine dernière. Très didactique.

Et maintenant, c'est l'heure du déjeuner, au restaurant de la fac, et reprise aux environs de 14h45, pile poil à l'heure donc, avec un talk sur le forensics sur téléphone portables.

  • "L'expertise judiciaire des téléphones mobiles" par David Naccache. Statistique qui date de 2004 : 70% du marché était partagé par quatre acteurs principaux : Nokia, Motorola, Siemens et Samsung. Sauf qu'en quatre ans, le paysage a un peu changé dans le monde... Je pense par exemple à Sony-Ericsson et LG, mais aussi à HTC, et surtout à l'iPhone qui est train de changer considérablement la donne. La présentation porte ensuite sur les données utilisateur, opérateur ou spécifiques au mobile contenues sur le téléphone, ainsi que les outils et méthodes pour les récupérer, ainsi que le cadre et les procédures judiciaires associés. Deux problèmes principaux. D'abord, il faut connaître le PIN de la SIM. Ceci peut se régler soit en demandant gentillement au prévenu, soit en récupérant le PUK chez l'opérateur. Ensuite, il faut pouvoir analyser le téléphone en ne modifiant pas, ou peu, son état. Ensuite, il existe des méthodes et outils spécialisés pour l'extraction de données, parfois limité par les capacités du téléphone lui-même ou son non fonctionnement, allant du download des données au dessoudage de la mémoire, en passant par l'attaque ou carrément l'infection du portable à l'aide d'applets malicieuses. Conclusion avec l'exemple étrange d'une attaque récente où deux machines incapables de communiquer entre elles arrivent à s'échanger un grand nombre aléatoire. Tout est basé sur l'échange de chaleur entre les machines, information asservie et lue en jouant sur la vitesse de rotation du ventilateur du processeur sur chaque machine. La même technique a été utilisée pour passer de l'information entre deux zones d'exécution d'un FPGA... Pfiouh, tiré par les cheveux... Ceci étant, une des deux machines tournait sous Debian. J'espère que ce n'est pas celle qui générait le nombre aléatoire :) Et d'en arriver à un "thermobug" de la taille d'une pièce d'un euro, manifestement destiné à reccueillir des données exportées, si on peut dire, par un programme espion implanté sur la machine. La fin sur les échanges de données était très bien, même si on a du mal à voir le rapport avec le début. Surtout parce qu'il n'y en pas en fait. Quand au début, sur les téléphone, comme le précise Bigbro dans son commentaire, c'était un poil vieux, avec des choses relativement surprenantes pour le monde de l'analyse judiciaire. Le coup de la batterie piégée par exemple me semble relativement douteux dans ce cadre... Au final, j'ai l'impression que la présentation n'était qu'un prétexte pour la partie finale qui n'a vraiment aucun rapport avec le sujet proposé. Mais bon, comme il n'y avait pas de résumé de l'intervention sur le site...
  • "Outils d'intrusion automatisée : risques et protections" par Mathieu Blanc, Moutane pour les intimes. La présentation porte sur les outils d'intrusion automatisés qu'on trouve depuis quelques années dans la trousse à outils du pentesteur. Il parle de Metasploit, Core Impact et Canvas. Ces outils automatisent l'intégralité du processus de test d'intrusion, depuis la découverte jusqu'au rebond. Mais ces outils présentent des risques: principalement erreurs de manipulation et utilisation pour des attaques volontaires. D'où la question de savoir comment s'en protéger, et en particulier la propagation automatique dont la furtivité n'est pas le but principal. Moutane nous décrit le fonctionnement, avec des shellcodes à deux étages qui implante un agent et du syscall proxying. Pour la détecter, il propose d'écrire des signatures pour Snort basée sur le code de l'agent qui permet de détecter la réalisation du deuxième étage de l'exploit et d'être relaitvement indépendant de la faille exploitée, donc du premier étage du shellcode, avec des résulats annoncés comme excellent, puisque sans faux-positif ou faux négatifs sur une plate-forme de test sous VMWare. Il propose également des techniques pour détecter l'exécution de l'agent sur la cible sous Windows, par interception des appels systèmes dans le noyau ou dans l'API Windows, dernière solution qui sera retenue en utilisant Microsoft Detours. La collecte des traces se fait via un serveur en Python. Côté contre-mesure, on aura la gestion des patches, un IPS avec les signatures qui vont bien dans Snort-Inline, le confinement des attaques ou la contre-attaque sur une faille de l'outil.
  • "Bogues ou piégeages des processeurs: quelles conséquences sur la sécurité" par Loïc Duflot. Partant de l'hypothèse, pas forcément irréaliste, que le processeur d'une machine soit buggé ou piégé, Loic analyse les conséquences en terme de sécurité sur le système d'exploitation qui tourne dessus. Le tout orienté sur les architectures x86. Après quelques rappels sur l'architecture x86, il nous présente quelques exemples de piégeage et analyse leur impact en terme de sécurité. Le but du piégeage est, à partir d'une application non privilégiée, d'atteindre le niveau maximum de privilèges avec une généricité et une discrétion maximales. Le premier exemple est une modifiée de l'instruction "salc" pour donner alternativement les privilèges ring 0 ou ring 3 lorsque le processeur est dans des états particuliers. Ce piégeage est exploitable avec une gestion mémoire "à plat", exemple sous OpenBSD à l'appui. Par contre, dans le cas général, ça ne passe pas. D'où une évolution du piégeage pour avoir accès à l'intégralité de la mémoire physique en modifiant également le comportement de "call" et "ret" sur l'activation d'une variable donnée, ce qui lui donne l'accès privilégié quelque soit le système d'exploitation. En terme de contremesures, réduction des applications exécutables sur la machine, suppression des moyens de compilation et d'exécution de code arbitraire, respect des bonnes pratiques de sécurité, etc. Bref, réduction du risque. Proposition irréaliste également d'exécution comparée sur des processeurs différents. Fin du talk sur deux petites démos rapides. Présentation très claire, précise et carrée.
  • "Autopsie et observations in vivo d'un banker" par Frédéric Charpentier et Yannick Hamon. Analyse réseau d'un virus appelé Anserin destiné au vol de mots de passe. Il hook IE pour afficher des formulaires malicieux récupérés depuis un "injector server" au milieu des sites bancaires et envoie les élements d'authentification saisis à un "collector server". Ce dernier serveur sert donc à récupérer les données, mais aussi à fournir les mises à jour et les configurations, le tout avec quelques éléments d'authentification. L'injector server est optionnel. Il pousse des formulaires simples ou évolués adaptés aux sites ciblés suite aux requêtes du malware. Exemples très instructifs sur le niveau des attaques à l'appui. Le virus dispose également de fonctions de résilience basés soit sur des FQDN pseudo-aléatoires ou des serveurs Fast-Flux, le tout hébergé chez des providers bulletproof pas vraiment bon marché, dont certains peuvent traiter des opérations bancaires, ce qui donne une idée des sommes que ça rapporte. On notera que d'autres bankers gèrent aussi Firefox. Un bon talk, plaidoyer pour les authentifications double canal ou multi-tiers. Perso, pour les paiements en ligne, je pense qu'il faudrait peut-être aussi creuser plus sérieusement les CB électroniques jetables. Ça ne bloquera pas les attaques de type relais, mais au moins le rejeu, ce qui est représente quand même une grosse partie de ce qui se fait.
  • "GenDbg : un débogueur générique" par Jean-Marie Fraygefond et Didier Eymery, co-écrit avec Jean-Marie Borello, Philippe Bion et Odile Eymery. Présentation d'un débugger générique dans le sens indépendant de la plate-forme, de l'architecture et de du système d'exploitation implémenté du fait du manque d'outils capable de s'adapter aux nombreux produits à tester. Fonctionnalités : IHM à la Softice, moteur de scripting, architecture client/serveur avec debugging à distance. Le code client qui s'exécute sur la cible, appelé "stub" est spécifique à la plate-forme testée et propose des primitives communes. Des modules optionnels plus ou moins génériques selon leur fonction viennent compléter le framework. Vous pourrez voir les slides pour plus d'information sur l'architecture et le fonctionnement. Ceci étant, dans la mesure où, malheureusement, GenDBG ne sera pas publié, au mieux une version binaire réduite à Win32 avec modules de base, le discours perd pas mal de son intérêt. Je veux dire que savoir que GenDBG existe avec pleins de features, de stubs et de modules, qu'il fonctionne comme ci et comme ça, c'est super, mais si on ne peut pas l'utiliser... Comment dire ?... Non rien. Une ch'tite démo pour finir, après avoir demander à des âmes charitables de développer des modules pour MacOS... Pour un outil non distribué, rappelons-le...

Fin de la journée, direction le cocktail. Et après ? Ben on verra...


Jeudi 5 juin 2008 - Jour 2

Et c'est reparti pour une journée. Étrangement, il y a moins de monde qu'hier matin...

  • "Sécurisation, état de l'art et nouveaux enjeux des Green Data Centers" par Christophe Weiss. La présentation porte sur les mesures de protection dédiées aux data centers, très orienté design des installations, sécurité physique et disponibilité : surtensions, courant maintenu, climatisation, protection incendie, contrôle d'accès, anti-intrusion, alarmes diverses, supervision des installations, etc. Avec l'apparition des blades, ou du moins serveurs pizza-box, on a vu une augmentation de la charge capacitive et de la densité thermique qui impacte le design des alimentations, de la climatisation et des moyens de redondance. La densification entraîne des consommation qui posent de nombreux problèmes avec les data centers anciens qui ne sont pas conçus pour absorber cette charge, en terme de puissance, de dissipation et de redondance. Bref, pleins de problèmes face à l'évolution. Je vous laisse découvrir tout ça sur les slides[2], il y en a un peu trop pour ces lignes. Le data center vert vise à l'efficience énergétique, tout en faisant tourner les installations 24/7. Stat intéressante : environ 2/3 de la consommation vient de la climatisation... Classification par "tiers" selon l'efficacité. Blablabla. Bon, je laisse tomber. C'est bien, mais c'est plein de données, de tableaux et de schémas dans tous les sens. Vous verrez avec les slides. Au point où on en est, c'est à dire à 10 minutes de la fin, ce talk est sympa, mais un poil monocorde, donc difficile à suivre à 9h du matin, et on sent que le speaker connait son sujet. C'est une bonne lecture pour la culture générale.
  • "Déprotection semi-automatique de binaire" par Alexandre Gazet et Yoann Guillot. Talk technique qui commence direct avec une introduction rapide sur quelques fonctionnalités de Metasm, le binding et le backtracing, qui visent à pallier certaines limitations d'un outil comme IDA. Les travaux sont illustrés par des cas pratiques. Le premier est le binaire Pouet.exe du Challenge Securitech 2006 sur lesquels ils démontrent de fonctionnalité de détection des sauts conditionnels biaisés et de nettoyage/factorisation du graphe d'exécution, avec une réduction de 70% du volume de code, permettant d'obtenir un binaire propre prêt à être analyser. Le second exemple porte sur le binaire du challenge T2 avec de la détection/suppression de junk code visant à rendre le binaire illisible et l'analyse de la machine virtuelle sur laquelle s'appuie la protection. C'est très technique, mais à la fois étonnamment clair. Enfin, disons que j'en comprends l'essentiel, ce qui, pour du reverse engineering, suppose un niveau de clarté et de simplicité élevé ;)
  • "ERESI: une plate-forme d’analyse binaire au niveau noyau" par Anthony Desnos et Sébastien Roy, co-écrit avec Julien Vanegue. ERESI est un ensemble d'outils et de bibliothèques dédiés au reverse publié sous GPL. Des bibliothèques de désassemblage, de scripting, d'analyse statique et dynamique. Ça donne un ensemble apparemment puissant et complètement scriptable. En particulier, certains composants sont dédiés à l'analyse noyau, typiquement kernsh, ressuscité et intégré dans le projet pour l'occasion. Accès à l'intégralité de la mémoire noyau et donc lecture, injection de code, altération de flux via la libelfsh, le tout reposant sur un shell interactif scriptable. Bref, du lourd dont ils illustrent les fonctionnalités avec des techniques de rootkit noyau, typiquement l'injection en mémoire d'un LKM ou, comme démontré en démo, le traçage d'un rootkit. Impressionnant. Malgré tout, c'était un peu long et parfois confus, à la limite du catalogue au début. Manifestement, il y a des gens qui n'ont pas aimé.
  • "Cryptographie : attaques tous azimuts", par Jean-Baptiste Bédrune, co-écrit avec Frédéric Raynal et Éric Filiol. Attaques opérationnels sur la crypto, avec peu de moyens nécessaires et un minimum d'effort. On commence par de failles d'implémentation classiques, avec par exemple une application web avec un client Java embarquant les clés privées RSA utilisées ou MacOSX qui laissait les mots de passe en clair dans le swap, puis plus tard, en mémoire et dans le fichier d'hibernation. Il passe ensuite à l'analyse de binaires implémentant de la crypto pour identifier des pratiques faibles. Il s'agit de retrouver les fonctions cryptographiques par identification statique de constantes ou de pattern d'instructions, puis aller plus loin par analyse dynamique pour découvrir précisément leur mode de fonctionnement précis et leurs entrées. Je la fait un peu rapide, mais cette partie constitue l'essentiel du talk. Les slides sont bien faits et suffisamment clairs sur les méthodes utilisées. L'idée donc, c'est de retrouver toutes ces fonctions pour voir si elles sont bien utilisées, et, si ce n'est pas le cas, en exploiter les faiblesses. Très bien, un poil long au milieu. Bonne démonstration du fait que la crypto ne s'attaque pas qu'en force brute :)

Maintenant, c'est le déjeuner. Je vais en profiter pour finir mes slides... Parce que genre je passe dans trois heures, et c'est pas présentable. Du tout...

  • "Sécurité dans les réseaux de capteurs" par Claude Castelluccia. Des unités de mesure, avec puissance de calcul limitée, dispersés aléatoirement dans l'espace qui vont s'organiser en réseau maillé pour communiquer leurs mesures vers point central et/ou relayer celles des autres. Les applications sont nombreuses. La sécurité est un problème difficule du fait des limites du matériel, en particulier la réserve d'énergie, de l'accessibilité des nœuds et du coût de fabrication. Les menaces tournent autour de l'écoute et de la compromission du réseau. Deux exemples d'application. D'abord les implants médicaux comme les pacemakers pour la configuration, le recueil, le stockage et la transmission de données, et même le déclenchement d'actions d'urgence. Les problématiques de sécurité sont relativement évidentes, mais il n'y a aucune sécurité. Ce qui pose un autre problème : le compromis entre sécurité et besoins d'accès, en particulier en cas d'urgence[3]. Problème aussi d'abus de consommation d'énergie, d'où déni de service potentiellement mortel. Solution potentielle : carte à puce sans contact comme système intermédiaire pour valider les accès. Mais reste quand même des informations accessibles potentiellement utiles pour des assureurs/employeurs peu scrupuleux. Deuxième exemple avec les capteurs de surveillance qui ont des caractéristiques très différentes du cas précédent : nombreux capteurs qui doivent être bon marché et sont facilement accessibles physiquement. Côté sécurité, on doit gérer l'infrastructure, son routage et son intégrité, ainsi que la bonne aggrégation des données sur les nœuds intermédiaires pour minimiser les émissions radio coûteuses en énergie. Mais cela pose un problème de sécurité, puisqu'on a plus de sécurité de bout en bout entre le capteur initial et la station de base, en particulier en cas de compromission d'un ou plusieurs nœuds. Ou alors, chiffrement homomorphe aux opérations de calcul. La fin du talk porte sur les problématiques d'échange de clés efficaces mais peu gourmands.
  • "Dépérimétrisation : futur de la sécurité réseau ou pis aller passager ?" par moi. Je suis relativement mal placé pour juger de ma prestation et de l'intérêt d'un sujet un poil polémique et légèrement à la mode. Je vous laisse consulter d'autres sources d'informations comme les blogs qui couvriront la conférence ou les commentaires qui seront postés ici même.
  • "Pentests : "Réveillez-moi, je suis en plein cauchemar !"" par Marie Barel. La présentation met l'accent sur les petits détails juridique qui peuvent faire déraper un pentest. C'est conforme aux attentes et clair. À lire pour la culture et, dans le cas des pentesters, pour vérifier qu'ils sont bien dans les clous.
  • Et finalement, les rump sessions :
    • Olivier Heen a annoncé de la conférence C&ESAR ;
    • Christophe Grenier nous a à nouveau présenté PhotoRec, avec de nouvelles fonctionnalités.
    • Jean-Philippe Gaulier nous a présenté un truc tout simplement hallucinant, un projet de documentation pour Scapy ;
    • les gards d'INL nous ont présenté pleins de choses, allant de la visualisation à nfqueue-bindings et WeatherWall, en passant par Wolfotrack ;
    • Nikoteen a une nouvelle fois marqué l'assistance avec une séance de hacking de cerveau sur un air bien connu des Scorpions ;
    • pour ma part, j'ai fait un bête script shell pour faire croire que le certificat du serveur de déclaration en ligne de l'IR était faible, ce qui n'est évidemment pas le cas[4], blague dont l'effet a quelque peu dépassé ce à quoi je m'attendais, ce qui montre bien que la plupart des gens, bien qu'au courant d'une faille relativement importante, ne font pas les vérifications de base ;
    • Vincent "Tyop?" Gasconi et son compère Manfred Touron qui présentaient l'Advanced CRSF, nouvelle attaque née du subtile mariage de CRSF et d'injections SQL en aveugle et à retardement ;
    • etc.

Vendredi 6 juin - Jour 3

Arrivée sur les lieux vers 8h50. L'amphi est pour le moins... clairsemé, mais va rapidement se remplir pour atteindre un taux de remplissage tout à fait surprenant pour un lendemain de social event. On commence à 9h20 avec le premier talk.

  • "Une Architecture de Bureaux Graphiques Distants Sécurisée et Distribuée" par Jonathan Rouzaud-Cornabas. Il décirt un architecture de bureau distant s'appuyant sur NX, SSH, de l'authentification forte et de la virtualisation. Gestion de la disponiblité par migration à chaud des VM et répartition de charge sur les clusters de serveurs. La sécurité intègre également des éléments de cloisonnement fort et de la détection d'intrusion. Le tout basé sur du logiciel libre. Il est difficile de se faire une idée en trente minutes, mais ça mérite de l'attention. Bon talk, avec un speaker qui parle fort, ce qui est tout à fait appréciable pour un premier talk.
  • "Walk on the Wild side" par Guillaume Arcas. Un présentation sur le trojan Storm. Ver apparu fin 2006, gros pic en 2007, avec un C&C en peer-to-peer, hébergé en fast-flux. But du trojan : envoi de spam, DDoD, proxying web et DNS. Le talk démontre le fonctionnement de Storm après analyse de 6Go de traces réseau et cinq-cent binaires collectés. Je ne vais pas m'étendre sur le fonctionnement qu'on peut retrouver un peu partout sur le net. Par contre, la présentation est bien délivrée, avec des points intéressants comme les évolutions techniques récentes, comme l'introduction de resolvers DNS malicieux ainsi que des hyptohèses sur la tête de l'écosystème qui sous-tend l'ensemble du système. Là encore, on trouve l'utilisation de bulletproof hosting déjà mentionné dans une autre présentation. Excellente entrée en matière si vous voulez creuser le sujet.
  • "SinFP, unification de la prise d'empreinte active et passive des systèmes d'exploitation" par Patrice Auffret. Introduction sur la prise d'empreinte à distance, avec le mode actif et le mode passif, le pourquoi, le comment, etc. Ensuite, on a un panorama des outils de fingerprinting actif et nmap en particulier, et de leurs limitations. Et puis forcément, le cœur du sujet, SinFP. L'outil, en mode actif, utilise trois paquets TCP standards à destination d'un seul port ouvert : un SYN sans option, un SYN avec pleins d'options et un SYN-ACK. Prise d'empreinte simple, légère et fonctionnelle, principalement avec le second paquet qui suffirait dans la plupart des cas. La description technique du fonctionnement est dans les slides et l'article, je vous y renvoie. Propriété intéressante : un OS a une signature unique. SinFP utilise des masques pour adapter sa vision de la signature au cas pratique dans lequel il est utilisé, typiquement passif vs. actif par exemple. Pour ce mode passif, SinFP modifie les paquets capturés pour qu'ils puissent être interprétés comme des paquets résultant d'un scan actif. Bonne présentation. J'aime bien le concept de SinFP qui travaille beaucoup plus sur l'interprétation de l'empreinte. À tester, voire utiliser, si vous ne le connaissez pas.
  • "Recueil et analyse de la preuve numérique dans le cadre d'une enquête pénale" par Nicolas Duvinage. En préambule, rapide présentation de l'IRCGN, puisque le speaker est gendarme. Le quotidien de ces gendarmes. Peu d'intrusions/compromissions, et qui utilisent des vulnérabilités bien connues, du fait d'un manque de déclaration de ce type de sinistre. Analyse de communications email, chat, IM. 90% de Windows, très peu d'utilisation de chiffrement. En fait, les preuves numériques interviennent surtout dans le cadre de délits non informatique. Il distingue trois familles : crimes pour lesquels l'informatique est un accessoire (SMS, emails, etc.), ceux pour lesquels l'informatique est un support (diffusion de contenus illicites) et enfin ceux dont l'informatique est l'objet (intrusion). Dans les trois cas, l'informatique fournit des éléments intéressants. Les deux premiers ne nécessitent pas de connaissance technologique. Le dernier diffère par l'objet même du délit. Preuve : tout élément matériel ou immatériel reccueilli et analysé apportant un indice. Un élément informatique peut tout à fait être une preuve. Dans la pratique, ce sont des supports de stockage numérique de tous types. La collecte des traces peut-être directe (perquisition) ou indirecte (requête). Les difficultés : élément potentiellement présent dans toute enquête, preuve potentiellement stockée à distance, à l'étranger, et se présenter sous une énorme variété de formes, dans pleins d'endroits différents. Autres défis : comment gérer un ordinateur allumé, un GSM en fonctionnement. L'exploitation de la preuve ne doit pas la modifier pour laisser place à la contre-expertise, mais c'est compliqué à gérer. D'où des copies brutes, en lecture seulement, et travail réalisé sur la ou les copies. Problème d'ordre techniques, genre ordre de réalisation des opérations de forensics, en particulier les relevés de preuves non informatiques ou encore supports des spécificités des preuves analysées, ou d'ordre non techniques. Enfin, interprétation de la preuve, avec une mise en perspective des preuves avec l'objet de l'enquête, les expliquer et en montrer les limites. Conclusion sur des conseils pour les RSSI. Excellente présentation, très intéressante. Grosse déception : pas d'article dans les actes...
  • "Voyage au coeur de la mémoire" par Damien Aumaitre. Analyse de la mémoire physique pour reconstruire la mémoire virtuelle. La première partie porte sur l'organisation de la mémoire et la reconstruction de la mémoire virtuelle à partir de la mémoire physique. Les slides sont globallement bien faits, donc je ne vais clairement pas épiloguer sur les détails. La reconstruction s'appuie sur une cartographie de la mémoire physique pour retrouver les structures qui vont bien en mémoire. La seconde partie s'intéresse aux moyens d'accès à la mémoire physique : FireWire, VMWare, hibernation, Coldboot, outils de forensics, et zoom sur le cas du FireWire qui dispose grosso modo d'un accès direct à la mémoire physique via DMA. Cet accès est contrôlable par l'OS, mais est typiquement activé pour les mass storage. La manipulation consiste à présenter un portable comme un iPod ou tout autre stockage de masse, permettant l'accès à la mémoire de l'hôte attaqué. Et enfin, des démos. En lecture, pour du forensics par exemple, mapper la mémoire et avoir une idée de ce qui tournait sur la machine au moment du dump et obtenir des données sympas, genre base de registre, SAM, secrets LSA, clés de chiffrement... Par exemple... En écriture ensuite, avec par exemple la possibilité de se loguer sans mot de passe... En patchant deux octets en base de registre. En exécution enfin, avec un accès en lecture/écriture en hookant des fonctions fréquemment appelées, comme _KUSER_SHARED_DATA, avec un shell SYSTEM qui pop au-dessus de la bannière de login. Excellente présentation. Lecture des slides et de l'article chaudement recommandée.

Et à table !

  • "Recherche et développement en sécurité des systèmes d'information : orientations et enjeux" par Florent Chabaud. Manque de perception des enjeux par les politiques, donc une culture de la sécurité peu présente. D'où un rôle à jouer pour la recherche. Passage en revue de l'article de Marcus Ranum sur les six idées les plus stupides en sécurité informatique : l'autorisation par défaut, le recensement de vulnérabilités, pénétrer et corriger, le hacking c'est super, sensibiliser les utilisateurs, il vaut mieux agir que ne rien faire. OK, mais avec quelques nuances. Vient ensuite le concept de défense en profondeur qu'il faudrait développer. Prévenir, bloquer, renforcer, détecter, réparer. Le tout illustré sur le Wi-Fi. Sauf que dans la réalité, on est mauvais en prévention, on mise trop sur le blocage, la tolérance est aggressions est mauvaise, la détection aussi et la capacité de réparation est très faible. Doù des orientations qui doivent s'inscrire dans la durée pour rattraper un retard évident. Dans la mesure où les problèmes viendraient d'erreurs de conception initiales, développer des OS plus sûrs. L'introduction des pots de miel me parait un peu fumeuse... Ensuite, on passe en revue les forces et faiblesses de la recherche française. On est bon en crypto et en méthodes formelles, mais ces compétences ne sont pas utilisées dans la vraie vie et sont donc sans impact. Côtés faiblesses, on pêche en OS, en protocoles réseau et en architectures matérielles, aussi bien dans le domaine universitaire qu'industriel. Il faudrait rééquilibrer la recherche en sécurité : développer une masse critique d'équipes spécialisées qui échangent. Bref, une communauté animée par la recherche académique. Thématiques prioritaires listées dans un rapport d'orientation, revu annuellement, dont la dernière version vient juste d'être mise en ligne[5] : architectures, l'informatique de confiance, cryptographie et gestion des clés, ergonomie et supervision, fédération d'identités, formats de données et protocoles, systèmes d'exploitation. Mention du projet ANR SEC&SI pour la conception d'un OS sécurisé/cloisoné pour l'internaute. L'orateur est agréable à écouter, mais c'est très paternaliste quand même. Limite yakafokon, parfois même contradictoire...

Ayant un train à prendre relativement tôt, je n'ai pas pu assister à la présentation de Philippe Lagadec, "Dynamic Malware Analysis for dummies", et lui présente toutes mes excuses. Si quelqu'un se sent de me faire parvenir un résumé, je le mettrai en ligne ici-même. Idem pour la mienne.


Me voilà donc rentré à Paris au terme de ce sixième SSTIC qui s'est révélé tout aussi excellent que les précédents. Encore une fois, la conférence a honoré son rang d'évènement incontournable de la sécurité informatique en France, probablement le seul à rassembler dans une ambiance chaleureuse et ouverte des populations aussi variées allant des universitaires aux industriels, des étudiants aux consultants, en passant par les gouvernementaux de tous poils. Bref, un must. Encore une fois.

Et les photos sont en lignes. À l'endroit habituel.

Et ceci marque la fermeture de ce billet, en tout cas pour les modifications majeures, mais pas de ses commentaires. Et à propos de commentaires, je tiens à remercier chaleureusement tout ceux qui ont participé à l'enrichissement de ce billet. Y compris ceux qui l'ont confondu avec un Twitter ou un #SSTIC qui lague ;)


Rendez-vous pris pour 2009 en tout cas.

Notes

[1] Dont le compte-rendu se fera... Plus tard...

[2] Quand ils seront en ligne ;)

[3] Securité vs. sûreté...

[4] Il y a aussi des gens qui font correctement leur boulot dans ce monde, et heureusement.

[5] Voir les slides pour les URLs.