Making network protocols go crazy

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

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.

Commentaires

1. Le lundi, juin 21 2010, 22:16 par Goulag PARKINSON

Ah bah merci de me griller ma couverture... encore bravo... Je pensais bien me cacher pourtant ;)

2. Le mardi, juillet 13 2010, 15:32 par GR

Mais qui êtes-vous donc ? :)

3. Le lundi, juillet 19 2010, 23:07 par Goulag PARKINSON

Même pas dur, tu vas sur http://www.paterva.com/ ensuite sur la page tu click sur le bandeau 2 (Locate, Aggregate and Visualize data) et tu regardes l'image. Bon allez, dans ma grande sainteté, je t'aide, directe l'URL de l'image http://www.paterva.com/web5/img/scr... .
Cela déchire quand même d'être profilé par maltego direct sur leur site. Trop bien.

4. Le vendredi, septembre 3 2010, 15:46 par GR

C'est beau.
Je suis sur que tu adores çà, en plus, te faire profiler :)