Dans le cadre de notre participation au SSTIC 2016, nous vous avions partagé en exclusivité
le compte-rendu de notre 1ère journée.
On continue avec le compte-rendu de la 2
ème journée, avec un joli programme en perspective !
N'hésitez pas à réagir.
Bonne lecture !
A first glance at the U2F protocol
Ce jeudi matin, Mickael Bergem a présenté avec Florian Maury une étude réalisée pendant son master et pour le compte de l’ANSSI, portant sur U2F – Universal Second Factor. U2F est un protocole d’authentification forte créé par la FIDO Alliance qui repose sur un token physique (ou logiciel) et communiquant en USB, en Bluetooth ou en NFC (pour les smartphones par exemple). Déjà disponible comme second facteur d’authentification sur les sites de Google, Github et Dropbox, il apporte des garanties de sécurité et une facilité d’utilisation supérieures aux solutions reposant sur l’envoi de codes par SMS ou la génération de codes TOTP (Time-based One-Time Passwords). Il permet notamment de se protéger contre les attaques par phishing, alors que les solutions précédentes sont inefficaces.
U2F intègre également une protection contre les attaques Man-In-The-Middle TLS, c’est-à-dire lorsque l’attaquant est directement sur le chemin réseau et est en mesure de présenter un certificat TLS accepté par le client (attaque difficile à réaliser). Pour cela, U2F repose actuellement sur une extension TLS nommée « TLS Channel ID », qui n’est implémentée que sur les serveurs de Google (dans leur librairie
BoringSSL). En revanche, la vérification de cette attaque est volontairement désactivée, pour éviter de bloquer les clients utilisant un proxy TLS, le proxy agissant alors comme un MITM TLS. Cette protection avancée n’est donc pour le moment pas utilisable (non supportée ou non vérifiée), U2F restant néanmoins une solution simple et efficace comme second facteur d’authentification. Une comparaison avec l’utilisation de certificats TLS clients (authentification mutuelle) montre que cette dernière solution est à préférer dans les contextes sensibles (interface d’administration par exemple), bien que plus difficile d’utilisation.
How not to break LTE crypto
Benoît Michau et Christophe Devine (ANSSI) ont présenté une revue du modèle de sécurité en LTE (4G), ainsi que plusieurs vulnérabilités trouvées dans des modems 4G fabriqués par Qualcomm, Mediatek et Samsung. Certaines implémentations acceptaient jusqu’en 2013 le contrôle d’intégrité nul (EIA0) pour toutes les connexions, ce qui permet de faire de l’interception en utilisant une fausse
base station LTE. Plus récemment, une attaque par analyse différentielle a permis d’extraire le secret partagé d’une carte SIM, permettant de déchiffrer toutes les communications passées ou présentes de l’utilisateur, car aucun mécanisme de
Perfect Forward Secrecy n’est utilisé en LTE. D’autres vulnérabilités permettent de demander aux terminaux de communiquer sans chiffrement, permettant de récupérer l’APN et l’IMSI, ou encore de récupérer l’IMEI d’un terminal en utilisant un « bit de politesse » qui une fois passé à 1 désactive les vérifications (ce bit est censé n’avoir aucun effet, d’après la norme). On notera également l’apparition des mots « ordiphone » (pour smartphone) et… « biscuits de pile » (pour
stacked cookies) dans cette présentation de l’ANSSI, qui a particulièrement fait réagir la sphère Twitter.
Méthodologie d’extraction de signatures issues des signaux AIS
Erwan Alincourt et Pierre-Michel Ricordel (IRENav / ANSSI) ont présenté leurs expérimentations pour détecter les signaux AIS forgés. AIS, pour Automatic Identification System est un système de suivi de la localisation des navires, permettant d’identifier et de suivre les navires, par la communication de leurs coordonnées GPS.
D’après les chiffres présentés, 1% des navires transmettent des fausses données, dont 44% sont des navires chinois : les falsifications sont triviales et ont par exemple permis à des navires iraniens de passer le blocus ou à des pêcheurs de sortir des zones de pêche autorisées sans être repérés. À l’aide d’adaptateurs RTL-SDR (par exemple, un simple tuner TNT) et d’une carte HackRF, les auteurs ont réalisé des acquisitions dans la rade de Brest, et ont analysé les caractéristiques des signaux recueillis (temps de montée et de descente de l’émetteur, temps avant et après modulation, corrélation entre puissance du signal et distance). Ces différentes informations leur ont permis d’identifier avec certitude un répéteur (connu) de signaux, situé à terre. Le maintien d’une base de connaissance et la vérification de la stabilité temporelle de l’empreinte des émetteurs peut permettre de détecter les faux émetteurs. Améliorer AIS en ajoutant une couche de sécurité est coûteux car cela nécessiterait de changer le protocole et les matériels, mais augmenter le coût de l’attaque en développant ces techniques de fingerprinting apparaît comme un axe de progression intéressant.
Comparaisons et attaques sur le protocole HTTP2
Dans cette présentation, Georges Bossert a d’abord rappelé que HTTP/2 est grandement basé sur SPDY, un protocole non standard développé par Google dont le but est de réduire la latence en utilisant une seule connexion TCP pour toutes les connexions HTTP à un même site. Il a ensuite détaillé une comparaison des piles protocolaires entre Apache, h2o, Tomcat et Nginx, pour mettre en évidence les différences d’implémentation de HTTP/2 entre ces serveurs web. Pour cela, Georges a construit un « vocabulaire d’entrée », identifié les cas limites (négation des MUST, SHOULD, MAY de la RFC) et lancé une inférence active de l’automate d’état de ces implémentations, grâce à LSTAR (L*, réimplémenté en Python pour l’occasion). En sortie, on obtient des graphes d’automates à état où il est possible de visualiser les différences et les écarts à la norme. Plusieurs utilisations peuvent être faites de ces graphes :
■ Créer un « smart-fuzzer » en partant d’un état légitime grâce au graphe, puis en essayant de passer sur des états illégitimes : cette approche a permis de provoquer des crashs de nginx, apache, et deux « bugs sécurité » sur h2o par exemple ;
■ Créer un outil de fingerprinting quand les traces sont différentes, permettant d’identifier l’implémentation : cette approche est concluante après 3 échanges ;
■ Faire de l’évasion d’IDS (Intrusion Detection System), en exploitant le non-respect des spécifications pour échapper au contrôle de l’IDS, par exemple en utilisant le fait que nginx maintient la connexion après des erreurs fatales.
Évolution des techniques d'attaques de circuits intégrés
Cette « conférence invitée » a été présentée par Olivier Thomas, CEO de Texplained, qui a expliqué de manière très intéressante les différentes attaques sur les circuits intégrés. Trois classes d’attaques sur les semi-conducteurs peuvent être identifiées :
■ Les attaques non invasives consistent par exemple en l’utilisation de « VCC glitchs » (perturbation de l’alimentation) ou de « Clock glitchs » (perturbation du signal d’horloge). L’analyse de la consommation d’un circuit (Simple ou Differential Power Analysis) est également une technique non invasive, qui peut permettre de récupérer une clé privée par exemple.
■ Les attaques semi-invasives nécessitent un accès direct au circuit intégré et un équipement plus important (et plus coûteux) et consistent principalement à faire de l’injection de faute à l’aide d’un laser de précision (« laser glitching » ou « laser fault injection »). En utilisant la bonne longueur d’onde (1064nm, infrarouge) le silicium est transparent pour le laser, qui peut directement accéder aux composants, et l’impulsion laser permet par exemple de déclencher un transistor sur commande. L’injection automatisée permet de « scanner » tout un circuit pour détecter les transistors provoquant un changement d’état particulier (par exemple, passage de la puce en mode administration, ou développement). Il est également possible d’utiliser le laser pour scanner la puce dans un premier temps, ce qui permet d’atteindre une plus grande précision dans les tirs. Enfin, il est possible de déterminer l’emplacement de l’horloge en localisant des « points de photoémission » (transition périodique). Ces attaques, lorsqu’elles sont ciblées, permettent par exemple de devenir « super-utilisateur » à coups de laser !
■ Enfin, les attaques invasives sont généralement destructrices pour la puce, car elles consistent à retirer successivement les couches du circuit pour obtenir un plan précis de son architecture, en utilisant des produits chimiques (Chemicals only), des produits chimiques et une abrasion mécanique (Chemical Mechanical Polishing), ou encore un plasma qui vient arracher des électrons (Plasma Etcher). Sur certaines puces dites shielded, un maillage entoure toute la puce et déclenche une « autodestruction » logique (effacement de toutes les mémoires) lorsqu’une maille est sectionnée. Il faut alors ruser en passant entre les mailles pour poser des sondes (Microprobing), ou bien appliquer des « pansements » sur les mailles sectionnées pour empêcher la détection.
Différentes techniques d’obfuscation de la puce ont également été présentées, comme l’utilisation de Silicium non dopé (ROM), ou l’utilisation de faux liens. En revanche, ces techniques n’arrêtent pas Olivier Thomas, qui explique qu’il peut extraire une carte complète (22000 portes) en une semaine en utilisant le bon matériel et le bon logiciel. Il cite notammen,t le logiciel ARES, qui effectue de la reconnaissance automatique d’image sur les images des tranches de la puce. Le coût d’une attaque sur ces puces n’est donc pas si élevé qu’on ne l’imagine, surtout en sous-traitant certaines opérations au lieu d’acheter le matériel adéquat, et peut descendre à moins de 30 000€ par exemple. En fonction de la puce, un nombre réduit d’exemplaires est suffisant pour mener complètement l’attaque (50 exemplaires pour une puce en 22nm, 5 pour du 65nm).
En conclusion, ces attaques sur circuits imprimés – qui nécessitent certes de l’expérience, et un peu de matériel et d’argent – sont relativement accessibles, et peuvent être vite rentabilisées une fois que l’analyse a été faite une première fois, ce qui pose la question de la réévaluation de l’échelle des Critères Communs.
App vs Wild
![]()
Dans cette conférence, Stéphane Duverger (Airbus) explique comment protéger en confidentialité le code (chiffré et signé à l’origine) d’une application dans un environnement hostile, ou compromis. En se basant sur Ramooflax, solution de virtualisation légère et libre présentée au SSTIC 2011, l’auteur choisit de virtualiser la mémoire physique pour pouvoir y stocker le code du programme déchiffré. La mémoire virtualisée est cloisonnée entre le système d’exécution complet (« VM RAM Origine » sur le schéma) et le code de l’application (stocké déchiffré, « VM RAM Secret » sur le schéma), tous deux disponibles à tout instant mais de manière exclusive : après vérification de l’intégrité de la RAM « Secret », les pages mémoires correspondantes sont passées en mode eXecute-only (grâce aux fonctions Intel EPT). Le code s’exécutant dans la partie « VM RAM Origine » ne peut donc pas accéder en lecture au code stocké déchiffré dans la « VM RAM Secret ». Le filtrage repose uniquement sur des considérations matérielles et ne dépend pas du système d’exploitation, bien que seuls les binaires ELF32 soient à ce jour supportés. Cette solution est encore en cours de développement mais pourrait permettre d’apporter un niveau de sécurité supplémentaire dans la protection en confidentialité du code d’applications.
Winbagility : débogage furtif et introspection de machine virtuelle
Nicolas Couffin, de la DGA MI (équipe IMPS), a présenté un outil permettant le débogage furtif de systèmes Windows. Dans le cas de l’étude d’un code malveillant, l’analyste a besoin d’éviter que le code ne détecte la modification de la machine virtuelle dans laquelle il est exécuté. Il n’est donc pas possible d’utiliser le débogueur de Microsoft (WinDbg). Dans l’objectif d’obtenir un environnement réaliste, il est nécessaire de conserver Patchguard activé, de ne pas être détecté par le logiciel malveillant, de pouvoir analyser de manière dynamique l’exécution du logiciel. L’auteur a ainsi présenté FDP, pour Fast Debugging Protocol, qui repose sur une modification de VirtualBox pour pouvoir interagir facilement avec le système invité. L’auteur a ensuite présenté un second outil, Winbagility, qui s’appuie sur FDP, et permet de poser des breakpoints hardware (des HardwareBreakpoints, des HyperBreakpoints, et même des HardHyperBreakpoints). Ses propriétés le rendent difficiles à détecter depuis le logiciel analysé, et en font un outil rare dédié à l’introspection furtive sous environnement Windows.
Déverrouillage d'Android en simulant un clavier/souris
![]()
Antoine Cervoise nous a ensuite présenté un outil permettant de « bruteforcer » les interfaces de verrouillage de terminaux Android, en simulant des entrées clavier ou souris sur le port
On-the-Go (OTG) des téléphones. Pour cela, il a utilisé un Arduino pour simuler les entrées clavier/souris HID, piloté par un Raspberry Pi. Une webcam USB connectée au Raspberry Pi permet de détecter la réussite du déverrouillage du téléphone, en utilisant la librairie ImageMagick.
En utilisant les listes de codes PIN et codes de déverrouillage les plus fréquents, il a donc été possible de trouver le code valide en quelques heures, malgré les délais parfois obligatoires entre des tentatives échouées (à raison donc de 100 mots de passe en 20 minutes).
On peut noter que ces attaques ont permis de mettre en évidence des failles dans des téléphones Samsung, qui plantaient après un certain nombre de tentatives, en laissant l’écran déverrouillé pendant quelques secondes, avant de verrouiller le téléphone de nouveau.
Enfin, une autre technique décrite dans l’article permet d’améliorer les résultats : « la divination peut être utilisée notamment en analysant les traces de doigts sur le téléphone afin de réduire le nombre de codes possibles et de tester manuellement les possibilités restantes ».
The Metabrik Platform: Rapid Development of Reusable Security Tools
Patrice Auffret est l’auteur de
The Metabrik Platform, un framework d’outils de sécurité (du pentest au forensic) associé à un shell et un « vrai » (l’auteur a insisté) langage de programmation, Perl. Metabrik utilise des « Briks » comme modules, dans la même veine que Metasploit. Ce projet permet d’automatiser un certain nombre de tâches, par exemple en chaînant des Briks pour atteindre un objectif plus rapidement. Les Briks sont hautement modulaires, et peuvent par exemple hériter d’une ou plusieurs autres Briks, ou être personnalisées et améliorées. En moins de 4 lignes dans Metabrik, il est donc possible de lancer une VM avec Virtualbox, de prendre un snapshot, d’exécuter un programme, puis de produire un fichier de différences sur l’état de la machine Windows. D’autre Briks permettent d’analyser simplement des fichiers et d’en extraire des données (par exemple, des métadonnées dans une image compressée). The Metabrik Platform est disponible et prêt à l’utilisation, avec plus de 200 Briks, sur le site
https://www.metabrik.org/.
DYODE : Do Your Own DioDE, une diode open-source à moins de 200€ pour les réseaux industriels
Dans cette présentation, Arnaud Soullié (Solucom) a montré comment fabriquer une diode réseau, c’est-à-dire ne laissant passer les données que dans un seul sens. Cette diode a la particularité de coûter environ 200€ alors que les diodes disponibles dans le commerce ont souvent un prix bien plus élevé (et des performances également supérieures), et elle est donc par exemple adaptée aux systèmes industriels qui ont des besoins en performance relativement faibles. L’ensemble est constitué de deux Raspberry Pi pour les guichets d’entrée et de sorties, de convertisseurs Cuivre-Optique
À ce jour, 3 modes sont disponibles : le transfert de fichiers, le transfert de données Modbus, et le partage d’écran (sans interaction). Le code est disponible sur
GitHub.
Nous reviendrons sur ce projet Solucom dans un article dédié.
Résultats et solution du challenge du SSTIC 2016
Comme chaque année, le SSTIC propose un challenge au public, constitué d’une série d’épreuves à résoudre. Parmi les épreuves de cette année, on notera entre autres : la présentation des épreuves au travers d’un RPG en Javascript, l’utilisation d’un secret partagé de Shamir pour reconstituer une clé, la rétro-ingénierie d’un programme TI-Basic (pour calculatrice), l’analyse de traces GSM et SMS depuis un enregistrement de SDR (Software Defined Radio), la rétro-ingénierie d’une archive sparse de 117To, d’un binaire Itanium (ia-64 bits), ou l’analyse d’une police TrueType.
Plusieurs outils open-source ont été améliorés par des participants du challenge. Les vainqueurs au classement rapidité sont Nicolas Iooss, Fabien Périgaud, et Eric Dangereux, au classement qualité : David Berard, Romain Carré, et Fabien Périgaud. Au classement ubiquité (solution pour toutes les épreuves) Fabien Périgaud est le seul classé. Ce dernier, présent dans les trois classements est également venu présenter une partie des solutions du challenge. Quelques chiffres enfin sur cette édition du challenge, qui a été téléchargé 2054 fois, et dont 100 participants ont validé le premier niveau, 45 le niveau 2 et 23 le niveau 3 (avec un seul participant accédant au classement ubiquité).
Rumps !
Un moment attendu au SSTIC est celui des rumps : des orateurs viennent présenter un sujet technique ou non, en 3 minutes montre en main, souvent de manière humoristique. Le public peut choisir d’accorder quelques dizaines de secondes supplémentaires aux orateurs en restant silencieux mais peut également choisir d’applaudir bruyamment pour précipiter la fin de la présentation, appuyée par un lance-missile USB pointé vers l’orateur et automatiquement armé au bout des 3 minutes. Petit florilège des différentes présentations :
■ « Pourquoi c’est flou » (Pierre Capillon) a décrit le fonctionnement du système de vidéoprojection et de streaming en direct des conférences sur internet, et démontré l’art des organisateurs pour arranger les câbles réseau et les convertisseurs vidéo ;
■ « Évolution de Fuddly depuis le SSTIC 2015 » (Eric Lacombe) a annoncé les améliorations apportées à son framework de fuzzing et de manipulation de données en Python, qui intègre des algorithmes de mutation automatisée, des attaques sur des piles réseau, et d’autres nouveautés intéressantes ;
■ « Near Field Beers » par Fabien Périgaud a montré qu’il était trivial d’usurper une carte NFC pour boire gratuitement dans les bars utilisant des tireuses en libre-service, à l’aide d’un Proxmark3 ;
■ « RAM & Disk EFI Dumper » par Solal Jacob, a partagé son expérience d’investigation numérique sur un ordinateur portable chiffré, en écrivant un dumper de RAM vers une clé USB, depuis lequel il est possible d’extraire les clés de chiffrement ;
■ « Étude d’un disque lolifrant » par Julien Lenoir et Raphaël Rigo, a présenté l’insécurité d’un disque dur externe protégé par un code PIN, après reversing du microprocesseur du disque : à partir d’un ordinateur il est possible de demander le code PIN directement au disque dur, sans l’avoir déverrouillé, ce qui rend inutile cette protection ;
■ « De la difficulté des communications sécurisées » par Guillaume Tessier, a décrit le protocole ZRTP (VoIP) et présenté des failles d’implémentation dans Linphone, application répandue de téléphonie sur IP ;
■ « R2M2 » par Guillaume Valadon a présenté un outil composé de radare2 et de miasm2 pour faciliter l’analyse de code ;
■ Dans « Comment ne plus avoir de pubs ? », Charles Hourtoule a présenté un outil pour augmenter artificiellement et gratuitement son nombre de followers ou de likes sur Twitter ;
■ « Fighting malware like a boss » (Pierre Chifflier et Fabien Pichot) a présenté une méthode originale pour contrer les logiciels malveillants : leur faire croire qu’ils sont analysés par des outils classiques comme des antivirus ou des outils d’analyse dynamique ;
■ « Amsterdam » par Eric Leblond, a présenté une infrastructure SELKS (ISO live avec Suricata, ElasticSearch, Kibana, Logstash, Scirius pour les jeux de signature) basée sur Docker (avec utilisation de docker-compose) pour monter un IDS facilement ;
■ « AJPy » par Julien Legras a présenté une bibliothèque pour attaquer les flux AJP ;
■ « Winning crap with Twitter API » a expliqué comment gagner des lots grâce à robot qui participe à des jeux-concours sur Twitter ;
■ « IDMEF et IODEF » par Thomas Andrejak, a présenté les formats de remontée d’incidents de sécurité IDMEF et IODEF, ainsi que des librairies développées pour faciliter l’utilisation de ces formats ;
■ « Vos empreintes sont-elles sûres ? » par Lucas Barthelemy et Léo Rannou à propos de l’usurpation des systèmes de reconnaissance digitale ;
■ « libECC » par la team du projet Eurisko de l’ANSSI, a décrit la librairie développée « maison » avec des objectifs de compatibilité, de sécurité et d’agilité cryptologique ;
■ « Manalyze » par Ivan Kwiatowski, est un analyseur statique pour exécutables PE ;
■ « Analyse d’un Exploit Kit Angler » par Kevin Denis, a présenté une analyse d’un code Javascript obfusqué avec plusieurs niveaux d’encapsulation, qui affiche en réalité… une iframe ;
■ « Just do it the hard way » (Mathieu Renard) a présenté avec un humour particulier les attaques hardware ;
■ « You are not alone » de Aska, a présenté une série de citations des interlocuteurs des équipes sécurité côté « défense », particulièrement humoristique (« Mais vous ne voulez quand même pas qu’on suive toutes les CVE qui s’appliquent à notre produit ? ») ;
■ « IVRE more » (Florent Monjalet) a présenté un outil de veille sur les réseaux extérieurs, auquel des modules de cartographie active et passive a été ajouté, dont les résultats sont représentés de manière visuelle ;
■ Dans « Univershell et Attaque contre Android Face Unlock », Antoine Cervoise a présenté rapidement l’association Univershell (workshops sécurité) ainsi que la déclinaison de son attaque sur les motifs de déverrouillage de téléphone ;
■ « Die hard » de Philippe Trébuchet, a présenté une attaque au niveau physique sur un dispositif « de désamorçage » en utilisant entre autres un BusPirate ;
■ « Dynamically detecting smart XSS with evolutionary fuzzing methods and machine learning involving cyber algorithms - Quelques échecs de GreHack » a finalement présenté après une parenthèse humoristique un retour d’expérience sur l’organisation de la conférence GreHack.
Après cette journée très riche, les participants ont pu se retrouver lors du Social Event organisé dans le centre-ville de Rennes.
Mickaël BERGEM
