explosion du mahé de l’iot - ossir : accueil · 2018-03-20 · les objets connectés...

JSSI 2018 – Paris – 13 mars 2018

Lény Bueno – [email protected]écuriser l’IoT – un challenge bien compliqué

Explosion du marché de l’IoT


Source : iot-analytics.com

P. 3 Digital Security – JSSI 2018 – Paris – 13 mars 2018

Objets connectés grand public ou professionnels

Contrôle d’accès (badges sans contact)

Ouverture de portes (garage, voiture, etc.) & interphones

Alarmes sans fil, capteurs domotiques

Drones

Abonnements urbains (cartes Velib’, Autolib, Navigo, etc.)

Réseaux cellulaires (GSM, téléphonie domestique DECT)

Bureautique sans fil (souris, clavier, casque)

Dispositifs médicaux (pacemakers, pompes à insuline, etc.)

Dispositifs de navigation (GPS)

Radiopilotage horaire (GSM NITZ, DCF77, etc.)



Sécurité des objets connectés



Infrastructure LPWAN

Réseaux LPWAN (Low Power Wide Area Network)



Infrastructure de courte portée

Réseaux de courte portée compatibles Smartphones



Infrastructure « relais »

Réseaux de courte portée utilisant une passerelle locale

Base matérielleMicrocontrôleurs et System-on-Chip (SoC)

↪ Pilotage d’actionneurs ou récupération de données de capteurs

↪ Offre une connectivité (ex: Bluetooth Smart, ShockBurst, LoRa, Sigfox, etc.)

↪ Supportent les protocoles de communication électroniques (ex: SPI, I²C, UART)

↪ Programmés et débogués via des interfaces et protocoles dédiés (ex: JTAG, SWD)

↪Micrologiciel placé dans une mémoire morte (souvent une Flash)

Micro-ordinateurs embarqués

↪ Système d’exploitation présent sur un support de stockage (carte SD)

↪ Secure Boot, chiffrement des données



Exemples de vulnérabilités matérielles (1/3)

Indications présentes sur le circuit imprimé

↪ Rôle des points de tests

↪ Emplacements de connecteurs de débogage



Accès à des fonctionnalités réservées aux développeurs ou à la maintenance



Erreurs de conception électronique



Démo !



Erreurs de conception électronique

Non-activation des mécanismes de protection

↪ Désactivation des interfaces de débogage

↪ Limitation d’accès à la mémoire Flash



Atteinte à la propriété intellectuelle, extraction du code exécutable

Base logicielle

Micrologiciels monolithiques

↪ Exécutable unique exécuté par un processeur

↪ Exploitation de vulnérabilités applicatives complexe (dépend du type de processeur propre au constructeur, prise de contrôle du flux d’exécution et après ?)

Micrologiciels hétérogènes

↪ Ensemble d’exécutables exécutés par un système d’exploitation

↪ Présence d’un système de fichiers

↪ Les vulnérabilités applicatives peuvent être exploitées afin d’obtenir un accès privilégié au système d’exploitation



Exemples de vulnérabilités logicielles (1/2)

Débordements de zone mémoire



Prise de contrôle de la caméra et du système Linux sous-jacent

Exemples de vulnérabilités logicielles (2/2)

Débordements de zone mémoire

Implémentations cryptographiques non-standard possédant des vulnérabilités

↪ Algorithme cryptographique propriétaire et vulnérable

Implémentations de protocoles ne respectant pas les standards définis

↪ Algorithme cryptographique standard mais vulnérable car mal implémenté

Utilisation de mots de passe ou clés de chiffrement par défaut



Couche de communication (1/2)

Elle fait le lien entre l’objet et son monde extérieur

Utilisation de protocoles de communication avec ou sans fil :

↪ Bluetooth Smart, (Enhanced) ShockBurst, ZigBee, SIGFOX, LoRa, LoRaWAN, TCP/IP, UDP, MQTT, etc.

Deux types de problématiques :

↪ Vulnérabilités inhérentes au protocole

↪ Vulnérabilités induites par une mauvaise utilisation du protocole



Couche de communication (2/2)

La radio logicielle (SDR) est aujourd’hui abordable :

↪ HackRF One, Yard Stick One, Blade RF

↪ Elle permet de démoduler, décoder, ré-encoder et moduler les protocoles de communication à l’aide de logiciels comme GNU Radio

Des équipements spécialisés pour certains protocoles de communication font leur apparition :

↪ Ubertooth, Bluefruit LE sniffer, Micro:Bit, etc.



Il est désormais possible de réaliser des attaques automatisées sur des protocoles radio complexes, à moindre coût

Exemples de vulnérabilités observées sur la couche de communication (1/4)

Transmission en clair de données sensibles

↪ Les mécanismes de sécurité Bluetooth Smart assurant le chiffrement et une protection contre l’interception passive ne sont pas utilisés



Récupération du code de déverrouillage d’un cadenas électronique



Absence d’authentification des équipements

Glucomètre connecté (Bluetooth Smart)

↪ L’application mobile identifie les équipements par leur adresse Bluetooth (BDADDR)

↪ Création d’un clone du périphérique en question ayant la même adresse

↪ Connexion du Smartphone sur le clone et envoi de fausses données



Le stockage de données médicales est soumis à des réglementations, l'insertion de fausses données peut avoir de lourdes conséquences




Drone miniature

↪ Communique via un protocole radio sur 2.4GHz

↪ Construction d'une télécommande à partir d'un Micro:Bit modifié

↪ Exploitation du système de saut de fréquence

↪ Contrôle complet du drone par l'attaquant



Démo !




Absence de contrôles d’intégrité

Chiffrement faible



Le cloud

Les objets connectés communiquent avec des services hébergés sur Internet

↪ Ces services manipulent et stockent les données transmises par ces objets, ils sont utilisés à la fois par les objets connectés ou leur passerelle, les applications mobiles et/ou de bureau

↪ Cette centralisation du stockage représente un risque d’accès à l’ensemble des informations des objets connectés utilisant ces services



Des mécanismes de sécurité doivent être présents sur l’ensemble de ces protocoles

Exemples de vulnérabilités touchant le Cloud (1/3)

Authentification faible ou inexistante

Mots de passe par défaut

Chiffrement faible ou inexistant

Mauvaise gestion des erreurs

Problématiques de contrôle d’accès et de suivi de session

Absence de chiffrement/signature des mises à jour (si HTTP par exemple)




Rétrogradation ou désactivation de chiffrement

↪ Une caméra connectée communique avec un serveur de contrôle via le protocole XMPP (eXtensible Messaging and Presence Protocol)

↪ Le protocole TLS est requis et chiffre les communications

Possibilité de désactiver l’utilisation de TLS

↪ Attaque de « l’homme du milieu » pour forcer le client XMPP à annoncer au serveur qu’il ne supportait pas le chiffrement TLS



Ni le client, ni le serveur n’implémentait de vérification du niveau de chiffrement


Énumération des ressources connectées

↪ Le protocole XMPP est utilisé pour faire communiquer des équipements en temps-réel, et le serveur XMPP sert de point de relais central



Le service d’annuaire était actif sur le serveur XMPP

Difficulté et coût de correction (1/2)

Souvent de petite taille, risque de vol

↪ Peu coûteux et facilement remplaçable

↪ Peu de ressources, complexité de mettre en place les différents mécanismes de sécurité, manque de journalisation

↪ Stocke régulièrement des clés de chiffrement ou des informations personnelles

Solutions complexes et hétérogènes

↪ Bien souvent mal documentées voire pas du tout

↪Multiplicité des passerelles faisant le lien entre les réseaux traditionnels et les protocoles de communication adaptés aux objets connectés



Difficulté et coût de correction (2/2)

Absence de fonctionnalité de mise à jour

↪ Rappel de tous les équipements impactés afin de mettre à jour leur micrologiciel

↪ Remplacement des équipements impactés s’il est impossible de les mettre à jour par programmation

Véhicules autonomes, systèmes de contrôles d’accès, équipements médicaux et industriels

↪ La prise de contrôle de ces équipements peut porter atteinte à la sécurité physique et l’intégrité des personnes

↪ Respect des réglementations sur le traitement des données (personnelles, de santé, financières)



La réputation des entreprises est en jeu

Repenser la sécurité

Quelles questions se poser ?

Y a-t-il des données sensibles stockées ?

Quel(s) moyen(s) de communication ?

Est-il accessible physiquement ?

Y a-t-il possibilité de mettre à jour le micrologiciel Over-The-Air (OTA) ?

Faut-il signer ou chiffrer les mises à jour ?



Mises à jour OTA


Digital Security – JSSI 2018 – Paris – 13 mars 2018P. 30

Fonctionnalité à implémenter en premier

Et correctement !

↪ Déclenchée par une action de l’utilisateur

↪ Couplée à une action physique sur l’objet (bouton, menu, redémarrage, etc.)

↪Maintien en condition opérationnelle en cas de problème de mise à jour

Chiffrement



Sécurise le stockage et les échanges de données

Implémentations basées sur les standards

Provisioning de clés propres à chaque objet

↪ Ex: Sigfox, LoRaWAN

↪ Risque de compromission globale si extraction d’une clé maîtresse

Clé non-prédictible, clé non extractible

↪ Retour à la sécurité matérielle…

Authentification



Assurer l’authentification mutuelle

Se baser sur des mécanismes éprouvés

↪ Appairage sur la couche liaison (ex: Bluetooth Smart)

Si l’application tourne sur un environnement non sûr (Smartphone/ordinateur vs microcontrôleur/SoC) il est préférable de procéder à une association applicative

↪ Un malware déployé sur le Smartphone / ordinateur bénéficie du lien établi avec le périphérique…

Sécurité matérielle



Désactivation des interfaces de débogage

Activation des verrous existants contre l’extraction de micrologiciel

Penser aux faiblesses de conception mécanique et électronique

Utilisation d’un Secure Element pour le stockage de secrets ?

↪ Cela implique le provisioning des Secure Element en usine et la gestion des secrets placés dans le Secure Element

↪ Lourd à mettre en œuvre (surcoût par pièce !)

Règles d’or de l’objet connecté (1/2)



Assurer son évolution

Sécuriser son contenu

Sécuriser les échanges

Permettre la transitivité

Permettre la traçabilité (si possible)

Règles d’or de l’objet connecté (2/2)



Intégrer la sécurité lors de la conception

↪Mécanique

↪ Électronique

↪ Applicative

S’entourer de profils variés

Ne pas se contenter d’un démonstrateur

↪ Tester la sécurité de la solution connectée


Lény BUENOConsultant sécurité[email protected]

mailto:[email protected]

explosion du mahé de l’iot - ossir : accueil · 2018-03-20 · les objets connectés...

Documents