jeudi 4 juin 2009

[SSTIC 2009] Day 2

ça continue pour cette deuxième journée. Déjà, certains ont du mal à se lever pour la première conf. de la journée. Bon, l'objectif est de faire un post moins long que pour le jour 1 !


Matinée

Une matinée dédiée au fuzzing ! En guise d'introduction, on commence avec une conf. d'Ari TAKANEN, Finlandais. Il nous explique sa vision sur le sujet : "Fuzzing : le passé, le présent et le futur". Ici, le but, c'est pas de montrer des vulns mais vraiment de voir les techniques de fuzzing et l'évolution de cette technique. Pour savoir quelle technique est la meilleure ou quelle sera celle qui nous conviendra le mieux, il faut prendre en compte trois critères :
  • les fonctionnalités offertes par le fuzzer ;
  • sa robustesse ;
  • ses performances.
L'idée est ici de considérer le modèle de fuzzing (mutation, pre-generated/scripted, block based, model based). Aussi, on souhaite ici se coller au fuzz en cours et l'automatiser au mieux. Par exemple, on cherchera à tenir compte des spécificités du protocole audité. Pour terminer, Ari nous propose une checklist pour choisir ou concevoir son fuzzer.

La deuxième conf est proposée par Gabriel CAMPANA. Elle fait la transition avec la précédente en présentant l'outil "Fuzzgrind". Ce dernier repose sur deux tools existants : Valgrind et STP. L'idée est que pour chaque nouveau protocole, c'est long de refaire son fuzzer. C'est là que Fuzzgrind arrive. Cet outil va travailler selon les 3 étapes suivantes :
  • exécution symbolique du programme audité ;
  • prise en compte des conditions (tous les cas) ;
  • création d'une équation pour chacune de ces conditions.
Des améliorations sont en cours mais déjà, l'outil a déjà trouvé des vulnérabilités dans des programmes comme readelf et swfextract ... en moins d'une heure ! Bravo !

La dernière conf sur ce thème du fuzzing est présentée par Laurent BUTTI. On s'attaque maintenant - dans le contexte d'une "architecture de convergence fixe-mobile" - à des protocoles dits de sécurité comme IKEv2 ou EAP . Et là où ça commence à faire peur, c'est qu'on trouve des failles là aussi ... En réalité ces protocoles apparaissent comme sûrs mais l'idée à retenir, c'est qu'il ne faut pas négliger les points sensés être sécurisés pendant les tests de tout genre car les failles vont provenir de l'ingénierie réseau et de l'implémentation de ses protocoles. En résumé, "don't trust any(one|thing)" ... (Source : Mulder dans X-Files ;).

On enchaîne avec la présentation de Romain RABOIN sur la sécurité des smartphones. Le speaker nous donne d'abord une vue d'ensemble des 4 OS les plus répandus sur le marché (Symbian, iPhone, RIM Blackberry et Windows Mobile). on va faire court : il existe des failles pour tous et il est possible d'espionner les données (appels, voix, ...) via des logiciels appropriés. on se focalise ici sur Windows Mobile et on essaie d'injecter le logiciel espion (un fichier *.cab). A priori, nous avons besoin d'un accès physique au téléphone, le temps d'injecter le programme. Ensuite, on peut agir à distance. Pour éviter cette nécessité, d'accès au téléphone de la victime, plusieurs solutions passent en revue et la gagnante consiste à utiliser le poste de travail avec qui le smartphone se synchronise. Le schéma est alors simple :
  • avoir un accès au poste de travail de l'utilisateur (ça n'a jamais posé problème) ;
  • programmer la synchronisation du logiciel espion avec le smartphone ;
  • c'est tout !
Il faut quand même savoir que notre programme malicieux n'est pas signé. une popup pourrait donc avertir d'utilisateur de son installation. Mais la modification (via rapi) d'une stratégie de sécurité permet de remédier à ce problème ;)

Pour la conf suivante, on change vraiment de sujet pour parler de watermarking avec Teddy FURON dans une présentation intitulée "le traçage de traitre en multimedia". Comme le titre l'indique, il s'agit de retrouver le ou les personnes coupables d'avoir effectuer une copie illégale d'un multimédia propriétaire (ouh ... pas bien !). Le défi est que les résultats puissent être suffisamment probants pour servir de preuve juridique. On se rend compte que ce n'est pas simples mais que le tatouage donne de bons résultats en se basant sur les faiblesses de la perception humaine (visuelle et sonore). Au final, on remarque que si le fichier n'a pas été trop dégardé par les pirates, nous pourrons retrouver les attaquants en estimant des probabilités sur leur culpabilité.

La dernière conf de la matinée est présentée par Marie BAREL, juriste attitrée du SSTIC ;) Elle nous présente un cas concret et que nous sommes amener à auditer régulièrement : le vol d'information par un stagiaire (ce que nous simulons pendant un pentest interne en l'occurrence). Les définitions du vol fournies par les lois françaises ne tiennent pas en compte des données numérique car :
  • par vol, il devrait y avoir "soustraction" or un vol d'information n'implique pas que l'entreprise touchée n'a plus à ses dispositions les données volées ;
  • par vol, on s'attend à voler un objet or les infomations représentent un objet "immatériel".
On voit qu'il est difficile de se protéger des vols d'information par les employés. Néanmoins, les chartes utilisateurs et NDA sont des premiers pas vers la protection. Il faut savoir aussi que l'employé a "obligation de loyauté" envers son employeur. Il n'empêche qu'une étude américaine affirme que 59% des employés vole des données avant de partir de la compagnie. Malheureusement, le contrat de travail ne prévoit pas toujours la confidentialité des informations après le départ d'une personne (même sur une durée limitée). Pire, le vol d'information est souvent repéré bien tard et la personne est certainement partie depuis ... Pire encore : qui a déjà vu une société où tous les accès (logiques et physiques) ont été correctement désactivés au départ d'une personne ?
En résumé, la loi n'est pas toujours adaptée au monde numérique et en voici la preuve. Cela a pour conséquence des brèches dont les coupables tenteront de se servir.
Pour terminer, je reprends les tois mots de la fin du speaker : "responsabilisation, communication et contrôle".

Après-midi

On commence avec Nicolas RUFF avec "Pourquoi la sécurité est un échec". Le titre annonce la couleur et avec la prés., on a presque envie de déprimer parce la sécurité, c'est notre raison de vivre (surtout si on n'a pas de vie sociale à côté ! :) mais on apprendra pendant les rump sessions qu'il existe des "copine de geek", OUF !) Bon, les problèmes majeurs datent d'il y a 30 ans selon notre speaker (Internet, langage C, ...) : OUF, je n'étais pas né, c'est pas de ma faute !!! J'arrête de déprimer et me dis que je vais quand même à faire de la sécu !
Lors de sa présentation, Nicolas nous montre les grosses failles Windows qui ont eu lieu et auxquelles il a participé et pas vraiment du neuf au final. On ne peut que confirmer que les environnements Windows sont prenables en tests internes. On explique dans la conf. le manque de prévention dans la sécurisation des SI par les entraprises et malheureusement, elles finissent par en payer les conséquences ... Reste à convaincre ces entreprises de payer "au cas où" ... Sinon, je propose qu'on prenne une comm' de 1% à chaque fois qu'on avait prévenu la boîte du problème en cours et qu'aucune correction n'a été apportée ...

Avant les rumps, on a eu des présentations de projets ayant pour but la sécurisation d'un OS pour un utilisateur lambda qui doit être capable d'effectuer toutes les opérations de bureautique classiques (mail, traitement de texte, e-commerce, ...) : c'est le projet SEC&SI. Les trois projets ont des approches différentes mais intéressantes. On retrouve les principes de serveurs mandataires, de sandbox, de hardening, etc. Pas de pronostic pour le moment mais on est obligé de marquer dans nos annales du SSTIC que "sh, ça nous a bien fait shourrir" :))

Quant aux rumps, on avait de tout. En tant qu'auditeur, j'ai surtout noté les outils IMA, reconet, evalSMSI et Netifera que je testerai dès que possible et même pourquoi pas, d'en faire un post.

PS : raté, je n'ai pas réussi à faire un post plus court qu'hier ; je retente demain !

4 commentaires:

Anonyme a dit…

Merci pour le compte rendu sur le SSTIC qui est très intéressant. Je me posais la question de savoir où on pouvait trouver evalSMSI.
Une recherche sur google a été vaine :)

Jérémy RENARD a dit…

L'adresse du projet est ici :
http://sourceforge.net/projects/evalsmsi/
Google a été plus gentil avec moi :)

Unknown a dit…

Pourriez vous me donner un lien valide pour evalSMSI ?

Jérémy RENARD a dit…

Voilà le lien :
http://evalsmsi.sourceforge.net/

Locations of visitors to this page