C&ESAR 2016 - J1
Une conférence sur un sujet au combien d’actualité avec le DDoS de Dyn par le botnet miraï par un gamer énervé. Ce botnet ayant pour particularité d’être consititué d’IoT, plus particulièrement de caméras IP non sécurisés.
Eric Jaëger – Présentation du thème de cet année: l’Internet des Objets & sécurité
Une conférence axé pas seulement sur la sécurité des objets connectés mais des interactions avec ces derniers. Bon, la définition d’un IoT c’est un peu… flou. C’est l’évolution « prévisible » des systèmes d’information qui viennent percoler dans toutes les strates de notre vie. Initié par la logistique à coup de RFID pour répondre au besoin de suivis, les IoT se multiplient et viennent peupler notre univers avec quantité de promesses de donnés de puissance de calcul et de chiffre d’affaire. Exemple avec un défibrillateur autonome, qui embarque une boite noire qui enregistre ce qui se passe autour de lui en cas de litige, avec en prime une connexion de télé-maintenance. Des bidules qui embarquent un processeur, ils sont pléthore. Du passeport biométrique à la brosse à dent connectée (et même des vibromasseurs) pour les petits objets du quotidien aux véhicules, pacemakers et batiments connectés. Pour certains objet on peut se poser des questions quand à l’intelligence d’une telle invention, comme les plateaux à oeuf connectés créant un internet du n’importe-quoi. Exemple de problème apporté par le mode connecté: la propriété physique qui peut être révoqué par le service numérique et la connexion dont il dépend comme ce fut le cas avec les liseuses électroniques et Amazon qui révoqua l’accès à 1984 d’Orwell suite à un problème avec les ayants-droits. Pour les entreprises, les objets connectés apportent de nouveaux challenges similaire à ceux du BYOD avec la définition du périmètre du SI. Challenges similaires aussi aux problématique des SCADA connecté puisqu’il s’agit d’objets physiques & numériques. Ces objets connectés sont parfois victimes, parfois complices, parfois ciblés volontairement ou pas par les attaquants et parfois source d’attaques. Se pose alors la responsabilité du propriétaire de l’objet dans les dommages qu’il cause à autrui dans ce contexte.
Présentation du programme
Damien Cauquil – IoT & Sécurité: une mission impossible
Souvent l’objet connecté s’associe à une application sur smartphone, le tout constituant une solution connectée. L’objet connecté est constitué d’un média de communication (radio/infra-rouge/son) d’un firmware et d’un SoC. Les SoC et autres micro-contrôleurs offrent des mécanismes de protection du firmware, mais ils ne sont pas toujours activés. De même certaines solutions de sécurité ne sont pas bien pensés physiquement. Ex: avec un cadenas « intelligent » dont l’ouverture peut être activée par court-circuitage de deux bornes sur le pcb en glissant un bout de métal au bon endroit. Coté firmware, les systèmes d’exploitation varie de VXWorks à Linux, avec leur lot de vulnérabilités et de backdoors. Le service central associé à l’IoT peut lui aussi être peu ou pas sécurisé. De même la couche de communication peut être peu ou pas sécurisée elle même et sont attaquable à coup de radio-logicielle comme une HackRF.
Du coup la sécurité des SI et des IoT doit évoluer pour prendre en compte ces objets et les contraintes de sécurité qu’ils apportent, notamment sur les aspect Forensic. Coté réseau, il va donc falloir ajouter d’autres moyens de monitoring de ces réseaux d’accès: zigbee, LoRaWan qui via l’objet connecté peuvent devenir un vecteur d’accès à des réseaux traditionnels. Il va sans dire qu’il faut conscillier coût minimal et sécurité maximale et s’assurer qu’un objet massivement déployé qui serais rétro-conçu ne compromette pas l’ensemble du parc.
Xavier Aghina – Etreprise et IoT: Un mélange instable.
Le monde des IoT est un monde « low-cost » aux capacités de calcul distribués et aux limites flou. (comme la présentation. L’orateur re-introduit des concepts déjà couverts par ses prédécesseurs. ) La question du cycle de vie des IoT en cas d’arrêt du service ou tout simplement de la disparition économique du fournisseur, excluant dès lors toute possibilités de mises à jour. L’arrivée des IoT dans l’entreprise viens éroder le périmètre sanctuarisé du SI. Transition du Byod au ByoIoT avec les problèmes qui vont avec. L’orateur évoque l’idée de déployer un AV sur les IoT d’entreprise. Plus sérieusement, ce n’est pas le tout de pouvoir logguer le comportement des objets connecter, il faut aussi pouvoir traiter ces logs ce qui implique les infrastructures et services associés: siem/soc/noc.
Jean-pierre Hauet – Risques de cyberattaques sur l’IoT en milieu industriel
La cybersécurité est une charge supplémentaire pour l’industriel qui à bien d’autres préocupation bien plus importantes comme la sureté de fonctionnement face à des agressions involontaires. La sécurité de fonctionnement à vu le jour à une époque ou on ne parlait pas de sécurité informatique (je vous épargne les cyber*). Face à la menace grandissante que représentait le pirratage informatique, l’ISA à intégré dans ses groupes de travail, un groupe de travail autour de la SSI. Les problèmes de sécurité dans l’industrie sont différents de ceux des SI (cf C&ESAR 2014). La disponibilité y est sacralisé, la ou la confidentialité n’est pas très valorisés. Et la durée de vie des équipements à 20-30 ans n’implique pas les mêmes cycles temporels, et la même réflexion quand à l’intégration de nouveaux mécanismes dans le système industriel. l’Industrial Internet of Thing est un système de systèmes dont il est difficile d’identifier le périmètre car il expose l’industriel à des attaques par le biais d’attaques physiques sur les IIoT. (bref c’est la galère). Un composant industriel pouvant être facilement repéré par certains mots clefs (shodan ?) il peut être envisageable que des ICS soient enrôlés dans un botnet et mènent des attaques à l’insu de l’industriel. (bon là on est re-parti dans le fog-computing, IPv6 et les réseaux basse consommation). Viens en suite la problématique de l’architecture de ces réseaux multiples et de la collecte des données issues de l’IIoT tout en respectant les preceptes de sécurité traditionnels mais qui ont fait leur preuves. C’est pas parce-qu’on a moyen de faire du BigData qu’il faut le faire, même si c’est à la mode. Segmentation, cloisonnement et sécurisation des protocoles restent des briques de base incontournables à appliquer (et pas que dans l’industrie hein 😉 ). Bon après l’IoT et la sécurité apporte aussi une autre problématique: le provisionning et l’enrôlement des équipements (toi aussi génère ta clef privé sur un µC qu’on rigole). Coté SoC, il faut des architectures « secure by design » avec secure-boot & cie, et une manufacture sûre au niveau radio-émission pour servir de base à un IIoT sûr. Coté réseau, les IIoT pourraient communiqué sur une sorte de réseau social des équipements issue du TCG inféaudé à un méta-server central et dont les membres pourraient mettre au banc un équipement infecté ou au comportement suspect (un vrai modèle de société… ). Ajoutons à ça les problématiques de supervision et de surveillance et on à fait le tour.
Aurélien Thierry – Test d’intrusion dans un système de contrôle de qualité de l’eau
petite introduction sur les protocoles 802.15.4 et 6LoWPAN qui viennent remplacer les couches ethernet et IP qu’on rencontre usuellement. Du coup comment faire en sorte qu’un PC avec ses outils de Pentest fonctionnent sur le réseau 6LoWPAN ? Les orateurs ont monté un projet ARSEN pour scanner et interragir avec un réseau 802.15.4 (les sources ici, merci Ivan). Ce protocole dispose de mécanismes de sécurité comme l’anti-rejeu et le chiffrement entre le coordinateur et le capteur. du coup une raz du compteur de trame permet le re-jeu. Le réseau est chiffré en AES CCM, ce qui permet des attaques crypto. Lors d’attaque par brouillage, le capteur reboot (sympa pour les compteurs anti-rejeu). Lorsquon simule un coordinateur sur un autre canal en brouillant le coordination, les capteurs viennent gentillement s’associer, laissant tout seul le coordinateur qui fini par rebooter (dans le doute reboot ?). Normalement, la « reconfiguration » implique une rotation de clef mais pas forcément spécifiée dans la norme. Du coup les constructeurs ont claqué une clef en dur dans les équipement (cryptofail?). Du coup avec ces attaques bien que reposant sur une présence physique sur site, il est possible de leurer complètement l’opérateur. Le problème principal repose sur la remise à zéro du compteur de trames.
