Catégories
conférences

C&ESAR 2019

J1

Introduction

26ème édition de C&ESAR, sur l’échange entre académique, éducation, gouvernement & industrie pour rendre le monde numérique plus sûr. Aucun système d’importance ne se conçoit sans numérisation, et donc sans prendre en compte la menace cyber qui pèse sur lui. Le thème de l’intelligence artificielle est un chantier dans lequel il va falloir trouver les moyens de sécuriser nos traitements et nos données. La conférence sur l’IA qui suit C&ESAR s’inscrit dans le même état d’esprit que C&ESAR, avec une session commune sur les problématiques cybersécurité & IA.
La recherche est aussi à l’honneur lors de l’ECW avec un workshop académique.

Virtualisation dans un cloud de télécomunication

Pour préparer la 5G,  afin de pouvoir offrir des serivces différentiés en fonction des abonnés, les opérateurs comme orange ont besoin d’un Cloud TELCO. On peut imaginer l’impact que peut avoir un incident sur un réseau mobile à l’heure ou les téléphones sont omniprésents et les usagers de plus en plus dépendants de ces derniers. La disponibilité est donc un gros enjeux. La confidentialité est elle aussi très forte pour des raisons réglementaires. 
Un Telco-Cloud est une infrastructure de virtualisation distribué sur le pays. Les équipements matériels ont été progressivement remplacé par des machines virtuelles faisant tourner le logiciel de l’équipementier. Le problème, c’est que ces fonctions virtualisés tournent sur du x86 vulnérable aux attaques matérielles type spectre/meltdown. L’OS c’est du linux, et il faut venir le durcir. Pour exécuter les vm, ils utilisent du OpenStack, et c’est pas les échanges qui manquent entre les composants OpenSTACK. KVM/Qemu souffre de pas mal de bugs de stabilité.
La transition d’un monde physique à un monde virtualisé multi-fournisseurs ne se fait pas sans heurts. Par exemple, pour un pare-feu virtuel chargé de filtrer des paquets issue d’un déni de service, les paquets ont déjà traversé la couche SDN avant d’arriver au pare-feu chargé de filtrer, il y a donc un risque de déni de service de l’infra virtualisée.

Pour se prémunir face à ces risques, les attaques types DDoS sont gérés par un ASIC. Qui dit sécurité, dit TLS et PKI, avec la gestion des secrets au sein d’un HSM qui ne doit pas devenir un SPOF. Le development sur les infrastructure cloud se fait en mode devops avec un gros impact sur la gestion des patchs en CI/CD. La supervision de sécurité, c’est la cerise sur le gateau, avec gestion au sein d’un siem de l’ensemble des logs produits par l’infrastructure.

Cloud & SOC

La réponse à incident est très complexe dans un Cloud, et la connnaissance des acteurs & intervenants est très mal maitrisé. La stratégie de détection sur une infrastructure non-maitrisée avec une cartographie réseau inconnue est une gajeure. De plus sur des portions externalisés qui sont parfois co-localisés avec des tiers dont les composants hébergés sont souvent vulnérables. 

Les provider cloud offrent des solutions de virtualisation des réseaux, de centralisation et de gestion de logs, etc… il faut donc s’appuyer sur ces derniers pour construire sa stratégie de détection. (#protip: pour le forensic, vu qu’ils font payer au débit réseau, vous pouvez utiliser une vm pour l’analyse directement chez le cloud provider 😉 ).

Legislation applicable aux opérateurs de réseau 5G.

La transition de la 4G à la 5G se fera avec un carrier 5G sur un coeur de réseau 4G. Horizon 2022, l’ensemble du coeur de réseau va basculer vers un coeur 5G, avec une segmentation forte des portions de la partie utilisateur. La virtualisation est un gros enjeu des coeurs de réseau 5G, notamment le fait de pouvoir dédier des tranches de ce réseau à des fonctions critiques. Les différentes réglementations sur les télécomunications ne sont pas forcément adapté au contexte 5G, qui lui est capable de gérer les priorités et de venir réserver une majorité de la bande passante pour les appels d’urgence lors d’une catastrophe. Il faut donc adapter la legislation aux spécificités de la 5G, ce qui laisse envisager l’élaboration d’une législation spécifique. 

VMWare & Cybersécurité

Puisque tout est virtualisable et virtualisé, du réseau au cpu en passant par le stockage, du coup les infrastructures définie logiciellemnet (Software Defined Infrastructures).  Par exemple, l’utilisation du SDI pour adapter l’infrastructure aux spécificités de l’attaque.  Autre projet de r&d: S2OS qui consiste à créer un OS sécurisé basé sur les technologies de SDI. Les conteneurs partageant le kernel, ne proposent pas forcément une couche de sécurité supplémentaire comme peut l’offrir la virtualisation traditionelle. l’idée de VMWare c’est de rapprocher le SDI du concept Kubernetes. 

Scada, sécurité & virtualisation

les automates industriels contrôlant un processus industriel ont de fortes contraintes de disponibilité et de réactivité. Lorsqu’on veux construire une plateforme de test, il est difficile de reproduire un système de contrôle matériel, les piles protocolaires ne sont pas libres, et les OS non plus. Donc ça fait beaucoup de barrières pour les chercheurs. Du coup les orateurs ont décidé de construire un bac à sable libre & ouvert, utilisant du matériel SCADA documenté avec une taille proche d’un SI industriel, soit 100 devices connectés et environ 1k capteurs.  La simulation se fait donc avec du matériel dédié (hardware in the loop). Du coup ça permet de construire des infrastructures de simulation pour la formation ou l’expérimentation. Le seul cas d’usage public accessible dans la litérature de traitement industriel à été réimplémenté sur la base de ces cartes avec une simulation python. Il fût en suite possible de jouer des attaques directement sur cet environement simulé.  Pour les capteurs de courant electrique, des cartes filles ont été développés pour adapter les niveaux de voltages.

Les simulateurs existant coûtent un bras, du coup les orateurs ont re-développé un simulateur python, et le source est disponible ICI.

Sécurité & Véhicules connectés

Le SDVN est un réseau véhiculaire virtualisé. En gros chaque véhicule est un switch, et le plan DATA est coupé en deux, avec une partie mobile, les vehicules, et une partie fixe que sont les bornes sur le bord des routes. On peut ainsi segmenter les données des véhicules d’urgence des véhicules traditionnels. Dans la 5G, il va falloir trouver des compromis entre SDVN, performance & couverture radio. Cependant cela se fait avec un accroissement de la complexité de l’infrastructure, lié à la complexité intrinseque de l’infra 5G.  Côté sécurité, le contrôleur SDN est une cible potentielle à surveillé de près. Car sans ce dernier, plus rien ne fonctionne. Comme les véhicules se déplacent, le plan DATA mobile peut s’avérer compliqué à gérer. La défense en profondeur est ici préconnnisé, avec une attention toute particulière sur la sécurité du plan DATA.

Validation par introspection de code & virtualisation.

Les piles logicielles qui sont exécutés sont très très riches & complèxes, et l’approche de sécurité est très orienté système. Gestion des droits, confinement, quotas… Mais l’analyse de code est toujours une valeur sûre car elle minimise par construction la surface d’attaque. Les outils d’analyse de code automatique offrent un autre moyen de réduire les risque en pointant du doit les erreurs. La virtualisation sur Unisim-vp à été enrichie par un mécanisme de typage polymorphique. Les types peuvent être concrêts ou symboliques.

IceBox – Analyse de malware par introspection de machine virtuelle

une solution d’introspection de machine virtuelle (vmi) adapté à l’analyse de malwares. Le problème de l’analyse dynamique, c’est que le malware tourne souvent au même niveau que les outils d’analyse. Le malware peut donc déployer un certain nombre de techniques pour détecter et corrompre ce relevé d’information. Quand on remonte au niveau Kernel, le malware lui peut par l’injection d’un driver le contourner.  Le malware peut aussi faire de l’anti-debug, etc… tout ça pour compliquer la tâche de l’analyste. Lorsqu’on met en pause une VM, et qu’on regarde l’êtat de son CPU, on ne sait pas si on est en espace user ou noyau, dans quel process on est, quel thread, etc… L’idée d’ICEBox, c’est de fournir un framework qui prend en charge cette problématique. Ce n’est pas le seul projet à faire de l’introspection de VM, mais il a le mérite d’être performant et de supporter Windows comme guest OS. Les breakpoints de l’hyperviseur permettent de rester furtif vis à vis du malware. IceBox gère aussi une callstack du noyau vers l’applicatif. L’outil est disponible ICI.

Analyse morphologique & LockerGoga

Le principe de l’analyse morphologique, c’est d’observer la structure et l’agencement des instructions et des fonctions dans un binaire, et de les comparer avec un autre. S’ils ont la même apparence, ils ont probablement la même finalité.  Cette analyse morphologique se fait par analyse de similarité entre les graphs à l’aide de l’outil Gorille

J2

les présentations suivantes sont issue du workshop SILM

Trusted-Execution Environments

Les trusted-zones sur les CPU servent à isoler du code du reste du système, typiquement employé pour des fonctions de sécurité ou des DRM. La question que l’orateur de TU Graz se pose, c’est est-ce que l’application qui s’exécute dans l’enclave CPU est-elle vraiment protégée ? Que se passe t’il si un attaquant exécute son code malicieux dans une enclave SGX ou une trust-zone Arm ? Les enclaves sont des boites noires, et on ne sait pas ce qu’il s’y passe. Le concept à été présenté par Joanna Rutko
wska en 2013. Exécuter dans une trust-zone est contraignant, on ne peut pas faire de syscalls, etc… Il existe des side-channels qui permettent de récupérer des méta-données de l’exécution du code dans sa trust-zone, mais c’est pas très puissant, et on peut durcir le code au niveau des sources pour rendre les side-channels innexploitables. Le chiffrement de zone mémoire est une fonctionnalité des trust-zones. Si un bit flip dans une zone chiffré, cela provoque un verrouillage du contrôleur mémoire, et un freeze complet du système. (plus d’infos sur la page de l’orateur). Quand on veux faire des choses depuis l’enclave vers la mémoire système, il faut trouver un moyen de toucher les zones mémoires sans risques de crasher le système. Pour se faire, l’orateur s’appuie sur intel TSX pour pouvoir faire du roll-back en cas d’erreur mémoire, et éviter le BSOD. Le mécanisme mis en place, il faut 45min pour accéder à  toute la mémoire, et quelques secondes pour aller chercher des infos proches de la zone d’appel. Pour l’exécution, l’orateur fait du ROP depuis l’enclave SGX. En s’appuyant sur ses connaissances, l’orateur à créé un jail pour les applications SGX.  La communication entre la sandbox et le processus hôte se fait par une zone mémmoire partagée, et l’enclave est verrouillée via seccomp. L’overhead n’est pas énorme. En utilisant les fonctions MPK de protection mémoire des cpu Intel, l’orateur à pu mettre en place une enclave hardware.

Splitting the Linux Kernel for fun & profit

Docker est une alternative très populaire à Docker car c’est plus léger qu’une VM, mais la contrepartie, c’est que le conteneur à accès au Kernel de l’hôte, et donc n’importe quel exploit kernel se transforme en carte « sortie de conteneur ».  Et ce ne sont pas les techniques qui manquent pour accéder à la mémoire du Kernel. L’orateur souhaite donc réduire les conséquences de l’exploitation d’une vulnérabilité Kernel en se basant sur les techniques de virtualisation matériel présent dans les cpu modernes. Dans les mécanismes hardwares du cpu pour la virtualisation, on à les instructions VT-X qui offrent un moyen de sécuriser une zone mémoire. On peut aussi mettre en place des vérifications d’intégrité de zones mémoire comme le code du noyau, ou certaines zones mémoires contenant des informations utile aux élévations de privilèges. Par contre l’orateur veux éviter de mettre en oeuvre un hyperviseur, et que ça reste un code pouvant être intégré dans les sources du noyau linux. Pour découper le kernel, l’orateur place une partie réduite du kernel dans la zone privilégiée du ring -1 traditionellement réservé à l’hyperviseur. (les sources sont sur github)

IOMMU & DMA Attacks

L’iommu permet d’assurer la ségrégation entre les périphériques ayant un accès direct à la mémoire physique (DMA). Le dma c’est un vieux système qui permetait au disque dur par exemple d’écrire directement les information demandées dans la zone mémoire adéquate pour des questions de performance et d’économie de cycles CPU. L’iommu permet de regrouper les périphériques dans des domaines et de leur donner accès a des zones mémoires particulières, protégeant ainsi le kernel et les zones mémoires sensibles des accès indues de la part des périphériques DMA (firewire,pcie, etc…).
L’orateur nous fait un état de l’art complet des attaques DMA.

Pitfalls & limits of dynamic malware analysis

L’analyse dynamique de malware peut faire gagner du temps, mais parfois n’est pas suffisante pour qualifier les intentions d’un code malveillant. L’unpacking statique est une tâche fastidieuse, et ça va souvent plus vite en dynamique. Pour observer l’exécution d’un code, c’est le debuggueur qui nous viens en tête, mais ces logiciels n’ont pas été conçus pour l’analyse de logiciels malveillants, et ne sont ni furtifs, ni sûrs. L’émulation est une autre approche, mais là encore ces émulateurs ne sont pas faîts pour encaisser les attaques, et en plus c’est très compliquer d’implémenter correctement des instructions cpu complexes. On peut aussi utiliser des modules kernel pour analyser les malwares, mais il faut qu’ils soient signés, ou désactiver la vérification de signatures, et en prime patchguard pose problème. Window 10 est accompagné d’une sandbox hyperV mais il ne fournis pas d’API pour l’analyse et l’introspection. C’est facile de détecter de la virtualisation, mais impossible de détecter l’introspection. (l’orateur rejoins le point de vue des auteurs de IceBox).

La virtualisation, c’est compliqué à mettre en oeuvre, et on peut vite se retrouver avec des race-conditions entre les différents cpu virtuels si l’analyse se fait sur une vm multi-cpu. Exemple avec PID d’un process qui est une construction de l’OS qui utilise des structures de donnés mouvantes. Les tables de pages sont un indicateur un peu plus stable, mais le matériel peut changer les tables de pages sans invalider le cache du tlb, et du coup c’est le bordel pour reconstruire la mémoire du process.  L’orateur détaille en suite de nombreux side-effects de l’introspection Xen sur les breakpoints, certaines instructions cpu,  la gestion des shadow pages, etc… Le hardware limite la furtivité de l’introspection, et il y a toujours moyen d’observer les effets de bord par mesures de temps. Une détection négative sur une sandbox indique juste que l’auteur du malware est peut-être plus malin que l’auteur de la sandbox. La diversité nous sauve, car il est très peu probable que les malwares importerons toutes les contre-mesures envisageables au risque de devenir énormes.

Combinaison de sources de SCA.

L’analyse par canaux auxiliaires consiste à mesurer les incidences d’un calcul au niveau d’un processeurs sur la consomation électrique, le rayonement électromagnetique, etc… Le problème c’est de réussir à correler ces signaux avec ce qui se passe dans le processeur. Lorsqu’on connait l’algorithme, on cherche à obtenir la clef privée qui sert au chiffrement. Les orateurs ont donc utilisé un réseau de neurones avec des données de références pour l’entrainer à selectionner et déduire les valeurs des bits d’une clef de chiffrement à partir des données mesurés par des sondes electro-magnétiques posées à différents endroits d’un microcontroleur.  Les expérimentations se sont faite en s’aider du jeu de données ASCAD. Après expérimentation, un seul canal auxiliaire suffit au réseau de neurone pour déduire la clef efficacement.

Cybersécurité & IA en environement contraint.

Intégration de Machine Learning dans un SOC. Après la réussite du ML supervisé sur de la détection de fraude, ils ont essayé de faire pareil sur de la détection d’attaques informatique. La donnée c’est l’enjeu n°1 d’un projet Data Science. La récupération de cette donnée nécessite donc beaucoup de travail avant de pouvoir bosser en machine learning.  La protection et l’anonymisation des jeux de données pour pouvoir les employer sans risques.

Une fois les donnés obtenues, les deux DataScientist se sont penchés sur les classiques kmeans, dbscan, randomforest sur les dataset CIC IDS 2017 et CIC IDS 2018, et IsolationForest sur leur DataSet Interne, et ils ont fini par valider IsolationForest pour une mise en production. IsolationForest à l’avantage de faciliter l’interprétation des données car pour chaque branche de l’arbre ont sait quel sont les features sur lesquelles le test était fait. La réduction des features permet aussi de faciliter l’interprétation des résultats par les experts.

ToxicIA – apprentissage profond appliqué aux Signaux parasites compromettants.

Lorsqu’on viens récupérer les signaux radio émis par la circulation du courant dans les cables d’alimentation ou les cables vidéo, il est possible de reconstruire l’affichage des écrans. Ces signaux parasites divulguent sur le champ radio des informations potentiellement sensibles. Cependant la récupération de ce signal n’est pas systématique, et il est souvent très bruité. C’est là que l’IA entre en jeux. En affichant des caractères sur un écran, et en passant le signal intercepté dans un réseau de neurones on peut lui apprendre à reconstruire des images non-bruités à partir des images bruités. Après expérimentation de nombreux algorithmes de débruitage, puis passage à tesseract, il s’avère qu’ils obtiennent un fscore d’a peine 0,3. En utilisant directement un réseau de neurone combinant débruitage ET reconnaissance de caractère, le fscore monte à 0,68. Par contre les caractères de petite taille sont très sensibles au bruit et difficiles à reconstruire. (cf opendenoising)

Machine Learning pour les systèmes de détection

Créer des règles de détection, c’est coûteux, et ça nécessite de les faire faire par un expert. En plus lorsque les donnés d’entrée chagne, il faut revoir les règles. Si on dispose de suffisament de données, on peut envisager de faire du machine learning. Le problème c’est qu’un algo de ML prend en entrée des tableaux ou des valeurs catégorielles représantant les caractéristiques de ce que l’on cherche à identifier. Il faut donc transformer les données brutes en attributs. L’extraction des attributs est très coûteuse et nécessite là encore de l’expertise. Si on laisse à l’algorithme le soin d’extraire les attributs caractéristiques à apprendre, on perds en interprétabilité par un expert. L’orateur c’est donc intéressé à l’abaissement du coût d’extraction de ces attributs. Les parsers contiennent un très grand nombre de techniques d’extraction d’attributs qui sont transformables en un modèle relationnel inter-entités(un peu comme un schéma de base de données). AutoFeatures va donc parcourir ce modèle pour transformer les donnés récupérés en un scalaire qui pourra alimenter l’algo de ML. Il faut en suite offrir à l’expert un moyen pour injecter ses connaissances. Pour ce faire il peut ajouter des features intéressantes, les whitelister ou les blacklister afin d’éviter d’aggréger des PID par exemple.

IA pour la détection de fake-news

La désinformation peut servir à faire gagner des conflits. les fake news ont des articles de presse intentionellement faux et dont ont peux vérifier l’absence de crédibilité. Ces fakes news n’ont qu’un seul intérêt: générer du traffic pour gagner de l’argent via les publicités. Le coût de la vérification de l’information est bien plus important que la production d’une fausse information. (bullshit asymmetry)
Dans le monde militaire les PsyOps & InfoOps sont cadrés dans une doctrine qui définis ce qui est autorisé ou non lors d’une opération. Les actions de désinformation vons s’appuyer sur des communautés qui servirons de relais et de chambre d’écho. Pour automatiser l’analyse des fake-news, il faut donc à partir des articles entrainer un réseau de neurone avec pour oracle des services de fact-checking. Une base de connaissance peut aussi servir à ce fact-checking. Cette approche fonctionne bien pour des faits simples.

Détection de comportement annormaux au niveau utilisateur  & entité.

L’IA c’est compliqué, il faut des connaissances métier fortes, des experts en DataScience et de bons jeux de données. Sur les pare-feux on à vite des volumes de données très important. A partir des logs de ces pare-feux, les orateurs génèrent des graphs qu’ils affichent aux analystes afin de faciliter la détection visuelle de l’annomalie, puis entrainent l’algo de machine learning dessus. en projetant les échanges sur un espace à deux dimentions, on essaye de préserver quelques propriétés: temporellement les ip doivent se rapprocher si elles communiquent fréquement entre-elles, ou s’éloigner si elles cessent d’échanger.  Une fois le graph généré, node2vec fait la projection sur un espace multidimentionnel. La projection est en suite réduite pour être visualisable sur 2 dimentions.
Il faut paramétrer correctement.

Evaluation de systèmes de masses de données dans le cadre d’analyse de logs. 

L’analyse de gros volume de logs c’est une problématique constante dans la mise en oeuvre d’un SIEM. à l’université de Rennes1, les logs sont passés dans greylog puis indexés dans elasticsearch (un classique du siem).  En jouant sur la taille et la complexité des requêtes, on voit bien que les performances s’effondrent avec l’augmentation de la quantité des données indexés. Comment faire pour passer à une très grande échelle ?  Pour ce faire, l’orateur à regardé du côté de HDFS et de MapReduce pour requêter de très gros volumes de données. Le problème d’Hadoop, c’est qu’il faut coder pour que ça fonctionne. Les niveaux d’abstraction sont loin d’être suffisant pour rendre ce genre d’infra accessibles à des opérateurs de SOC. 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *