Making network protocols go crazy

Aller au contenu | Aller au menu | Aller à la recherche

lundi, juin 10 2013

SSTIC 2013 - jour 3

Premières conférences

Je n'ai malheureusement pas assisté aux premières conférences. Je vous invite à regarder les comptes-rendus disponibles aux liens suivants :

La réponse aux incidents ou quelques recommandations

Alexandre Dulaunoy

CIRCL : 6 personnes qui opèrent en mode autonome pour le Luxembourg.

Les CERT fournissent des recommandations sous forme de rapport. Cette présentation humoristique propose un rapport de recommandation à destination des auteurs de malware.

Intéressant : en téléchargeant les CRL pendant 1 an, ils ont fait des stats sur les raisons de la révocation. Par exemple, 230 CA compromisent (code 2).

Cas du malware PlugX qui embarque une DLL déjà signée (McAfee par exemple) qui possède la fonction LoadLibrary() et l'utilise pour loader une DLL non-signé. Le tout uniquement en mémoire, et ça passe. C'est la solution ultime, plus besoin de trouver une solution pour signer son malware.

Un malware furtif communiquant sur HTTP devrait instrumenter le browser (et ne pas utiliser de User-Agent spécifique et facilement détectable).

A noter que la plupart des malware ne donnent pas lieu à un article à cause du très faible niveau technique du développeur.

Détection comportementale de malware P2P

Xiao Han

De plus en plus de malwares utilisent du P2P pour leurs communications. L'orateur présente une architecture afin d'extraire le trafic P2P only d'un flux réseau. Ensuite, un outil automatise la séparation entre les flux P2P "classiques" de ceux des malwares connus. Taux de détection annoncé : 97,2% de précision.

Ça fonctionne plus ou moins par prise d'empreinte du comportement des malwares connus, et à l'ajout dans une base de connaissance de ces comportements. C'est l'apprentissage supervisé qui permet ce bon taux de détection.

Attestation distante d'intégrité sous Android

Mimitri Kirchner

Lorsqu'on démarre son ordinateur qui utilise TrueCrypt (ou un mot de passe BIOS), comment être sur que la demande de mot de passe affichée n'est pas liée à un programme malicieux qui va voler notre mot de passe ? (attaque de type evil maid).

L'idée est d'utiliser un smartphone comme Verifier TPM de confiance pour interroger le Collector TPM du PC. Utilisation d'OpenPTS (implémentation de référence du TCG). Une application pour Android utilisant le Verifier d'OpenPTS a été développée : elle se connecte en SSH sur USB tethering pour interroger le Collector.

Sauf que pour que le serveur SSH soit actif sur le PC, il faut déjà avoir entré sa passphrase, et être tombé dans le piège de l'evil maid. On peut juste savoir qu'on vient de se faire avoir. Dommage.

Le rôle des hébergeurs dans la détection de site Web compromis

Davide Canali

Installation d'applications Web vulnérables dans des environnement Web mutualisés. Choix de failles facilement détectables. Le but est de tester le comportement des principaux hébergeurs face aux intrusions.

Les résultats de ces tests sont à voir dans les slides (c'est trop compliqué de noter ici). Mais en gros, quasiment personne ne détecte et ne rapporte ces attaques à leurs clients.

Faire face aux cybermenaces => détecter (les attaques) et former (des experts en SSI)

Ludovic Mé

Conférence de clôture. Une analyse de texte intéressante du livre blanc 2013 sur les cybermenaces, lors de l'intro. Puis, une partie sur la détection d'intrusion et sur la formation, les deux piliers supports de ce livre blanc (selon l'orateur). En version courte, aujourd'hui, les IDS c'est l'échec, comment les améliorer ? Exemple d'utilisation de Blare comme HIDS noyau pour aider à la corrélation. Ensuite, comment modifier la société afin qu'elle que les différents intervenants soient mieux formés aux risques informatiques.

SSTIC 2013 - jour 2

UEFI : bootkits

Pierre Chifflier & Sébastien Kaczmarek

Présentation conjointe pour cause de similarité au début, puis split pour les spécificités. Ça c'est du travail d'équipe.

BIOS vs UEFI : BIOS c'est vraiment vieux. C'est chargé de l'initialisation de l'ordinateur et de la découverte des périphériques. C'est aussi x86 only. Trop de limitations, d'où l'introduction de l'UEFI pour régler celles-ci.

Par rapport au BIOS, l'UEFI est très proche d'un OS (multiples couches réseau, support de différents file systems. Le MBR est remplacé par des binaires PE (32-bits et/ou 64-bits). L'UEFI est un vrai OS, avec des drivers (TCP/IP, VGA, ...).

Partie 1 : Sébastien Kaczmarek

L'implémentation officielle d'Intel est Tianocore (disponible sur sourceforge). Cette implémentation possède un serveur Web ... et un interpréteur Python. A noter que tout a été redéveloppé from scratch (libc, pile TCP/IP, parseurs PE, ...).

But de Dreamboot : corruption noyau, contournement de l'authentification et escalade de privilèges (sur SecureBoot non activé). Aucune exploitation de faille, ce sont les capacités offertes par le boot qui permettent ce genre d'attaque. L'idée générale est de poser des hooks de fonctions sur les différents composants EFI (fichiers .efi au format PE). Exemple : winload.efi. MsvpPasswordValidate() est la fonction finalement patchée pour contourner l'authentification Windows.

Pour l'élévation de privilège, l'idée est de parcourir la structure _EPROCESS (DKOM ?). Le bootkit Dreamboot est disponible sur le Github de Quarkslab. C'est une ISO qui permet d’acquérir les droits SYSTEM sous Windows 8.

Partie 2 : Pierre Chifflier

Cette fois, c'est un bookit matériel sur PCI. Même but : élévation de privilège, mais cette fois en utilisant une carte graphique PCI. Moins de 100 ko disponibles pour mettre le code. Pour les détails, voir les slides et le papier ;)

Programmation d'un noyau sécurisé en ADA

Arnauld Michelizza

Les protections actuelles sont réactives (bit NX, randomisation, ...), les vulnérabilités sont tout de même exploitées par les attaquants. L'idée principale est que pour éviter 80% des bugs d'implémentation de type buffer overflow ou integer overflow ou déréférencement de pointeur null, il faut utiliser un langage qui est garanti sans ce type de bug : Ada.

Langage toujours vivant aujourd'hui, et bien maintenu. Le portage Linux est Gnat. C'est un langage utilisé dans les applications critiques ou la vie humaine est en jeu.

Faisabilité d'écriture d'un noyau en ADA : 11000 lignes de code, 400 en assembleur. Pile IPv6, ext2, quelques drivers (clavier/souris). Le langage ADA fait des vérifications à la compilation, et à l'exécution. Cout en performance +65% de cycle d'horloge, et facteur 4 en taille. Les vérifications faites sont là pour interdire les buffer overflow & co.

Hack Android/Samsung

Etienne Comet

Différents types d'exploits : physique nécessitant un accès local, ou à distance. Ensuite, il est souvent nécessaire d'exploiter des failles locales pour élever ses privilèges. Ce talk se concentre sur ce dernier point, en attaquant directement le noyau.

Le noyau Android est un Linux patché avec des features spécifiques : binder, Ashmem, ... . Les constructeurs (tels Samsung) modifient aussi le noyau par eux-même. Ainsi, ils élargissent la surface d'attaque.

Le debug de ce genre de système n'est pas automatique avec les outils OTS. La voie royale est l'utilisation de bug de type information leak. Exemple du bug /dev/diag, exploitant copy_from_user() pour récupérer les données kernel space. C'est une faille spécifique à Android/Samsung.

Compromission d'un environnement VoIP Cisco

LEXFO

L'idée est d'attaquer le Cisco Call Manager. C'est le composant qui gère les échanges SCCP. Si accès root sur le Call Manager, on peut écouter l'ensemble du réseau VoIP. Il y a déjà eu des confs sur le sujet, mais personne ne s'est occupé du Call Manager en lui-même.

Attaque style black box pour commencer : ils ont exploité une injection SQL pour récupérer un mot de passe chiffré. En auditant le code en mode white box, ils ont déchiffré la clé : c'est la même pour tous les Call Managers. FAIL.

Après l'accès admin à l'interface Web, recherche de vulnérabilité d'exécution de commande. Faille trouvée ;) puis recherche d'une autre faille pour élever ses privilèges vers root. Un fichier Perl exécuté par l'utilisateur informix est dans le fichier sudoers sans avoir à entrer le mot de passe. Ce fichier appartient à informix. FAIL.

Ça finit par une démo d'exploitation à distance pour gagner un accès root via l'interface Web du Call Manager. Ce sont 6 failles 0-day exploitées (par un programme PHP dans la démo). Cisco n'a pas été contacté.

Observatoire de la résilience de l'Internet français

Guillaume Valadon

Rapport disponible http://www.ssi.gouv.fr/observatoire/ .

Note : outil pour faire des graphes de grands réseaux : GEPHI.

Sécurité des applications Android constructeurs et backdoors sans permission

André Moulu

Les applications vérolées se trouvent majoritairement sur les Market alternatifs. Ce sont souvent des applications payantes dévérouillées dans lesquelles un malware a été intégré.

La sécurité des applications est principalement basée sur l'utilisation UID/GID différents par application, et par de l'isolation de processus.

/system/app : 216 applications par défaut sur un Galaxy SIII contre 91 sur un Nexus 4. Bien sur, plus il y a d'applications, plus la surface d'attaque est grande. Une suite d'outils a été développée pour analyser ces applications (nommée ASA. Voir aussi Androguard). Ainsi, on peut facilement lister les applications qui utilisent telle ou telle permission (exemple : INSTALL_PACKAGES).

Exemple d'une vulnérabilité permettant de faire de l'élévation de privlège : recherche d'une application tournant en UID/GID privilégié, analyse du code source : on trouve une exécution de code arbitraire via l'appel d'un classique /bin/sh avec des paramètres non-filtrés. Allô quoi.

Beaucoup de vulnérabilités découvertes, une présentation très intéressante. Il faut lire le papier pour les détails.

Limites des tables Rainbow et dépassement par l'utilisation de méthodes probabilistes optimisées

Pierre Lestringant

L'écart de performance entre les rainbow tables et le brute force est de plus en plus réduit grâce aux GPU. Autre problème des rainbow tables, plus elle est grande (2 To, par exemple), plus les accès disques ralentiront le crackage.

L'orateur propose des solutions algorithmiques pour corriger ces problèmes de performance ; l'idée principale est de réduire la taille du fichier final en faisant des études probabilistes d’occurrences de suites de caractères afin de réduire le nombre de mot de passes "rainbow"isés.

La présentation est purement algorithmique, si ça vous intéresse, lisez l'article ;)

Les RUMPS :)

Quelques présentations ayant retenu mon attention :

  • MGCPScan && MGCPForge, des outils pour exploiter les faiblesses de la VoIP (RTC) => démo de MitM de comunication. Ca marche aussi sur Internet si la gateway MGCP est accessible depuis Internet .... (par Sn0rky)
  • Houracle : Proxy TNS pour faire du MitM sur Oracle TNS (par Nicolas Collignon)

SSTIC 2013 - jour 1

Innovation in symmetric cryptography

Joan Daemen

En 1988/1989 : la crypto se résumait aux stream ciphers (basés LFSR) contre les block ciphers (exemple : DES). Ensuite, l'orateur parle de vieux algorithmes qui furent cassés par lui-même ou d'autres.

C'est une conférence faite par un crypto pour les cryptos. Je n'ai donc pas tout suivi.

A noter que l'orateur est un belge parlant le français, mais qu'il préfère faire sa présentation en anglais dans une conférence franco-française avec un public de français. Je trouve que c'est à la limite du manque de respect. Voilà pour l'intro.

Mise a plat de graphes de flot de contrôle et exécution symbolique

Eloi Vanderbeken

Ou comment débrouiller automatique du code brouillé (différent du code obfusqué). L'idée est de retrouver les fonctions, et en donner un graphe d'exécution (mise à plat de flot de contrôle).

Plusieurs approches :

  • dynamique avec suivi d’exécution
  • dynamique avec suivi de données
  • statique

L'approche statique est la plus exhaustive et donne les meilleurs résultats, même si les résultats sont parfois abstraits et l'opération complexe et lourde. Une première passe d'analyse statique est faite, suivi d'une exécution symbolique qui permet de simplifier le CFG.

Polyglottes binaires et implications

Ange Albertini (Corkami)

Un outil se sécurité doit comprendre plusieurs langages pour bien protéger les systèmes d'aujourd'hui : infection via une page HTML, exploitation par un code Java, installation d'un binaire Windows PE.

L'orateur exploite les faiblesses de format des documents usuels (PE, PDF, ...) pour ajouter du code caché. Par exemple, PDF autorise 1024 octets au début d'un document PDF. Démo : ajout de notepad.exe dans cet espace. Le document s'ouvre, et notepad.exe s'exécute ...

Autre exemple : un document PDF qui donne un contenu différent en fonction de la visionneuse, à cause de l'interprétation du standard (summatra, Chrome, Adobe).

Puis démo d'exécution de code HTML dans un document PDF (placé dans une variable PDF). Le document s'ouvre, et le HTML peut s'exécuter dans un navigateur.

L'intérêt de ces techniques :

  • évasion de filtres (anti-virus, réseau)
  • contournement de la SOP (pour HTML/JavaScript)
  • exécution d'un fichier sain mais qui embarque un document malveillant (exploitant une faille)

Ces attaques sont connues sous le terme de "confusion de type".

Recompilation dynamique de code binaire hostile

Sebastien Josse

Les malwares sont de plus en plus difficiles à analyser avec les outils "OTS". Il y a beaucoup d'outils, mais bien souvent trop facilement détectés, ou mal adaptés.

Idée : un outil le plus générique possible pour donner le plus d'information possible sur un malware. Par exemple, automatisation du unpacking. Le but est d'automatiser le plus possibles les tâches ingrates.

Création de l'outil VxStripper, un outil d'instrumentation d'un processeur émulé (QEMU). Le but est de décompiler le code et de générer du LLVM recompilable.

Entrée : unpacking puis normalisation. Sortié : un binaire recompilé en LLVM.

QEMU est utilisé pour sa capacité de traduction de binaire en LLVM. Traduction qui est très efficace, selon l'orateur. L'outil supporte actuellement une dizaine d'outils de unpacking. Outil non-publie (DGA oblige).

Parsifal : un parseur robuste et efficace

Olivier Levillain

Un outil pour parser des protocoles binaires. But : écrire des parseurs à l'aide de code concis. Ecrit en OCaml, pour des raisons de performance (peut gérer des Go de données).

C'est du Perl Net::Frame, en moins bien :) Voir aussi binpack dans l'IDS Bro.

nftables

Eric Leblond

Evolution de netfilter en terme de performance et évolutivité. Deux capacités qui manquaient dans netfilter et comblées par nftables. nftables est développé par Patrick McHardy.

Autre ajout : un nouveau langage, accessible par une bibliothèque.

Compromission d'un terminal sécurisé via l'interface carte à puce

Guillaume Vinet

Carte a puce offrant des fonctions de sécurité (signature, chiffrement). C'est un excellent coffre fort numérique. C'est de plus en plus utilisé pour nos PC. Problème : saisie du code PIN sur un PC (environnement faiblement sécurisé). Solution : utilisation d'un terminal sécurisé type bancaire. Ainsi, le code PIN ne transite plus sur le PC.

Mais si un logiciel malveillant est installé, il peut exécuter les fonctions de sécurité de la carte à puce (mais ne peut toujours pas voler le code PIN) via l'utilisation du protocole de communication. L'idée est donc d'attaquer le terminal en utilisant le protocole ISO 7816-3. L'orateur a trouvé un certain nombre de vulnérabilité dans ce protocole comme des fuites d'information mémoire.

Pour implémenter ses tests, l'orateur a développé un émulateur de cartes à puces. Il a utilisé une plateforme Arduino. Architecture :

  Raquette ISO 7816-3 <-> Arduino <-> Server Python sur PC

En exploitant certaines failles, il a réussi à dumper le code binaire du firmware. Une autre vulnérabilité permet de récupérer jusqu’à 17 octets de la dernière réponse protocolaire. En exploitant cette vulnérabilité pour tenter de récupérer le code PIN, on n'obtient que du zéro : la protection du code PIN est bien effective au niveau du terminal.

A noter que ce protocole ainsi que l'architecture processeur des terminaux bancaire est très similaire sur les téléphones portables (carte SIM) et les dispositifs OTP. Du coup, ses travaux pourraient être adaptés à ce domaine.

Attaques applicatives via périphériques USB modifiés

Benoit Badrignans

L'idée : piéger des claviers/souris/clé USB à des fins malicieuses (infection, vol de données, ...).

Exemple de faille sous Linux : élévation de privilèges au branchement d'une clé USB avec un filesystem Mac malformé (LDM). Au niveau du matériel (Hub, root Hub), il est possible de sniffer et de faire du fuzzing.

Plateformes de tests disponibles : Micro-controleurs (SMSC, Cypress), téléphones portables (Android + USB-Gadget), outils de pentest prèts à l'emploi (Facedancer USB, ...).

Démo d'une clé USB "piégée". Elle usurpe un USB descriptor autorisé sur la machine victime, et contourne le fait qu'elle soit montée en read-only pour voler un fichier. Le périphérique USB est composite (à la fois mass storage et clavier). Il possède aussi un Linux embarqué ;)

Les attaques sont resté à haut niveau (couche applicative), et pourtant on peut déjà faire beaucoup de choses.

Red October

Nicolas Brulez

Opération Aurora de 2009. Red October, c'est en 2013. C'est une campagne de cyber espionnage complète, basée sur 34 modules. Débutée en Mai 2007 ... Certains modules permettent d'injecter une backdoor sur les téléphones mobiles. D'autres de faire de la récupération de données sur des clés USB.

La cible de ces campagnes était principalement les organismes étatiques.

Étapes d'infection :

  • email piégé (spear phishing)
  • pièce jointe avec un doc Word ou Excel malicieux (que des failles connues exploitées)
  • installation d'un dropper permettant la connexion au serveur C&C

Le dropper extrait et exécute le payload malicieux. Pas besoin de 0day, les gens ne patchent pas. Les fichiers de payload sont chiffrés sur le disque, et déchiffrés uniquement en mémoire au moment de l'utilisation (connexion au serveur C&C).

Attaques lancées en moyenne tous les 2 mois (le temps de mettre à jour le soft). Kaspersky a lancé une analyse par sinkhole : "vol" d'un nom de domaine utilisé par Red October et installation d'un serveur pour récupérer des statistiques.

Les statistiques montrent que le pays le plus "infecté" est la Suisse ... Les tâches exécutées sont fournis par le serveur C&C sous forme de DLL, et sont uniquement stockées en mémoire.

Il y a un grand nombre de catégorie de modules : recon, spreading, email, exfiltration, mobile, ...

L'embarqué entre confiance et défiance

Aurélien Francillon

Un pot pourri de ce qu'on croyait impossible, mais qui le devint, en terme d'exploitation de vulnérabilités sur les systèmes embarqués. Exemple de processeur sur base d'architecture de Harvard.

Un PC n'est pas un PC : c'est un empilement de systèmes embarqués. Exemple : le disque dur possède un système embarqué. On peut le mettre à jour grâce à un simple utilitaire, et les firmwares ne sont pas signés. Démo de backdoor de disque dur pour rendre accessible les données depuis Internet, en utilisant le protocole HTTP. C'est beau.

Excellente conf.

vendredi, juin 8 2012

SSTIC 2012, après midi du troisième jour

Miasm: Framework de reverse engineering

Fabrice Desclaux - CEA

Présentation d'un framework de reverse engineering écrit en Python; Composants : Miasm, Elfesteem, Grandalf.

Excellente fonction : émulateur de code (reverse dans une sandbox). Recherche automatique de comportements à risque (exemple : un paramètre est controlé par l'utilisateur et permet d'écrire EIP). Ce mode est basé sur des règles écrites par le reverser.

Une présentation de furieux ^^

Outil : http://code.google.com/p/miasm/.

Rétroconception et débogage d'un baseband Qualcomm

Guillaume Delugre - SOGETI

Le baseband est le processeur en charge de gérer les communications du réseau téléphonique. Sur un smartphone, un autre processeur est utilisé pour le système. Une clé 3G ne possède que le processeur baseband. L'orateur s'est attaqué à cette clé 3G. Utilisation d'une interface série sur USB pour exécuter des commandes de debug sur le baseband. Exemple : dump complet de la mémoire. Le processeur est basé sur du ARMv5. L'orateur a créé son propre débugueur pour ce matériel.

Il a pu écrire du shellcode, utiliser les commandes de diagnostic via l'accès série/USB pour l'écrire en mémoire, puis l'exécuter sur le baseband. C'est un code qui permet d'avoir un proxy GDB pour aider au debug. Pas mal.

Outil : http://code.google.com/p/qcombbdbg.

Protéger et défendre le cyberespace militaire : la démarche nationale

Arnaud Coustilliere - Ministère de la Défense

Une présentation pas très intéressante (malheureusement).

SSTIC 2012, matinée du troisième jour

Pas de compte-rendu pour les trois premières conf (pour cause de social event).

Utilisation malveillante des suivis de connexions

Eric Leblond

Slides : https://home.regit.org/2012/06/transparents-de-ma-presentation-au-sstic/ Blog : https://home.regit.org/2012/06/opensvp-a-new-tool-to-analyse-the-security-of-firewalls-using-algs/.

Présentations courtes

Clément Lecigne - Google

Netusse, un kernel fuzzer (de socket) qui existe depuis 2006. Google SoC de 2006 pour tester la solidité de la pile FreeBSD.

Développement pour tester sur les failles déjà existantes pour voir si l'outil les détecte. FreeBSD :

  • REDZONE pour détecter les buffer overflows
  • il y a aussi d'autres protections contre les heap overflow (voir présentation)

Note : Récupérer le lien de cette présentation (qui n'est pas dans les actes).

Description de l'exploitation des failles heap overflow sous FreeBSD.

Démo : un beau 0day sur kernel FreeBSD 8.2 et 8.3.

Outil : https://code.google.com/p/netusse/.

Etienne Millon - EADS Innovation Works

Vérification de code système par typage statique. Donc, une conf sur l'analyse statique ^^ Le typage des variables est fait lors de la compilation.

Outil : http://penjili.org/.

Ronan Mouchoux - CERT La Poste - @yenos

Détection de domaines malveillants par analyse sémantique et mathématique.

Spoofing des réponses DNS pour rediriger le trafic vers une machine (firewall) de contrôle. Les requêtes DNS sont analysées afin de détecter l'utilisation de noms de domaines aléatoires (cas des botnets). Utilisation du filtrage bayésien pour classer les noms de domaines comme malveillant ou non.

Limitations :

  • certains noms d'hôtes officiels ressemblent à des noms malicieux (cas serveur d'update TrendMicro)
  • certains noms de domaines malicieux utilisent la concaténation de mots, et coutournent ce contrôle

Ces noms de domaines sont générés par un DGA (Domain Generation Algorithm). Ils correspondent aux serveurs de Command & Control utilisés dans le botnet. Merci à Kevin pour cette information que j'avais ratée.

Successes (and limitations) of (static) binary analysis

Halvar Flake - Google

De plus en plus d'entreprises investissent dans l'analyse statique. Probablement des millions de bugs ont été corrigés grâce à cela. Ce sont les hackers qui ont poussé les entreprises dans cette direction.

Explication de la faille CrackAddr() de Sendmail datant de 2003. Une attaque sur la machine à état du parsing des adresses emails. Un état n'était pas correctement géré, et une suite de () permettait d'écrire au delà de la taille d'un buffer local (stack overflow). Une simple décrémentation était manquante dans le code.

Comment l'analyse statique peut détecter ce genre de bug ? les outils actuels n'y arrivent pas.

Les navigateurs sont déplacés dans des sandboxes aujourd'hui. Comme ça, la compromission du navigateur n'entraîne pas la compromission des données de la machine. Mais comme toutes ces données sont de plus en plus déplacées dans le Cloud ...

La complexité des programmes a maintenant dépassé notre capacité à les comprendre.

Note : version originale : Our ability to construct software has exponentially outpaced our ability to understand software

Nos outils d'analyse ne permettent de comprendre qu'une petite île dans un énorme océan. Nous devrions considérer que l'ouverture de n'importe quel document est l'équivalent à l'ouverture d'un exécutable (page web, PDF, Word, ...) et se protéger contre ça.

jeudi, juin 7 2012

SSTIC 2012, après midi du deuxième jour

Expert judiciaire en informatique

Mem Zythom - Expert judiciaire et blogueur

Expert judiciaire n'est pas un métier, c'est une activité exercée en parallèle de son métier. Il intervient à la demande des magistrats pour donner des éclaircissements. Il est désigné. Il faut être inscrit sur une liste. Pour celà, il est nécessaire d'en faire la demande par le dépot d'un dossier auprès du procureur de la République. Un certain nombre de conditions sont à remplir (longue liste).

Une suite d'exemples d'expertise (instruction, commerce, civil, privée).

Zoom sur la partie inforensique de l'expertise. Utilisation d'outils gratuits et commerciaux.

Le rôle de l'expert judiciaire doit comprendre techniquement les problèmes afin de pouvoir les expliquer au magistrat. Son rôle n'est pas de prendre des décisions. Ensuite, il évoque les problèmes rencontrés au cours de son activité :

  • missions mal rédigées
  • la confrontation avec les experts des parties concernées

Ce dernier point est très formateur sur le management de réunions de crises.

Forensics iOS

Jean Sigwald - SOGETI Jean-Baptiste Bédrune - SOGETI

Comment obtenir une image sur disque d'un terminal iOS et la déchiffrer. Extraction :

  • logique (outils de backup du device)
  • physique (image des partitions)

Pour l'extraction physique, il est nécessaire d'avoir un accès root (jailbreak). Inconvénient : ca laisse des traces, pas terrible dans le cadre de l'inforensique. Avec certaines protections, le fichier est même chiffré (versions récentes de iOS).

iOS utilise un secure boot. L'interface USB utilise un protocole Apple (USBMUX : USB/TCP). Elle permet le backup, par exemple. Si il n'y a pas de Jailbreak, il faut passer par des vulnérabilités dans la BootROM (secure boot). Dans ce cas, le code PIN n'est pas nécessaire. La flash est chiffrée en AES-256 avec une clé stockée en hardware (Apple a communiqué sur le fait que ces clés sont générées de manière aléatoire en usine et que personne n'y a accès).

Historique des améliorations au niveau protection cryptographique de iOS.

Une démo.

Comme j'ai un peu déccroché, je passe la main à @g4l4drim : http://www.n0secure.org/2012/06/sstic-2012-analyse-forensic-de.html

Suite

J'ai malheureusement dû rater les rump sessions :(

SSTIC 2012, matinée du deuxième jour

Compromission d'une application bancaire JavaCard par attaque logicielle

Julien Lancia

Je n'ai pas suivi cette conf, je vous renvoie chez n0secure : http://www.n0secure.org/2012/06/sstic-2012-compromission-dune.html

IronHide : Plate-forme d'attaques par entrées-sorties

Fernand Lone Sang - LAAS-CNRS Vincent Nicomette Yves Deswarte

Complexité croissante de la protection des systèmes d'exploitation. Etude des attaques hybrides (logiciels + matériels). Focus principal sur les attaques par entrées/sorties des composants matériels.

Pour étudier ces attaques et avoir un grand contrôle sur les tests, ils ont développé leur contrôleur en utilisant un FPGA. Ce contrôleur d'entrées/sorties se nomme IronHide.

Rappels sur l'architecture matériel et la gestion de la mémoire (espace mémoire, port I/O, PCI, PCI-Express). Focus sur PCI-Express. C'est un modèle en couches (physique, liaison, transaction et logique du contrôleur). Dans la couche transaction, nous avons les I/O, la configuration, les accès mémoire ainsi le message "applicatif".

Détails d'architecture d' IronHide.

Cet outil permet de générer tout type de paquets (valides, invalides). Le firmware est écrit en langage C. Il souffre actuellement de problèmes de performance (5 Mo/s).

Expérimentations :

  • la carte IronHide est connectée sur la carte mère cible
  • une connexion depuis la machine d'analyse avec un cable RS-232 sur l' IronHide pour le reporting
  • et un autre cable RJ45 pour le command & control

Dans les tests, des dénis de service sont possibles sur l' I/O MMU, même avec des paquets valides lors de certains accès mémoire.

Démonstration d'une attaque : interception à distance des frappes claviers (accès arbitraire à la mémoire). Les paquets sont construits en utilisant Scapy. Leur méthode d'accès mémoire contourne les protections de l' IO/MMU, puisqu'ils utilisent directement les ports I/O.

Travaux futurs :

  • Création d'un IDS/NIDS pour contrôleurs

La qualité d'hébergeur en 2012

Romain Beeckman - Directeur Juridique - OVH

Conférence invitée.

Pas de slides, donc pas de compte-rendu. Na ! Et puis c'est une conf juridique ;)

Je note quand même des trucs ; réponses à des questions comme :

  • notions d'éditeur, d'hébergeur et de courtier (eBay)
  • un courtier doit être uniquement passif (pas d'optimisation des résultats de recherche, par exemple)
  • on devient éditeur si on a la capacité de modifier un contenu
  • les responsabilités et obligations d'un hébergeur
  • comment réagir lorsqu'on est hébergeur et notifié d'un contenu illicite
  • l'hébergeur doit mettre en place des moyens pour les utilisateurs de notifier de la découverte de ces contenus
  • le stockage des logs doit être d'au moins 12 mois

Résultats du challenge

Axel Tillequin Fabien Perigaud Florent Marceau

Par Julien Perrot (le grand gagnant du challenge). Un très bon travail de reverse.

Présentations courtes

Anthony Desnos - VirusTotal

Elsim + Androguard = Androsim Analyse automatique de programmes pour détecter les similarités entre codes et/ou bibliothèques. Le but est de trouver si un programme non-malicieux a été patché pour des fins malicieuses et/ou publicitaires. Détection à base de signatures, et surtout d'algorithmes de recherche de similarité. Tests sur le top des jeux Android : une majorité de code publicitaire (17% de code utile pour AngryBirds).

http://code.google.com/p/elsim/ http://code.google.com/p/androguard/

Davide Canali - EURECOM

Analyse des attaques Web par l'utilisation de Honeypots. Très peu d'études sur le début des attaques et sur ce que font les pirates ensuite. Setup : 500 sites Web avec 7 CMS (+ Web shells) chacun et 100 noms de domaines. Redirection via un proxy vers 7 VMs.

Outils permettant de voir :

  • si les attaquants automatisent l'exploration (suivi des liens)

3 mois de collecte :

  • 9.5 Go de requêtes HTTP
  • 73 000 IP sources
  • 178 pays
  • 11 000 User agents

Attaques les plus fréquentes (69 000 attaques détectées) :

  • Shells
  • OsCommerce (vulnérabilités file upload)

Les classes d'attaquants, analyse basée sur les fichiers uploadés :

  • Phishing
  • Spam
  • Défiguration
  • Link farming (Blackhat SEO)
  • Drive-by-download, botnets

Pierre Karpman - ENS Cachan / Supélec

Durcissement de programmes C avec SIDAN.

But : détecter :

  • les flots illégaux de contrôle du programme
  • les écritures dans la mémoire depuis des endroits illégaux

Des listes d'invariants :

  • une variable X ne doit être que entre telle ou telle valeur
  • on lance l'analyse
  • si la variable X n'est pas comprise dans ce range durant l'analyse, on peut éventuellement trouver une faille.

SIDAN est implémenté comme plugin dans Frama-C.

Ces travaux se rapprochent de ceux d' endrazine présentés au CCC de décembre 2012. http://www.slideshare.net/endrazine/ccc28c3-post-memory-corruption-memory-analysis

Contrôle d’accès mandataire pour Windows 7

Damien Gros - thésard - CEA

Le modèle DAC est limité. Difficile à mettre en place de manière globale dans le cadre d'une politique globale. Confidentialité et intégrité sont également manquants dans ce modèle. La solution est le Controle d'Accès Mandataire (MAC). Pour Linux : SELinux, SMACK, TOMOYO, RSBAC.

Implémentation d'un équivalent à SELinux (de type Type Enforcement) sous Windows 7 en utilisant l' API hooking sur la SSDT (32-bits). L'outil permet aussi de créer automatiquement une politique de base par l'analyse d'un processus s'exécutant.

mercredi, juin 6 2012

SSTIC 2012, après midi du premier jour

Windows Run Time

S. Renaud - Quarkslab K. Szkuldlapski - Quarkslab

Ca commence par un diff binaraire entre Windows 7 RTM et Windows 8 CP (kernel). Une fonction intéressante en est sortie: ()''. Interface Metro. Il existe des applications (App). Il faut absolument passer par le Windows Store. Les App :

  • Sont sandboxées
  • Ont un accès limité aux resources (permissions explictement données)
  • Utilisent un sous-ensemble des APIs Win32
  • Sont packagées (*.appx == *.zip) et signées
  • Ont un fichier .xml définissant les permissions

Tout passe toujours par la base de registre (HKCU pour des modifications par utilisateur).

Capacités :

  • accès réseau
  • accès système de fichiers
  • ...

Microsoft donne un certain nombre de requirements pour les App:

  • SAFESEH, DYNAMICBASE et NXCOMPAT
  • Pas d'applications Win32 natives

Même si on peut exécuter des applications natives depuis une App, ces applications seront sandboxées (héritage). La sandbox est basée sur un mécanisme de jeton pour l'attribution de permissions d'accès aux ressources de la machine. Mais impossible d'empêcher l'appel à des syscall(), et pas possible de sécuriser l'accès à des partitions FAT. Les données de communication transitent sur le port ALPC.

Conclusion : la fonction NtCreateLowBoxToken() permet une bonne isolation des App.

L'information, capital immatériel de l'entreprise

Garance Mathias - Avocate

La présentation juridique du SSTIC.

Le droit ne connait pas la notion d'information ni de système d'information. Il connait uniquement la notion de donnée, ou la notion de secret des affaires. Il existe aussi le droit à l'information du public et à la vie privée et au respect des correspondances (également appelé droit à l'intimité). Le droit à la vie privée des entreprises est un droit en construction (exemple : le bulletin de paie du patron de l'entreprise n'a pas le droit d'être divulgué). Question : qui est responsable de l'information ? Qui est responsable des BYOD ? Si mon bien est volé sur mon lieu de travail (si je m'en sers pour réaliser ma mission), ce sera l'employeur qui sera responsable. Nécessité de protéger son système information (mesures physiques, techniques, formation, sensibilisation) pour pallier le risque d'insécurité juridique.

"Celui à qui vous dites votre secret devient maitre de votre liberté". La Rochefoucault

Audit des permissions en environnement Active Directory

Géraud de Drouas - ANSSI Pierre Capillon - ANSSI

Rôle de serveur de contrôle d'accès au système d'information et d'annuaire global.

Difficile d'auditer des objets dans un annuaire de grande taille (1_000_000+ objets). Problème : les données resterons compromises lors du transfert d'un serveur attaqué vers un serveur sain.

L'objet intéressant : le DACL qui décrit les permissions d'un utilisateur. Comment récupérer ces données sans :

  • éteindre le serveur
  • le charger
  • être restreint ensuite.

Le fichier .dit dans le répertoire \\Windows\\NTDS ne peut être copié de manière simple. Mais une commande permet de l'exporter (toute la base). Un outil a été réalisé pour automatiser cette extraction. Cette base de donnée n'est malheureusement pas dans un format standard (genre SQL), il faut donc la convertir pour aider à l'analyse.

Ce format est horrible : un genre de matrice dans laquelle il faut faire de nombreuses déréférences pour trouver l'information souhaitée. Mais grâce à leur outil, ça devient facile : il suffit de cliquer pour ajouter des filtres et révéler les comptes en anomalie. Outil qui semble très efficace pour aider l'auditeur.

Note : les ACE des systèmes de fichiers ou autres SharePoint fonctionnent de la même manière.

L'outil ne sera disponible que sur la base de demandes individuelles (en gros). Mais tous les détails d'implémentation sont disponibles dans les actes.

Windows 8 et la sécurité : un aperçu des nouvelles fonctionnalités

Bernard Ourghanlian - Directeur Technique et Sécurité Microsoft France

Toutes les nouveautées ne seront pas présentées (pas assez de temps). Améliorer la protection de bout en bout afin de protéger le terminal.

  • intégration en standard d'un anti-malware
  • meilleure protection des accès aux ressources
  • sécurisation du processus de boot
    • utilisation d' UEFI et de TPM
  • des briques simplifiant la gestion de BYOD pour l' IT

Question : Qu'est-ce que ce mode multicast pour WDS ? L'orateur nous parle d'installation de programme en multicast :/ Note : WDS c'est Windows Deployment Service.

Boot sécurisé :

  • vérification de la signature de l' OS Loader depuis le boot d' UEFI
  • la couche ELAM se charge de bloquer les malware juste après l' OS Loader

Utilisation de cartes à puce virtuelles :

  • stockage de certificats (sur le disque dur) chiffrés avec une clé (contenue dans le TPM)
  • l'export de certificat est interdit (le TPM interdit l'export des clés contenues dans celui-ci)

Direct Access :

  • connecté à Internet c'est comme être connecté à son entreprise
  • chiffrement fort des communications
  • un check est fait (anti-virus, patches)

Authentification client :

  • Via SSL ou quelque chose de ressemblant. What?

Contrôle d'accès static (classique) et aussi dynamique :

  • refonte du modèle d' ACL (exemple : possibilité d'utiliser du AND et du OR, mais aussi des IF)
  • mise en place de permissions en fonctions de la localisation de la connexion source (exemple : hors entreprise ou en pays hostile).

Vraiment pas assez de détails techniques, une vraie présentation marketo-vendor-pitch.

10 ans de SSTIC

Fred Raynal Nicolas Fischbach Philippe Biondi

SSTIC 2012, matinée du premier jour

20 years of PaX

PaX team - plus qu'une personne sur trois dans l'équipe

Introduction sur ce que PaX est aujourd'hui. Modèle de menace: accès aribitraire à la mémoire (userland, kerneland) en lecture/écriture. Il vaut mieux dépenser son temps à prévenir l'exploitation des bugs que de les chercher. Une fonction importante: kernel self-protection. Nous n'aborderons dans ce compte-rendu que cette fonction qui est moins connue.

Quelques techniques d'exploitation :

  • return-to-libc
  • ROP (Return Oriented Programming)
  • JOP (Jump Oriented Programming)

Fonctions de kernel self-protection :

  • Non-exec kernel pages
    • Les pages userland ne doivent pas être exécutables depuis le kernel
  • Read-only kernel data
    • constification : création de mappings des données vers du read-only
  • Séparation de la mémoire userland/kerneland
    • Prévention de l'utilisation de code userland depuis le kernel
  • Restriction sur les copies userland/kerneland
    • Bounds checking pour les copies kerneland vers userland ou vice versa
    • Protection contre les stack overflow (limiter aussi les attaques ROP/JOP)
  • Protection contre les race condition de type copie/utilisation
  • Nettoyage automatique sur les appels free()
    • La mémoire libérée est nettoyée, tout de suite (2 lignes de code au bon endroit)

Certaines fonctions implémentées dans PaX ont été inspirées par le reverse engineering de Windows 95 (durant les années 90). Ces fonctions nécessitent une mise à jour de la toolchain de compilation : plugin gcc, par exemple. Quelques plugins :

  • Stackleak : prévention de la fuite d'information depuis la stack
  • Constify : constification automatique des structures ops
  • Kernexec : prévention de l'exécution de code userland
  • Size overflow : prévention de l'exploitation de failles integer overflow

Les futures protections :

  • Control Flow Enforcement : protection compète contre les ROP/JOP
    • Sous forme d'un plugin compilateur
    • Support JIT (Just-in-Time)
  • Détection et prévention des size overflow
    • Même plugin que pour le kernel
    • Ce plugin aurait protégé contre les failles CVE-2012-2110 et CVE-2012-2131 (OpenSSL)
  • User-after-free

Et beaucoup d'autres protections basées sur des plugins compilateur. Cela semble être le meilleur moyen aujourd'hui d'avoir des protections génériques. Le support LLVM/clang est également envisagé.

Les hyperviseurs : ils ajoutent une couche de complexité dans le système, et donc abaissent la sécurité du système. Le support ARM est prévu, mais seulement les fonctions compilateur et userland (beaucoup plus difficile pour le kerneland).

SSL/TLS - état des lieux et recommandations

Olivier Levillain - ANSSI

Description du fonctionnement du protocole de communication ("SSLv3/TLSv1.*) (ClientHello, ServerHello'', ...). Le client propose des algorithmes crypto, le serveur choisi.

SSLv2 (1995) à proscrire pour des raisons de faiblesses sécuritaires. Ce protocole tend à disparaitre. SSLv3 (1996) : problèmes avec la vieille implémentation. Ces problèmes sont corrigés par TLSv1.0.

Mais attaque à clair-choisi adaptative sur TLSv1.0 (Rogeway 2002). Corrigée dans TLSv1.1. Dans TLSv1.2, nouveaux algorithmes de gestion de l'authentification. Comme DHE/ECDHE qui assure la PFS (Perfect Forward Secrecy), afin qu'une caputre de session à un instant t ne puissent pas être déchiffrée dans le future.

Test de différents navigateurs pour le support des différentes version du protocole :

  • SSLv2 est désactivé par défaut sur les dernières versions de firefox
  • Chrome ne semble pas basé sur OpenSSL, il utilise son implémentation

Test de différents serveurs sur le support des différentes version du protocole. Scan de serveurs avec sslscan. A voir : référentiel RGS.

Test automatisé des navigateurs : http://ssltest.offenseindepth.com.

Le magasin de certificat : différents programmes utilisent différents magasins. Des avantages et des inconvenients à l'utilisation de magasins. Le magasin sous Linux est dans $HOME/.pki.

Note : Voir l'IDS Suricata.

Aucune réponse dans cette présentation concernant la gestion de la confiance globale au système (les PKI). Aucune étude non-plus sur le certificate pinning.

Netzob : un outil pour la rétro-conception de protocoles de communication

Frédéric Guihery Georges Bossert Guillaume Hiet

De nombreux protocoles (propriétaires ou non) qui ne sont pas documentés. Un des buts de la rétro-conception est le fuzzing de l' API, ou l'écriture de règles d' IDS. La communauté est globalement dépourvue d'outils d'analyse (processus manuel et visuel).

  • Vocabulaire : liste des messages et leur format
  • Grammaire : règles de procédure permettant d'assurer la cohérence des messages échangés.

Découpage du message brut en couches, puis champs. Les champs possèdent une liste d'attributs qui donneront la sémantique (optionnelle). La partie découpage en champ (automatisé) est basée sur un algorithme issu de la bio-informatique. Classification des messages (regroupés par similarité) aussi basé sur un algorithme issu de la bio-informatique.

Fonctions de l'outil :

  • Import => inférence du protocole => simulation => export.
  • Export : génération automatique de module Scapy.

Démo : découpage (presque) automatique de messages Ehernet/IP/UDP/DNS. Démo : instrumentation d'un serveur TCP pour inférence des différents état d'un protocole.

  • Output : un automate des états du protocole.

Note : aHR0cDovL2dvby5nbC9pOFo3UA==

prompt$ perl -MMIME::Base64 -e 'print decode_base64("aHR0cDovL2dvby5nbC9pOFo3UA=="),"\n"'
http://goo.gl/i8Z7P
prompt$ printf "GET /i8Z7P HTTP/1.1\r\nHost: goo.gl\r\n\r\n" |nc goo.gl 80 |grep http
Location: http://sarssi-conf.org/SAR-SSI2011-Programme.pdf
The document has moved <A HREF="http://sarssi-conf.org/SAR-SSI2011-Programme.pdf">here</A>.

Sécurité de RDP

Arnaud EBALARD - ANSSI Aurélien Bordes - ANSSI Raphaël Rigo - ANSSI

Microsoft recommande l'utilisation des RPC via la MMC et non pas de RDP. Initialement uniquement un protocole de déport d'affichage, mais étendu ensuite avec de nouvelles fonctions (énormément, tellement qu'il est lié à tout le système au final). 2000 pages de documentation sur le site de Microsoft ...

RDP participe simplement à la mise en place de canaux de communication entre composants (matériel ou logiciel). Protocole complexe : 8 messages pour établir une session.

Démo : recupération de la clé RSA (512-bits) depuis une capture de paquets. Factorisation du RSA, puis rejeu du traffic déchiffré : accès mot de passe admin et tout le déport de session. C'est beau. Pas de perfect forward secrecy.

Pour corriger ces erreurs de sécurité, Microsoft a introduit Enhanced RDP Security (pour remplacer le Standard RDP Security) :

  • TLS

Un protocole avec beaucoup de fonctions (même pour la sécurité), mais (presque) pas configurable. Une logique étrange pour le client Microsoft RDP au fil des versions (exemple : certificats X.509 doivent être formés d'une manière particuilère).

Démo :

  • L'admin a déjà coché la case pour reconnaître le certificat serveur
  • Attaque : MiTM sur Enhanced RDP Security
    • on laisse passer les premiers messages pour l'authentification
    • on se met ensuite en MiTM pour la suite afin de récupérer le mot de passe.

Finalement, le passage à TLS n'a pas vraiment amélioré la sécurité de RDP. Conclusion : l'utiliser sur un réseau vraiment sécurisé.

mardi, juin 15 2010

Compte-rendu SSTIC 2010 - jour 3

Vendredi 11 Juin

Bon, là, je me suis levé un peu tard (social event oblige). Donc, veuillez m'excuser pour le manque de détails concernant les présentations du matin ^^ Mais comme je suis un mec sympa, je vais faire de la pub pour le blog d'Erwan, et mettre des liens vers ses notes pour les présentations que j'ai manqué.

Note : Et pourtant, le CO a fait un effort cette année, puisque la première conférence ne débute pas à 9h :)

09:45 - Trusted Computing : Limitations actuelles et perspectives

Frédéric Guihery
Frédéric Remi
Goulven Guiheux

1ère conférence

10:15 - JBOSS AS: exploitation et sécurisation

Renaud Dubourguais

2ème conférence

11:15 - Audit d'applications .NET complexes - le cas Microsoft OCS 2007

Nicolas RUFF

3ème conférence

11:45 - Conférence invitée

Mathieu Baudet

4ème conférence

14:15 - PoC(k)ET, les détails d'un rootkit pour Windows Mobile 6

Cedric Halbronn (Sogeti/ESEC)

L'orateur commence par nous expliquer quels sont les composants classiques des rootkits :

  • avoir une méthode injection
  • implanter une backdoor avec un module de communication
  • se protéger sur la machine compromise (furtivité, redémarrage)
  • fournir des services

Contraintes spécifiques aux téléphones mobiles :

  • c'est un système embarqué, il faut bien gérer la mémoire et la batterie
  • c'est un environnement mobile, hétérogène, avec des méthodes connectivités nombreuses
    • il est connecté par intermittence, avec ou sans connexion à Internet
    • il possède de multiples canaux de communications (SMS, Internet, USB, WiFi...)
  • se baser sur les services présent (longue liste)

Pourquoi avoir choisi Windows Mobile pour développer ce rootkit ?

  • les API Windows Mobile sont les même que sur un PC Windows
  • très répandu
  • véritable OS basé sur Windows
  • c'est du Windows ^^

Le composant d'injection développé ici est par l'insertion d'une SD-card. On peut imaginer aussi en utilisant des méthodes "social engineering" en envoyant un lien Web dans un SMS (lien pointant vers un binaire Windows Mobile). Il est aussi possible d'utiliser un format spécifique des SMS (nommé WAP Push). Il s'agit d'un SMS au format XML (méthode utilisée par le malware Interceptor pour BlackBerry).

Note : certains téléphones exécutent sans confirmation des binaires contenus dans un WAP Push. Mais si l'application n'est pas signée, il y a un popup de confirmation visible à l'utilisateur.

Le rootkit a accès à toutes les API. La première chose à faire est de passer en mode noyau (fonction "SetKMode"). Le modèle de sécurité de Windows Mobile étant pour le moins faible, un processus utilisateur peut appeler cette fonction sans problème. Et vlan, on passe en mode noyau :)

Ensuite, le composant de backdoor doit initialiser la communication TCP/IP depuis le mobile vers l'extérieur (à cause du NAT que la plupart des opérateurs implémentent). Une autre possibilité serait l'utilisation de SMS comme canal de communication (avec une limitation à 140 octets, et le fait que les messages ne doivent pas être visibles à l'utilisateur). C'est l'option retenue pour les tests du rootkit décrit ici.

Un point cruciale lors du développement de ce genre de code malicieux : la gestion de la batterie. En effet, si la batterie se vide plus vite que l'accoutumée, l'utilisateur se rendra compte de quelque chose (toujours le cas BlackBerry). Il faut donc se brancher sur un composant existant dans le téléphone (API hooking, en prenant les commandes AT par exemple) pour se débarrasser de la gestion de la batterie. Aussi, hooker les APIs d'envoi/réception de SMS permet de masquer la fenêtre qui apparait à ce moment là.

Note : un smartphone, c'est 2 CPUs : 1 pour le BaseBand et 1 pour l'OS.

Démo. Outil en interface Web bien flashy pour communiquer avec le rootkit. A la réception d'un SMS, la fonction hookée répond à un ordre donné plus tôt. rootkit pas détectable par les anti-virus actuels.

14:45 - Projet OsmocomBB

Harald Welte

Au niveau de la communication téléphone vers BTS (ou BSC ? voir le fichier pdf pour le schéma d'architecture général), le chiffrement est fait à la couche physique (Layer1). Le processeur BaseBand des téléphones à son propre système d'exploitation (firmware) :

  • il lui manque les fonctions de sécurité modernes comme une pile non-exécutable, la randomisation des adresses ...
  • il est écrit en C et assembleur

Description du chipset BaseBand complète :
GSM Phone Anatomy

OsmocomBB : Open Source MObile COMunication, BaseBand

Démo. L'architecture du software permet de sniffer le réseau GSM depuis un PC standard :) Le fonctionnement est assez simple (mais surement pas l'implémentation). On branche le téléphone sur un port série de l'ordinateur, et le téléphone détecte se branchement au démarrage et démarre sur le firmware qui le souhaite. Ce firmware implémente les fonctions BaseBand, et en plus exporte une interface réseau classique pour pouvoir facilement brancher un Wireshark dessus (par exemple). Du coup, un PC peut servir à développer les fonctions réseau GSM de manière beaucoup plus simple.

Note : il existe aussi la couche UMA : c'est du GSM over IP

15:30 - Conférence invitée

Patrick Pailloux (Directeur de l'ANSSI)

Discussion à propos des menaces géo-politiques. L'ANSSI à pour mission principale la cyber-défense. Ce qui inclue la protection :

  • des infrastructures des hôpitaux
  • des systèmes de distribution d'énergie
  • de la sécurité des machines à voter
  • les infrastructures critiques (nouveau, depuis environ 1 an)
  • ...
  • large spectre de métiers à couvrir.

Ce travail doit se faire avec les homologues internationaux, ce qui ajoute encore une difficulté.

Dans le cadre des missions de l'ANSSI, les armes ne sont pas du coté de l'État, mais du coté des citoyens. Les armes prolifèrent donc du coté des citoyens, et l'État est quelque peu désarmé. Ainsi, il est difficile d'identifier les acteurs des attaques informatiques.

Un exemple de challenge : il y aura un jour la possibilité de voter sur Internet (au minimum pour les résidents Français à l'étranger). L'ANSSI se doit de trouver une solution suffisamment sécurisée en terme de technique. Autre exemple, le bracelet des prisonniers qui ne doit pas être falsifiable. En même temps, l'ANSSI doit vérifier le niveau de sécurité des infrastructures gouvernementales, et communiquer pour former les citoyens et les industriels (c'est un enouveauté, dans le passé l'agence était plutôt secrète).

L'ANSSI est sensé être l'organisme qui sait répondre à des questions techniques en matière de sécurité au niveau de l'état (parlement, députés, ...).

Note : certains appareils d'IRM fonctionnent sous Windows. Et rien n'avait été prévu pour installer des mises à jour de sécurité. En travaillant avec les hôpitaux, l'ANSSI à permis d'établir une certaine pression envers les fabricants d'IRM pour qu'a l'avenir ces appareils puissent être mis à jour.

Fin du SSTIC 2010

Rendez-vous l'année prochaine les enfants.

Compte-rendu SSTIC 2010 - jour 2

Jeudi 10 Juin

"Ca recommence comme avant".
"Pas tout à fait comme avant".
-- Matrix

09:00 - Présentation des résultats du challenge de reverse du SSTIC

Présentation du classement et remise des prix.

Présentation d'une solution par Arnaud Ebalard NatIsBad :

  • décompression de l'archive par 7zip
  • reconstruction de 2 fichiers .apk en analysant le format du fichier extrait
  • récupération d'un premier message signé (PGP) et chiffré (format spécial)
    • chiffrement de type décalage (ROT)
    • répondre aux énigmes pour trouver des coordonnées GPS
    • un mot de passe est contenu dans une section chiffrée (PGP)

Autre méthode :

  • reverse de 2 fichiers .smali
  • collecte des infos des coordonnées
  • collecte du mot de passe
  • reverse de la fonction "deriverclef()" contenue dans la bibliothèque libhello-jni.so
    • bug dans l'utilisation de la fonction cryptographique : seuls les 2 premiers caractères du mot de passe sont pris en compte (résultat : O7)
  • on peut ensuite déchiffrer un binaire qui affiche une adresse email (résultat final)

09:45 - Sécurité de la plate-forme d'exécution Java : limites et propositions d'améliorations

Christian Brunette
David Pichardie
Frédéric Guihery
Goulven Guiheux
Guillaume Hiet

Travail collaboratif entre AMOSSYS, l'INRIA et SILICOM.

Constats :

  • l'implémentation de la plateforme Java de plus en plus complexe.
  • des vulnérabilités récurrentes.
  • un mécanisme de contrôle d'accès peu utilisé.

Une question :

  • Java est-il adéquat pour le développement d'applications de sécurité ?
    • Voir les résultats d'évaluation de la sécurité Java par l'ANSSI.

L'architecture Java semble simple sur le papier ; mais elle est plus compliquée en pratique (beaucoup de composants ne passant pas par la JVM pour accomplir des fonctions bas niveau). Il existe 3 vérifications de sécurité lors de l'exécution d'une application Java :

  • à la compilation (JAVAC)
  • au chargement des classes (ByteCode Verifier : BCV)
  • à l'exécution (HIT)

Il existe d'autre mécanismes de sécurité :

  • un contrôle d'accès orienté code (JPSA)
  • un contrôle d'accès orienté identité (JAAS)
  • chargement des classes en utilisant du cloisonnement
  • vérification de la signature et de l'intégrité des classes

Le composant JPSA est écrit en Java (d'où la nécessité de bien protéger cette partie). Mais la plupart du temps, ce composant est soit inutilisé, soit mal utilisé par les développeurs. Il existe également un certain nombre de problèmes ou de questions à propos de la JVM elle-même :

  • rémanence des données confidentielles
  • échappement de la vérification de ByteCode (BCV escape)
  • quelle confiance dans l'implémentation ("évaluabilité")
    • les propriétés sont-elles effectivement assurées dans l'implémentation de la JVM ?
    • suppression de certaines vérifications ?
  • pas ou peu d'intégration avec les protections OS
  • pas de contrôle d'accès au sein-même de la JVM

Propositions d'amélioration (pour le langage Java "at large") :

  • guide de développement
  • guide de configuration et de déploiement
  • auditer, rechercher des failles
  • limiter la surface d'attaque
  • appliquer le contrôle d'accès

Propositions d'amélioration (pour la JVM):

  • augmenter la confiance dans le module d'exécution
  • proposer un contrôle fin de la durée de vie des données confidentielles
  • améliorer l'intégration avec les mécanismes de sécurité de l'OS
  • implémenter le contrôle d'accès au sein de la JVM
  • étendre les vérification faites par le BCV

Suivi d'un exemple de modification de code pour appliquer ces propositions : éviter la fuite d'objets partiellement initialisés.

Conclusion :

  • langage non-parfait, mais au moins pensé dès le départ pour la sécurité
  • mais certaines classes d'attaques sont non-couvertes de base (injection SQL, par exemple)
  • des faiblesses dans l'architecture et l'implémentation
  • faire un effort dans la sécurisation de la bibliothèque de base
  • augmenter la confiance dans la JVM (trouver le bon compromis performance vs sécurité)

10:15 - Analyse de l'efficacité du service fourni par une I/O MMU

Eric LACOMBE
Fernand LONE SANG

L'I/O MMU est un mécanisme de sécurité permettant de contrer les attaques DMA. C'est une gestion du contrôle d'accès à la mémoire pour les périphériques. Cela fonctionne en ajoutant une couche de virtualisation sur les adresses mémoires (mapping virtuel). Les attaques DMA sont réalisées :

  • soit depuis le CPU
  • soit depuis un contrôleur d'E/S

DMA permet un accès directe à la mémoire :

  • transfert de données entre contrôleur d'E/S et mémoire pour décharger le CPU.
  • l'I/O MMU s'intercale entre les contrôleurs d'E/S et la mémoire pour contrôler l'accès (limiter les zones mémoires accessibles)
  • fait de la translation d'adresses mémoire

Intel VT-d implémente l'I/O MMU.

  • description de l'architecture matériel (MMU, RAM, chipset, DRHU, ...).
  • c'est de la virtualisation de requête DMA.

Vecteurs d'attaques contre l'I/O MMU :

  • modification de la configuration d'une DRHU
  • altération des tables de pages pour donner accès à de nouvelles pages physiques
  • altération des tables de contexte
  • altération du registre d'une DRHU (plus difficile à détecter que les autres altérations).
  • modification du source-id (spoofing du contrôleur d'E/S)

Exemple de scénario d'attaque :

  • permettre une écoute réseau par exploitation d'une vulnérabilité matérielle
  • mise en œuvre de l'attaque :
    • FireWire et Ethernet partagent une même identité (accès aux mêmes régions mémoire)
    • du coup, le contrôleur FireWire peut modifier les trames Ethernet reçues !!
  • utilisation d'un iPod et de "social engineering" pour rejouer une attaque "pré-enregistrée" lorsqu'il est branché sur le port FireWire de la victime (nécessite le même hardware que l'attaquant, l'attaque étant spécifique au matériel réseau).
  • l'attaque utilise FireWire pour modifier à la volée les trames ARP de la carte Ethernet victime, et ainsi rediriger le trafic ("ARP poisonning")

Demo. La vidéo tourne sur la victime, il branche l'iPod. Elle s'arrête, et vient tourner sur la machine de l'attaquant. C'est beau.

Conclusion :

  • la solution qu'est l'I/O MMU possède des limites, la principale étant le partage d'identité (source-id) entre différents contrôleurs d'E/S
  • nécessite une confiance entre contrôleurs
  • ne contrôle pas les échanges internes au "southbridge"

Recommandation :

  • utilisation conjointe de VT-d et VT-x, TxT (TxT protège contre l'attaque de modifications sur les tables de contextes et de pages puisqu'elles sont stockées dans la mémoire principale du système)

11:15 - Quelques éléments en matière de sécurité des cartes réseau

Guillaume Valadon
Loic Duflot
Olivier Levillain
Yves-Alexis Perez

Cette présentation est la même (sauf la démo) que celle donnée à CanSecWest 2010. J'en ai déjà fait un résumé sur ce blog. Mais bon, comme j'aime bien, j'en refait un autre (plus court) ici.

Les cartes réseaux sont devenues très complexes (plusieurs processeurs, firmware, contrôleurs, opérations d'administration à distance, ...). Exploiter les cartes réseaux pour :

  • empoisonnement ARP, DNS
  • SSLStrip
  • bref, tout type d'attaque réseau est imaginable

Cas d'étude : "Broadcom NetXtreme". Lors de celle-ci :

  • une vulnérabilité a été mise en évidence
  • elle est exploitable de la même manière quelque soit l'OS (lien).

Cette carte possède un processeur MIPS qui accède à toute la mémoire de la carte, au SMBus, aux paquets entrant/sortant, à l'espace de configuration PCI. La carte possède des fonctions ASF (envoi d'alertes via le réseau) et doit fonctionner même si plus rien ne marche. Elle supporte aussi les "RMCP Security Extensions" (RSP), ainsi que le support de l'authentification et du contrôle d'intégrité. RMCP utilise un protocole tournant sur le port 664/UDP (toutes les requêtes à destination de ce port sont interceptées par la carte réseau, aucune application sur l'OS ne pourront l'utiliser). L'ASF "legacy" utilise lui le port 623/UDP (même punition, l'OS ne verra aucun paquet à destination de ce port).

L'ASF/RMCP est très simple sur UDP. Mais il y a aussi AMT et IPMI qui sont plus complexes, et sur TCP. Dans le cas d'AMT et IPMI, la carte réseau doit implémenter une pile TCP ... risque d'autres vulnérabilités accru.

Démo de compromission à distance.

12:00 - Honeynet Project en 2010

Sebastien Tricaud - PicViz labs (conférence invitée)

Buts du projet :

  • améliorer la sécurité d'Internet à aucun cout pour le public (tout un programme)
  • fournir des documents et des outils
  • organiser des challenges

L'orateur s'attache ensuite à la description de l'organisation du projet. De manière simplifiée, il est découpé en chapitres ; un chapitre représentant un pays (Canada, USA, Mexique, Brésil, France, Allemagne, Espagne, Norvège, Chine, Iran, ...)

Le projet est orienté sur la recherche, et non sur l'opérationnel. Objectifs :

  • piéger nos ennemis
  • analyser leurs activités
  • se renseigner
  • discuter et échanger
  • fournir des informations telles que :
    • papiers
    • KYE (Know Your Enemies)
    • KYT (Know Your Tools)

Ces informations sont accessibles via différents média :

  • site Web
  • blog (des différents acteurs)
  • twitter

Exemple de réalisation : travail avec Fyodor ("nmap") pour détecter facilement le vers "Conficker" (travail issu de la recherche du chapitre Allemand). Un script NSE a été écrit pour que tout utilisateur de "nmap" puisse scanner son réseau afin de détecter les machines compromises. Quelques outils :

  • Glastopf
  • Google Hack Honeypot

Les honeypots s'articules autours de trois grandes catégories :

  • serveur/client
  • haute/basse interaction
  • analyse

D'autres outils :

  • Nepenthes : émulateur de vulnérabilités connues.
  • PhoneyC : honeypot client écrit en Python
    • interaction avec des pages Web, téléchargement, analyse, alerte (PhoneyC)

Conférencier : sebastien@honeynet.org (Blog LogViz)

14:30 - La sécurité des systèmes de vote

Frédéric Connes

ABSENT

15:00 - Applications Facebook : Quels Risques pour l'Entreprise ?

Alban Ondrejeck
Francois-Xavier Bru
Guillaume Fahrner

ABSENT

15:45 - Projet OpenBSC

Harald Welte (conférence invitée)

Peu de documentation publique sur les protocoles GSM/3G. Et du coup, quasiment aucune évaluation de la sécurité de l'implémentation sur ceux-ci. Les entreprises ne livrent aucune documentation ("closed minded"). Même les gros clients (les opérateurs) de ces produits ("manufacturers") ne reçoivent que peu de documentation, et aucun code source. Peu de personnes connaissent vraiment la suite complète de protocoles. Ils connaissant juste ce qui est nécessaire au bon fonctionnent opérationnel.

GSM, c'est bien plus que la gestion des communications téléphoniques. On trouve également ce protocole dans les endroits suivants :

  • BWM peut ouvrir/fermer les portes d'une voiture
  • les systèmes d'alarmes
  • applications de "Smart Metering"
  • GSM-R (système de contrôle de train européen : "European Train Control System"
  • les caisses enregistreuses des supermarchés quand quand la caisse est pleine
  • numéros de transaction pour le commerce électronique

Les implications sécurité :

  • personne ne connait les détails des protocoles et du réseau GSM à part les fabricants
  • pas de recherches indépendantes en sécurité
  • pas d'implémentations "open source" (of course, j'ai envie de dire)
  • retard de 10 ans par rapport à la sécurité sur les protocoles régissant l'Internet
    • pas de firewall, de filtrage ou de détection d'intrusion
    • les opérateurs comptent seulement sur le fait que 'ça va marcher comme prévu'
    • pas de stratégie de gestion des incidents

Des problèmes de spécification :

  • chiffrement optionnel
  • manque d'authentification mutuelle
  • appels 'silencieux'
  • obtention des coordonnées GPS de l'appareil via les protocoles RRLP et SUPL (invisible pour l'utilisateur)

Des problèmes d'implémentation :

  • fuite de l'information TMSI au changement de réseau
  • des parsers TLV peu testés
  • options obscures et peu testées

Des problèmes d'opérationnel :

  • débordement de champ VLR
  • ré-allocation TMSI trop peu fréquente

Mais par où débuter la recherche sécurité ?

  • à partir du combiner de téléphone ?
    • certains ont tenté, mais trop difficile (pas d'accès au hardware)
    • tentatives comme TSM30 (THC GSM), mados pour les Nokia DTC3
  • à partir de la couche réseau ?

Premières étapes :

  • obtenir les spécifications GSM : > 1000 documents PDF
  • obtenir un équipement réseau GSM (BTS)
  • obtenir des traces réseaux

Note : dans une démo publique, il a fait sonner tous les téléphones de l'assistance ^^

C'est une suite complexes de différentes interfaces avec leurs protocoles associés. Pour l'interface réseau GSM :

  • Layer1 : Radio Layer
  • Layer2 : LAPDm
  • Layer3 : Radio Resource, Mobility Management, Call Control
  • Layer4+ : USSD, SMS, LCS

Pour l'interface A-bis, une autre suite de protocoles ...

Il a démarré ses recherches en 2006. En 2008, il a réussit à faire apparaitre son antenne comme un vrai réseau pour son téléphone. 01/2010 : les 25 premières antennes OpenBSC tournent chez des opérateurs. Mais toutes les fonctionnalités GSM ne sont pas implémentées :

  • support des équipements BS-11 BTS (E1) et ip.access nanoBTS (IP Based)
  • roaming, et envoi de SMS

Note : les iPhones crashent facilement à cause de paquets ne respectant pas les spécifications. L'orateur n'a même pas eu besoin d'utiliser du fuzzing pour s'en apercevoir ...

Problèmes connus des GSM :

  • pas d'authentification mutuelle
  • algorithme de chiffrement faible
  • et puis, de toute façon, le chiffrement est optionnel (et l'utilisateur ne sait pas si c'est on ou off)
  • le réseau GSM peut demander au téléphone sa position GPS exacte
  • des features obscures de part les spécifications :
    • demander à un téléphone d'appeler tel numéro
    • d'envoyer un FAX par SMS

Utilisation de Scapy pour coder les différentes couches réseau.

Il peut maintenant envoyer des données :

  • depuis un rogue network vers les téléphones (OpenBSC, OpenBTS)
  • depuis un proxy A-bis vers le réseau ou les téléphones

Liens : GSM Phone Anatomy
OpenBSC
OpenBTS
OsmocomBB

Note : environ 7/8 personnes à développer ce code.

16:45 - Rump Sessions

Les habituelles rumps, mais avec rien de vraiment extra-ordinaire cette année. Ah si, l'excellent Netglub de l'ami Guillaume Prigent.

lundi, juin 14 2010

Compte-rendu SSTIC 2010 - jour 1

Mercredi 9 Juin 2010

Comme tous les ans, l'amphi est plein. Toujours difficile de trouver une place assise, c'est un peu lourd. Mais bon, je ne vais pas commencer par me plaindre ^^ Aller, c'est partie pour another compte-rendu du SSTIC 2010.

10:00 - Systèmes d'information : les enjeux et les défis pour le renseignement d'origine technique

Bernard Barbier - Directeur Technique (DGSE)

Une conférence par une personne de la DGSE est Probablement une première, du fait de la confidentialité des informations traitées. Le but est de délivrer un message aux experts sécurité que nous représentons.

La DGSE est mandatée pour accomplis certaines missions. Ces missions sont définies par un décret de 1982. Une nouvelle organisation dans la "communauté du renseignement" qui est apparu suite à l'élection de N. Sarkozy. L'organisation est complexe, on peut citer les entités suivantes :

  • SGDDSN, ANSSI, DCRI,DRM, DGSE, DPSD, DNRED, TRACFIN
  • environ 3000 personnes

Les priorités :

  • contre-terrorisme
  • contre-prolifération des armes
  • contre-espionnage
  • lutte contre la criminalité
  • lutte contre la cyber criminalité

Missions de la Direction Technique :

  • voir (satellites de surveillance, exemple : satellite Helios (http://fr.wikipedia.org/wiki/Helios_(satellite))
  • sentir (par des capteurs physiques : pression, température, tremblements, radio-activité)
  • écouter (interception des communications, interception de proximité (via un matériel à base de laptop, mais pas en France puisque c'est illégal ^^))

Missions plus informatiques :

  • rétro conception (casser la crypto, par exemple)
    • développement d'un calculateur à base de FPGA
    • probablement le plus gros centre informatique d'Europe (après les Anglais)
  • traitement des métadonnées (le contenant, le contenu)
    • traduction des langues étrangères (outils de transcription automatiques pour passer de l'oral à l'écrit)
    • des péta-octets de données stockées (être capable de remonter à des données de plusieurs années pour faire, par exemple, un lien complet entre les appels téléphoniques et la chaine des personnes impliquées)
  • géolocalisation (être capable de lier position et image)

Et surtout, être capable de coupler toutes ces disciplines pour avoir une vue globale.

Exemple de réalisation : libération des otages Français retenus à l'étranger.

La France est dans le TOP5 : USA, GB, Israël, Chine.

La lutte informatique vue de la DGSE :

  • un enjeu majeur de souveraineté
  • près de 10 ans de retard par rapport aux autres pays du TOP5
  • responsable de l'attaque, mais savoir se défendre en premier
    • comment faire confiance au hard/soft étranger (routeurs, anti-virus)
  • on détecte mal les incidents (au moins comparé aux USA)
    • être capable de les détecter
  • réinventer la sécurité de SCADA (pas pensé sécurité au départ)
  • être capable de LIO/LID (Lutte Informatique Offensive/Défensive)
    • intrusion par exploitation de failles, social engineering par email, laisser trainer une clé USB, ..., bref les méthodes d'intrusion classiques (mais pas depuis la France, c'est illégal ^^)
    • très sensibles, ne pas laisser de traces (discrétion, et durée).
    • agir à l'extérieur de la France pour ne pas enfreindre la loi française
    • être anonyme

La DGSE, c'est surtout deux organismes différents (l'un orienté attaque, l'autre défense)

  • comment les faire travailler ensemble ?
  • mais d'abord mettre en place la défense
  • énormément de failles dans nos systèmes, les attaquants on peut-être 10 ans d'avance
  • LIO est surtout utilisée pour affaiblir le système de la cible pour permettre l'écoute

Note : la DGSE a des 0days.

11:15 - Tatouage de données d’imagerie médicale – Applications et Méthodes

Gouenou Coatrieux (Telecom Bretagne)

Description du watermarking (embedder, reader, shared key). Applications : copyright protection, finger printing, contrôle d'intégrité, data hiding, self-correcting image ...

Deux grandes classes : data protection, data hiding.

WM pour vérifier l'intégrité de l'image et son authenticité. C'est un outil complémentaire à la crypto, il ne se substitue pas à celle-ci.

Applique un hash sur les modifications à l'embedder. Puis le hash est extrait via la clé pour vérification de la signature.

Tatouer le dossier médical dans l'image :

  • mais grande quantité d'info.
  • d'où l'idée du data hiding

Comment tatouer des images sensibles (ne pas modifier l'information utile).

  • utilisation d'un WM lossless (être capable d'enlever la marque)
  • mais la sécurité est abaissée

Il faut trouver le bon compromis. Et ce n'est de toute façon pas aussi bon que la crypto. Besoin d'un standard pour évaluer la distorsion des images médicales.

12:00 - Visualisation et Analyse de Risque Dynamique pour la Cyber-Défense

Philippe Lagadec (OTAN)

Concerne uniquement la défense informatique.

  • c'est une priorité pour l'OTAN
  • guider une implémentation opérationnelle avec l'industrie

Quatres phases : "Observe", "Orient", "Decide", "Act"

  • "Observe" => IDS, logs, supervision, forensics
  • "Orient" => corrélation, analyse, détection avancée, visualisation
  • "Decide" => recommandation de réponses, simulation, aide à la décision
  • "Act" => application de la réponse (auto ou non), reconfiguration dynamique du réseau.

Aujourd'hui, uniquement "Observe", et un petit peu de "Orient".

Avoir réponse a une question majeure : comment est l'infrastructure en temps réel (failles, machines compromises, machines soumises à un risque d'intrustion, ...).

Énormément d'outils générant de l'information sur le réseau : "NIDS", "HIDS", "firewall", "syslog", anti-virus, vulnérabilités, ...

  • mais difficulté à unifier leur format pour consolider l'information.
  • utilisation d'outils de type "SIEM".
  • très difficile de visualiser de manière synthétique.

Visualisation : prototype "CIAP" ("Consolidated Information Assurance Picture") :

  • Information Modem
  • Data Repository
  • User Interface
  • Application Interface

Voir en temps réel les vulnérabilités et les attaques en cours.

  • Démo de l'outil (interface Web de visualisation).
  • Outil RadialNet fournit avec nmap
  • Vue Treemap

Permet l'analyse de risque dynamique ("DRA", "Dynamic Risk Analysis"). Processus :

  • construction complète de la description du système depuis l'outil "CIAP"
  • génération du graphe d'attaque ("Exposure")
  • MAJ de l'analyse de risque ("Risks")

Différents états possibles des machines du réseau : normal, vulnérable, exposé, compromis.

  • puis démo de l'outil de "DRA" (interface Web également)

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

Fabien Allard
Mathieu Morel

But : détecter l'utilisation du proxy HTTP pour faire passer un tunnel TLS (exemple : détection du P2P et de backdoors communiquant en HTTPS).

Options possibles pour atteindre ce but :

  • cryptanalyse des flux (couteux en ressources)
  • coupure de chiffrement (atteinte en confidentialité)
  • reconnaitre le protocole à l'origine du flux par analyse statistique/comportementale (option retenue)

Objectif : déterminer le protocole à l'origine du flux chiffré.

Hypothèse : chaque protocole a un comportement caractéristique:

  • échanges de paquets, tailles et temps inter-paquets
  • c'est une empreinte qui est observable après chiffrement/encapsulation dans HTTPS

Idée : extraire les paramètres pertinents, puis comparer ces paramètres à un modèle statistique.

Fonctionnement :

  • BDD d'apprentissage
  • projection de chaque observation
  • construction d'un modèle
  • classificiation des flux à la volée à partir du modèle.

Sélection des paramètres à extraire des flux par un algorithme de sélection automatique en utilisant les plus discriminants. Puis applications de 6 méthodes d'apprentissage statistiques pour trouver la plus pertinente dans le cas présent.

  • l'algorithme RandomForest retenu (une forêt d'arbres de décision)

Puis développement d'une autre méthode basée sur les Modèles de Markov Cachés ("MMC") pour une classification probabiliste.

Démo :

  • outil basé sur une interface Web (encore)
  • tests basés sur la récupération de nombreux flux
  • taux de bonne classification > 96%
  • temps de classification très rapide (~ 45s pour l'apprentissage, et moins de 0.5s pour classifier un nouveau flux)

Note : l'outil analyse le flux complet, et pas seulement les premiers paquets.

Conclusion :

  • taux de fausses alarmes encore trop élevé
  • pas de détection sur protocoles inconnus
  • reste à analyser les méthodes de contournement

14:45 - Réflexions pour un plan d'action contre les botnets

Eric Freyssinet (conférence invité) (Lieutenant-colonel en Gendarmerie)

Présentation de l'organisation de son service en France (et DOM-TOM). Il existe un lien avec Interpol pour lutter contre les botnets. Environ 100000 gendarmes au niveau national.

Les botnets sont responsables :

  • de 85/90% du spam selon les sources
  • de phishing
  • de distribution de logiciels malveillants
  • de collecte de données personnelles
  • d'attaques en DDoS

Les botnets sont commercialisés : loués, vendus, reloués, .... Les organisation derrières ceux-ci sont parfois mafieuses.

Quelques exemples :

  • hébergeur Atrivo sans scrupules. Fermé en septembre 2008 mais relocalisé ensuite.
  • l'affaire McColo ... hébergeur fermé, mais les personnes n'ont pas été identifiées. Le niveau de spam a baissé suite à cette fermeture, mais il a repris son niveau normal au bout de quelques semaines.
  • Microsoft qui fait tomber Waledec.
  • l'affaire Mariposa (02/2010). Identification de 3 personnes contrôlant ce botnet. La société vendant ce service a aussi été identifiée (BufferFly Flooder).

L'orateur nous parle ensuite de ses réflexions articulées autour de trois axes : prévention, détection, réaction. Il existe de nombreux acteurs responsables des botnets : développeurs, revendeurs, pasteurs (herders), mules, commanditaires, hébergeurs, clients, victimes.

Éléments de prévention :

  • sensibilisation des utilisateurs
  • mesures de sécurisation (opérateurs, entreprises, ...)
  • sensibiliser la population (éviter les mules, par exemple)

Éléments de détection:

  • groupes de travail (lutte contre le spam, phishing, ...)
  • entreprises (Team Cymru, ShadowServer, Eurecom "FIRE")

Tous ces éléments de détection génèrent de la données brute de collecte. Malheureusement, il n'existe pas de format standardisé pour partager celles-ci. Néanmoins, il existe des propositions telles que :

  • un language commun pour la collecte de données
    • IODEF "Incident Object Description Exchange Format" (RFC 5070)

Un autre point est le stockage de ces données. Il existe un base plus ou moins commune aujourd'hui : "Cyborg". Il reste tout de même à trouver une méthodologie pour que les différents acteurs de la détection puissent travailler ensemble de manière efficace.

Enfin, le volet réaction :

  • groupe de travail Interpol "Working Party on IT Crime - Europe"
  • rapports sur le crime dans les mondes virtuels
  • groupe de travail Interpol "Botnet project"
    • prouver qu'il est possible d'identifier et faire fermer un botnet
    • des invités de la "Team Cymru"

Quelques pistes législatives :

  • actions maitrisées sur les réseaux
    • bloquer la propagation des menaces
    • prendre le contrôle de botnets et forcer le nettoyage
    • utiliser le botnet pour nettoyer les machines infectées (interdit aujourd'hui)
  • considérer l'envoi de spam comme un délit (en fonction d'un certain seuil)

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

Christophe Devine
Damien AUMAITRE

Pour débuguer un programme sous Windows, il existe le mode de boot "DEBUG". Malheureusement, ce mode désactive certaines protections Windows tel que "PatchGuard" ou les "DRM". La présentation s'attache au développement d'un débugueur pour Windows 7 64-bits qui contourne ces limitations. Quelques problèmes se posent ensuite, tels que la signature des "drivers" (un débuguer efficace doit tourner en mode "driver").

Mais ensuite comment hooker l'IDT si PatchGuard est activé ? Et comment contourner la vérification de la signature d'un "driver" ?

  • la réponse est l'utilisation de "DMA" sur bus "PCI" pour exécuter du code arbitraire, et ainsi charger un "driver" non signé.

Le "driver" établira un canal de communication utilisant l'accès "DMA" en mémoire physique. Avantages et but de la solution "VirtDbg" :

  • grande furtivité (comme "BluePill").
  • empreinte minimal sur la cible (déport des fonctions vers le client).
  • utiliser le moins possible les fonctions de l'OS.
  • utilisation d'une carte "PCMCIA" pour communiquer avec le "DMA" (voir SSTIC 2008 et SSTIC 2009).
    • utilisation d'une "CardBus" avec un "FPGA" (utilisation de "VHDL" pour simuler un processeur "MIPS").
  • utilisation d'un composant de type hyperviseur ("driver"). Virtualisation a chaud comme "BluePill" (pour l'instant, utilisation de VT-x uniqement).

Démo.

Problème, charger l'hyperviseur pendant que "PatchGuard" ne regarde pas. Il ne regarde pas tout le temps certaines fonctions de l'"IDT". Et ça marche. Hyperviseur de 600/800 lignes environ. Puis utilisation de "Metasm" pour parler le "stub" "GDB".

Conclusion : - debugueur furtif qui accède à tout en contournant les protections Windows - traçage de code malicieux très haut niveau

16:30 - Analyse de programme par traçage

Daniel Reynaud
Jean-Yves Marion
Wadie Guizani

Dans cette présentation, les orateurs nous parlerons d'analyse dynamique de programmes à des fins d'aide à l'analyse statique. Les traces ont l'avantage d'être des objets "propres". On peut décorréler deux tâches :

  • extraction des traces
  • analyse

Utilisation de "TEMU" (basé sur "QEMU") pour l'analyse dynamique, puis de "Vine" pour l'analyse statique. L'outil développé se nomme "TraceSurfer", et il permet la détection des comportements d'auto-modification. Aujourd'hui, la grande majorité des programmes malicieux utilisent cette technique pour rendre difficile le "reverse engineering". Grâce à l'outil "TraceSurfer", la partie fastidieuse de suppression de l'auto-modification devient bien plus aisée. L'outil permet la visualisation de la protection binaire mise en place (de type packers, UPX, Temida, ...). L'outil génère une trace d'exécution dynamique qui sera ensuite utilisée par un plugin "IDA".

Note : Voir aussi "Pin" (pintool.org) pour l'extraction des traces.

"TraceSurfer" : 160 lignes de C++ et 750 de Python. Basé sur l'outil Pin.

Code source : Tartetatintools
Indefinit Studies

17:00 - Intéressez vous au droit... avant que le droit ne s'intéresse à vous

Eric Barbry (cabinet Alain Bensoussan) (conférence invitée)

L'année 2010 est exceptionnelle au niveau des modifications sur le droit de notre métier. Description des casquettes du DSI/RSSI en 2009. Beaucoup de casquettes, et en plus du droit. En 2010, le DSI/RSSI devrait devenir un juriste à cause de toutes ces nouvelles lois. Nouvelle menace : le phishing dans l'entreprise. Voir les 10 conseils de la CNIL pour sécuriser son SI.

Note : clause à 7000 € sur le Cloud computing est inacceptable.

Une présentation "style one-man-show" qu'il est difficile de résumer ici.