Making network protocols go crazy

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

Mot-clé - SSTIC

Fil des billets - Fil des commentaires

mardi, juin 15 2010

Compte-rendu SSTIC 2010 - jour 3

Par GR le mardi, juin 15 2010, 13:11 - Compte-rendu

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.

aucun commentaire

Compte-rendu SSTIC 2010 - jour 2

Par GR le mardi, juin 15 2010, 10:45 - Compte-rendu

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.

4 commentaires

lundi, juin 14 2010

Compte-rendu SSTIC 2010 - jour 1

Par GR le lundi, juin 14 2010, 15:06 - Compte-rendu

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.

aucun commentaire