Du 6 au 9 juin 2023, le Symposium sur la Sécurité des Technologies de l’Information et des Communications (SSTIC) a rassemblé les experts de la cybersécurité. Considéré comme l’un des évènements les plus importants de l’année dans le domaine de la sécurité informatique en France, le SSTIC a offert un évènement unique pour échanger des connaissances, présenter des recherches de pointe et explorer les nouvelles tendances en matière de défense numérique.
Le SSTIC est réputé pour son niveau technique important et cette année ne faisait pas exception. Nous avons eu la chance d’assister à des présentations de qualité, allant des concepts théoriques avancés aux applications pratiques, sur de multiples sujets comme la cryptographie, le reverse engineering, la recherche de 0-day ou le forensic. Les présentateurs, issus d’acteurs majeurs de la cybersécurité tels que des organismes gouvernementaux, universitaires ou acteurs privés, ont partagé leur expertise et ont offert aux participants un aperçu approfondi des dernières avancées dans le domaine.
Ultrablue
Lors de la première matinée, une conférence de l’ANSSI nous a particulièrement marqués : le projet Ultrablue. Celui-ci part d’un constat simple : il est primordial de garantir l’intégrité d’une machine qui a été laissée sans surveillance. Une méthode efficace pour y parvenir consiste à analyser la chaine de boot, qui comprend plusieurs étapes essentielles telles que l’UEFI, le bootloader, le kernel, l’initramfs avec chiffrement de disque et phrase de passe, ainsi que l’init. Chacun de ces éléments communique avec une puce TPM (Trusted Platform Module) pour renforcer la sécurité du démarrage.
Pour ce faire, il peut être très intéressant de vérifier l’état de la machine par rapport à un état enregistré sur un serveur d’attestation distant. Cependant, cette solution comporte plusieurs points négatifs : le serveur peut ne pas être joignable (par exemple si aucun accès Internet n’est disponible), la mise en place d’une telle infrastructure peut devenir rapidement couteuse suivant le nombre de machines à vérifier, etc.
La solution présentée par l’ANSSI consiste à utiliser le protocole Bluetooth avec son téléphone et exploiter ce dernier comme serveur d’attestation. Cette solution est actuellement disponible pour les clients Linux, tandis que des développements sont en cours pour rendre ce système compatible avec les plateformes Android et iOS.
Au démarrage, l’état du système est comparé avec l’état stocké sur le téléphone et si ce dernier a changé, le système envoie une indication sous forme de différence, similaire à la fonctionnalité « git diff » utilisée dans les systèmes de contrôle de version. Cette indication permet de déterminer précisément ce qui a changé et offre à l’utilisateur la possibilité de choisir s’il souhaite poursuivre le démarrage de la machine ou non, en fonction des résultats de cette comparaison.
Vous pouvez trouver davantage d’informations sur ce projet et accéder à son dépôt GitHub via le lien suivant : https://github.com/ANSSI-FR/ultrablue. Ce projet comprend également un banc de tests permettant d’évaluer la performance et la fiabilité du système d’attestation proposé.
GMSA
Un autre outil qui nous a particulièrement intéressés est gmsad, présenté par Vincent Ruello et William Bruneau du CEAg.
La mise en place d’un service Kerberisé sous Linux en environnement Active Directory nécessite plusieurs étapes cruciales. Tout d’abord, il est essentiel de créer un compte de service spécifique qui sera utilisé pour l’authentification Kerberos. Une fois ce compte créé, il faut positionner les clés Kerberos dans la keytab sur la machine Linux. Cela garantit que le système dispose des informations nécessaires pour effectuer l’authentification Kerberos.
Cependant, la gestion des mots de passe peut être un défi. Pour assurer la transparence de l’authentification Kerberos et faciliter la gestion des mots de passe, l’utilisation du gMSA est recommandée. Lorsque le mot de passe gMSA est modifié, les machines peuvent le récupérer jusqu’à ce qu’il soit mis à jour. C’est là que gmsad entre en jeu.
Disponible sur GitHub à l’adresse suivante : https://github.com/cea-sec/gmsad, gmsad permet la récupération et la mise à jour des mots de passe des comptes de services partagés. Il facilite également la gestion de la keytab, un élément essentiel pour l’authentification Kerberos. À partir du keytab d’un compte qui a la capacité de récupérer le secret d’un gMSA, gmsad crée un keytab pour le compte de service et le renouvèle lorsque c’est nécessaire.
Batterie Android
La gestion de la batterie sur une plateforme embarquée se révèle être un défi délicat. En effet, à ce jour, il n’existe pas de politique de protection claire en ce qui concerne l’accès aux capteurs de la batterie sur les plateformes Java et Android. Cette lacune expose à trois principaux risques nécessitant une attention particulière.
Tout d’abord, la vie privée des utilisateurs peut être compromise si l’activité de la batterie est journalisée sans leur consentement. Cette surveillance indésirable peut révéler des informations sensibles sur les habitudes et les comportements de l’utilisateur.
Ensuite, l’accès non autorisé à la batterie peut être utilisé comme un canal de communication caché entre deux applications malveillantes. Cela ouvre la porte à des échanges de données secrètes sans éveiller les soupçons des utilisateurs ou des mécanismes de sécurité.
Enfin, il est possible d’exploiter un processus sécurisé, tel que la saisie d’un code PIN, en espionnant les variations de la consommation de la batterie lorsque l’utilisateur touche l’écran. En analysant les pics de consommation associés à chaque pression, en tenant compte de leur fréquence et de la durée entre eux, il est théoriquement possible de retrouver les touches spécifiques tapées par l’utilisateur. Cette technique s’appuie sur l’utilisation de chaines de Markov pour reconstituer les séquences de touches.
Face à ces risques, il devient impératif de développer des politiques de protection et des mécanismes de sécurité robustes pour la gestion de la batterie sur les plateformes embarquées. Les concepteurs de systèmes doivent prendre en compte les implications en matière de vie privée et de sécurité lors de l’accès aux capteurs de la batterie et veiller à mettre en œuvre des mesures de protection appropriées pour prévenir toute exploitation malveillante.
Steam
Le deuxième jour, la conférence s’est ouverte sur la présentation d’une recherche de vulnérabilité dans Steam, présentée par l’entreprise Thalium.
Le programme de bug bounty de Valve sur HackerOne a permis de mettre en lumière des vulnérabilités dans certains de leurs produits, notamment dans la plateforme de jeux Steam. Étant donné la diversité des cibles potentielles sur Steam, comme le moteur, l’API et le client lui-même, les chercheurs se sont concentrés sur une fonctionnalité spécifique peu documentée appelée “Remote Play”. Cette dernière permet une connexion directe en pair-à-pair entre deux utilisateurs afin de permettre à un joueur ne possédant pas un jeu d’y jouer à distance sur la machine de l’autre joueur (un système rappelant RDP).
Le client Windows étant en grande partie protégé et obfusqué, les chercheurs se sont basés sur l’application Android contenant les noms de fonctions non obfusqués, ce qui a facilité l’analyse inverse (reverse engineering). Trois principales surfaces d’attaques ont été identifiées : les messages de contrôle, les périphériques HID à distance et les données audio/vidéo.
Un fuzzer nommé « rpfuzz » a été créé pour identifier les vulnérabilités potentielles. D’après les dires des chercheurs, de nombreuses failles ont pu être remontées, mais certaines étant en cours de traitement par Valve, seules deux vulnérabilités spécifiques ont été décrites: une vulnérabilité de type « format string » (fuite de mémoire à distance) permettant le contournement de l’ASLR, la fuite d’information sur l’environnement système de la victime, etc, et une vulnérabilité de type “request forgery” pouvant amener à la fuite de page web, au scan du réseau interne ou encore à pivoter sur des services vulnérables.
Toutes les informations collectées, y compris les fuites, sont envoyées en direct à l’attaquant via le canal « stats » mis à disposition par Remote Play.
Retour sur 20+ de CERT à l’ANSSI
La conférence de clôture réalisée par l’ANSSI nous a permis de plonger dans l’histoire du CERT-FR et de l’évolution des cyber-attaques de 1999 à aujourd’hui.
En 1999, le CERT-A est créé pour répondre à la peur du “bug de l’an 2000”. Il avait pour objectif de réaliser une veille technologique et répondre aux attaques informatiques. En 2001, la DCSSI (ancêtre de l’ANSSI) est née et prend en charge la protection des infrastructures vitales de l’état. L’ANSSI sera créée plus tard, en 2009.
En 2011, la compromission de Bercy est un tournant pour les équipes CERT de l’ANSSI. En effet, c’est la première opération d’analyse et de remédiation sur un réseau de grande ampleur. Cette attaque a notamment permis à l’ANSSI de structurer ses activités d’analyse et de remédiation. Elle a également donné l’idée aux équipes de l’agence de développer un outil d’analyse de large périmètre : DFIR-ORC. À la suite des incidents de Bercy, les intérêts politiques, diplomatiques, économiques et industriels français ont été constamment attaqués.
Après 2017, la tendance des attaquants n’est plus de cibler les OIV (Organisme d’Importance Vitale) ou entités étatiques directement, mais plutôt de compromettre leurs chaines d’approvisionnement ou encore leurs prestataires de conseils. En effet, la compromission du réseau informatique d’un prestataire peut permettre dans certains cas à un attaquant de rebondir sur le réseau interne de l’entreprise cliente (via des accès VPN, comptes sur l’Active Directory ciblé, etc.).
Dès 2021, la stratégie des attaquants évolue, ceux-ci ciblent maintenant les petites et moyennes entreprises présentent dans la chaine de sous-traitances des OIV.
Final words
En plus des présentations, le SSTIC a offert une multitude d’opportunités d’échanges et de networking. Les pauses café, les sessions de questions-réponses et les espaces de discussion informelle lors des social events ont favorisé les interactions entre les participants, les orateurs et les représentants des entreprises partenaires. Ces moments privilégiés ont permis de partager des idées, de tisser des liens professionnels et de renforcer la communauté de la cybersécurité.
