Blog

Akerva

Faites l’expérience de la sécurité active & réactive

Veille sécurité

Retour sur l’édition 2022 du SSTIC

Veille sécurité | 17/06/2022 Cette année 2022 aura permis le retour d’un évènement qui nous tient tous à cœur dans le monde de la Cybersécurité : le SSTIC. Cette version-ci a eu deux particularités, celle d’être la 20e édition de cette conférence mais aussi le retour en présentiel après deux années uniquement à distance. Les conférenciers et les spectateurs furent au rendez-vous avec plus de...

Cette année 2022 aura permis le retour d’un évènement qui nous tient tous à cœur dans le monde de la Cybersécurité : le SSTIC. Cette version-ci a eu deux particularités, celle d’être la 20e édition de cette conférence mais aussi le retour en présentiel après deux années uniquement à distance. Les conférenciers et les spectateurs furent au rendez-vous avec plus de 800 inscrits et un nombre important de spectateurs suivant les conférences en streaming.

Plusieurs thèmes ressortent de ces présentations, comme chaque année la cryptographie était présente, tout comme les attaques logicielles et matérielles ainsi que des présentations d’outils. Cependant, il est à noter la grande disparité des sujets abordés tout le long de ces trois jours avec aussi des conférences sur :

  • Le Forensic de Pegasus et GnuGP
  • La présentation des réseaux mobiles
  • L’évolution de la défense dans les réseaux locaux
  • La détection d’attaque
  • L’aide à l’audit de code

Voici un résumé des conférences qui nous ont le plus intéressées, que ce soit par leur thème, la manière dont elles étaient présentées ou encore pour un intérêt purement offensif. L’idée ici est de vous donner envie de regarder ces conférences. Vous trouverez donc les liens vers les vidéos et articles en fin de résumé.

 

Smartphone et forensique : comment attraper Pegasus for fun and non-profit

Étienne Maynier est un militant, analyste et chercheur en sécurité chez Amnesty International. Il nous a tout d’abord présenté l’objectif de son travail qui est de réaliser de l’analyse sur les manières informatique de s’en prendre à des défenseurs des droits de l’homme ou des ONG, avec entre autres, le logiciel-espion Pegasus.

L’analyse du logiciel a principalement été réalisée sur Iphone car il est difficile de réaliser un backup sous Android sans altérer l’état de l’OS car il faut un téléphone rooté pour y arriver, alors que cela peut être fait sur un Iphone uniquement avec Itunes et sans droit élevé.

NSO Group est une entreprise Israélienne créée en 2010 et qui a commercialisé le logiciel Pegasus. Ahmed Mansoor (un blogueur dans les Émirats Arabes Unis, militant des droits humains et des réformes) fut la première victime connue de ce logiciel, et depuis, des centaines d’autres personnes ont été infectées par ce dernier.

Durant ses premières campagnes, Pegasus utilisait comme vecteur de compromission un SMS contenant un lien activant ainsi des zero-days permettant de prendre le contrôle du périphérique. Amnesty international a découvert plus de 600 serveurs liés à cette attaque grâce à l’analyse des périphériques compromis. Une fois ces serveurs découverts et les papiers scientifiques sur le sujet publiés, les serveurs étaient décommissionnés et NSO Group en commissionnait de nouveaux.

La grosse évolution du logiciel-espion qui se produisit en 2018, fut le changement du moyen d’attaque, qui au lieu de passer par des SMS utilisait une redirection vers une page malveillante sur un réseau compromis. Puis, il activait là aussi des zero-days pour réaliser sa kill-chain à travers Safari au début puis dans d’autres composants ensuite.

Pegasus a aussi utilisé WhatsApp comme vecteur d’attaque, sur plus de 1 400 personnes. Meta a d’ailleurs porté plainte contre la société NSO Group, cette dernière étant au bord de la faillite à la suite des nombreux scandales qui ont éclaté après les révélations sur Pegasus.

Conclusion : La présentation a été appréciée car elle permet de se rendre compte de l’évolution de ce type de logiciel espion mais aussi des cas d’usages, que ce soit pour réaliser de l’analyse dessus mais aussi pour ceux qui voudraient utiliser ce genre de logiciel et pour quelles raisons. De plus, le présentateur a appuyé sur le côté traumatisant que ce genre d’attaque peut avoir pour des gens qui se rendent compte que soudainement une entité peut tout savoir de leur vie en ayant accès à l’intégralité de leur téléphone.

 

La signalisation chez les opérateurs mobiles

Benoit Michau, chercheur et expert dans la sécurité des réseaux télécoms chez P1 Security, nous a introduit au monde de la téléphonie mobile et de son infrastructure.

Afin de mieux comprendre le principal sujet de sa présentation, il faut savoir que le front et le back end téléphonique possédés par les différents opérateurs mondiaux ou locaux cohabitent afin de permettre à tout un chacun d’émettre et de recevoir des appels, peu importe le pays dans lequel on se trouve. Les paquets échangés entre eux sont des paquets de signalisation permettant de transmettre de l’information sur un abonné (métadonnées et échanges protocolaires) et des paquets contenant des données telle que la voix.

Le principal problème à cette cohabitation vient du fait que les échanges entre ces différentes infrastructures ne sont pas sécurisés, laissant la possibilité aux attaquants de tenter de s’introduire dans ces infrastructures ou de voler des informations personnelles y transitant. Pour résumer, une fois passé l’accès au réseau initial qui lui est chiffré, aucune protection n’est présente : les données sont en claires et non signées. Ainsi, on peut accéder à la géolocalisation des utilisateurs, intercepter leurs données, les corrompre, etc.

Plusieurs attaques ont été présentées, ainsi que les contre-mesures associées. Voici l’une d’entre elles qui s’appuie sur un principe d’attaque par l’homme du milieu.

  • L’objectif en premier lieu est de récupérer l’IMSI de la personne (c’est-à-dire son identifiant unique lié à son numéro de téléphone permettant de l’identifier sur le réseau).
  • Un peu de recherche doit ensuite être réalisé avec cet identifiant afin de savoir quel front end prend en charge cet abonné, c’est-à-dire quel opérateur pour simplifier.
  • La dernière partie de l’attaque se déroule lorsque l’attaquant fait croire au back end qu’il est le front end légitime et a le droit de recevoir tout ce qui est normalement routé à cet abonné (appels, SMS, connexion de données). Pour finir, l’attaquant redirige le trafic vers le front end légitime sans que son attaque soit découverte.

Une des contre-mesures possibles est la mise en place d’un SMS Home Routeur, qui permet d’éviter de délivrer l’IMSI d’un client à une entité qui le demande, qu’elle soit légitime ou non. Cela permet une certaine confidentialité tout en évitant l’attaque que nous avons vu au-dessus.

Mais il existe aussi pour se protéger de l’anti-spoofing et la mise en place de filtrage sur la signalisation ce qui permet de détecter toute demande réalisée de façon trop nombreuses pour être légitime.

Comme expliqué précédemment, certaines mesures de protection peuvent être mises en place par les opérateurs, mais le principal problème est qu’il n’y a aucune obligation légale au sujet de la sécurité de ces réseaux et qu’elles diffèrent fortement d’un opérateur à l’autre.

Conclusion : Ce talk est une bonne porte d’entrée afin de mieux comprendre la sécurité des réseaux mobiles. Un petit CTF est même fourni pour s’entrainer : https://ctf.p1sec.fr

 

Ica2Tcp : Un proxy SOCKS pour Citrix

Cette conférence met en lumière un problème que tout pentester a eu une fois dans sa vie : proxyfier une connexion vers un environnement Citrix. C’est le sujet de ce talk présenté par Hugo Clout, Pentester chez Synacktiv.

Voici une citation du résumé de la conférence sur le site de SSTIC : « Il est à ICA ce que l’option -D est à la commande ssh d’OpenSSH : il permet d’exposer une interface SOCKS5 sur un port local qui est redirigé à travers la connexion ICA établie jusqu’au serveur distant » qui je trouve décrit parfaitement ce que fait l’outil.

Parlons un peu plus du protocole ICA maintenant, qui est le protocole frère de RDP, car il fonctionne comme et permet les mêmes actions que ce dernier, c’est-à-dire l’envoi et la réception de flux (audio, vidéo…) depuis un client lourd vers et depuis un serveur. Il possède lui aussi des « virtual channels » et c’est là toute l’idée du développement qu’a réalisé Hugo Clout afin d’utiliser la connexion ICA déjà ouverte pour faire passer notre trafic en ouvrant un canal virtuel custom. Pour résumer rapidement, un canal virtuel est un tunnel utilisé afin de faire passer de l’information ayant trait à une fonctionnalité en particulier, par exemple, le copier-coller.

Malheureusement, depuis octobre 2021, l’option « virtual channel allow list » est activée par défaut du côté du serveur Citrix et bloque les channels virtuel custom, demandant à l’administrateur de les autoriser explicitement dans cette fameuse liste.

Cela pourrait rendre l’outil caduc, même s’il se peut que la liste blanche de canal virtuel soit désactivée par l’administrateur qui n’a pas le temps ou l’envie de s’en occuper.

De plus Hugo Clout propose comme solution, afin de bypasser cette protection, de faire en sorte de remplacer le driver côté client du canal virtuel et écraser côté serveur, si on peut, les exécutables qui sont autorisés à l’utiliser. Il ignore cependant si cela va réellement permettre de bypasser la protection.

Conclusion : Un outil intéressant pour les pentesters.

 

OASIS: un framework pour la détection d’intrusion embarquée dans les contrôleurs Bluetooth Low Energy

Présentation faite par Romain Cayre, doctorant au sein de l’équipe TSF du LAAS-CNRS et Clément Chaine.

Le BLE (Bluetooth Low Energy) est un protocole Bluetooth à faible consommation avec une pile protocolaire simple qui a souffert de multiples vulnérabilités. Cependant, il n’est pas forcément possible de patcher les périphériques qui l’utilisent.  Ces derniers restent donc vulnérables à des attaques publiques qui peuvent être détectées.

Dans un premier temps, la présentation liste plusieurs attaques comme GATTACKER, BTLEJUICE ou encore BTLEJACK qui globalement permettent soit de faire des attaques de l’homme du milieu, soit du hijacking. Dans un second temps, Romain Cayre présente la manière de fonctionner du framework de détection qui se concentre principalement sur les attaques visant le protocole et non pas les implémentations.

Pour mettre en œuvre la détection, le présentateur explique qu’il a été nécessaire de faire du reverse engineering sur le protocole et de se concentrer sur la localisation des données permettant de constater l’attaque. Une fois ces données localisées, le Framework OASIS va poser des « hooks » dans les « firmwares » modifiés pour intercepter les données et alimenter la détection.

Pour les 6 attaques les orateurs ont mené des tests avec des jeux d’attaques et des jeux d’utilisation normaux afin d’évaluer la qualité de leur détection. Leur taux de détection est supérieur à 94%, ce qui en fait une solution efficace.

Conclusion : Une présentation qui permet de mieux comprendre les attaques sur BLE et ensuite de réaliser comment la détection peut être mise en place sur des périphériques qu’on ne peut pas mettre à jour facilement.

 

DroidGuard: A Deep Dive into SafetyNet

Romain Thomas, Ingénieur Sécurité chez UL nous présente son travail sur le composant SafetyNet s’occupant de vérifier l’intégrité du système d’exploitation Android. Ces contrôles sont utilisés par les développeurs pour prévenir le lancement d’application sur le périphérique qui contredirait les besoins de sécurité définis mais il est aussi utilisé par Google pour prévenir la fraude et les abus.

DroidGuard est un composant de SafetyNet avec un code qui est mis à jour et dont l’obfuscation est modifiée toutes les deux semaines et ce qui augmente considérablement la difficulté pour l’analyser. Il possède environ 60 classes et une partie obfusquée contenant une VM.

L’idée de cette présentation était de décrire l’état de l’art de l’implémentation de SafetyNet et plus particulièrement les mécanismes internes derrière SafetyNet et DroidGuard. Il a été réalisé une explication du fonctionnement de la VM et des vérifications réalisées pour détecter l’utilisation de Magisk, la mise en place d’émulation, du root du périphérique ou encore de Pegasus.

Conclusion : Ce talk permet de mieux comprendre les sécurités mises en place sur un Android, mais aussi de constater que des protections contre Pegasus sont présentes dans l’OS, ce qui fait un lien avec la présentation du premier jour.

 

Lost in translation : Comblez le fossé entre AppSec et développeurs avec CodeQL

Les failles de sécurité dans les logiciels open source comme dans la librairie Log4J peuvent entraîner des conséquences sérieuses sur la sécurité du parc informatique mondial. La question que se pose le présentateur est : Comment une vulnérabilité présentée en 2016 à la Black Hat peut être encore présente en 2021 et aboutir à ce que nous avons connu avec Log4Shell ?

Ainsi, Xavier René-Corail qui est directeur du Security Lab de GitHub, nous a présenté la solution que lui et son équipe ont développé pour aider à l’audit de code source et plus spécifiquement améliorer la sécurité des projets open source.

Citation d’une partie de la présentation écrite sur le site du SSTIC : « Le GitHub Security Lab a été créé avec cette mission de réparer le pont entre les chercheurs en sécurité informatique et les développeurs open source. Et pour cela, CodeQL est un outil majeur de notre attirail. CodeQL peut accélérer votre travail, le traduire et le déployer concrètement chez les développeurs et enfin rapprocher les deux communautés pour collaborer sur la sécurité du code. »

En prenant comme exemple la vulnérabilité Log4J, Xavier René-Corail nous a présenté son outil. Il a réalisé sous nos yeux un module CodeQL permettant de rechercher un pattern dans le code audité et ainsi lister facilement toutes les méthodes où ce pattern était découvert.

Conclusion : C’est un outil qui semble puissant et facile d’utilisation pour un auditeur, même s’il demande une certaine connaissance en développement et donc ne peut pas être utilisé par n’importe qui. La fonctionnalité de pouvoir créer des modules d’audit et de les partager à la communauté nous semble tout à fait correspondre à la logique de l’open source et de l’augmentation de la sécurité pour tous.

 

Pour aller encore plus loin…

Nous tenons à vous conseiller la présentation de Fabrice Desclaux et Frédéric Vannière sur « la mise en quarantaine du navigateur ». Un talk sur un sujet intéressant et réalisé de façon plutôt énergique. Je n’en dirais pas plus pour ne pas gâcher la surprise.

Mais aussi « Sasusb : présentation d’un protocole sanitaire pour l’USB » par Fabrice Desclaux et Louis Syoën, pour son côté didactique et la mise sous lumière d’un sujet épineux ; « comment faire pour assainir une clef USB potentiellement malicieuse ? »

Ainsi que « Évolution de la sécurité défensive des réseaux locaux : historique, SD-LAN et micro-segmentation, vers le zero-trust » de Josselin Mouette, Architecte chez EDF et « Network detection is not dead (or why we aren’t always too late) » de Chloé Huet – Le Rumeur qui sont intéressants pour l’approche réseau qu’ils offrent.

 

Les RUMPS :

Plusieurs RUMPS furent intéressantes, dont la « Stabilo Boss » d’Etienne Sellan. Afin de ne pas vous spoiler les petites trois minutes de la présentation, je dirai juste que non content d’avoir trouvé une vulnérabilité, Etienne Sellan s’est aussi permis de la corriger avec les moyens du bord. On vous la conseille donc fortement. Il y a aussi : « Comment *ne pas* concevoir son portefeuille matériel » de Nix ou encore « Et là, couic SMB ! » de Vlad qui sont toutes deux à regarder.

Voilà, c’est fini pour ce résumé du SSTIC 2022. Je me permets aussi de remercier les organisateurs pour ce Symposium 2022 ainsi que tous les conférenciers.

Tom, Consultant Sécurité Akerva

Actualités & blog

Restez informé des dernières actualités d'Akerva

RESTEZ INFORMÉ DES ACTUALITÉS AKERVA

ABONNEZ-VOUS À NOTRE NEWSLETTER