Compte rendu de la conférence sécurité INSA-2016

Date : 07 Janvier 2016

Le 27 janvier 2016 s’est déroulée la troisième édition de la conférence sécurité organisée par l’INSA de Toulouse et le LAAS-CNRS. Six présentations ont été faites ce jour-là (le programme est disponible ici) sur des sujets comme la sécurité matérielle ou les vulnérabilités des protocoles sécurisés. Les présentations étaient en majorité techniques. Nous résumons ci-dessous cette journée.

 

"Véhicules connectés : le point sur la sécurité et la protection de la vie privée"

Par : Yves Roudier (Université de Nice Sophia Antipolis)

L’orateur présente un bilan sur les problèmes de sécurité dans les véhicules connectés et sur les solutions pour se protéger.

Depuis les années 70, les systèmes embarqués n’ont pas cessé de se développer. Aujourd’hui ils sont de plus en plus nombreux dans les véhicules modernes, et leur complexité s’accroit à tel point que l’on peut utiliser l’expression « d’ordinateur sur roue ».

Ces systèmes se déclinent depuis les applications de communication (internet, Wi-Fi, Bluetooth, NFC, …), de positionnement GPS, d’aide à la conduite (reconnaissance de signalisation routière) …, jusqu’aux systèmes de conduite autonome.

Tous ces systèmes embarqués, ainsi que les systèmes hors véhicules (systèmes de gestion du trafic routier, de guidage, de sécurité routière, …) constituent ce que l’on appelle les Systèmes de Transport Intelligent (ou STI).

A titre d’exemple l’orateur aborde en particulier les deux systèmes embarqués suivants :

  • Les services connectés :
    • L’Emergency call (ou eCall) est un système d’appel d’urgence automatique permettant à une voiture accidentée d’appeler les services d’urgence en donnant sa position (géolocalisation).
    • Le Breakdown call (bCall) est un système d’assistance automatisé dédié aux pannes automobiles.
  • Les communications entre véhicules, ou avec des infrastructures routières, reposant sur des capteurs à l’intérieur et à l’extérieur du véhicule, comme Car2Car (https://www.car-2-car.org/index.php) qui est un consortium européen regroupant des constructeurs automobiles.

Tous ces systèmes posent deux types de problèmes de sécurité :

De nouvelles solutions sont en cours d’étude pour cibler ces problématiques et protéger les systèmes embarqués. EVITA (« E-safety vehicle intrusion protected application » : http://www.evita-project.org/), est un projet européen dont le but est de concevoir des architectures sécurisées intra-véhiculaires.

Le nombre de véhicules connectés augmentant considérablement d’année en année, il est important que la cyber-sécurité devienne une priorité pour les constructeurs automobiles, pour intégrer dans les véhicules les moyens de protection qui existent déjà (tel que la détection de trames anormales, ou de module HSM, …) et contribuer à leur développement. Surtout dans la perspective du véhicule autonome, car une prise de contrôle à distance d’un véhicule peut créer de graves problèmes de sécurité.

 

"Regards critiques sur SSL/TLS"

Par : Olivier Levillain (ANSSI)

Après un court historique, l’orateur présente les protocoles de sécurisation SSL/TLS et les principaux problèmes qui les ont affectés.

Le protocole Secure Sockets Layer (SSL) a été créé par Netscape en 1994 dans le but de sécuriser les échanges sur internet. L’IETF a racheté le brevet et l’a renommé Transport Layer Security (TLS).

SSL et TLS sont donc deux variantes d’un même protocole permettant de sécuriser une communication entre un client et un serveur : confidentialité (chiffrage des échanges), intégrité des données échangées (fonction de hachage) sur le canal de communication, et authentification des parties (certificats).

La négociation entre un client et un serveur est composée d’un échange de plusieurs messages dans le but de s’accorder sur les algorithmes et les clefs à utiliser.

Depuis sa création, ce mécanisme de sécurité contient des failles et donc a souvent été attaqué.

Aperçu de différentes attaques ayant eu lieu ces dernières années :

  • Attaque sur SSL mise au point par Serge Vaudenay (2001), basée sur les temps de réponse des serveurs, et qui exploite une faiblesse de l’implémentation du remplissage dans le mode de chiffrement CBC,
  • Attaque « BEAST » (septembre 2011) qui exploite une faille dans les protocoles SSL 3.0 et TLS 1.0, et permet, via une attaque Man-in-the-Middle (MiTM), de décrypter les cookies HTTPS,
  • Attaque « Heartbleed » (avril 2014) qui exploite une vulnérabilité logicielle de la librairie OpenSSL, et permet à un « attaquant » de lire la mémoire d'un serveur ou d’un client pour récupérer, par exemple, les clefs privées utilisées lors d'une communication avec le protocole TLS,
  • Attaque « POODLE » (octobre 2014) qui exploite une faille de conception dans SSL v3, et permet, grâce à une attaque MiTM, d'abaisser le niveau de sécurité des connexions sécurisées par SSL/TLS pour casser le chiffrement SSLv3,
  • Attaque « Freak » (février 2015) qui exploite une faiblesse cryptographique dans le protocole SSL/TLS, et permet, via une attaque MiTM, d'abaisser le niveau de sécurité de la connexion en fournissant une clé RSA temporaire faible lors d'un échange de clés de chiffrement RSA,
  • Attaque « Logjam » (mai 2015) qui exploite une faiblesse dans l’algorithme d’échange de clés Diffie-Hellman (DH), et permet (comme FREAK), via une attaque MiTM, d'abaisser le niveau de sécurité de la connexion pour décrypter les communications.

L’analyse de ces failles permet de conclure sur la nécessité d’améliorer la qualité des tests logiciels à réaliser sur les protocoles avant leur mise en exploitation, et sur l’amélioration des développements logiciels notamment en se servant des fonctionnalités des compilateurs pour auditer la qualité du code.

L’arrivée de la version 1.3 de TLS devrait également apporter de nombreuses améliorations notamment sur la phase de négociation et sur la disparition programmée des procédés de cryptographie obsolètes (PKCS#1 v1.5, RC4, CBC).

 

"Fraude à la carte bleue : quand les truands lisent les rapports de recherche !" 

Par : Assia Tria (CEA, Gardanne)

L’oratrice présente le résultat d’une analyse forensic d’une fraude à la carte bleue (qui a eu lieu en 2011). Cette analyse a été faite à la demande de la justice qui a été saisie après que le GIE Cartes Bancaires ait porté plainte au vue des importantes sommes d’argent volées. Cette fraude, ainsi que les auteurs, ont été découverts grâce à l’arrestation d’un porteur de cartes falsifiées en France. Beaucoup de retraits illicites d’argent ont été effectués en dehors du territoire français notamment en Belgique.

L’équipe forensic a fait un premier travail d’analyse sur un exemplaire de carte falsifiée sans la détériorer. Cette analyse montre que cette carte est composée de trois parties :

  • Le corps en plastique de la carte,
  • La puce,
  • Un module FUN (carte ouverte programmable, contenant un microcontrôleur et sa mémoire interne) supplémentaire collé sur la puce.

Une analyse aux rayons X a permis d’identifier de minuscules soudures reliant des pattes du module FUN à certains connecteurs de la puce.

L’étude approfondie du mécanisme de la fraude (par une analyse Side Channel sur la courbe de consommation du courant lors des échanges de messages) montre que le module supplémentaire laisse passer une partie des communications entre la carte et le DAB, puis prend la main lors de la procédure d’identification du code PIN pour retourner systématiquement un code de vérification ok (code 9000). Il rend la main ensuite à la puce légitime de la carte pour finir la transaction.

Les auteurs de cette étude ont été très étonnés par la qualité du travail (qualifié d’orfèvre) de soudure et de montage en sandwich de tous ces éléments sur une épaisseur de carte de moins d’un millimètre. 

Cette fraude a (semble-t-il) exploité un article d’un chercheur anglais paru en 2010 (Mr Ross Anderson, professeur à l’Université de Cambridge) sur la possibilité de hacker les cartes à puce bancaire (https://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken.pdf).

Les fraudeurs ont rendu possible ce que l’article de Ross Anderson présentait comme une hypothèse d’attaque. Et grâce à beaucoup d’ingéniosité, ils ont réussi à miniaturiser ce que la présentation d’Anderson montrait comme un système électronique très encombrant, incompatible avec la discrétion nécessaire pour pirater un distributeur d’argent.

 

"Security Challenges in SDN/NFV 5G Networks"

Par : Kahina Lazri (Orange Labs)

Principes du SDN (Software Defined Networking) :

  • Séparation des Control et Data Planes.
  • Centralisation des fonctions de contrôle du réseau.
  • Standardisation des interfaces : protocole OpenFlow par exemple.

Principe du NFV (Network Function Virtualization) : Utiliser les technologies de virtualisation appliquées aux équipements réseaux.

Cela permet d'utiliser des VMs au lieu d'avoir des appliances physiques pour les fonctions réseaux.

La plupart des problèmes de Sécurité de ces modèles sont liés au contrôleur des équipements (centralisé) :

  • Ce contrôleur est un SPOF.
  • Si le contrôleur est compromis, alors le réseau entier l'est aussi.
  • Incohérences entre les "vues" réseaux des différents équipements (topologies, routage) en cas de problème.
  • Scalabilité (chez Orange un contrôleur peut gérer aujourd'hui environ 200 switchs).

Exemple d'attaque sur les réseaux SDN: Topology poisoning (Hong 2015 http://faculty.cs.tamu.edu/guofei/paper/TopoGuard_NDSS15.pdf)

Cette attaque utilise le protocole LLDP pour changer la topologie du réseau et provoquer une attaque Man-In-The-Middle.

 

"PayTV et protection de la propriété industrielle"

Par : Edouard et Mohamed (Groupe Canal+)

Les programmes chiffrés de Canal+ sont composés de deux types de flux :

  • Le programme lui-même (chiffrement faible).
  • Les données de contrôle qui servent notamment à déchiffrer ce programme (chiffrement fort).

La présentation considère le cas du piratage dit linéaire : pour voir la télévision en direct et non pour le téléchargement ou streaming par la suite.

Il existe plusieurs types de piratage :

  • Relais pirate : Un abonné Canal+ redistribue le flux déchiffré à des destinataires. L'inconvénient de cette méthode est la forte consommation en bande passante.
  • Card Sharing : Un abonné Canal+ redistribue les données de contrôle uniquement à des destinataires. Avec ce flux de contrôle, ces destinataires peuvent déchiffrer et donc visionner le programme.

Un audit de Sécurité a été réalisé sur le décodeur G5 (2010) et a révélé plusieurs problèmes :

  • Envoi en clair sur Internet du numéro de série de la carte de l'abonné.
  • Les identifiants et mots de passe de certains serveurs de collecte (utilisés pour les statistiques) sont visibles en clair dans des classes Java.
  • Une librairie contenue dans un module du décodeur est vulnérable aux attaques de type Buffer Overflow.

 

"Sécurité et matériel"

Par : Raphaël Rigo (Airbus Group Innovations)

Les PCs ont beaucoup évolué durant les 20 dernières années. Les PCs modernes ont du code dans différents composants : contrôleur clavier, écran, contrôleur réseau, Touchpad, carte graphique, etc.

Cette présentation expose l'impact des contrôleurs intégrés, de ce matériel qui contient du logiciel, et des fonctions type secure boot.

Exemple du BadUSB : Un chipset de clé USB a un firmware, qui peut être reprogrammé, et qui devient un vecteur d'attaque.

Techniques et étapes du reverse engineering :

  • "Gros" Embarqué :
    • Extraction du firmware.
    • Reverse des binaires.

Problème : Complications dues aux composants matériels potentiels (cryptoprocesseurs, etc.) qui sont de plus en plus présents.

  • "Petit" Embarqué :
    • Dump de la mémoire flash.
    • Sniff de bus.
    • "Décapping" de composants afin de réinitialiser les fusibles de protection, et pour permettre l'analyse et le reverse.

Exemple d'une étude réalisée sur un équipement : cas du disque dur chiffré Zalman VE400.

Ce cas a été présenté au SSTIC 2015: https://www.sstic.org/2015/presentation/hardware_re_for_software_reversers/

Premiers constats :

  • Le chiffrement est indépendant du boîtier. Un disque chiffré placé dans un boîtier Zalman neuf est accessible une fois le bon code PIN entré.
  • L'activation du chiffrement entraîne la création d'un blob binaire à la fin du disque.

Afin d'étudier le niveau de sécurité du disque, les étapes suivantes ont été suivies :

  • Etude des mises à jour : tout est chiffré, ce qui rend impossible le reverse de ces binaires.
  • Recherches sur Internet afin de trouver des informations sur les composants, les datasheet, ou des informations via des communiqués.
  • Etude du PCB (carte électronique) : Avec une photo de l'avant et de l'arrière de la carte, ce qui permet de comprendre les connexions entre composants.
  • Dump des mémoires.
  • Dump des contrôleurs.

Pour analyser plus en détail le PCB, la carte a été passée aux rayons X, ce qui permet de distinguer les connexions non visibles à l'œil nu entre composants.

La mémoire flash est connectée au contrôleur PIC32. Afin de lire cette flash, il a fallu la dessouder, puis utiliser un outil nommé GoodFET pour en récupérer le contenu. Mais le code récupéré sur la flash est aussi chiffré.

Ensuite, une analyse en mode "boîte noire" a été menée avec un analyseur logique Saleae Logic Pro 16 (oscilloscope pour signaux numériques).

Les échanges entre le microcontrôleur et le SoC permettent de récupérer le hash du PIN (hash de 64 bits). Mais ce hash (algorithme propriétaire) n'a pas pu permettre de retrouver le PIN.

Une analyse par "decapping" a été mené avec de l'acétone, ce qui a permis de voir les transistors au microscope. Pour voir sur plusieurs couches, il faut pratiquer le "delayering" en enlevant les couches de métal avec de l'acide fluorhydrique par exemple.

Ensuite, on peut faire une analyse de la structure pour comprendre la logique des composants avec un microscope optique ou électronique.

Conclusion :

Le reverse engineering matériel est indispensable mais de plus en plus difficile à mener à cause de la miniaturisation et de la vitesse croissante des composants.

Il y a de plus en plus de cryptographie et de mécanismes de trusted boot, ce qui rend les audits de sécurité sur les équipements plus difficiles, en particulier sur les produits propriétaires.

Précedent Précedent Suivant Suivant Imprimer Imprimer

© 2024 Cert-IST