Compte-rendu du SSTIC 2016 - Jour 1

Du mercredi 1^er au vendredi 3 Juin 2016 s’est tenu le Symposium sur la Sécurité des Technologies de l’Information et de la Communication (SSTIC), qui a rassemblé plus de 450 participants pour sa 14^eédition.

Trois jours de conférences techniques se sont enchaînés, alternés d’un cocktail et du traditionnel « Social Event » en centre-ville de Rennes. Pas moins de 35 conférences ont été présentées par 59 orateurs, et 35 rumps (présentations très courtes de 3 minutes maximum) ont permis de détendre l’atmosphère jeudi après-midi. Le programme complet est disponible sur le site du SSTIC https://www.sstic.org/2016/programme/.

Voici le compte-rendu de la première journée.

La conférence d’ouverture a été présentée par Brad Spengler, auteur du projet grsecurity. Pour rappel, grsecurity est un projet de durcissement du noyau Linux visant à améliorer sa sécurité et à le protéger d’un large éventail d’attaques. Brad a commencé par détailler les nombreuses améliorations qui ont récemment été apportées à grsecurity (support ARM, protection contre des exploits récents, blocage des périphériques USB qui n’étaient pas branchés au boot – désactivable à la demande), y compris dans PaX, le patch en charge de la gestion de la mémoire (le but étant d’empêcher les corruptions de mémoire, qui peuvent conduire à de l’exécution de code).

Ensuite, l’auteur a donné son point de vue sur l’écosystème de la sécurité de l’information dans son état actuel : les acteurs de la sécurité manquent de recul et de regard critique, et succombent parfois au sensationnalisme (ce qui n’est pas sans rappeler le kickstarter proposant un routeur Tor pour protéger ses communications qui avait rencontré un vif succès avant que plusieurs failles de sécurité ne soient révélées). Il y a selon lui trop de conférences, décevantes au niveau de la qualité des articles et des présentations, qui ne sont par ailleurs pas forcément le meilleur moyen d’effectuer des transferts de connaissance. Il y a également trop « d’experts » qui se plaignent de l’état de la sécurité sans rien créer ou publier.

Enfin, d’après Brad : “il y a de plus en plus de bugs, mais la sécurité s’améliore”. Les attaques à l’état de l’art deviennent plus difficiles à réaliser, tandis que beaucoup de menaces plus « anciennes » continuent de peser sur les utilisateurs, comme les macros Office.

La conclusion de cette conférence d’ouverture, qui fait écho à la conférence de clôture est la suivante : « Security will never be achieved through bug reduction ». La sécurité doit être prise en compte dès la phase de conception, au lieu de consister à réparer les différentes failles au fur et à mesure de leur découverte.

La journée s’est poursuivie avec plusieurs conférences :

A. Chevalier, S. Le Berre, et T. Pourcelot (ANSSI / SOGETI) ont présenté un outil d’analyse collaborative de logiciels malveillants nommé Polichombr, publié sur le Github de l’ANSSI. Dans leurs travaux d’analyse et de rétro-ingénierie des logiciels malveillants, les auteurs ont été confrontés à la difficulté de traiter un grand volume de code de manière collaborative et ont décidé de créer Polichombr pour les assister. Cet outil permet notamment :

• Une centralisation des informations et du stockage des fichiers ;
• L’automatisation de tâches d’analyse (calcul des empreintes, découvertes des zones intéressantes dans le binaire…) ;
• La classification automatique des logiciels malveillants à l’aide de l’algorithme maison « MACHOC », qui utilise des patterns dans le « graphe de flot de contrôle » (Control Flow Graphen anglais) invariants lors d’une recompilation ;
• La synchronisation avec IDA pour récupérer le travail d’autres analystes (plugin Skelenox) ;
• L’export de règles de détection Snort et d’IOC (Indicators of Compromission) OpenIOC.

Julien Lenoir (Airbus) a présenté un outil développé en interne permettant de développer facilement des scripts d’unpacking en Python, pour des binaires Windows 32 bits. Les techniques de « packing » consistent à compresser, voire chiffrer tout ou une partie d’un binaire original. Dans le cas d’un logiciel malveillant, la charge utile est donc dissimulée et peut échapper aux contrôles des antivirus. Gunpack, qui s’est inspiré du moteur d’unpacking MutantX-S, effectue une reconstitution dynamique du payload à l’exécution en instrumentant l’OS pour suivre l’exécution du packer, et en tirer les informations utiles à l’écriture d’un unpacker.

Pierre Capillon (ANSSI), a présenté de manière didactique une analyse récemment effectuée sur un boîtier utilisant un algorithme de cryptographie propriétaire. L’accès physique au boîtier étant interdit, seules les attaques logiques ont pu être réalisées. Pendant 6 semaines, l’auteur a étudié les mises à jour du fimware disponibles publiquement pour comprendre le format de fichier utilisé, l’architecture de la puce, et a fini par trouver des vulnérabilités dans le firmware. De nombreuses techniques d’analyse, fructueuses ou non, ont été présentées, parmi lesquelles le calcul d’entropie du fichier à l’aide de binwalk (permet de savoir s’il s’agit d’un payload chiffré notamment), l’observation des modifications au niveau binaire entre des versions différentes du firmware, le fingerprinting de données binaires (formats de fichiers connus par exemple) et de structures habituelles de code… On retiendra notamment la capacité de l’auteur à identifier l’empreinte SHA256 de la chaîne vide dans un blob binaire, ou l’utilisation par le constructeur de l’algorithme ROT13 pour obfusquer des en-têtes ASCII. En conclusion, l’auteur souligne que la cryptographie propriétaire peut s’attaquer beaucoup plus facilement qu’on ne le croit.

7 agents de l’ANSSI sont ensuite venus présenter le projet Eurisko, prototype d’une carte électronique mettant en œuvre une chaîne de démarrage sécurisé intégrant un mécanisme d’authentification pré-boot. Eurisko a des objectifs fonctionnels et de sécurité et embarque notamment deux interfaces Gigabit ethernet sur une carte de 7x7cm à faible dissipation thermique (pas de ventilation), sur une base Linux grsecurity et une « base de code maîtrisée ». La chaîne de démarrage ne repose pas sur la sécurité de la BootROM (interne au System on Chip– abrégé SoC – puce centrale d’un circuit imprimé) mais sur un composant sécurisé dédié, certifié EAL 5+, contenant une mémoire flash protégée en confidentialité et en intégrité, ainsi que de sa propre source d’entropie et de fonctions d’accélération cryptographie matérielles. Notamment, l’intégrité et la sécurité des communications au sein même du circuit imprimé (notamment avec le SoC) sont vérifiées, pour qu’enfin le système d’exploitation soit déchiffré et exécuté depuis une carte microSD. La partie logicielle a également été durcie en respectant la norme C99, en interdisant l’allocation dynamique (prévention de la corruption de mémoire) et en gardant le code linéaire et synchrone (prévention des race conditions).

F. Pollet (Thales) et N. Massaviol (Toucan System) ont présenté une étude anonymisée de la sécurité des systèmes embarqués dans les véhicules, basée sur leurs expériences avec des grands constructeurs français. Ils ont notamment pu constater les différences d’architecture des systèmes multimédias. Les résultats sont sans appel : backdoors présentes dans certains composants (souvent à l’insu du constructeur) livrés par des prestataires, interfaces de développement non désactivées, ou mires de login facilement accessible, les points d’entrée sont nombreux et relativement facilement accessibles. Il leur a ainsi été possible de récupérer le contenu du fichier /etc/passwd (ou /etc/shadow) pour « rooter » le véhicule, ou d’exploiter l’absence de signature des mises à jour pour flasher un firmware arbitraire. Les systèmes d’exploitation utilisés dans les exemples étudiés étaient soit Android 2.2 ou 4.0 – pour lesquels plusieurs vulnérabilités sont connues – soit Linux, utilisant parfois un compte root sans mot de passe.

L’exploitation de ces vulnérabilités permet le détournement des fonctionnalités légitimes (diffuser du son à fort volume ou désagréable pour déstabiliser le conducteur), l’accès à internet, et potentiellement le contrôle des composants connectés au bus CAN. Enfin, les évolutions à venir dans le domaine de l’automobile comme le contrôle à distance pour le covoiturage (ouverture par smartphone), le platooning(véhicules qui se suivent de manière automatique pour former des convois) ou l’apparition de véhicules complètement autonomes, vont présenter des risques encore plus importants et nécessitent une maîtrise des risques bien plus rigoureuse de la part des constructeurs.

Benoît Camredon (Airbus Group) a présenté une série d’outils open-source d’analyse USB, permettant d’interagir avec les composants connectés ou directement avec l’hôte. Parmi les nombreuses possibilités offertes, nous pouvons noter la présence d’un proxy USB intégrant un dissecteur de paquets, d’un « pare-feu USB » en mesure de bloquer les clés USB, d’un keylogger, d’un fuzzer, mais aussi d’un scanner permettant de connaître les drivers USB disponibles sur l’hôte. Un mode « keyboard » permet aussi de réaliser des attaques similaires au Rubber Ducky en émulant un clavier, et un mode « replay » permet de rejouer des trames USB, qu’il s’agisse d’un lance-missile USB ou d’une impression vers une imprimante.

Florian Saudel, d’AMOSSYS, a expliqué la problématique des confusions de type en C++, où des hypothèses non vérifiées sur le type des objets passés à une fonction permettent d’exécuter du code arbitraire. Ces attaques reposent sur une mauvaise utilisation du polymorphisme et la présence de « bad cast ».

Jean-Karim Zinzindohoué (INRIA, équipe Prosecco) a présenté un langage de programmation fonctionnelle moderne dédié à la vérification formelle : F*, ainsi que son utilisation dans l’implémentation d’une primitive de code d’authentification de messages (Message Authentication Codes, mieux connus sous l’abréviation MAC) : Poly1305. Pour rappel, la vérification formelle permet d’assurer par des preuves mathématiques certaines propriétés d’un programme, comme le fait qu’il ne peut pas crasher, ou la confidentialité des données. Ces travaux font notamment suite à la publication d’une implémentation formellement vérifiée de TLS : miTLS, également développée par l’équipe Prosecco de l’INRIA.

Amaury Leroy (CERT Airbus Group) a présenté son projet de crawler dont le but est de récupérer des données diverses dans le cadre d’une veille : détection de mots-clés ou de changements significatifs dans l’infrastructure réseau (Whois, SSL, DNS par exemple).  Le passage à l’échelle sur les solutions cloud classiques comme Amazon EC2 est problématique car effectuer des millions de requêtes DNS ou de recherches Google par jour provoque un blocage rapide du crawler. L’auteur a donc réalisé un botnet en utilisant des Raspberry Pi et en les déployant chez des amis pour récupérer les informations nécessaires. Sa solution utilise notamment du SSH avec port knocking, le framework Rebus pour la communication, et Selenium / PhantomJS pour le scrapping d’informations.

Ivan Kwiatkowski a présenté une attaque contre le jeu de stratégie Broken Synapse, lui permettant de lever le brouillard de guerre et de gagner un avantage significatif dans ses parties en ligne. Il a pour cela d’abord intercepté les données HTTP échangées avec le serveur, sans réussir à interpréter les données retournées par le serveur. Il a ensuite choisi de reverser le code du jeu pour désactiver le brouillard de guerre quel que soit le mode de jeu, ce qui peut permettre à un attaquant de gagner facilement des parties et de monter au classement sur Steam de manière déloyale.

Éric Jaeger et Olivier Levillain ont présenté un questionnaire élaboré pour la sélection des candidats à la formation « Experts en SSI » du centre de formation de l’ANSSI, autour de la question : « comment évaluer efficacement un candidat lors d’un entretien ? ». FizzBuzz est un jeu (il faut compter jusqu’à 100 et dire « Fizz » pour les multiples de 3, « Buzz » pour les multiples de 5, et « FizzBuzz » pour les multiples de 3 et de 5) qui est également utilisé comme exercice lors du recrutement de développeurs, de manière apparemment efficace. Plusieurs autres exemples de tests en apparence simple mais révélateurs d’un état d’esprit ont été présentés.

La journée s’est terminée par un cocktail et a permis aux participants de se rencontrer et de discuter des sujets de la journée (et de la crue de la Seine).