En direct du SSTIC, le retour...

C

ontrairement à une habitude bien ancrée, j'ai décidé d'éclater ce compte-rendu du SSTIC en trois billets, un pour chaque jour, ou presque. À la relecture, j'ai en effet l'impression qu'un seul billet est déjà lourd à lire déjà à la fin de la première journée, donc si ça regroupe les trois...

Voici donc le retour sur la seconde journée, la plus chargée, que je mets rapidement en ligne avant d'attaquer le troisième jour.

Jeudi 10 juin 2010 - Jour 2

Comme chaque année, le jeudi est la journée la plus chargée du SSTIC par la technicité des sujets abordés d'une part, et la durée du fait des rumps et du tant attendu social event d'autre part.

• "Presentation des résultats du challenge" par Raphaël Rigo, ANSSI, et solution par Arnaud Ébalard, EADS Innovation Works. Vous connaissez le classement qui est en ligne depuis une semaine. Arnaud prend ensuite la parole pour présenter comment il a résolu le défi. Les huit solutions sont disponibles en ligne. Je vous invite chaudement à aller les lire, c'est super intéressant et, pour ne rien gâter, ne se ressemblent pas. Raphaël reviendra préciser quelques points techniques du challenge... Et promouvoir, ô surprise, la campagne de recrutement de l'ANSSI... Décidément ;)
• "Sécurité de la plate-forme d'exécution Java : limites et propositions d'améliorations" par Christian Brunette, David Pichardie, Frédéric Guihery, Goulven Guiheux et Guillaume Hiet, Amossys-INRIA-Silicom. La présentation est basée sur les résultats de travaux demandés par l'ANSSI sur la sécurité de Java. Ça commence par une présentation de l'architecture générale de l'environnement Java, des propriétés et des mécanismes de sécurité, avec un focus sur JPSA. On enchaîne avec des exemples de problèmes récurrent de sécurité dans les applications Java : mauvaise utilisation des mécanismes fournis, ambiguités ou mécompréhension avec la bibliothèque standard, failles de la JVM elle-même. Les auteurs poursuivent avec des propositions pour améliorer la sécurité des applications Java : guides de développement/configuration/déploiement, audit de la bibliothèque standard, limitation de la surface d'attaque avec par exemple de la modularité, l'application du contrôle d'accès et, gros morceau, travailler sur le code et les fonctionnalités fournies par la JVM pour la renforcer. On termine avec une proposition pour l'extension de la vérification de bytecode. Bonne présentation générale, pas technique mais synthétique et claire.
• "Analyse de l'efficacité du service fourni par une IOMMU" par Éric Lacombe, Fernand Lone Sang, Vincent Nicomette et Yves Deswarte, LAAS/CNRS. La présentation commence par la description des attaques DMA qu'une IOMMU est censé prévenir. Vient ensuite une présentation de la technologie Intel VT-d qui fournit un service de traduction d'adresses pour les requêtes DMA permettant de contrôler l'accès à la mémoire par certains périphériques. Viennent deux catégories de vecteurs d'attaque. La première catégorie vise la reconfiguration de l'unité de traduction, lui permettant d'accéder à des zones de mémoire a priori interdites. La seconde catégorie vise le système d'entrées/sorties via les métadonnées fournies aux contrôleurs d'I/O en usurpant l'identité d'un périphérique. Une preuve de concept exploitant ce dernier vecteur est démontrée. Avec un scénario d'attaque visant à réaliser un ARP cache poisoning en injectant directement des trames ethernet dans la mémoire des cibles via son méchant 3vil iPod de n'hack3r.
• "Quelques éléments en matière de sécurité des cartes réseau" par Guillaume Valadon, Loic Duflot, Olivier Levillain et Yves-Alexis Perez, ANSSI. La présentation traite de failles dans le firmware des cartes réseau, en discutant de l'exploitation d'une faille particulière des cartes réseau Broadcom qui touche le protocole ASF^[1] avec en particulier les fonctionnalités de gestion distante fournies par RMCP^[2]/RSP^[3]. Ces flux d'administration sont traités directement par la carte, indépendamment de l'hôte et de son OS. Les auteurs présentent la vulnérabilité qu'ils ont identifiée dans le traitement des messages RSP et les méthodes qu'ils ont utilisé pour comprendre le problème et l'exploiter, avec en particulier un debugger pour carte réseau qui sera démontré. La vulnérabilité et son exploitation sont décrites, et auraient bien été complètement démontrées si Murphy ne s'en était pas mêlé. Dommage, d'autant que tout avait parfaitement fonctionné à Cansec fin mars :/ On termine avec quelques pistes de contre-mesures, comme ne pas utiliser ASF ;) Note intéressante : si Broadcom semble avoir géré la vulnérabilité rapidement et produit un nouveau firmware dans le mois, les constructeurs ont mis plus de deux mois à le distribuer...
• "Honeynet Project en 2010" par Sébastien Tricaud, Honeynet Project. Le retour du come-back de la revanche des honeypots :) Sébastien, qui a été nommé CTO du Honeynet, nous présente un aperçu de la structure du projet, de sa philosophie, ses orientations et son positionnement sur des activités de recherche et la restitution au public des résultats, avec en particulier des outils et des papiers comme les fameux "Know Your Enemies" et les plus récents "Know Your Tools". Suit une petite introduction à certains projets particuliers comme Nepenthes/Dionaea qui vise à récupérer des malwares exploitant des failles connues et PhoneyC qui crawle le web pour récupérer du code malicieux. Un petit mot sur les challenges proposés et une invitation à aller résoudre le challenge du moment sur la VoIP. Le projet lance tous les ans pleins de projets, une vingtaine cette année, au Summer Google of Code. Pour le futur, en guise de conclusion, la mise en place d'une plate-forme d'échange de données et le développement de systèmes d'anonymisation des traces. Présentation sympathique, pour ceux qui s'interrogent sur les activités du Honeynet.

Miam time engaged. Retour à 14h30 pour la suite des hostilités.

• "La sécurité des systèmes de vote" par Frédéric Connes, HSC. Un sujet polémique s'il en est. L'auteur commence par proposer quatre critères à réunir pour fournir un système de vote fiable : disponibilité, intégrité, auditabilité et secret de vote. Aucun système actuel ne réunit ces quatre propriétés, d'où la recherche de protocoles permettant de fournir ces garanties. L'auteur propose d'introduire une référence indépendante. Première proposition : double vote électronique et papier, avec comparaison des deux sur la base de recomptage papier aléatoires. Deuxième solution : fourniture d'un reçu de vote et publication sur un site web, mais pose des problèmes de complexité. L'auteur propose une troisième solution qui introduit une publication des votes pour garantir l'intégrité, tout en garantissant le secret du vote par le truchement d'une marque qui décorrèle l'identité du choix. L'électeur récupère un reçu lisant tous les choix de vote possibles. Sa propre marque se trouve en face de son choix. Les autres choix sont liés à des marques valides, liées par le passé à ces choix. Ce modèle préserverait le secret du choix de l'électeur et lui fournit sa propre marque, en face de son choix. Cela lui donnera aussi la possibilité de vérifier après publication les autres choix figurant sur son reçu. La génération de la marque est évidemment une étape cruciale, ainsi que la récupération des autres marques. Des solutions sont proposées, je vous invite à aller voir les actes pour les détails et réponses à diverses objections. Globalement, si le protocole a l'air de tenir la route, il se pose tout de même la question de la mise en œuvre de la vérification du vote qui nécessite la participation de tous les votants. Là, je rejoins l'avis un peu pessimiste de Vanhu : les gens ont déjà du mal à aller voter massivement, si en plus il est nécessaire que chacun vérifie son votre individuellement... Et je ne parle pas du problème de l'implémentation... En tout cas, il faut saluer l'approche ouverte et difficile de proposer un protocole, de plus intéressant, sur un sujet aussi sensible. Chapeau.
• "Applications Facebook : quels risques pour l'entreprise ?" par Alban Ondrejeck, Francois-Xavier Bru et Guillaume Fahrner. On commence par une description du modèle d'application Facebook et une discussion sur la vulnérabilité des applications et leurs capacités de nuisance, en particulier quand elles sont malveillantes. La stratégie d'attaque proposée consiste à fournir une application malveillante qui va réaliser à l'insu de ses utilisateurs des actions plus ou moins sympa. La diffusion reposera sur d'une part la création de profils fictifs et d'autre part sur la promotion automatique de l'application à l'installation sur, par exemple, le mur de l'utilisateur pour créer un effet viral. Les expériences réalisées par les auteurs sont intéressantes, en particulier la courbe d'évolution du nombre d'utilisateurs qui installent l'application. Côté Facebook, aucun contrôle a priori, par contre, retrait de l'application suite à des plaintes d'utilisateurs. Par contre, l'application pouvait être remise en ligne immédiatement sous un nom différent... On finit par des recommandations qui tournent essentiellement autour de la formation. Belle démonstration de diffusion virale de code malicieux via Facebook.
• "Projet OpenBSC" par Harald Welte. Bien que les protocoles soient publics, GSM/3G est un sujet très peu abordé par les étude sécurité du fait du monde très fermé qu'est l'industrie de la téléphonie. L'accès au hardware, aux logiciels et à la documentation est à un prix prohibitif quand il est seulement possible. Bref, GSM, c'est certes la voix, mais c'est également un transport pour pleins d'autres applications relevant du monitoring/administration/maintenance d'équipements distants et du transfert d'informations. La sécurité GSM/3G est en retard d'une bonne dizaine d'année par rapport aux réseaux IP traditionnels, alors que les conséquences sont énormes considérant la pénétration de la technologie dans de nombreux domaines. Le projet OpenBSC est de fournir le matériel nécessaire à l'étude et l'amélioration de la sécurité des infrastructure GSM/3G, avec en particulier les problèmes de spécifications, d'implémentation et d'opération. Le problème peut être pris du côté du téléphone, mais cela pose pleins de difficultés, en particulier pour faire ce qu'on veut du module GSM. Il peut aussi être pris du côté du réseau qui semble nettement plus simple à appréhender, et là que se situe OpenBSC qui propose une implémentation libre d'un réseau GSM qui s'expose à une BTS^[4] comme un BSC^[5] via une interface A-bis. Il se trouve qu'au-delà des travaux de sécurité prévus à l'origine, un vingtaine d'OpenBSC se trouvent être utilisés sur de vrais réseaux GSM. Les derniers slides posent pleins de problèmes connus ou constater pendant le développement de l'outil avec pas mal de soucis de vie privée à la clé. Quelques considérations sur le fuzzing GSM, en particulier par insertion de trafic sur le lien A-bis entre la BTS et et le BSC. En conclusion, l'auteur pointe le manque de sécurité et de robustesse des implémentations GSM disponibles sur le marché et invite tout le monde à s'intéresser au GSM parce que bon... TCP/IP, c'est "so last decade" ;) Du lourd, ça fait parfois peur...

Et maintenant, c'est l'heure de la fameuse séance de rumps ! Je vous livre les titres, auteurs et éventuels commentaires à l'arrache, donc pas forcément de manière exhaustive. Je complèterai plus tard si nécessaire.

• Rump session
  • "Kesse SSTIC" par le CO de la conférence. Des chiffres sur l'organisation du SSTIC : 450 inscrits, en 25h, 358 badges imprimés à l'avance, 12 secondes pour le scan à l'entrée, 27 femmes, 11 CO et 19 CP, association loi 1901, 77kEUR de dépenses vs 74kEUR de recettes, 34% du budget pour le Social Event, 30% pour le RU et 12% pour les pauses^[6], 467 pages dans les actes, 22 soumissions dont 13 retenues.
  • "Retex sur pentest Blackberry Enterprise Server", Ary Kokos. Trois compromissions complètes de BES en pentest via des failles triviales. Un mot de passe par défaut MS SQL permet d'enregistrer un compte admin qu'on utilise pour déclencher des fonctionnalité de synchro et de journalisation pour récupérer des informations, déployer des applications sur les terminaux, faire du DoS, bouncer les emails au niveau du serveur pour les espionner.
  • "1,$s/blonde/geek/g", Renaud Bidou qui bâche cher sur le cloud et certains flames sur les WAF... Y'en a un qui prend, ça solde ses comptes en live...
  • "Timing attack en pause café sur les cartes à puce pour machines automatiques", Florian Gleis et Pierre Capillon. Une carte à puce pour acheter du café, avec un système mal foutu au niveau de l'enchainement des opérations pour la gestion de la "fidélité", laquelle est incrémentée *avant* de débiter la carte du prix du café. Du coup, ça fait pleins de cafés gratis.
  • "Analyse de mémoire flash de téléphone portable", Christophe Grenier. Challenge d'analyse de la mémoire d'un téléphone Sony avec un scénario alambiqué et deux dumps mémoire. Quelques coups de Photorec patcher pour les originalités du Wear Leveling plus tard, c'est fini...
  • "Netglub, Really Open Source Information Gathering" : outil libre de data mining, extraction d'information et de knowledge management sur un principe distribué. Démo sympa.
  • Laurent Dupuis qui présente deux projets. Le premier est un spider appelé Bubulle qui nourrit le moteur de recherche QSWX. Le second est SecurityGarden, une ferme d'outils à la Packetstorm, mais green ;) Le tout en ligne fin de semaine prochaine normalement...
  • "Challenge BOSS", Caroline Fontaine. Le BOSS est un challenge autour de la stéganographie dont le but est de retrouver sur un lot de 1000 images les 500 qui contiennent un message. Le but est de stimuler la recherche en stéganologie.
  • "DESIIR", Pascal Sitbon, Arnaud Tarrago et Pierre Nguyen. Dispositif d'échange sécurisé via USB, évolution du même projet présenté l'an dernier en rump.
  • "Fiabilisation d'outils", Aurélien Bordes. But : contourner des cas où pwdump ne fonctionne pas. Solution : abus des fonctionnalités de réplication de l'AD par spoofing pour récupérer les bases d'utilisateur. Démo à l'appui. Quote : "l'AD, c'est un peu la déchetterie du système d'information" :)
  • "ExeFilter contre les méchants PDF", Philippe Lagadec. Une démo d'ExeFilter sur du filtrage/nettoyage de documents PDF vérolés.
  • "Weblogic for fun & profit". Possibilité d'attaquer anonymement la JNDI de l'outil via son protocole propriétaire T3. On voit bien le but du jeu, pour les moyens, c'était un peu rapide...
  • "Quand les intruseurs font du monitoring temps réel", Denis Ducamp. La présentation d'un projet, Ikare, sur le maintien du niveau de sécurité suite à des tests d'intrusion en testant régulièrement des sets de propriétés réduits.
  • "RDP 2 TCP" Nicolas Collignon, Romain Raboin. Encapsulation de TCP sur RDP vers un Terminal Server et rebond sur le réseau interne. Démo du PoC, codé à l'arrache pendant le voyage vers Rennes, qui foire au premier essai. Retour dans quelques minutes pour la fin...
  • "Oracle a new hop". Démo de tunneling à travers une base Oracle à base d'injection SQL puis élévationd e privilèges via PL-SQL pour faire des requêtes HTTP. J'adore :)
  • "Scapytain", Philippe Biondi. Un slideware en Gimp pour présenter une framework de gestion de campagnes de tests à base de Scapy.
  • "RDP 2 TCP, le retour de la démo foirée". Et... bingo, ça marche \o/

Et c'est la fin. Direction le Social Event qui s'est déroulé, comme l'an dernier, au Coq Gadby. Évènement une nouvelle fois réussi grâce à une météo certes maussade mais clémente côté précipitations, un ambiance très décontractée, un cadre agréable et une cuisine sympathique. Ensuite, ce fut le cortège vers la Rue de la Soif, avec une grosse concentration de SSTICers collés au comptoir du Barantic. Enfin, la foule s'est éclatée entre les différents bars de nuit du quartier sur la promesse de se retrouver le vendredi matin. Quelque chose me dit que l'amphi devrait être plutôt... Clairsemé demain matin... Mais chuuuuut...

Vous pouvez toujours suivre le SSTIC sur Twitter (#sstic2010, #sstic) et Identi.ca (#sstic2010, #sstic), ainsi que sur d'autres fils et blogs sur lesquels les billets commencent à fleurir çà et là :

• par Mat chez Hurukan.
• par Erwan sur n0secure avec un billet par intervention !
• par M. Vanhu :
  • Jour 1.
  • Jour 2.
• par Jean-Philippe sur Identi.ca.
• par Jer001 qui semble avoir zappé la journée d'hier ;)

Notes

[1] Alert Standard Format

[2] Remote Management and Control Protocol

[3] RMCP Security-Extensions Protocol

[4] Base Transceiver Station

[5] Base Station Controler

[6] Soit 58kEUR de bouffe/boisson...