Introduction
Comme chaque année, plusieurs consultants d’Intrinsec étaient présents au SSTIC (Symposium sur la Sécurité des Technologies de l’Information et des Communications) qui s’est déroulé du 1 au 3 juin 2016 à Rennes. Nous vous partageons nos comptes-rendus de ces trois journées.
Nous avons apprécié cette édition et remercions les comités d’organisation et de programmation, ainsi que les orateurs pour leur travail de qualité.
La particularité du SSTIC, du fait de son caractère de conférence scientifique, consiste en l’existence d’articles complets pour accompagner les présentations. Ils sont rassemblés dans les actes au format papier et disponibles également sur le site de la conférence, avec les diapositives et vidéos. Nous vous encourageons de vous y reporter en plus de ces comptes-rendus.
Liens vers les comptes-rendus des autres jours :
Conférence d’ouverture : grsecurity
Brad Spengler est intervenu pour la conférence d’ouverture. Il est connu pour être l’auteur de grsecurity qui est un patch permettant de durcir le noyau Linux.
La première partie de sa présentation portait sur un rappel des nouvelles fonctionnalités de sécurité implémentées récemment autour de l’ajout d’aléa dans les adresses mémoires de structures sensibles du noyau, de DenyUSB pour empêcher l’ajout de nouveaux périphériques USB après le démarrage, ainsi que de RAP qui va entraîner selon lui la mort des techniques de ROP (Return-Oriented Programming), JOP (Jump Oriented Programming), etc. en se basant sur une « verification of type hash on indirect control flow transfers ».
La seconde partie, plus adaptée à l’exercice de la keynote, s’intitulait « state of infosec union » (en référence à l’allocution annuelle du Président des États-Unis devant le congrès).
Tout d’abord, il a dressé un tableau peu positif de notre communauté : obsédée par les bugs et vulnérabilités de plus en plus nombreux. Il note cependant une sophistication des attaques par corruption de mémoire (buffer-overflows et autres) qui sont devenues spécifiques à des applications (ex. : Flash, Adobe Reader…). Selon lui, il y a trop de conférences (qu’il estime ne pas être le meilleur moyen de transfert de connaissances) pour que seul du contenu de qualité soit présenté.
Il s’est élevé contre certains « charlatans thought leaders » qui produisent du contenu qu’il juge survendu pour plusieurs raisons. Selon lui, il est plus facile de produire du contenu creux et attrayant, que de le remettre en question. Il remarque aussi le passage des divulgations sur Bugtraq les décennies précédentes à Twitter de nos jours qui incite à viser la simplification pour mieux attirer l’attention. Il note que cette situation provoque un décalage entre l’état de l’art de la recherche et ce qui constitue les menaces individuelles classiques : les APT sont à la mode contrairement aux attaques courantes (macros Office, extensions cachées, utilisateurs crédules…).
Dans le futur, afin que le niveau de sécurité s’améliore, il espère que les chercheurs en sécurité s’intéresseront plus à l’élaboration de techniques de protection génériques, pérennes et qui n’augmentent pas la surface d’attaque (il cite bien entendu grsecurity en modèle), qu’à la divulgation en série de bugs unitaires.
Enfin, il conclut en nous donnant les recommandations suivantes pour être, selon lui, des membres utiles de la communauté :
- Appliquer une réflexion critique
- Apprendre qu’il est acceptable d’admettre de ne pas savoir
- Exploiter les critiques constructives comme des opportunités d’amélioration
- Rejeter la course à la gloire et plutôt soumettre du contenu riche et de qualité à des publications comme Phrack
- Ne pas prendre de raccourcis : travailler autant que nécessaire et apprendre les fondamentaux
- Se plaindre est à la portée de tous, il est préférable de s’appliquer à corriger quelque chose
Démarche collaborative d’analyse de codes malveillants
Adrien Chevalier, Stéfan Le Berre et Tristan Pourcelot de Sogeti/ANSSI ont profité de cette conférence pour présenter leur méthodologie d’analyse collaborative de codes malveillants. Ils ont publié également les outils qu’ils ont développés dans ce but.
Ce besoin vient du constat qu’il y a plus d’auteurs de logiciels malveillants que de personnes pouvant les analyser (rétro-ingénierie). Cette analyse permet d’identifier et catégoriser les logiciels malveillants ainsi que d’extraire des éléments pour en permettre la détection. En synthèse, leur besoin consistait à obtenir rapidement des indicateurs de compromission (IOCs) et des rapports avec en entrée de nombreux échantillons (samples) accompagnés de leur contexte de collecte (ex. : ministère concerné).
Ils ont présenté les différentes étapes d’une analyse avec les difficultés que chacune présente avant de dévoiler l’outil Polichombr (nom d’un Pokémon) dont le développement a débuté en 2014. Il est désormais disponible publiquement sous licence libre CeCILL (https://github.com/ANSSI-FR/polichombr). Il répond aux challenges suivants : stockage des échantillons, centralisation d’informations et de connaissance (capitalisation), travail d’équipe, automatisation de l’analyse, classification et partage des résultats.
Deux sous-projets ont également été dévoilés :
- Skelenox : script IDAPython pour interagir avec Polichombr
- Machoc : algorithme de calcul d’empreinte sur un code en se basant sur son graphe de flot de contrôle. L’empreinte a l’avantage d’être légère (transmissible par email), adaptée aux exécutables, résistante à la recompilation (le graphe reste similaire) et aux changements d’architecture processeur (32/64 bits)
Les échantillons déposés sur la plateforme sont automatiquement analysés et classifiés s’ils appartiennent à une famille connue. Si besoin, l’analyste peut aussi effectuer une analyse manuelle dans IDA en reprenant le travail d’un collègue (partage de fichiers .idb via Skelenox) et partager ses résultats. En sortie, il est possible d’exporter des éléments techniques pour les analystes, des indicateurs de compromissions (IOC) pour les équipes de défense et de réaction sur incidents, et des rapports de synthèse, le tout filtré en fonction du niveau de sensibilité pour partager les bonnes informations aux bons interlocuteurs.
Gunpack : un outil générique d’unpacking de malwares
Julien Lenoir d’Airbus Group Innovation nous a présenté son outil Gunpack pour faciliter l’écriture de scripts pour l’unpacking de malwares.
Après un bref rappel sur le packing et l’état de l’art de l’unpacking (des outils existent, mais peu sont opensource et scriptables), l’orateur a présenté Gunpack qui fonctionne par une instrumentation du système d’exploitation (qui a l’inconvénient d’être détectable par un packer avancé). Il comprend deux composants : un pilote noyau et un processus Python.
Au niveau noyau, Gunpack identifie le comportement du packer en modifiant les droits des pages mémoire (ou-exclusif sur écrite et exécution) du programme analysé à son insu, et en interceptant les fautes générées. Les appels système (syscalls) sont aussi interceptés.
Ces événements collectés permettent de comprendre le fonctionnement du packer et d’écrire un script d’unpacking.
Les limitations actuelles de Gunpack sont les suivantes :
- Support du 32 bits uniquement
- Seul Windows 7 en mode PAE est supporté
- Ne fonctionne pas avec un packer utilisant un virtualiseur (le code original est modifié sous une forme de bytecode exécuté par une machine virtuelle propre au packer)
L’orateur a terminé en présentant quelques exemples concrets d’utilisation.
Cryptanalyse en boite noire de chiffrement propriétaire : étude de cas
Pierre Capillon, du Bureau Audit et Inspection de l’ANSSI, a présenté un cas pratique d’analyse en boîte noire d’un chiffrement propriétaire. L’objectif étant de mettre en défaut ces implémentations propriétaires pour montrer qu’elles ne sont souvent pas sécurisées (faux sentiment de sécurité) tout en démontrant les compétences et moyens nécessaires pour réaliser ces attaques.
Le contexte était celui d’un équipement embarqué propriétaire, protégé par un radiateur et qu’il était impossible d’endommager (prêt). Sans vulnérabilité sur l’équipement, le seul moyen d’analyser le firmware était de récupérer le fichier de mise à jour. Il se trouvait protégé par un mécanisme d’obfuscation/chiffrement auquel l’orateur s’est attaqué.
Il nous a montré les différentes étapes de son analyse, notamment les comparaisons effectuées entre deux versions pour distinguer les parties identiques et modifiées, ainsi que les différentes tentatives infructueuses (recherche d’opcodes et de conventions d’appel, fingerprinting de données façon binwalk, rétro-ingénierie du logiciel de mise à jour).
Au bout de 6 semaines (3 en équivalent temps-plein, au lieu des 2 jours initiaux prévus), les différents morceaux du fichier de mise à jour du firmware ont été obtenus en clair et ont révélé un binaire ELF de 42 Mo implémentant un OS temps réel complet et propriétaire en C++ obfusqué.
En conclusion, il a montré que la cryptographie faite-maison est souvent inversible, et il a découvert des vulnérabilités dans le firmware qui ont été corrigées depuis. Le fabricant a également changé l’algorithme.
Eurisko : développement d’une carte électronique sécurisée
Les auteurs de cette présentation sont : Arnaud Ebalard, Arnaud Fontaine, David Diallo, Jean-Pierre Flori, Karim Khalfallah, Mathieu Renard et Ryad Benadjila de l’ANSSI.
Ils se sont attelés à la création d’une carte électronique sécurisée (composant dédié certifié EAL5+) avec des objectifs fonctionnels et de sécurité.
Les objectifs fonctionnels étaient :
- Présence de deux interfaces réseau Gigabit Ethernet (par exemple pour servir de base à un routeur ou un HSM)
- Consommation inférieure à 5 W
- Taille réduite
- Utilisation de composants sur étagère libre d’accès (COTS)
Les objectifs de sécurité étaient :
- Noyau Linux durci avec grsec
- Code maîtrisé (le moins de code externe possible)
- Authentification pré-boot
- Intégrité du processus de boot
- Sécurisation des mises à jour
Les raisons de ce projet étaient :
- La montée en compétence (sur architecture ARM et en développement logiciel et matériel)
- La découverte de l’état de l’art des composants électroniques
- Les difficultés liées au processus de création façon industrielle
Ils nous ont ensuite présenté en détail les composants de la carte, dont le SoC qui boot sur une image servie de manière sécurisée depuis un autre composant de stockage lui aussi sécurisé. La chaîne de compilation ainsi que les règles de développement auto-imposées (langage C simple : C99, pas d’allocation dynamique, typage le plus fort possible, code linéaire et synchrone) ont aussi été dévoilées.
Leur retour d’expérience sur l’utilisation de composants sécurisés (ticket d’entrée et niveau de sécurité obtenu) et sur le prototypage R&D (expérience acquise, relations de sous-traitance et résultats obtenus) a été décrit en conclusion.
Évolution et dé-évolution des systèmes multimédias embarqués
Cette présentation de François Pollet (Thales Communication and Security) et de Nicolas Massaviol (Toucan System) portait sur la sécurité des systèmes embarqués présents dans les véhicules modernes. Elle se basait sur un retour d’expérience d’audit sur deux modèles de deux constructeurs différents non cités (deux versions d’un des modèles ont été revues).
Les deux modèles séparent le bus de communication (bus CAN) multimédia (qui sert au divertissement à bord : musique, téléphonie, etc.) du bus véhicule (qui sert à piloter et monitorer le moteur, les freins, etc.). Cependant, dans le premier cas, les boîtiers multimédia et télécom sont reliés aux deux bus (en faisant des cibles privilégiées) tandis que sur le second modèle, ils ne sont reliés qu’au bus multimédia et les messages passent une passerelle pour rejoindre le bus véhicule.
Concernant le boîtier multimédia, voici les vulnérabilités les plus sérieuses découvertes :
- Le port JTAG devait être désactivé en production mais ne l’était pas en pratique, et pour l’autre constructeur un port série avec mire d’authentification était accessible
- Fichier de mise à jour chiffré et signé, mais contournable
- Obtention d’informations (comme des mots de passe) dans les puces mémoire accessibles.
- Au niveau du système d’exploitation : le premier constructeur utilise des versions d’Android anciennes et vulnérables à des exploits connus, et le second constructeur expose un accès root sans mot de passe en plus d’une vulnérabilité dans la signature des mises à jour (il suffit de supprimer de l’archive le fichier contenant les signatures pour que la mise à jour modifiée soit acceptée).
Une fois ce boîtier compromis, l’attaquant peut diffuser de la musique très forte et impossible à couper afin de surprendre et perturber le conducteur, ou chercher à rebondir sur le bus véhicule pour saboter le fonctionnement physique du véhicule.
Concernant le boîtier télécom, ils ont noté une importante surface d’attaque (JTAG côté matériel, GSM/2G/3G côté radio et SSL côté applicatif) et ont découvert des vulnérabilités.
Ils ont conclu sur l’avenir des véhicules connectés avec l’autopartage dans le cloud, le démarrage à distance, la délégation de conduite en convoi, l’arrivée des véhicules autonomes et du PYOD (intégration smartphone et véhicule).
USBiquitous: USB intrusion toolkit
Benoît Camredon d’Airbus Group nous a présenté son projet USBiquitous qui est parti du constat de l’omniprésence du protocole et des ports USB qui s’accompagne d’une croissance du nombre de vulnérabilités découvertes. Afin de mieux auditer les périphériques et les implémentations de ce protocole il a créé un framework multi-composants : une carte matérielle (USBq Board) avec plusieurs interfaces et faisant tourner Linux plus un module noyau spécifique (USBq Core), une bibliothèque en espace utilisateur (USBq API) utilisée par des applications (USBq Apps)pour implémenter les fonctions désirées. La carte peut émuler un client ou un hôte USB, ou bien se placer en proxy.
L’orateur nous a ensuite présenté l’état de l’art (et le vide que comble son projet) et un bref rappel sur le protocole USB puis les différents composants du projet en détail.
Grâce à ces briques de base, il est plus facile d’implémenter des cas d’usage intéressants :
- En mode proxy : l’utilisateur peut observer et modifier les messages, les stocker sous forme de pcap pour analyse ultérieure, implémenter un pare-feu USB (ex : selon le type de périphérique) ou un keylogger, et générer des messages invalides par mutation pour détecter des bugs…
- En mode émulation de périphérique : simulation de clavier (façon RubberDucky / Teensy), fuzzing de l’implémentation USB de l’hôte (une vulnérabilité dans Windows a notamment été découverte), rejeu d’échanges précédemment capturés (utilisé par l’auteur pour résoudre une partie du challenge SSTIC 2015), énumération des classes de périphériques supportées par l’hôte…
- En mode émulation d’hôte : il est possible d’énumérer les périphériques USB connectés, d’implémenter des télécommandes pour périphériques spécifiques (ex. : lance-missiles USB), fingerprint le périphérique pour détecter la puce USB utilisée, implémenter l’attaque BadUSB…
En conclusion, l’orateur espère que ce projet pourra être utilisé pour identifier des vulnérabilités dans les hôtes et périphériques USB ou pour le pentest.
Confusion de type en C++ : la performance au détriment de la « type safety »
Florent Saudel, doctorant chez Amossys, s’est intéressé aux vulnérabilités liées à l’exploitation d’une confusion de type dans du code C++. Son travail est motivé par le fait que cette classe de vulnérabilité est à l’origine de six CVE permettant l’exécution arbitraire de code depuis le premier semestre de cette année.
De manière synthétique, cette vulnérabilité provient d’un mauvais « cast » (transtypage) dans le code lié à l’utilisation des quatre opérations de conversion de type : static_cast, reinterpret_cast, dynamic_cast et const_cast (la dernière ne provoquant pas cette vulnérabilité). Chacune implémente plus ou moins de contrôles sur les types de départ et d’arrivée, à la compilation ou à l’exécution, ayant donc des implications en matière de sécurité et de performance.
Un exemple simple permettant de comprendre le concept a été présenté suivi des primitives nécessaires pour l’exécution de code arbitraire : fuite d’information (accès à des informations sur la pile), corruption mémoire (écriture de données arbitraires) et détournement du flot de contrôle (exécution des données précédemment injectées et interprétées en tant que code).
En conclusion, il note que les classes de programmes les plus vulnérables sont les navigateurs et les interpréteurs. Également, l’exploitation de cette vulnérabilité peut être détectée à l’exécution par l’ajout automatique à la compilation de code qui contrôle la validité, mais qui a l’inconvénient de ralentir l’exécution.
My friends botnet: How to use your friends to perform Cyber Int ?
Amaury Leroy du CERT Airbus nous a expliqué son souhait ultime d’avoir une copie d’Internet (tout du moins des informations réseau : bases WHOIS, noms de domaine et adresses IP…) accessible hors-ligne pour effectuer des requêtes rapidement, de manière discrète et qui permettent un suivi des évolutions dans le temps.
Le problème posé est celui de la grande quantité de stockage nécessaire l’ayant amené à se tourner avec enthousiasme vers le cloud. Mais il a rencontré plusieurs difficultés (pas assez d’adresses IP de sortie disponibles sur Amazon EC2, bannissement des serveurs dédiés traditionnels pour cause d’usage abusif, VPS disponibles chez des hébergeurs exotiques peu fiables et déjà blacklistés, Tor insuffisamment performant…).
Il s’est donc attelé à la création de petits boîtiers qu’il peut disséminer chez ses amis, afin de répartir l’effort de collecte des données brutes, pour enfin les centraliser sur son serveur.
Il a ensuite montré deux cas pratiques d’exploitation des données :
- Les commentaires déposés sur les échantillons sur VirusTotal
- Les données d’historique DNS passif afin de suivre les actions d’un groupe d’attaquants
Composants logiciels vérifiés en F* : Poly1305
Benjamin Beurdouche et Jean Karim Zinzindohoue de l’équipe Prosecco (INRIA Paris et Microsoft Research INRIA) se sont interrogés sur la sécurité des composants critiques d’Internet, par exemple OpenSSL, et quel pourrait être l’apport des méthodes formelles.
Ils ont présenté le langage F* : open-source, orienté fonctionnel, types riches, interaction avec un solveur SMT (pré- et post-conditions). Pour la compilation, ces propriétés sont « effacées » pour laisser placer à de l’OCaml/F# qui est compilable.
Plusieurs propriétés peuvent être prouvées statiquement, dont la sûreté mémoire et la prévention des dépassements d’entiers.
Il a ensuite présenté une application concrète à l’algorithme de MAC (Message Authentication Code) récent Poly1305.
Broken Synapse
Ivan Kwiatkowski est intervenu pour nous présenter ses travaux sur le jeu Frozen Synapse. Son objectif était de lever le brouillard de guerre (qui masque certaines unités) pour obtenir un avantage sur ses adversaires.
Sa première analyse de trafic réseau avec Wireshark n’a pas été concluante, il a alors tenté une rétroingénierie de l’application avant de découvrir qu’il analysait un moteur de script connu (Torque Game Engine) et qu’il fallait plutôt qu’il se tourne vers les fichiers .cs.do qui contiennent la logique du jeu telle qu’écrite par ses développeurs sous forme de scripts compilés.
Ses travaux l’ont amené à écriture un émulateur/décompilateur de ce format : il parvient donc à réobtenir les scripts initiaux qu’il peut alors modifier et recompiler, pour les réinjecter dans le moteur et au final jouer avec sa version modifiée sans le brouillard de guerre.
L’intérêt de cette méthode est qu’elle se dispense de l’analyse du protocole réseau.
Un FizzBuzz pour le cyber
Éric Jaeger et Olivier Levillain de l’ANSSI se sont intéressés aux questionnaires de recrutement (à un emploi, ou dans leur cas, pour l’entrée dans une formation) avec l’objectif d’évaluer davantage la réflexion et l’aptitude à appréhender la sécurité par rapport aux connaissances pures.
Ils se sont inspirés du fameux test de recrutement pour développeurs intitulé FizzBuzz et nous ont montré plusieurs exemples de questions à choix multiples pour lesquelles il est possible de répondre sans calculer ni chercher sur le Web, et en quoi ils sont plus intéressés par le processus de réflexion, l’approche de résolution et les questions soulevées (côtés recruteur et candidat) que par les réponses exactes.
Voici des exemples de sujets abordés (les exemples de questions sont disponibles dans l’article) : mathématiques, culture informatique, cryptologie, shell, réseaux, langage C, gestion d’incidents.
