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.

lundi, avril 19 2010

Compte-rendu CanSecWest 2010 - jour 3

Friday March 26

08:30 - 09:00 Breakfast

09:00 - 10:00 Stuff we don't want on our Phones: On mobile spyware and PUPs - Jimmy Shah, McAfee, Inc

Chercheur en antivirus pour la mobilité. Les spyware sous plateformes mobiles : - adware : pas aussi intrusifs que sur PC - PUP : Potentially Unwanted Program, comme des serveurs Web ou FTP intégrés au téléphone. Mais aussi des programmes qu'une entreprise ne souhaite pas voir sur ses téléphones comme Metasploit, Aircrack, ...

En Indes, le gouvernement a demandé un accès de type spyware aux téléphone Blackberry. Ils ont aussi réduit la taille des clés de chiffrement de 256 bits à seulement 40 bits. Ils ont aussi obtenu que les serveurs Blackberry soient en Indes, pour pouvoir monitorer le trafic. Le gouvernement a aussi prétendu avoir cracké le chiffrement "non-corporate".

Etisalat a poussé une mise à jour sur les Blackberry. Un reverse engineering a montré que cette mise à jour intégrait du lawful interception. Une copie des mails était envoyée à une adresse Etisalat. Ce reverse a été simplifié puisque l'update était au format .JAR, au lieu du format .COD.

Une famille de vers iPhone (OSX/RRoll.A-B) modifiait l'image de fond et désactivait le démon SSH. L'auteur était Ashley "ikex" Towns.

Attention, certains spywares sont distribués via Android Appstore (cas d'une App de banking). Il existe aussi des Appstore alternatifs aux originaux, où le contrôle est difficile.

Présentation sans intérêt, j'ai arrêté de la suivre à la moitié. En gros, il fait un historique des recherches en développement spyware pour téléphones mobiles faites par d'autres, et présentées à BlackHat et autres conférences (Spyphone (iPhone), Phonesnoop (Blackberry)).

A noter aussi un PoC de botnet (WeatherFistBadMonkey), mais jamais releasé. Envoi des emails, fait du DDoS et fournit un reverse shell.

La présentation s'est achevée parce que l'ordinateur de l'orateur n'avait plus de batterie ... à 10 minutes de la fin. Un mec de l'organisation est venu l'aider pour rétablir le courant. Ça donne le niveau. Sur le mur tweeter de CanSecWest, les gens se lâchent sur la présentation. Je ne suis pas le seul à l'avoir trouvé pourri.

10:00 - 10:30 Second Breakfast

10:30 - 11:30 Practical Exploitation of Modern Wireless Devices - Thorsten Schroeder and (contributing) Max Moser, Dreamlab Technologies

Les gars sont du Dreamlab Technologies et de remote-exploit.

C'est un talk sur l'injection et l'écoute de données pour les claviers sans fils basés sur les fréquences 27 MHz. Keykeriki est un petit dispositif hardware, ils ont aussi fait le firmware. Le talk n'aborde pas l'infrarouge ou les technologies bluetooth.

Ça parle des communications en sens unique sur 27 MHz. Le protocole n'a pas de support pour le chiffrement (enfin c'est à la charge du fabriquant d'implémenter çà), et les messages ne sont pas protégés contre le rejeu. Ils ont reversé le protocole des claviers Logitech et Microsoft. Chaque frappe au clavier provoque l'envoi d'un paquet avec le keyboard ID, la touche, et l'état (appuie ou relâche).

Ils ont releasé la V1 de Keykeriki en may 2009, et il pouvait juste sniffer les claviers Microsoft, Seimens-Fujitsu et Logitech. Une SDCard pour le stockage des données, et du cracking à la volée du chiffrement. L'injection était limité, parce que certains bits du protocole n'était pas encore vraiment reversé.

Nordic Semi NRF24xxx permet d'avoir un receiver, et jusqu'à 6 appareils connectés (concept du multiceiver). Le protocole supporte un CRC (mais optionnel). Pour sniffer, il faut tout d'abord trouver l'adresse de l'appareil. Il faut identifier le préambule, et seulement ensuite on peut trouver cette information. Cette-ci est sur 5 bytes. et le préambule fait 8 bits. Un heuristique est utilisé pour trouver cette adresse, avec un certain niveau de False Positive. Keykeriki a une interface JTAG pour le débogage.

Microsoft utilise du crypto hardware AES-128 dans ses claviers. Ensuite, une explication sur les différents paquets et leur format. Les claviers Logitech utilisent aussi le chiffrement AES-128.

Note : certains appareils utilisés pour le vote sont basés sur ce genre de hardware. Certains appareils sont aussi présents dans les voitures.

Démo sur un clavier Micorosoft, remote command execution par injection de frappes clavier. Ce n'est pas du simple replay, ils ont implémenté les fonctions d'un vrai clavier. Injection possible jusqu'à 75 mètres ...

Ils ont l'intention de fournir une version gratuite et une version commercial du produit, ainsi qu'un module Wireshark. Toutes les infos sur http://www.remote-exploit.org/.

11:30 - 12:30 RFID Hacking at Home - Dr. Melanie Rieback, Vrije Universiteit Amsterdam

Elle bosse dans le lab ubisec, Security in Ubiquitous Computing. C'est le même genre de travail qui a été fait dans la présentation précédente.

Les menaces à prendre en compte : - lecture non autorisée - clonage - DoS - tracking - écoute

Existe-t-il des malwares pour RFID ? - exploits - vers - virus Via l'exploitation de buffer overflow dans le format des messages. Rien de connu pour l'instant.

Note : utilisation de Google Trend pour voir l'évolution d'un sujet (comme RFID malware).

Elle bosse sur un dispositif nommé RFID Guardian. Un dispositif mobile de pentesting et firewalling pour RFID. C'est un projet vendor-neutral, tout est disponible sur http://rfidguardian.org/. Le but est de montrer au monde que les RFID ne sont pas suffisamment sécurisés. Le dispositif coûte dans les 500 euros à fabriquer. Le bootloader est GPL. Ils cherchent des sociétés qui voudraient collaborer avec eux.

Fonctionnalités: - emulation de tag RFID - attaques de rejeu - attaques de relai - selective jamming - tag spoofing - RFID firewall (ACL) => n'autoriser que les bonnes personnes à accéder au tag RFID => mais ça n'empêche pas une personne d'écouter le trafic. - implémentation de SSL. Ça marche, mais c'est très lent - RFID fuzzing (Bstorm)

12:30 - 13:30 Lunch

Remise des prix de PWN2OWN, les gagnants se voient remettre un super laptop et un gros chèque de 10,000 CAD.

13:30 - 14:30 Advanced Mac OS X Physical Memory Analysis - Matthieu Suiche

Il a créé sa propre société MoonSols. Spécialisé dans le forensics. C'est notamment l'auteur du Sandman framework et de Windd.

Pourquoi ? La mémoire non-volatile ne suffit pas. Actuellement uniquement base sur x86 (32-bits) Mac OS X. Uniquement de l'acquisition basée sur du software. En hardware, le mapping mémoire n'est pas le même.

Accès à la mémoire physique : - soit accès au /dev/mem, mais c'est désactivé par défaut (et on ne peut pas rebooter, c'est du live forensics) => donc utilisation bcopy_phys() - soit utiliser l'hibernation (Safe Sleep)

Safe Sleep : créé une image compressée (format WKDM). Et peut éventuellement être chiffré (mais désactivable sans rebooter). Le but de l'analyse est d'éviter la recherche de chaine en mémoire de manière aléatoire. Méthodologie: - recherche des symboles kernel - initialisation du gestionnaire de mémoire - parcourir l'espace d'adressage virtuel du kernel - collecter l'information.

On obtient : - la liste des threads - les processus - information sur la machine - les descripteurs de fichiers - des informations réseau - des fichiers ouverts et leur contenu - des mots de passe ...

Windows stocke les symboles dans des fichiers séparés (.PDB). Sous Mac OS X, ils sont stockés dans l'exécutable kernel. Pour lire les données d'adresse des symboles kernel, ils faut utiliser une formule de conversion. S'ensuit une description du parcours de l'espace d'adressage virtuel. Maintenant, on a les sympboles kernel et le gestionnaire de mémoire est initialisé, tout l'espace mémoire kernel est maintenant parcourable.

D'abord récupérer les informations de version du système. Puis la liste des systèmes de fichier. La liste des extensions kernel via le parcours de la liste chainée kmod. Puis la liste des processus BSD via la structure kernproc, ainsi que les informations associées dans la structure de données du processus. Reconstruction de la syscall table.

Détection de rootkit : si un offset dans une entrée syscall n'est pas dans les symboles kernel, y'a un soucis ^^

Démo. Commandes info (version du kernel, mémoire, CPU), mount (listage des filesystems avec leur mountpoints). syscall pour la syscall table (avec offset associés, et si l'entrée est correcte pour détecter la modification d'une entrée comme par du hooking). kext pour avoir la liste des extensions kernel. ps pour la liste des processus avec parent ID. On peut "zoomer" sur un processus via la commande pid. Puis démo en zoomant sur le processus loginwindow. Une simple commande exploite une faiblesse de ce programme divulguée début 2008 qui affiche en clair le mot de passe utilisé pour se loguer.

Site : http://www.moonsols.com/ Twitter : msuiche

14:30 - 15:30 Full Process Analysis and Reconstitution of a Virtual Machine from the Native Host - James Butler, MANDIANT

Une présentation qui se rapproche très fortement de la précédente. Cette fois c'est sous Windows que ca se passe. Il fait l'historique des dispositifs hardware permettant un accès à la mémoire physique (PCI, bus DMA, PCMCIA, ...). Ensuite les méthodes software (BSoD, \.\DebugMemory, ...). Il n'est plus possible aujourd'hui depuis un processus userland d'avoir accès à la mémoire physique (Doh!). Outils : Windd (Matthieu Suiche), Memoryze (MANDIANT). Description du mécanisme de translation d'adresse mémoire sous x64. Des pages de débogueur kernel Windows.

VMSafe (disponible dans VMWare vSphere) fournit de l'introspection de la mémoire et de l'état des CPUs, du filtrage des paquets réseau, monitoring et contrôle complet des processus, montage des filesystems depuis le guest sur le host. XenAccess tente d'implémenter les même fonctions.

Démo. Son outil se branche sur une machine virtuelle VMWare en cours d'exécution (un guest Windows). Il se branche sur le fichier .vmem que VMWare utilise pour ses machines en cours d'exécution. Donc, outil est vraiment poussé, beaucoup de choses sont explorés dans la mémoire des processus.

Vraiment trop orienté Windows internals, je n'ai pas vraiment suivi (désolé Charles). L'orateur n'était pas aussi didactique que le précédent.

15:30 - 16:00 Break

16:00 - 17:00 Through the Looking Glass: An Investigation of Malware Trends and Response Activity - Jeff Williams, Microsoft

Historique de la détection des botnets. Puis zoom sur le malware Win32/Waledac. Il parle de la bêtise des utilisateurs qui cliquent sur n'importe quel lien. Waledac installe aussi automatiquement d'autres malwares une fois la machine infectée. S'ensuit une énumération d'autres malwares ainsi que leur distribution à travers le monde. L'idée est que chaque botnet est distribué de manière différente à travers le globe. Certains sont plus répandus en Russie, d'autres en Chine, d'autres encore aux États-Unis.

Tous les botnets n'utilisent pas le même canal de C&C : IRC, HTTP, P2P, autre.

Waledac est un acteur majeur de production de spam. Son canal de C&C se base sur différents protocole : HTTP, P2P et l'architecture est basé autour d'une structure hiérarchique de type fast-flux DNS. Tous les domaines sont en .com. Microsoft a bossé avec Verisign (gestionnaire des .com) et les forces de l'ordre pour couper ce botnet. Ce botnet possède un middle-tier pour masquer la tête du réseau. Cette opération s'est appelée "Operation b49".

Cela a créé un précédent : le shutdown de certains domaines. Pour la première fois, on a montré qu'un botnet basé sur du P2P pouvait être contrôlé par une autre personne que le hurder.

Maintenant, grâce aux enseignements de cette opération, Microsoft lance le projet MARS (Micrososft Active Response for Security) pour couper le plus de botnet possible. Des centaines de milliers d'heures de ressource humaines sur ce projet.

Présentation était très courte et sans détails techniques, en forme de "Microsoft sauveur du monde".

17:00 - 18:00 The Jedi Packet Trick takes over the Deathstar: taking NIC backdoors to the next level - Arrigo Triulzi, Independent Security and Networking Consultant

Le speaker est loin, il est connecté via Skype. Talk originellement donné à PacSec 2008. Il a découvert par hasard que le NIC faisait du checksum offloading. Il s'est posé la question : peut-on en tirer quelque chose ? Il utilise une carte Broadcom (Tigon, basé sur un processeur MIPS), avec un firmware téléchargeable sur le site du fabriquant. L'idée est d'implémenter une attaque depuis une carte NIC1 vers une carte NIC2. Une carte n'a pas l'habitude de gérer une attaque venant de l'intérieur. Via PCI-to-PCI. Comment créer un rootkit directement dans une carte ?

Pré-requis : - NIC1 pour communication externe - NIC2 pour communication interne - nVidia GPU (on dirait que l'attaque repose en grande partie sur le fait qu'il y ait un kit de développement nVidia) - EFI BIOS

nicssh utilise plusieurs fonctions : findnic pour trouver une autre carte en scannant le bus PCI. grabnic pour injecter un firmware sur une carte vulnérable. forward pour mettre en place du forwarding de paquets. Il y a aussi nicfw (le firmware modifié).

La possibilité de faire du remote update nécessitait des droits admin. Cela fonctionne en envoyant un WOL suivi d'un message UDP dans un format particulier. Mais pousser un firmware via UDP est risqué, on risque de perdre des morceaux.

En gros, il injecte un nouveau firmware à distance, et ouvre un shell sur la carte réseau ...

Amélioration suivante, utiliser un module EFI pour charger nicssh 2.0 sur la NIC. Ce module chargera le nouveau firmware et installera nicssh sur le GPU. Le but final étant d'obtenir la persistance pour se protéger contre le re-flashing de la NIC. Le module EFI est stocké dans le SATA pour gérer ca.

Ces problèmes de sécurité viennent de failles crypto, d'une mauvaise gestion des clés (PKI FAIL). Une autre idée est d'utiliser les ucode pour mettre à jour les CPU (les errata). Les updates de ucode ne sont pas persistantes lors des reboots. EFI est encore la solution. C'est encore du work-in-progress, plein de choses sont encore à explorer dans ce domaine.

18:00 - 19:00 C8H10N4O2 and C2H6O (and teardown)

lundi, avril 12 2010

Compte-rendu CanSecWest 2010 - jour 2

Thursday March 25

09:00 - 10:00 SEH overwrite and its exploitability - Shuichiro Suzuki, Fourteenforty

SEH overwrite est la méthode d'exploitation principale pour les programmes sous Windows. Il existe des méthodes de protection (DEP, SEHOP, SafeSEH). Sont-elles suffisantes ? SEH est le système de gestion des exceptions employé sous Windows. Il y a une liste chainée dans la pile. C'est une liste chainée gérant les exceptions. Le classique stack overflow permet de ré-écrire le pointeur d'entrée de la liste des exceptions. Suivi d'une description de la callstack quand une exception survient. Description de SafeSEH. Et d'une faiblesse de SafeSEH. Il existe encore une zone exécutable dans la protection SafeSEH, et le but est de l'utiliser. Il passe ensuite aux faiblesses de SEHOP (SEH Overwrites Protection). Une autre protection nommée Hardware DEP empêche l'exécution de code dans l'attribut exécutable. Il y a aussi l'ASLR qui a de nombreux impacts sur SEH. Il passe à l'explication du contournement de ces protections. L'idée pour contourner SEHOP est de reconstruire une chaine de gestion des exceptions valide. Pour contourner le Hardware DEP, il utilise des méthodes de type return-into-libc et de return-oriented programming. Ne pas perdre de vue qu'on parle d'un stack overflow, et donc ces techniques fonctionnent.

Liste des choses a faire : - re-créer la chaine SEH (bypass SEHOP) - ré-écrire l'exception handler address dans un module non protégé SafeSEH - créer une pile pour exécuter le code voulu (bypass Hardware DEP) => utilisation de memcpy() pour ensuite placer un code ou on veut ...

Demo sous Windows 7. Bon, il nous lance un débogueur, et fait de l'exécution pas à pas pour bien tout comprendre sur un programme vulnérable.

ASLR rend difficile la création d'une chaine SEH valide. Il rend aussi difficile de trouver les instructions utiles à une adresse fixe.

Conclusion : cette présentation demande de fortes compétences en exploitation de failles sous Windows. Sans ca, c'est difficile de comprendre les tenants et les aboutissants. Pour terminer, il donne un tableau des conditions d'exploitation en fonction des différentes protections.

10:00 - 10:30 Second Breakfast

Je reconfigure ma carte WiFi qui a décidé de ne plus fonctionner :/ Mise en place de connexion sur le bon AP, établissement de mon tunnel SSH préféré avec du DynamicForwarding pour éviter tout risque d'écoute de mon trafic. Vive les serveurs dédiés sur Internet.

10:30 - 11:30 There's a party at ring0, and you're invited. - Julien Tinnes & Tavis Ormandy, Google

Ils bossent dans l'Information Security team de Google. Il y a du sandboxing dans Google Chrome et Android. Le talk est a propos du kernel comme cible des attaques de type local privilege escalation. Deux types de bug kernel : memory management corruption et bug de logique. Exemple de bugs de logique : CVE-2001-1384, CVE-2003-0123. Exemple de bugs de mémoire : CVE-2003-0961. En milieu kernel, on contrôle tout l'espace d'adressage, on accède à la complexité de gestion de l'espace mémoire. Exploiter le kernel sert par exemple à : sortir de chroot(), contourner les MAC, contourner les vserver. Pour bien se protéger, il vaut mieux utiliser un suite de protection kernel comme grsecurity. Avant, ce genre d'attaque n'était pas très répendues sous Windows, mais cela change. Très peu de remote kernel exploits pour Linux (publics en tout cas). Certains bugs sont exploitables en remote via le Web browser (exemple : faille dans le driver nVidia). Grande surface d'attaque pour le kernel : ioctls, devices, kernel parsers. Filesystems, network protocols, format des exécutables ... Demo orientée kernel Windows. Ils ont trouvé un moyen de placer le bit supervisor à 1 en exploitant une faille. Ce qui donne un accès au mode Virtaul-8086 (ring0?). GDI a été deplacé du userland vers le kernelland pour des raisons de performances. Mais le GDI est ce qu'il y a de plus simple à exploiter à distance. Par exemple via IE, en accédant aux fonts (TTF) qui sont gérées via GDI. Description d'une faille dans le parsing des fonts TTF (donc, code exécuté en ring0). Description de l'exploitation des NULL pointer dereferences sous Linux. Exemple d'une faille découverte par eux : CVE-2009-2692. NULL pointer dereference en local via sock_sendpage. sock_sendpage à un modèle de fonctionnement fragile, puisque nécessite la MAJ de tous les modèles si on modifie certaines fonctions pointées dans la structure proto_ops. Par exemple, pour une faille, une structure était initialisée à NULL. Il suffisait de placer son shellcode à NULL pour qu'il soit exécuté au lancement. Puis ils ont trouvé un autre bug de même type : CVE-2009-2698 dans udp_sendmsg. Suivi d'un exemple d'exploitation pour fasync, une faille de type use-after-free. Suivi d'un exemple d'exploitation sous NetBSD. Explication sur la syscall interface sous Windows : compliquée, instable, et non documentée. Vaste aussi (300 sous Linux). Normalement seulement utilisé par du code Microsoft. Les syscall sont très vulnérable au fuzzing car peu résistants aux mauvaises entrées. Et comme le kernel parse des fonts, des pixmaps, la syscall interface est un excellent candidat au fuzzing. Plus facile de trouver des bugs en fuzzant la syscall sous Windows sur sous Linux. Solution pour se protéger contre les privileges escalation : TPE (Trusted Path Executables). Facile à contourner sous Linux, à moins d'utiliser grsecurity. Gagne en popularité sous Windows. Pour contourner cette protection; on peut utiliser des failles dans des programmes interprétés (Python, Perl, ...). Autre solution : le sandboxing, à base de chroot() et de ptrace() (lent et difficile à mettre en place). SECCOMP-based sandbox aussi (sera peut-être implémenté dans Chrome-Linux). Mais si on ne peut protéger le kernel, l'utilisation de la virtualisation peut être une alternative. Une autre bonne protection pour le kernel Linux est l'utilisation de PaX, qui utilise des techniques de limitation de permissions dans le kernel.

Conclusion : Si le kernel trust une donnée userspace, une faille de sécurité de type escalade de privilège existe. Cela vaut pour l'existence d'une donnée, mais aussi pour l'absence d'une donnée. En gros, c'était une liste d'exemple d'exploitation de bugs kernel sous Linux et Windows. Tavis est plus Windows, et Julien plus Linux. La surface d'attaque kernel est grande et grossit de plus en plus. De plus en plus facile à atteindre en remote. La difficulté d'exploitation va de simple à très dur. Les technos de prévention d'exploitation en kernel sont aujourd'hui immatures. En gros, les sandbox c'est bien, mais il y a toujours une surface d'attaque depuis la sandbox vers le kernel qu'il est difficile de protéger.

Lien : http://blog.cr0.org/2010/03/theres-party-at-ring0-and-youre-invited.html

11:30 - 12:30 Babysitting an army of monkeys: an analysis of fuzzing 4 products with 5 lines of Python - Charlie Miller, Independent Security Evaluators

Fuzzing de 4 produits en 5 lignes de Python. Fuzzing de PDF (Preview et Acrobat Reader). Fuzzing de PPT (OpenOffice et PowerPoinet). Dumb fuzzing : faire des modifications sur un fichier correct. Smart fuzzing : utiliser des entrées créatives "from scratch". Compromis : utilisation de dumb fuzzing avec de nombreux fichiers différents. Idée : avec suffisamment de fichiers en entrée, on peut couvrir une grande surface des fonctionnalités offertes par le format. Mais toujours la limitation du CRC et de la compression sur ces fichiers.

Méthodologie : - download de plus de 80 000 fichiers PDF depuis Internet. - Acrobat Reader + Valgrind sous Linux pour mesurer la couverture de code. - réduit à ~1500 fichiers

Le fuzzer de 5 lignes: - change juste des bytes au hasard par des valeurs prisent au hasard. - ne rien supprimer, ne rien ajouter.

Utilisation de son framework de fuzzing parallèle (Tiamat). Scripté par AppleScript et monitoring du CPU pour savoir quand lancer le fichier suivant. Enregistrement des crashs répétés. Utilisation de libgmalloc (comme libefence) pour détecter les heap overflow sous Mac OS. Utilisation de memcheck (outil Valgrind) pour simuler l'exécution de programme et enregistrer les opérations mémoire invalides. Détection sous Linux. Crashwrangler classe les bugs en disant si ils sont exploitables ou pas.

Le fuzzing est une histoire de filtrage. Filtrage des résultats pour les classer en crash, exploitables, ... Recherche des crashs donnant des EIP uniques grâce à libgmalloc et Valgrind. S'ensuit une liste de chiffres sur le classement, et le nombre de bugs exploitables au final. Lancement de plus de 3 millions de tests depuis 1500 fichiers PDF.

Plus on fuzz un fichier unique, plus on trouve de faille exploitables: 500 => 1; 1000 => 2; 1500 => 3; 2000 => 4; ...

Ensuite même chose, mais contre Preview (viewer PDF sous Mac OS). Ensuite même chose, mais contre les fichiers PPT d'OpenOffice. Ensuite même chose, mais contre les fichiers PPT d'Office.

L'orateur a fini par faire un check lui-même pour vérifier l'exploitabilité de ce qu'il a trouvé. Il est souvent d'accord avec le résultat de Crashwrangler. L'autre programme pour tester s'appelle !exploitable et donne des résultats moins fiables.

Conclusion : plus on fait d'itérations sur ces 5 lignes de Python, plus ou trouve de bugs exploitables. L'idée intéressante ici était de prendre des fichiers valides, et de modifier 1 byte de manière aléatoire dans chacun de ceux-ci, et d'itérer sur chacun un grand nombre de fois pour avoir le plus grand nombre de fichiers de fuzzinga différents. Mais l'orateur arrive à une conclusion étonnante : les outils qu'il utilise ne sont pas doués pour détecter les erreurs et l'exploitabilité ... Beaucoup de chiffres affichés, difficile de tirer une conclusion claire.

ooo Un gars éteint son ordinateur portable sous Windows. Je vois l'écran de mise à jour : 72 patchs restants ... ooo

12:30 - 13:30 Lunch

13:30 - 14:30 ShareREing is Caring - Halvar Flake and Sebastian Porst, zynamics GmbH

EScript.api (Adobe Reader JavaSript Engine). Le talk est a propos d'un plugin IDA Pro nommée BinCrowd. BinCrowd a permis de détecter que c'est en fait l'engine SpiderMonkey qui est derrière EScript.api. Cela a été possible sans le code source associé.

L'idée est de trouver les programmes intégrant les mêmes bibliothèques non-dynamiques dans leur code. Ainsi, si on trouve une faille dans un programme A qui intègre une bibliothèque vulnérable, on peut trouver les autres programmes qui ont aussi cette faille.

S'ensuit une description de l'algorithme permettant l'identification de duplication de bibliothèque. C'est une fonction de hash pour un graphe. Ainsi, une comparaison numéraire est possible. Mais en fait, a l'usage, cela se montre trop limité, et il est nécessaire de développer un algo pour gérer un callgraph complet avec les adresses de fonctions associées.

BinCrowd est aussi une solution pour faire du RE entre équipes qui ont un différent niveau d'accréditation. Les données sensibles ne peuvent être transmises entre équipes qui ne possède pas le même niveau. Ainsi, il est possible de partager le travail, mais pas les données sensibles. Cela fonctionne comme un middleware, avec une base de données centrale, et un contrôle du transfert des informations.

Tout le monde peut utiliser BinCrowd, le plugin (opensource?) ainsi qu'un compte sont nécessaires.

14:30 - 15:30 Cisco IOS Exploitation with IODIDE - Andy Davis, KPMG

Il fait de la rechercher sécurité chez KPMG en Angleterre. IODIDE est un IOS débogueur et un Integrated Disassembler Environment écrit en Python. Il communique avec IOS via le remote gdb intégré. Il a une interface graphique. S'ensuit une explication du fonctionnement du gdb Cisco (qui varie au niveau du remote protocole par rapport à celui d'un gdb standard). Le gdb Cisco ne supporte qu'un nombre limité de commandes. On peut s'y connecter via IP où un accès port série.

Démo.

Grâce à cet outil, on peut utiliser un débogueur ressemblant à OllyDbg pour voir l'état des registres, les exceptions, l'état de la pile, ainsi que le code désassemblé ... le tout en remote. Le débogueur a vraiment l'air puissant. Recherche de données en mémoire. Obtention de la liste des process. Affichage de la configuration Cisco actuelle. On peut aussi modifier les registres et la mémoire. L'environnement de désassemblage est pas mal non-plus, il permet d'ajouter des commentaires de manière simple.

Ensuite un historique des failles IOS. Stack et heap overflows. Format string (mais seulement fuite d'information, pas de %n chez IOS). Mike Lynn a été le premier à créer un shellcode pour IOS (un connect-back shellcode) mais qui n'a jamais été diffusé.

IOS est un gros binaire ELF dont toutes les fonctions ont des adresses différentes en fonction de la version d'IOS. Le processeur est du PowerPC. Identifier la version exacte est très difficile. Si l'ont utilise une adresse incorrecte lors d'une tentative d'exploitation, le router reboute.

Étude de cas sur une faille dans le serveur FTP. Un stack overflow dans le verbe MKD. S'ensuit une explication de l'exploitation des stack overflow sur architecture PowerPC. L'équivalent de EIP sous x86 est ici LR (Link Register). L'adresse que nous souhaitons utiliser pour lancer le shellcode se retrouvera dans le PC (Program Counter).

Le shellcode devra supprimer le prompt pour un password au login, et donner un accès "level 15" équivalent à root. Et surtout, sortir de manière propre sans crasher le routeur. Pour supprimer le password prompt, il écrit la valeur 1 à un offset. Pour accroitre les privilèges, il écrit la valeur 0x1f000000 à un autre offset. Pour sortir de manière propre, il fait l'équivalent d'un kill(-1), pour se tuer lui-même. Mais ca ne coupe que la connexion, pas le service FTP.

Il a diffusé un shellcode (cassé) en juillet 2008. Maintenant, il utilise un méthode return-oriented programming. Il utilise le propre code PowerPC pour écrire une adresse où il veut. En 2 paquets, il obtient la suppression du password prompt, et l'élévation de privilèges. Mais il utilise des adresses hard-codées.

Utilisation du syscall #34 pour accéder à la chaine de version IOS. Utilise la fonction send() pour retourner l'info via la socket ouverte.

Démo. Via IODIDE (Exploit Edition), il exploite la faille. Pas mal.

Conclusion : excellent outil de débogage et désassemblage. A mon avis excellent pour écrire des exploits IOS. Pas grand monde fait de la recherche sur l'exploitation IOS; plein de boulot en perspective dans le domaine. IODIDE ne supporte que PowerPC pour le moment. Il sera releasé en open source (mais pas l'Exploit Edition).

15:30 - 16:00 Break

16:00 - 17:00 Random tales from a mobile phone hacker - Collin Mulliner

Checheur en sécurité sur les appareils mobiles. Tout ce qui possède une carte SIM.

Découverte de fuite d'information et exploitation à l'aide d'URI "from hell" principalement. Tout d'abord fuite d'information par connexion à des sites Web via le navigateur intégré au téléphone mobile. Aujourd'hui les téléphones ont un vrai navigateur (WAP est mort), et l'accès au Web est populaire.

- MSISDN : numéro de téléphone. - IMSI : SIM card ID - IMEI : phone ID

Rumeur : certains téléphones feraient fuir des infos privées via les en-têtes HTTP. Du coup, il a mis un place un logging systématique des en-têtes HTTP sur son serveur Web qui est assez populaire. Il peut collecter des données pour vérifier. Quelques exemples : - Rogers : opérateur Canadien révèle le MSISDN. - H3G Italie : révèle aussi le MSISDN. - Vodafone aussi. - Orange UK aussi, et bien plus encore. - Pelephone, Israel, fait fuir le MSISDN, l'IMSI et l'IMEI clairement dans les en-têtes.

Et l'énumération continue, c'est l'hécatombe. Certains encodent l'info en Hex ^^ D'autres infos souvent remontées : customer ID, point de connexion (APN).

Apparemment, les téléphones n'ont pas ces infos, elles sont donc ajoutées par un proxy/gateway de l'opérateur. Le sujet des Web proxy de téléphones semble compliqué.

Démo. Une liste d'information capturées avec des statistiques.

L'orateur trouve étonnant que ces fuites d'informations n'aient pas eu une plus grande attention médiatique.

L'orateur fournit un lien pour valider son opérateur (sans qu'il ne logue, rires) : http://www.mulliner.org/pc.cgi

Ensuite on passe au hack du Kindle. Il possède une carte SIM qui marche sur tout téléphone, mais sans voix ni SMS. On peut seulement accéder au net via un proxy hardcodé chez amazon.com. Le trafic est rejeté si il ne vient pas du navigateur du Kindle. Mais comment ? Utilisation de privoxy (ou Modify Header) pour ajouter un en-tête x-fsn. L'outil Tethering implémente ca. Le hack permet un accès complet à Internet.

Ensuite il passe a Digital Picture Frame (HUAWEI DP230). Il a un modem et une carte SIM et un numéro de téléphone ... Désossage, branchement sur le port série puis accès shell (admin:admin). Il peut recevoir des SMS et possède un accès GPRS. Un SMS en XML permet de modifier la conf de l'appareil, comme par exemple modifier l'image de fond. Il doit par contre être originaire d'un numéro spécifique. Spoofer ce numéro est assez facile. Des services en ligne le fond pour pas cher. C'est le download des binaires qui a permis de reverser ce fonctionnement.

Quelques attaques: - désactiver l'accès Internet "<req><GPRS apn="brick"/></req>" - effacer toutes les images

Conclusion : les numéros assignés par les opérateurs sont guessable. On peut bricker tout un parc de machine de ce genre en brute-forçant un petit espace de numéros.

Il passe ensuite sur les cartes pré-payées. Quand le compte est vide, le trafic est redirigé vers un portail Web pour la recharge. On peut faire du DNS tunnel comme ca ^^ mais c'est identifiable par l'opérateur à cause de la nécessité d'avoir un endpoint DNS. Ça reste du tunnel DNS sur une connexion 3G, les performances ne sont pas super.

Maintenant les URIs from hell : des protocoles spéciaux implémentés dans les navigateurs des téléphones. C'est facile de faire crasher un téléphone avec du JavaScript embarqué dans un site Web malicieux, les téléphones trouvant automatiquement les URI qui les intéressent. Pour l'iPhone, une attaque permet le lancement d'un appel automatique via un iframe et un URI de type "sms:" ou "tel:" (<iframe src="sms:numéro" ...>). Avec une chaine trop longue dans le "sms:" URI, le téléphone freeze (CVE-2009-0961). Pour l'instant, ca fait juste apparaitre la fenêtre d'envoi de SMS ou d'appel. Pas d'automatisation possible.

Conclusion : il n'y a pas que les smartphones dans la vie, il faut penser aussi aux simples? téléphones, aux réseaux des opérateurs mobiles et au "Consumer Electronics Devices".

17:00 - 18:00 Legal Perspectives of Hardware Hacking - Jennifer Granick, EFF

Présentation orientée lois aux US. Mais utile, car si on enfreint les lois US depuis un autre pays, on peut être poursuivi en posant les pieds chez eux (en gros). L'EFF travail sur le droit des développeurs, sur les DRM, ...

Nouveauté : accéder à du software embarqué viol le DMCA.

Elle n'aborde pas les violations de brevets, ni les "trade secrets". Les présentation est donc orientée violation du DMCA. Quelques exemples : iPhone jailbreaking, calculatrices TI, Kindle Souvent, les attaques s'articulent autour de la signature des composants (la chaine de confiance TPM). Et donc à une attaque ciblée sur les clés de signature. Pour le Kindle, c'est une méthode pour contourner le DRM.

Note : pour la calculatrice TI : la clé privée est dérivée de la clé publique :) Le fait que les clés de signatures soit faibles n'entre pas en compte lors d'une poursuite judiciaire.

Ce qu'il faut retenir : - éviter de cliquer pour accepter le EULA - avoir l'autorisation du fabriquant du produit - et d'autres encore.

Un talk sur la légalité que je n'ai pas vraiment suivi.

Question ouverte : pourquoi dans toutes les conférences de sécurité, la seule femme qui présente parle des aspects légaux ?

18:00 - 19:00 Lightning Talks - Various

ooo La fille qui s'occupe de faire le gong entre les talks boit une bière. Elle prend une pause comme dans une pub. D'ailleurs, les gens qui font un lightning talk ont le droit à une bière. ooo

- CSP (Content Security Policy) - URL shorteners (utilisation d'encoder de shellcode alphanumeric pour les URI véhiculant un exploit genre smb://long_string, et on place dans un URL shortener, et ca passe) (Saumil Shah) - Waledac Botnet (Thorsten Holz) Attaque Sybil pour couper une partie du réseau P2P. - 2600 Hz or not, Jon Van Boxtel

Saumil gagne le prix du meilleur talk.

20:00 - 1:00 Party Venue TBA

lundi, avril 5 2010

Compte-rendu CanSecWest 2010 - jour 1

Wednesday March 24

La matinée de cette première journée est consacrée à l'enregistrement des participants. Environ 500 personnes présentes dans la salle.

13:00 - 14:00 Internet Nails Marcus Ranum, Tenable

Une histoire de bad software engineering et de bad design ; où comment une petite erreur de design peut couter très cher. En 1971, FTP est inventé et codé. Les premières versions de transport d'email était faite via FTP. En 1976, NCP. Qui était l'ancêtre de TCP. Fonctionnement a sens unique, pas encore de full-duplex. Suivi d'une explication sur le fonctionnement de FTP.

Question clé : peut-on parler de design pour FTP dans un monde de software a cet époque ?

Puis, description sur la difficulté de faire fonctionner FTP au travers d'un firewall. Blabla sur l'introduction des firewalls. Le premier produit commercialisé en 1991 coutait $175,000. L'idée est que le design de FTP de l'époque coute des millions aujourd'hui, a cause de la difficulté de filtrage de ce protocole au niveau firewall. Puis une autre histoire : pour décharger le noyau, les Sockets BSD furent introduit. Le but était d'accepter un plus grand nombre de connections. Mais il fallait garder une table des sockets ouvertes, et cela n'a pas protégé contre le SYN flooding. En 1995, le protocole HTTP a été imaginé pour être stateless, aussi pour décharger le noyau. HTTP fonctionne en ouvrant de nombreuses connections TCP short-lived. Ce fut lent, et les codeurs de navigateurs Web décidèrent de faire ces connections en parallèle ...

Résultat : du surf plus rapide, mais plus de load sur le réseau et le serveur.

Aujourd'hui, on a amélioré le code gérant les short-lived connections pour résoudre ces problèmes. En 1997, le E-commerce. Problème avec HTTP, aucun état n'est maintenu, et c'est devenu nécessaire (gestion de l'authentification, garder la liste des courses ...). Ainsi des frameworks de développement furent introduit pour garder l'état des connexions via un session management. Tout cela, parce que HTTP a été designé pour être stateless. Quel coup pour tout ceci ? Sans compter les erreurs de codage menant à toutes les failles que l'on connait. Vient ensuite la gestion de la charge. Chaque load balancer doit garder l'état pour savoir où rediriger les requêtes et éviter de briser l'état de la session. Tout cela alors que TCP/IP sait déjà gérer l'état d'une session ... et en plus de ré-implémenter une gestion de session, nous avons de nouvelles classes de vulnérabilités (XSS, XSRF, ...).

Conclusion : un mauvais design coute extrêmement cher. D'où l'idée de développer le "design intelligent" mais par un visionnaire omniscient. Le soft est au coeur de tout, on doit faire mieux, être moins concernés par le "backward compatibility" et être plus au fait des conséquences d'une petite décision de design.

14:00 - 15:00 Under the Kimono of Office Security Engineering - Tom Gallagher & David Conger, Microsoft

Respectivement Senior Security Test leader et Software Design Engineer. Historique des menaces : macro virus principalement. Avant 2006, tèrs peu d'attaques sur le format des documents eux-même. Quand Microsoft a vu que les failles commençaient a être commercialisées, ils ont décidé d'investir pour éviter les failles dès le début. Nouvelles organisation : chaque produit à une liste de contacts sécurité. Chaque produit à une liste de feature owner.

1. Harden the attack surface : suivre le SDL, automatiser la revue de code, SafeInt?, suppression des vieux parseurs (exemple : 3 parseurs différents pour JPEG), fuzzing distribué (300+ formats de fichier à supporter, certains n'étant pas simples et nécessitant des fuzzers particuliers). Suivi d'une explication sur le fuzzing distribué, qui pourrait être utilisé pour les tests en général. L'idée est de centraliser la gestion du fuzzing : les tests, les résultats, les erreurs et les rapports. Le but est aussi de répartir la charge pour exploiter les machines non utilisées. Microsoft a developé un client de fuzzing distribué facile à utiliser par tous les dveloppeurs. Un serveur avec interface Web centralise le tout. Une fonction intéressante permet de re-tester contre les régressions, en prenant par exemple une call stack d'erreur en input. Également la possibilité de tester les même bugs sur différents produits. Pour chaque bug trouvé, toutes les infos sont disponibles (état des registres, call stack complète ...). En gros, ils ont fait un botnet sur leur réseau qui sert à faire du fuzzing. Ils ne se posent pas la question de l'exploitabilité d'un bug quand ils en trouvent un, ils le patch (au minimum, ca rendra le produit plus stable).

2. Reduce the attack surface : File Block (exemple: bloquer les formats non utilisés) et Gatekeeper (évaluation de la 'correctness' des fichiers à l'ouverture, avec mécanisme de mise à jour des informations de 'correctness'). Demo. En gros, ils ont mis un anti-virus dédié aux formats de fichier dans Office.

3. Mitigate the Exploits : Création d'un Office 'Protected Viewer' qui classe toutes les sources venant d'Internet comme untrusted. Architecture avec un processus Host et un processus Client. Utilise des composants de sandboxing (isolation des processus). Ceci est géré par wwlib.dll, qui lance une instance de winword.exe dans une sandbox.

4. Improve the User Experience : l'améliorer en rapport avec la confiance. A l'avenir, en prenant l'exemple de l'ouverture d'un attachement mail : Open > Gatekeeper Validation > Sanboxed Viewer > User Clicks enable > Document Opened. Ensuite, le user peut le sauvegarder, et le rouvrir sans ces checks. Option très intéressante pour regarder les "conneries" envoyées par les potes, les documents sont vus dans la Sandbox, et ne doivent pas pouvoir abimer le système (exemple pris tel quel par l'orateur).

Conclusion : Ils ont d'abord décris un processus de tests bien fait, pas forcément orienté uniquement sécurité. Ensuite, ils ont décrits les améliorations apportées à Office qui elles ont été pensées pour la sécurité.

15:00 - 15:30 Break

Quelqu'un s'est amusé à broadcaster le SSID "CanSecWest". C'était évidemment un faux.

15:30 - 16:30 Automated SQL Ownage Techniques - Fernando Federico Russ, Core

Description d'une méthode blackbox automatisée d'intrusion SQL. La vulnérabilité est exploitée de manière à éviter les "False Positives". Première étape de reconnaissance. Un web spider utilisant un MitM proxy. Reconstruction des QUERY_STRING et parfois du chemin de l'URL (cas mod_rewrite). Parcours aussi les champs HTML <form>. Fonctionne en mode fuzzing, et peut potentiellement abimer l'application. Détection des erreurs (HTTP error codes, error strings, redirections ...). Pour déterminer la présence d'une injection, une liste de test retournant true/false est jouée. Si true, alors on contre-test par une autre méthode pour confirmer. C'est une technologie de type système expert. Une autre fonction est de déterminer le type de la base de donnes (produit, version). La méthode retenue : du brute-force sur les fonctions possibles (HEX() pour DB2, HOST_NAME() pour SQL Server, VERSION() pour MySQL, ...). L'implémentation tourne autour d'une couche d'abstraction nommée "channel". Elle fournit une API (UNION, Scalar, Blind, ...).

ooo Le téléphone rouge sonne, Charlie Miller semble avoir exploité avec succès une faille dans l'iPhone. Il gagne un truc ^^ ooo

L'outil permet de savoir si la requête exploitée est de type SELECT. Il détecte la morphologie (nombre de colonnes, leur type, la visibilité dans le HTML, ...). Un exemple d'utilisation : remplacer la vrai requête par la notre (SELECT user,pass FROM credentials). Pour que cela marche, il faut détecter le nombre d'élément de la requête d'origine (ici 2), et leur type (ici string). Si c'est le cas, nous pouvons construire la requête de l'exemple. Si les types ne sont pas les mêmes, on peut utiliser des fonctions pour "caster" les valeurs. Pour extraire toutes ces informations, une requête SQL CASE est utilisée (CASE WHEN ... THEN ... ELSE). Mais cela permet uniquement d'extraire bit par bit (un bit étant true/false).

ooo Le téléphone rouge sonne de nouveau, une nouvelle faille a été trouvée (IE? 64-bit). ooo

16:30 - 17:30 Can you still trust your network card? - Yves-Alexis Perez & Loïc Duflot

Yves-Alexis et Loïc travaillent pour l'ANSSI (Agence Nationale de SSI). Tout type de carte réseau. Leur hardware est complexe (plusieurs processeurs, différents types de mémoire, ...). Leur firmware est complexe (gestion de la segmentation TCP en offloading, remote management, ...). Ça n'a rien a voir avec les bugs drivers ou les vulnérabilités de l'OS. Description de l'architecture. PHY (send/recv sur le réseau), DMA-engine (send/recv sur le bus interne), negociation and link control (full-duplex, ...). Explication pour la carte Broadcom intégrée sur certains NIC. La carte possède un processeur MIPS, le firmware permet une customisation pour processer des paquets propriétaires par exemple. La mémoire interne de la carte est mappée sur la mémoire de la machine hôte. Protocole ASF. La carte réseau reçoit les évènements des autres devices de la machine via SMBus. Utilisation du protocole RMCP pour rebooter et autres actions ... ASF n'a aucune interface sécurité de prévu, et les fabriquant ne sont pas vraiment incités à en faire.

ooo Le téléphone rouge sonne : Firefox sous Windows 7. ooo

ASF 2.0 ajoute un nouveau protocole : RSP. Des extensions sécurité pour RMCP, comme l'authentification et le contrôle d'intégrité. Mais pas de chiffrement. RMCP est en écoute sur 623/UDP. La version secure sur 664/UDP. Broadcom fournit un outil de configuration ASF. Ces paquets UDP ne sont jamais vu par l'OS, puisque interceptés par la carte réseau avant.

Vulnérabilité potentielle sur le protocole d'authentification (réduction de l'entropie). Problème d'implémentation sur le username (CVE-2010-0104), limité à 16 caractères sans null byte avec 1 byte pour spécifier sa longueur. Nécessité de déboguer la carte réseau par un débogueur de NIC (accès aux registres du processeur MIPS). Ils ont développé un débogueur NIC maison. Ils ont ensuite pu écrire un exploit pour la faille trouvée dans la gestion du champ username. Comme il n'y a que 255 octets (moins le padding) pour placer le shellcode de l'exploit, ils utilisent l'accès aux network buffers pour placer leur shellcode. En effet, le NIC est le mieux placé pour accéder aux network buffers. NIC utilise le DMA engine ; il peut donc lire et écrire la mémoire de la machine hôte. Un paquet réseau exploitant une faille peut donc être utilisé pour écrire des données dans la mémoire de la machine hôte sans contrôler son OS.

Suivi d'une démo sur l'amélioration de leur exploit : lancement des paquets RMCP exploitant la faille. Puis d'un message ICMP magique. Enfin, un rootshell en écoute sur le port 2 est activé. De plus, faire un ps sur la machine victime montre juste un shell, et un khelper (donc, attaque assez stealth).

Note : Le débogueur accède aux registres de la NIC via le driver local qui lui, à accès aux registres du processeur de la carte NIC via un mapping mémoire. Pas besoin de JTAG et compagnie.

Conclusion : Ce n'est pas encore le moment de paniquer. Peu de cartes supportent ASF, et encore moins l'ont activé par défaut.