Compte rendu SSTIC 2008 - journée du jeudi

Fri 06 June 2008 by Loïc Cornet

Le SSTIC continue avec une journée très hétérogène : du debugging aux aspects juridiques de la sécurité des systèmes d'information, on parle de tout dans ces conférences pour le plus grand bonheur de tous ;-)

La sécurisation des "Green Data Centers" par C. WEISS.

Cette deuxième journée commence par un sujet plutôt atypique : la sécurisation d'un data center.La particularité de ce sujet est qu'il aborde des points spécifiques en termes de sécurité :- un périmètre étendu : le data center va du terrain où il est localisé à l'extincteur incendie ;- la sécurité est fondée sur l'aspect physique principalement ;- des contraintes supplémentaires sont à prendre en compte comme la pression écologique oul'augmentation du coût des énergies pour ne citer que ces deux exemples.C'est alors logiquement que les évolutions vont dans ce sens : optimisation de l'espace, meilleure répartition de l'énergie, etc...A ce sujet, une des évolutions notables concernent l'implémentation de serveurs blade (depuis 2004).L'audit d'un Data Center considère aussi bien les contrôles d'accès au site que les protectionsincendie / inondation en passant par les protections anti-intrusion.Au final, l'objectif est l'optimisation des différents facteurs physiques (ex : énergie) et la continuité d'activité.Plus précisément, les exigences sont classifiées et nous retrouvons ainsi les salles de type Tier I à Tier IV,ce dernier étant le plus contaignant. Par exemple, une salle de niveau Tier IV demande une très haute disponibilité(99,99% d'activité).Pour conclure, une présentation sobre où les experts du PRA/PCA y ont certainement trouvé un intérêt.

Déprotection semi-automatique de binaire par Yoann Guillot et Alexandre Gazet

Présentation d'un très haut niveau technique, concernant la « déprotection » de binaires obfusqués. La première partie montre les limites du désassembleur IDA lorsque les binaires sont massivement obfusqués : un graphe complexe, des sauts conditionnels biaisés, la présence d'éléments neutres.....La solution présentée consiste (à grosses mailles) à parcourir l'arbre des objets internes, rechercher des constructions du graphe dites « en diamant », factoriser les flots, réordonnancer intégralement le graphe… en bref, procéder au nettoyage du code afin d'éliminer les protections. Dans le contexte du challenge T2 (challenge de reverse), une « moulinette » a été développée à l’aide de metasm afin d'automatiser en grande partie toutes ces tâches d'analyse et de nettoyage. Au final, à partir d'un binaire obfusqué de plusieurs millions d'instructions assembleur, l'automatisation permet de retrouver 800 lignes de macro-assembleur, puis de restituer les 300 lignes de code C du binaire !!Outre le haut niveau technique, la présentation est très compréhensible, même pour les personne non experte en reverse. La technique et l'outil semblent très prometteur sur l'analyse de codes binaire, notamment la restitution du code de haut niveau. Il ne reste plus qu'à étendre le concept ;-)

ERESI: un plate-forme d'analyse binaire au niveau noyau, par Sebastien ROY

La conférence démarre sur une présentation du projet ERESI animée par Sebastien Roy. http://www.eresi-project.org/ERESI est donc un framework dédié au debugging sous plusieurs architectures: IA32, Sparc, MIPS, il supporte actuellement les plate-formes Linux, *BSD et Solaris. Il est composé de 5 exécutables et 14 librairies, celui-ci peut aussi bien faire de l'analyse statique des binaires à l'instar d'IDA que de l'analyse dynamique.

Après cette introduction assez claire, Anthony Desnos prend le micro pour nous parler du sujet de fond de la présentation, à savoir les nouveaux outils dédiés au debugging noyau dans ERESI, à savoir: Ke2dbg et Kernsh.La présentation se focalise sur les fonctionnalités offertes par ces deux outils: accès à la mémoire du noyau, modification du noyau, analyse statique du binaire du noyau, etc.

C'est donc le 3ème debugger à être présenté au SSTIC 2008 ! Il faut croire qu'il y avait vraiment un besoin à ce niveau.

Cryptographie : attaques tous azimuts, par Jean-Baptiste Bédrune

Cette présentation de Jean-Baptiste Bédrune a semble-t-il pour but de nous exposer les risques liés aux mauvaises implémentations des fonctions de chiffrement.

En premier, la présentation balaye rapidement les problèmes triviaux qui ont pu être rencontrés par le passé avec par exemple la présence d'une clef privée RSA dans une application Web en java, ou les credentials de Mac OS X dans les fichiers d'hibernation et en mémoire.La présentation s'oriente après sur l'analyse des binaires afin d'identifier les fonctions de chiffrements. Cette démarche a pour but de faciliter l'analyse du binaire dans la recherche des implémentations induisant des vulnérabilités.Une démonstration avec un plug-in pour le desassembleur IDA nous est présenté, les fonctions d'initialisations de crypto sont trouvée grâce à des constantes ou des patterns d'instructions. Par la suite, une analyse dynamique est réalisée pour comprendre le mode de fonctionnement des fonctions de crypto.

Sujet au final relativement technique mais somme tout assez clair et bien présenté. Une telle méthode fera sûrement gagner du temps dans les tâches de reverse-engineering.

Sécurité dans les réseaux de capteurs, par Claude Castelluccia

Cette présentation traite de la sécurité des réseaux de capteurs, difficile à mettre en œuvre étant donné les caractéristiques des capteurs :- faible autonomie ;- faible puissance de calcul ;- petite quantité de mémoire, etc.

Abordant le domaine médical et notamment les pacemakers, l'intérêt de sécuriser ces capteurs prend tout son sens. Une solution envisagée et prometteuse contre les dénis de service consiste à combiner une puce RFID avec le capteur lui-même, afin de lui offrir une sorte de pare-feu passif…D'une manière plus générale, le focus est mis sur la difficulté de mettre en place des communications chiffrées entre les capteurs. En effet, la crypto nécessite des ressources (processeur, mémoire...), et augmente la taille des messages échangés entre les capteurs (consommation d'énergie).Quelques solutions avancées sont l'agrégation des capteurs, ainsi que le chiffrement par flot. Il apparaît clairement qu'il est nécessaire de trouver un compris entre la sécurité, l'autonomie des capteurs et également la sûreté des patients dans le cas des pacemakers. Le problème parait complexe, mais le challenge en vaux la peine ! (surtout pour les pacemakers o)

La dépérimétrisation : futur de la sécurité ou pis aller passager, par Cédric Blancher

Si vous n'avez jamais entendu parler de ce sujet, rendez-vous à un cocktail avec petits fours vous dirait Cédric Blancher, le speaker de la présentation. Ce sujet "à la mode" repose sur l'idée de dépérimétriser le réseau de l'entreprise et globalement, remet donc en cause le cloisonnement des données. Largement supporté par le forum jericho, il s'agit globalement de ne plus utiliser, ou presque, d'équipement sécurité réseau (tel un pare-feu) puisque, disent-ils, leurs résultats sont médiocres face aux attaques. En fait, le mouvement fait face aux "boîtes à tout faire". Et sur ce propos, il ne devrait pas y avoir de désaccord : un équipement doit être dédié à sa fonctionnalité principale et pas autre chose. Par exemple, un pare-feu doit filtrer les flux réseau et point !Mais pour autant, dans l'idée, la communauté Jericho énumère à travers leurs "11 commandements" des arguments qui manquent de pertinence, à la limite de la palissade parfois en termes de sécurité informatique. Quant au document"Business Case for Deperimetrisation", il propose moins de barrière pour plus de business. Hé oui, la sécurité embête tout le monde et surtout la prod et briderait le business paraît-il ? C'est pas pour ça que vous travaillez dans la sécurité vous ? Au risque de faire quelques déçus, la sécurité a pour but premier de trouver des compromis entre sécurité et rentabilité de l'entreprise et l'exposer le moins possible aux incidents. Vous avez dit "inci..." quoi ? En effet, c'est l'aspect que le forum Jericho oublie d'aborder. En même temps, mettre les réseaux à plat, faciliter le travail de l'attaquant, et laisser les utilisateurs gérer leur poste nomade quand on sait que l'humain est très souvent le maillon faible d'une attaque; pourquoi est-ce que celaprovoquerait-il des incidents ?

Pentest : "Réveillez-moi, je suis en plein cauchemar !" par Marie Barel

Il nous fallait bien le SSTIC pour aborder enfin les tests d'intrusion d'un point de vue juridique.Et qui dit consultant SSI juridique dit ... Marie Barel ! Ok, c'était écrit dans le titre ;)Pour commencer, Marie nous a fait sourire en classant Nessus dans les outils "passifs" mais nous l'avons bien compris,c'est parce qu'il n'exploite pas de faille.Pour résumer brièvement le contenu de la présentation, il faudrait retenir les phrases suivantes :- le contrat entre le prestataire et le client, c'est très très très important ! Attendez, je rajoute encore un "très" !et attention, les contrats type, c'est pas bien !- il ne faut surtout pas négliger les phases de préparation (délimitation du périmètre, intervention d'un tiers ? (ex : hébergeur),etc ...)- l'expert sécurité, il maîtrise !Si le ton est quelque peu ironique, c'est qu'en réalité, les aspects juridiques sont d'une complexité inouïe et certainementplus encore que le plus difficile des pentests que vous ayez pu faire sur le plan technique et là, Marie, pour nous l'expliquer, elle maîtrise !Ici aussi, il n'y a pas un pentest pareil et puisqu'il y a forcément risque et argent mis en jeu, la prudence est indispensable. Si des lois (notamment le code pénale) essaient de cadrer tous les scénarii, c'est irréaliste dans la pratique. En effet, les mesures de protection juridiques côtés client et prestataire souffrent de failles elles aussi : on ne peut pas être exhaustif et la réalité ne permet souvent pas de mettre en place les propositions d'une loi ou recommandation juridique. Bref, sécurité technique, organisationnelle ou juridique, même combat : il faut limiter le risque au maximum.