XMCO a pu assister à l’édition 2023 de Quarks in The Shell qui s’est tenue au Campus Cyber de La Défense le 18 avril 2023.
L’évènement proposait une dizaine de conférences permettant aux professionnels autant qu’aux passionnés de sécurité informatique d’y trouver leur compte. Ainsi, la matinée était dédiée au retour d’expérience de Martin Undersinger au sein du “Projet Pegasus” ainsi qu’aux travaux de recherche et développement de QLab sur divers sujets comme l’outil Pastis, les problématiques de sécurité de Google App Script, sans oublier le protocole MLS (Messaging Layer Security), ou bien les méthodologies d’exploitation de moteurs JavaScript et en terminant avec un retour d’expérience sur l’audit de l’IDS open source Falco.
L’après-midi était, quant à elle, destinée à des échanges et des bonnes pratiques ainsi que des démonstrations autour des deux logiciels de Quarkslab, QFlow et QShield. La problématique centrale retenue était “Comment protéger vos applications, clés et données contre les attaques statiques et dynamiques ? Comment réduire les risques liés au transfert de fichiers (en analysant les emails et URLs) ?”. Afin d’y répondre, divers sujets ont été abordés tels que :
- La cryptographie en boîte blanche,
- Prouver la légitimité des objets connectés,
- Compilation et obfuscation,
- L’utilité des workflows,
- Les moteurs d’analyse et les malwares.
Pegasus : autopsie d’un scandale
Pour cette première présentation, Martin Untersinger, journaliste au Monde, est revenu en détail sur le logiciel espion israélien, Pegasus, ayant fait l’objet d’un scandale durant l’année 2021. Pour cette présentation, il a répondu à la question : “Comment enquêter quand notre principal outil de travail, notre smartphone, est potentiellement compromis ?”
Cette présentation est détaillée et pleine d’exemples concrets puisque Martin Untersinger a lui-même fait partie du consortium de journalistes à l’origine des révélations faites durant l’année 2021. Ce consortium, sous l’égide de Forbidden Stories, était composé de plus de 80 journalistes de 17 médias internationaux ainsi que l’ONG Amnesty International qui a apporté toute son expertise informatique.
Nous avons appris que durant ces 6 mois d’enquêtes, la crainte d’être parmi les “victimes” du logiciel était au cœur de l’enquête. En effet, les journalistes ont œuvré dans l’ombre afin que ni NSO Group, l’entreprise ayant conçu et commercialisé Pegasus, ni leurs clients ne soient au courant de cette enquête. Parmi ces clients, on retrouve une vingtaine de services de renseignement.
Pour illustrer ses propos, Martin Untersinger nous a expliqué qu’ils ont fait un rollback (retour en arrière) technologique en utilisant par exemple des téléphones portables classiques et non des smartphones. Mais une seconde difficulté, et non des moindres, fut la récupération d’appareils potentiellement compromis afin d’en faire une analyse forensique et détecter des traces de compromissions par Pegasus. En effet, toujours dans un souci d’extrême discrétion auquel la confiance des tiers s’ajoute, les journalistes ne pouvaient pas simplement aller à la rencontre de potentielles victimes et leur demander qu’ils leur confient leur téléphone ainsi que la sauvegarde complète de leur cloud (par exemple les sauvegardes iCloud pour les iPhones).
Malgré toutes ces difficultés, le consortium de journalistes a réussi à mener à bien son enquête et mettre en lumière les violations des droits de l’homme perpétré par les clients de NSO Group grâce à son logiciel. Cela a abouti à des sanctions, des procès, d’autres enquêtes complémentaires et des lois à l’encontre de NSO Group, mais aussi à des correctifs des vulnérabilités mises en cause par le logiciel espion.
Messaging Layer Security : plus on est de fous, plus on chiffre
Lors de cette présentation, Angèle Bossuat, ingénieure cryptographe au sein de Quarkslab, nous a présenté le futur standard de sécurité pour les messageries sécurisées et plus particulièrement au niveau de la gestion de la sécurité lors des conversations de groupe.
Les conversations à 2, dites tête-à-tête, offrent un très bon niveau de sécurité et respectent les principes de secret de transmission et de sécurité post-compromission. En revanche, lors des conversations de groupe, une façon, simple mais très coûteuse, d’appliquer ce protocole tête-à-tête sans perdre de sécurité consiste à voir le groupe comme plusieurs paires, et donc à envoyer le même message autant de fois qu’il y a de paires.
Et s’il existait un meilleur moyen de maintenir la sécurité et d’être efficace ? C’est en répondant à cette question qu’Angèle Bossuat nous a présenté Messaging Layer Security (MLS).
Ce protocole de sécurité implémente des Asynchronous Ratcheting Trees (ART) qui permettent une gestion plus sécurisée, plus simple et moins coûteuse des conversations de groupe sans oublier une meilleure gestion des membres du groupe (entrée & sortie).
Dans la construction de l’Asynchronous Ratcheting Tree (ART), des clés de groupe intermédiaires sont construites à chaque feuille de l’arbre. Il est important que toutes les parties se mettent d’accord sur la structure exacte de l’arbre afin de dériver les mêmes clés. De plus, il n’est pas nécessaire d’attendre qu’un autre membre du groupe réponde à un message pour effectuer le protocole d’échange de clés et de dériver la clé de groupe partagée. Un protocole efficace permet à un membre d’un groupe ART de mettre à jour ses clés personnelles et d’établir une nouvelle clé de groupe partagée, en utilisant la structure arborescente sous-jacente du groupe.
Pour conclure cette présentation, Angèle Bossuat nous a confié que le protocole MLS venait d’être soumis à l’IESG (Internet Engineering Steering Group) le 27 mars 2023 afin d’être approuvé en tant que standard de chiffrement de bout en bout de messages de groupe et de publier la RFC associée.
Un jeu de funambules : la cryptographie en boîte blanche et ses compromis
Au cours de cette présentation, Matthieu Daumas nous a introduits à la cryptographie en boîte blanche, avec l’objectif de rester loin des considérations purement mathématiques.
On y apprend que le défi à relever est d’implémenter des algorithmes de chiffrement et déchiffrement de manière à ce que les actifs cryptographiques soient sécurisés même dans le cas où un attaquant aurait accès à toutes les procédures et au matériel employé.
En effet, dans le cadre d’implémentations matérielles classiques, il est nécessaire de mettre en place des protections contre les attaques par canaux auxiliaires ou encore d’utiliser des enclaves sécurisées pour éviter le vol des secrets cryptographiques comme les clés privées.
Ce que l’on retient, c’est qu’une boîte blanche parfaite n’a pas encore été inventée, toutes celles ayant été proposées ont été cassées. Comme dans beaucoup de cas en cryptographie, la sécurité est assurée grâce à la complexité en temps des attaques qu’il serait nécessaire d’utiliser pour casser les primitives mathématiques sous-jacentes (comme le logarithme discret dans le cas de Diffie-Hellman ou la décomposition en nombre premiers avec RSA). L’important n’est pas de trouver une boîte blanche parfaite, mais d’assurer un bon compromis coût / performance.
En parlant de coût, il est bon de noter que le coût en termes de temps de calcul de l’utilisation d’une boîte blanche est très élevé, d’un facteur de plusieurs centaines de milliers. Ce coût supplémentaire augmente d’autant plus que la boîte blanche assure une forte sécurité.
Méthodologie d’exploitation de moteurs JavaScript
Avant-dernière présentation avant la pause de midi, Emmanuel Genier et Adam Taguirov nous ont présenté différentes méthodes d’exploitation des moteurs JavaScript V8 (utilisé par Chrome) et JSC (composant de WebKit utilisé notamment par Safari ou le navigateur de la PlayStation).
Dans la première partie, nous avons découvert de quelle manière sont disposés en mémoire les objets JavaScript. Dans la seconde, des méthodes d’exploitation basiques ont été présentées : addrof et fakeobj. La première permet d’obtenir l’adresse d’un objet JavaScript et la seconde permet d’injecter dans le moteur une valeur arbitraire qui sera interprétée comme l’adresse d’un objet.
La troisième partie a consisté en la généralisation de ces deux primitives vers une lecture et une écriture arbitraire. Enfin, un exemple complet d’exploitation du moteur V8 a été présenté dans la quatrième partie.
Pour terminer, différents mécanismes de protection mis en place par WebKit et JSC sur iOS nous ont été présentés. Ceux-ci ont pour principal objectif d’éviter l’exploitation du genre d’attaques démontrées précédemment.
Google Apps Script : ce talk requiert l’accès à vos mails
Nicolas Kovacs et Sébastien Rolland, ingénieurs chez Quarkslab, nous ont expliqué le fonctionnement de la plateforme Google Apps Script ainsi que les problèmes de sécurité liés à celle-ci, à travers la présentation de plusieurs scénarios d’attaques.
En effet, dans un premier temps, ils nous ont expliqué que Google Apps Script est une plateforme permettant de développer facilement des applications interagissant avec celles de Google (Google Sheets, Gmail, Google Docs, Google Drive, …). Cette plateforme peut être utilisée par des particuliers, et des entreprises qui utilisent Google Workspace. Son utilisation principale est pour l’automatisation de certaines tâches entre les différentes applications de Google.
Ils nous expliquent par la suite, que des utilisateurs malveillants peuvent créer des scripts dans le cadre de certaines attaques, comme l’hameçonnage.
L’un des scénarios présentés est le suivant : un attaquant va créer une application implémentant un script malveillant. Par exemple, ce script pourrait permettre de récupérer les fichiers stockés dans l’application Google Drive de la victime en les exfiltrant vers un autre Google Drive, ou en l’envoyant par mail à l’attaquant. L’accès à cette application reste néanmoins difficile, car une page intermédiaire va apparaître, indiquant que l’application n’a pas été vérifiée.
Dans un second scénario, le principe reste le même, mais l’objectif est de contourner cette page. Si une entreprise utilise Google Workspace, alors l’accès à des applications créées dans ce Workspace sera considéré comme « sûr », la page intermédiaire ne s’affichera pas. Il faut donc pour cela que l’application soit créée en interne avant de pouvoir faire exécuter le script par un employé.
Raphael, Florian et Louis-Albert
