De retour du SSTIC 2010

12 juin 2010 – 14:08

Me voici de retour de l’édition 2010 du SSTIC. C’était la première fois que j’allais à cette excellente conférence, réunissant pas moins de 450 personnes autour de différents thèmes centrés sur la sécurité des systèmes d’information. Au programme : 3 jours de conférences, des rump sessions, un social event, des geeks, des trolls, du code qui défile, bref une super ambiance. Plusieurs personnes ont déjà fait un compte rendu détaillé de chaque conf (qui plus est en temps réel, chapeau à eux !), aussi je ne détaillerai ici que celles que j’ai trouvées les plus marquantes. Ce billet est pour le moment incomplet, il sera terminé très prochainement.

Enjeux et défis pour le renseignement technique

La première conférence est présentée par Bernard Barbier, directeur technique de la DGSE. Il y présente les activités pratiquées par l’agence à l’extérieur du territoire français, principalement en matière de renseignement d’origine technique, et rappelle les différents enjeux liés à la sécurité des systèmes d’information, en particulier les moyens de communication et la cryptographie. Quelques méthodes techniques d’obtention de renseignement sont illustrées, tout en rappelant leur aspect souvent clandestin et les conséquences que cela peut avoir dans certains pays. On y apprend (ou pas) que la DGSE pratique l’écoute téléphonique, analyse des photos satellite, utilise des super-calculateurs à des fins de cryptanalyse, et met en œuvre des techniques visant à fragiliser les méthodes de chiffrement lorsque celles-ci ne sont pas cassable en un temps raisonnable. Le tout étant présenté avec une transparence relative mais appréciable, du moins tant qu’on ne demande pas de la taille des clés RSA que l’agence est en mesure de casser :) . La conf se termine par un message clair : la DGSE recrute 100 personnes par an. Candidats, faites-vous connaître…

Keynote par Bernard Barbier, directeur technique de la DGSE

Keynote par Bernard Barbier, directeur technique de la DGSE

CASTAFIOR : Détection automatique de tunnels illégitimes par analyse statistique

Fabien Allard et Mathieu Morel (Thales) présentent un outil permettant de détecter l’utilisation de différents protocoles encapsulés dans du HTTPS. Leur méthode est basée sur un apprentissage utilisant un ensemble d’exemples traité en utilisant différentes méthodes de classification, les paramètres étant principalement la longueur des paquets et le temps entre chacun. Leurs expériences montrent que les meilleurs résultats sont obtenus en combinant Random Forest et les modèles de Markov cachés. Au final, on obtient 96% de bonnes classifications, et aux alentours de 5%.

virtdbg : un débogueur noyau utilisant la virtualisation matérielle

Damien Aumaitre et Christophe Devine (SOGETI ESEC) dévoilent un debugger au but simple mais ambitieux : pouvoir debugger un système Windows 7 64 bits sans activer le flag /DEBUG, ni désactiver PatchGuard. Deux problèmes : impossible de charger un driver non signé par la méthode classique, ni de patcher l’IDT (PatchGuard l’en empêche). Leur technique consiste à utiliser le DMA afin d’injecter leur driver comprenant leur hyperviseur. Pour ce faire, ils utilisent un FPGA connecté par PCMCIA sur la machine à debugger, et en USB sur le debugger. L’hyperviseur utilise la virtualisation hardware basée sur la technologie Intel VT-x (à la BluePill), et permet d’intercepter les interruptions 1 et 3. L’interface de leur debugger est codée en Python, et dialogue avec l’hyperviseur en utilisant le protocole GDB. Le tout avec une démo qui marche, bravo à eux :) .

Démo de virtdbg par Damien Aumaitre et Christophe Devine

Démo de virtdbg par Damien Aumaitre et Christophe Devine

Analyse de programme par traçage

Pour Daniel Reynaud, Jean-Yves Marion et Wadie Guizani, l’analyse statique de blob binaire c’est bien, mais pas suffisant. Surtout dans le cas de binaires packés par couches. On propose donc un outil libre nommé TraceSurfer basé sur PIN, permettant de suivre de déroulement d’un programme en générant des traces, puis de les importer dans des outils comme IDA Pro. Le résultat est assez sexy ; on peut alors visualiser les instructions effectivement exécutées par le programme, et détecter les éventuelles protections anti-debugging comme les auto-modifications ou contrôles d’intégrité. Il est possible de générer des graphes mettant en évidences les différentes couches d’un binaire packé. Pour tester sa performance, l’outil a été lancé sur un cluster dans le but de détecter des protections anti-VM de plusieurs milliers de malwares obtenus grâce à un honeypot. Les résultats sont assez intéressants, bien que je ne me souvienne plus des chiffres… À tester !

TraceSurfer en action dans IDA Pro

TraceSurfer en action dans IDA Pro

Intéressez-vous au droit… avant que le droit ne s’intéresse à vous.

Éric Barbry nous livre un véritable one man show qui contraste fortement avec le caractère technique des conférences précédentes. La France possède toute une série de lois relative aux systèmes d’informations, dont certaines difficilement applicables, et en pratique rarement appliquées en intégralité : Informatique et libertés, LSQ, LCEN, HADOPI, LOPPSI, etc. Et pourtant, «nul n’est censé ignorer la loi»… L’accent est porté sur la responsabilité, autour de questions concrètes telles que «Qui est le responsable si un employé télécharge illégalement du contenu ou parie en ligne sur des sites non autorisés depuis son bureau ?». Une très bonne intervention qui aura su capter l’intérêt de l’auditoire tout en traitant d’un sujet souvent considéré comme barbant ;)

Les multiples casquettes du RSSI

Les multiples casquettes du RSSI

Résultats et solution du challenge

Le lendemain matin, on présente les résultats du challenge de cette année, qui en a dérouté plus d’un. Les solutions sont en ligne, je vous invite donc à les lire car je doute vraiment être le mieux placé pour les exposer ici… On a droit à un résumé par Arnaud Ébalard (EADS Innovation Works) dont la solution a été classée 1ère en terme de qualité. En vrac, on notera la récupération des .APK en utilisant les spécificités du format ZIP et un bruteforce sur les pages physiques, une couche crypto ressemblant à du Vigenère, une clé publique dont la seule composante utile était la sous-clé ElGamal, l’utilisation de PARI/GP pour l’attaquer, la décompilation des .DEX avec Baksmali, du reversing de librairie .SO, des énigmes tordues, et un hash Shabal 256 mal utilisé. Un grand bravo à lui ainsi qu’à tous ceux qui ont réussi le challenge !

Mentions spéciales pour le challenge

Mentions spéciales pour le challenge

Analyse de l’efficacité du service fourni par une IOMMU

Par Éric Lacombe, Fernand Lone Sang, Vincent Nicomette et Yves Deswarte (LAAS/CNRS). Le but d’une IOMMU est de contrôler les accès à la mémoire par les différents périphériques d’entrée/sortie, telle que la MMU vis-à-vis du CPU. Dans le cadre des attaques DMA, une IOMMU traduit les adresses virtuelles demandées par le périphériques en adresses physique en se basant sur deux critères principaux : le source-id identifiant le périphérique, et des tables de traductions internes. La conférence présente deux attaques visant chacun de ces critères : la reconfiguration des tables et le spoofing de source-id. La deuxième attaque est mise en œuvre en utilisant un pont PCI – PCI Express, fréquent surtout pour les machines anciennes. Un tel pont permet de connecter des devices PCI sur l’interface PCI Express ; le problème étant que tous les devices PCI rattachés partagent alors le même source-id. Une démo faisant intervenir un iPod malveillant et une carte réseau connecté sur un tel pont montre comment il est possible de déclencher une attaque d’ARP Cache Poisonning. Les paquets ARP étant injectés par l’iPod dans les buffers de réception gérés par les drivers de la carte réseau, l’attaquant n’a plus besoin d’envoyer de trames. On a ainsi droit à un hijacking en live d’un épisode de The Big Bang Theory regardé en streaming :)

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). Cette excellente conférence revient sur l’exploitation d’une vulnérabilité des cartes réseau Broadcom, patchée depuis. On y apprend avec stupéfaction (du moins pour ma part !) qu’une carte réseau est très loin d’être un élément « simple ». En effet, celle-ci possède un firmware qu’il est possible de flasher temporairement, qui gère certains protocoles de façon automatique et ce sans que le CPU en ait conscience ! Ainsi, ces carte réseau comportent leur propre pile IP et est même capable de gérer des messages SOAP… Le problème, c’est que celles-ci sont parfois implémentées sans notion de sécurité. Ici en l’occurrence, les auteurs mettent en évidence un buffer overflow touchant le champ « username » du protocole ASF, utilisé pour le management et le monitoring. Pour être en mesure de l’exploiter, ils ont du coder un debugger de carte réseau, en utilisant le fait que les registres de la carte sont mappés en mémoire, et que celle-ci possède des options de debug (mode single-step, breakpoint…). En live, ils exploitent la vulnérabilité et montrent comment déclencher un remote root shell en envoyant un message ICMP. Vraiment bluffant…

Exploitation de buffer overflow dans le firmware d'une carte réseau

Exploitation de buffer overflow dans le firmware d'une carte réseau

Applications Facebook : Quels Risques pour l’Entreprise ?

Alban Ondrejeck, Francois-Xavier Bru et Guillaume Fahrner montrent les résultats d’une expérience intéressante visant à mettre à l’épreuve le (non) contrôle des applications Facebook. Sous le couvert d’une application « Who crashed you? » codée maison et a priori « utile », ils récoltent des informations personnelles sur les utilisateurs l’ayant installé, et exploitent le caractère viral du réseau social. En créant une vingtaine de profils fictifs et en ajoutant divers personnes comme amies, ils parviennent très rapidement à répandre l’application et à collecter des informations sur tous leurs utilisateurs (dommage, je n’ai pas noté les chiffres). Cela montre une absence de contrôle concernant les permissions de telles applis.

Projet OpenBSC

Harald Welte part d’un constat simple : les protocoles GSM et 3G sont documentés publiquement, mais les études de sécurité à ce sujet sont très peu nombreuses, du fait que l’industrie de la téléphonie est un monde très fermé (coût très élevé du hardware, notamment). Et pourtant, ces protocoles sont beaucoup plus répandus que ce que l’on pourrait croire. Comme le dit si bien l’orateur, «GSM is more than phone calls» : ce protocole est utilisé non seulement par les téléphones, mais aussi par certaines voitures, trains, systèmes d’alarmes, distributeurs, etc. Après avoir exposé rapidement l’architecture d’un réseau GSM, l’auteur introduit le projet OpenBSC, qui vise à fournir les éléments nécessaires à la réalisation de son propre réseau GSM. Une sorte d’Asterisk pour le GSM, en gros… Les différents problèmes de sécurité du GSM sont rapidement abordés : pas d’authentification entre le téléphone et le réseau, chiffrement faible, optionnel et non explicite (rien ne permet à un utilisateur de savoir si ses communications sont véritablement chiffrées), dénis de service possibles, géolocalisation… N’ayant jamais étudié ces protocoles, je suis loin d’avoir tout saisis, mais la conférence était très intéressante et incite à en savoir plus.

Architecture d'un réseau GSM

Architecture d'un réseau GSM

Rumps sessions

Pour les néophytes du SSTIC, les rumps sessions sont des mini exposés de 4 ou 5 minutes présentables par n’importe qui et sur n’importe quel sujet, lié de près ou de loin à la sécurité. Je n’ai pas tout noté (pas comme Sid), donc voici en vrac quelques une d’entre elles :

  • Kesske SSTIC, qui dévoile pas mal de chiffres sur l’édition 2010 du SSTIC. Pour ne citer que le minimum : 450 places écoulées en 25 heures, près de 2/3 du budget passe dans la bouffe (social event et resto universitaire), et un taux d’acceptation de 60% pour les soumissions de papier.
  • Timing attack sur machine à café, ou comment exploiter une vulnérabilité de machine à café pour gagner de la fidélité sur sa carte, et donc des café gratuits. Le principe est simple : retirer la carte après que la machine ait incrémenté la fidélité, et avant le débit :)
  • Netglub, où on a le droit à une super démo d’un outil Maltego-like en C++/Qt et « vraiment OpenSource » permettant de faire de la recherche d’information. Vraiment sympa, j’ai hâte que ça sorte.
  • Deux projets qui vont bientôt sortir : le moteur de recherche de vulnérabilités QSWX et son spider Bubulle, et SecurityGarden, une sorte de PaketStorm en mieux.
  • ExeFilter contre les méchants PDF : outil de nettoyage de fichiers, utilisable pour désactiver les contenus malveillants dans un PDF et accessoirement se protéger des 0-days potentiels.
  • BOSS : Break Our Steganography System, un challenge de stégano débutant à la fin du mois.
  • Scapytain : Philipe Biondi expose de façon inédite un outil de gestion de campagne de tests basé sur Scapy.

Présentation de Scapytain sous GIMP

Présentation de Scapytain sous GIMP

JBOSS AS: Exploitation et sécurisation

Renaud Dubourguais (HSC) présente un état de l’art des vulnérabilités touchant le middleware JBOSS AS, démos à l’appui. Dès le début, c’est très clair : il n’y a pas de mécanismes de sécurité par défaut. Autrement dit, il y a de quoi faire… Console d’administration JMX accessible sans authentification (ou avec admin/admin), déploiement de backdoor sous forme d’application SAR, utilisation du protocole RMI, accès à la web console… Des mécanismes de sécurité existent (JBOSS SX, sandboxing) mais sont rarement implémentés en pratique. Une conférence très intéressante qui donne envie d’auditer du JBOSS…

Audit d’applications .NET complexes

Nicolas Ruff (EADS) dresse un état de l’art des techniques de reversing de code .NET permettant d’auditer les applications Microsoft. Une fois compilé, le bytecode .NET conserve la sémantique du code source, et il est possible de le décompiler avec des softs adaptés comme l’excellent Reflector, et d’utiliser l’API de reflexion pour récupérer de nombreuses informations. La compilation de ce bytecode en langage machine peut se réaliser à la volée (Just In Time) ou bien sous forme de DLL dans le Global Assembly Cache, que l’on peut également analyser avec des outils comme IDA. J’y apprend également que Windbg supporte le debugging d’applications .NET avec l’extension SOS accessible par la commande .loadby sos mscorwks. Démonstration pratique avec Songsmith, et hop.

PoC(k)ET, les détails d’un rootkit pour Windows Mobile 6

Cédric Halbronn expose les spécificités de l’implémentation d’un rootkit pour smartphone Windows Mobile 6. Ce genre de plateforme impose certaines contraintes, principalement la quantité de mémoire et la consommation de la batterie. Cependant comme le dit si bien l’auteur, le modèle de sécurité de Windows Mobile est très permissif. Les applications doivent être signées pour pouvoir s’installer… mais cette restriction est implémentée par le simple affichage d’un message d’avertissement. D’autre part, il est possible d’installer facilement un certificat dans le magasin de certificats privilégiés du téléphone, qui est invisible et inaccessible pour l’utilisateur. Il est alors facile de mettre en place un système de download & execute furtif. En outre, le passage en mode noyau se fait on ne peut plus simplement, grâce à l’appel à l’API SetKMode() ! Il devient alors possible de hooker le driver baseband gérant les commandes AT, la saisie du code PIN (qui transite en clair entre le baseband et le CPU), les SMS… L’injection de DLL est aussi possible, donc camoufler des fichiers peut se faire de la façon habituelle avec un hook des API FindFirstFile() etc. Le rootkit exposé ici est injecté par WAP Push, est contrôlable par une interface graphique, et n’est pas détecté par les anti-virus, qui d’après l’auteur «ne détectent qu’entre 5 et 10 virus»… Une question est posée : «Comment se protège-t-on alors ?». La réponse est claire : «On ne prend pas Windows Mobile» :)

Interface d'admin du rootkit

Interface d'admin du rootkit

Projet OsmocomBB

Harald Welte nous parle maintenant du projet OsmocomBB, visant cette fois-ci à fournir un baseband OpenSource pour téléphone mobile. J’ai été un peu largué, mais la démo super visuelle et intéressante a retenue mon attention. Il s’agissait de sniffer les communications GSM avec un mobile Motorola (coutant aux alentours de 15€) connecté à un laptop, puis et de les rendre affichables dans Wireshark (sans les déchiffrer). Le tout dans un amphi plongé dans le noir et illuminé par le code défilant à l’écran… Comme le disaient certains, «Le SSTIC revient aux sources» !

Wieshark sniffant du GSM

Wieshark sniffant du GSM

Conclusion

Comme je le disais en intro, j’ai volontairement omis quelques conférences (notamment celle de clôture), principalement car car la mémoire me fait défaut, ou bien parce que j’estime que des bien meilleurs résumés ont été fait avant moi…

Globalement les conférences étaient d’excellente qualité. Mes coups de cœur restent les interventions techniques, (virtdbg, l’IOMMU, la sécurité des cartes réseau, JBOSS, le reversing d’applis .NET, PoC(k)ET, GSM…) même si les autres ne manquaient pas de qualité. Concernant la conférence sur OPA que je n’ai pas mentionnée ici, je suis assez d’accord avec ce qu’a exposé Sid sur son blog. Son contenu aurait pu être beaucoup plus intéressant, dommage qu’elle visait le mauvais public…

En tout cas, chapeau aux comités d’organisation et de programme ! J’espère pouvoir revenir l’année prochaine. En attendant, rendez-vous à la Nuit Du Hack le week-end prochain ;)

Mes photos sont disponibles sur ma galerie Picasa.

  1. 9 réponses à “De retour du SSTIC 2010”

  2. Haha la première conf :D

    Par SilkCut le 13 juin 2010

  3. Ca, c’est du billet !

    Merci pour ce résumé bien condensé, Trance.

    A bientôt pour la NdH, oui…

    Geo

    Par Geo le 14 juin 2010

  4. Merci beaucoup pour le résumé, et à samedi pour la NDH

    Par tracid56 le 14 juin 2010

  5. Merci Trance pour le résumé du SSTIC.

    Malheureusement je n’ai pu y aller mais tu as du croiser des personnes de ma promo :D

    Sympa le recrutement de la DGSE ^_^

    Vivement samedi pour une NDH de folie.

    Par Nickname le 14 juin 2010

  6. Super résumé, merci ! Tu as dû te régaler.

    Sinon j’ai relevé 2 petites fautes de frappes :

    Premier paragraphe : « qui plus est en temps réel (qui plus est en temps réel, chapeau à eux !), »

    Paragraphe CASTAFIOR : « l’utilisation différents protocoles encapsulés dans du HTTPS »

    Par JB le 14 juin 2010

  7. Effectivement, merci c’est corrigé. C’est ça les articles non relus… :)

    Par Emilien Girault le 15 juin 2010

  8. super le résumé ,mais…
    si j’étais un spy d’une puissance étrangère ,c’est bien là que j’irai glaner quelques informations sensibles pour étoffer
    mes informations ,comme la liste de noms d’ ingénieurs qui travaillent pour Thales,Eads,la liste des parades de decryptage .etc…

    Par bernard_les_bons_tuyaux le 2 octobre 2010

  9. Peut être, mais en même temps, rien de vraiment sensible n’est dévoilé au SSTIC. Le monde de la sécurité est petit, donc retrouver la liste des gens travaillant sur un domaine n’est pas bien compliqué, il suffit d’arpenter les blogs et les papiers publiés aux grandes conférences. Au niveau du contenu, quasiment tout ce qui a été dit au SSTIC peut se retrouver sur le site officiel. Et encore une fois, rien de secret n’a été publié…

    Par Emilien Girault le 3 octobre 2010

  1. 1 Trackback(s)

  2. 13 juin 2010: Sécurité de l’Information | Archives de Sécurité Tube

Désolé, les commentaires sont fermés pour le moment.