Comme tous les ans, XMCO vous propose une revue de certaines conférences du SSTIC.
Le SSTIC, Symposium sur la Sécurité des Technologies de l’Information et des Communications, est une conférence francophone réputée pour la qualité technique des sujets présentés.
Cette édition marquait les 20 ans de la conférence, et son retour en présentiel, dans l’enceinte du couvent des jacobins à Rennes après 2 éditions à distance pour des raisons sanitaires.
Références SSTIC :
- Site officiel : https://www.sstic.org
- Programme de Conférence : https://www.sstic.org/2022/programme/
- Direct : https://streaming.sstic.org
- Actes : http://actes.sstic.org/SSTIC22/sstic-2022-actes.pdf
Smartphone et forensique : comment attraper Pegasus for fun and non-profit, Etienne Maynier @tenacioustek
Lors de cette présentation, Étienne Maynier, membre de l’organisation AmestyTech, branche technique de l’Organisation de défense des droits de l’Homme Amnesty International est revenu sur la chronologie et la méthodologie utilisée lors de l’investigation ciblant le logiciel espion Pegasus publié en juillet 2021.
M. Maynier a commencé par un bref historique de la surveillance ciblée de certains défenseurs des droits humains, rappelant notamment qu’au début des années 2010, des sociétés européennes occupaient le marché des outils de surveillance privé, mais que ces entreprises s’étaient effondrées suite à de nombreuses révélations les concernant. Après ce bref historique, il a présenté la genèse de NSO Group, société éditrice de Pegasus, basée en Israël et employant plus de 800 personnes. Celle-ci, succédant aux sociétés européennes spécialisées dans le secteur, s’est démarquée par sa promesse de pouvoir pirater les iPhones (les précédentes sociétés ciblant principalement Android et Windows), notamment via l’utilisation de vulnérabilités 0-day (inconnues de l’éditeur).
Il a ensuite enchainé sur le fonctionnement global de Pegasus (infrastructure de Commande & Contrôle), les difficultés liées à son étude (suppression automatique du malware, non-persistance). M. Maynier a notamment exposé une technique utilisée pendant son enquête et qui lui a permis d’identifier le réseau de serveurs d’anonymisation utilisé par le malware.
Une présentation des différents modes d’infections a ensuite été effectuée, mettant en avant l’utilisation de certaines vulnérabilités 0-day et 0-click, reposant pour certaines sur de l’injection de trafic HTTP. Il a également été fait mention de la difficulté croissante à contourner la sécurité des iPhones (cf. https://www.sstic.org/2022/presentation/an_apple_a_day/), ainsi que de certains schémas d’infection reposants sur des applications tierces telle que WhatsApp.
La suite a consisté en un passage plus technique, dans lequel M. Maynier a détaillé les méthodes de forensiques utilisées lors de ses analyses. La présentation s’est axée sur l’investigation pour iPhone, reposant notamment sur l’analyse des backups du téléphone. Il a souligné la difficulté à réaliser une analyse de masse, du fait des faibles privilèges disponibles sur les téléphones et de l’impossibilité de rooter/Jailbreaker des téléphones à grand échelle, surtout ci ceux-ci appartiennent à des tiers. De plus, Pegasus possède des mécanismes de suppression en cas de jailbreakage de l’appareil.
Il a ensuite présenté un outil développé par son équipe dans le cadre de leurs investigations : Mobile Verification Toolkit (https://github.com/mvt-project/mvt). Cet outil permet d’évaluer si un téléphone a été compromis par Pegasus, ainsi que d’extraire et préanalyser plusieurs artefacts forensiques utiles pour vérifier son état d’intégrité. Le présentateur a insisté sur le fait qu’Apple et Google avaient, à plusieurs occasions, prévenu des utilisateurs que leurs mobiles avaient été infectés par le malware. La conférence DroidGuard: A Deep Dive into SafetyNet, présentée le lendemain, a également mentionné un mécanisme de détection du malware Pegasus, cette fois-ci via l’API Safetynet.
Etienne Maynier a conclu sa conférence en notant que la solution pour lutter contre ces malwares ciblant les défenseurs des droits humains n’était pas technique, mais passait d’abord par des accords internationaux visant à empêcher leur développement en limitant l’existence légale d’organisations comme le NSO Group.
Binbloom v2, Damien Cauquil @dcauquil
Damien Cauquil est chercheur en sécurité informatique chez Quarkslab et spécialisé dans le reverse engineering. Lors de ce SSTIC 2022, il a présenté la version 2 de l’outil Binbloom.
Cet outil a pour objectif d’aider les chercheurs à trouver les informations nécessaires au chargement d’un firmware (programme informatique intégré dans un matériel) dans un désassembleur.
En effet, l’étude des firmwares nécessite généralement l’extraction de données de la mémoire. Cependant, il arrive de se trouver face à une mémoire inconnue, dont nous il est impossible de savoir comment les informations sont stockées dans la mémoire et comment ces données sont chargées dans la mémoire du système. Ces informations peuvent être disponibles sur la documentation technique du constructeur… ou pas.
C’est là qu’intervient, Binbloom v2. L’outil aide les chercheurs à trouver les informations suivantes :
- Le boutisme (endianness) : ordre dans lequel les octets sont placés
- L’adresse de base : première adresse où la mémoire du firemware est chargée
- Base de données UDS : vérifie si la mémoire possède un tableau contenant les ID des commandes UDS.
Binbloom v2 apporte surtout une nouvelle méthode afin de déterminer l’adresse de base du firmware, et c’est sur celle-ci que le conférencier s’est étendu.
La majorité des outils existants (rbasefind, basefind.py, basefind.cpp, ou même Binbloom v1) essaient de trouver des données pertinentes dans le contenu d’un firmware comme des chaînes de texte ou des pointeurs, et les utilisent pour récupérer l’adresse de base avec plus ou moins de succès. Cependant, ces outils ne supportent pas, par design, les architectures 64 bits. De plus, si le firmware ne contient pas de chaine de caractères et possède plusieurs kilo-octets de données, l’analyse statistique a peu de chance de donner des résultats probants. Sur une architecture 32 bits, il est possible de trouver l’adresse de base en testant toutes les adresses possibles (soit 4.294.967.295 adresses possibles), ce qui est infaisable dans un temps raisonnable pour une architecture 64 bits (35.184.372.088.831 adresses possibles).
C’est pourquoi Damien Cauquil s’est penché sur la recherche d’une méthode unifiée pour les architectures 32 et 64 bits ne nécessitant pas de tester toutes les combinaisons possibles.
La méthode présentée consiste à trouver des pointeurs qui sont des adresses renvoyant à un ou plusieurs emplacements spécifiques où d’autres données sont stockées. Ces pointeurs sont très intéressants, car ils sont basés sur l’adresse de base du firmware avec un déplacement spécifique, appelé offset, et peuvent être utilisés pour trouver l’adresse de base. Une fois les pointeurs identifiés, il est possible de réaliser une liste de potentielles adresses de base candidates.
Pour cela, il faut tout d’abord différencier les blocs de code (contenant un set de fonctions) et les blocs de données (utilisées par les fonctions). Afin de trouver les blocs de données, Binbloom v2 calcule l’entropie de Shannon en fonction d’un offset particulier. En effet, les blocs de données ont généralement une entropie située entre 0 et 0.5 (seuil défini de manière expérimentale sur des architectures connues). Une fois le bloc de données identifié, Binbloom v2 recherche des points d’intérêts, c’est-à-dire des chaînes de texte ou tableaux de valeurs similaires. Ces derniers ont de grandes chances d’être référencés dans le code via un ou plusieurs pointeurs. De ces points d’intérêts, il est possible d’établir une liste d’adresses de base candidates.
Pour chaque adresse de base candidate, Binbloom v2 établit un score en fonction du nombre de pointeurs menant à des points d’intérêts avec une pondération servant à minimiser l’impact des faux positifs. Finalement, Binbloom v2 renvoie à l’utilisateur une liste des meilleures adresses de base candidates sans utiliser de bruteforce.
Pour résumer, la méthode proposée par Damien Cauquil est la suivante :
1. Calculer l’entropie afin de déterminer les blocs de code et de données
2. Rechercher les points d’intérêt (chaînes de texte et tableaux de valeurs similaires) dans les blocs de données
3. Générer une liste d’adresses de base candidate
4. Pour chaque adresse candidate, considérer le nombre de pointeurs valides (c’est-à-dire des pointeurs pointant sur des points d’intérêt) et calculer un score
5. Afficher les 10 meilleurs candidats, du score le plus élevé au score le plus bas.
Cependant, Damien Cauquil souligne 2 axes d’amélioration. Tout d’abord, la détermination des blocs de code et de données basée sur l’entropie peut varier d’une architecture à l’autre. Les seuils utilisés par Binbloom v2 sont génériques et peuvent manquer de précision pour certaines architectures spécifiques. Deuxièmement, Binbloom v2 dépend toujours de l’utilisateur final pour fournir des informations sur la taille des données de base de l’architecture cible (32 ou 64 bits).
Binbloom v2 est disponible sur le répertoire GitHub suivant : https://github.com/quarkslab/binbloom
Plus d’informations peuvent être trouvées sur l’article de blog rédigé par Damien Cauquil : https://blog.quarkslab.com/binbloom-blooms-introducing-v2.html
La signalisation chez les opérateurs mobiles, Benoit Michau et Marin Moulinier
Benoit Michau et Marin Moulinier ont présenté leurs travaux concernant la signalisation chez les opérateurs mobiles pendant cette édition du SSTIC 2022. Il a été mis en évidence les différents problèmes de sécurité existant dans l’infrastructure réseau des opérateurs mobiles. Ces problèmes exposent les abonnés à différentes attaques telles que des tentatives de fraude ou de l’espionnage.
Tout d’abord, la signalisation dans les réseaux mobiles concerne tous les messages permettant :
- L’attachement d’un abonné à un réseau (identification, authentification et localisation de l’abonné à travers son IMSI qui est unique et l’identification du terminal à travers l’IMEI)
- L’initiation et le routage des appels, des SMS et des connexions de données
- La gestion de la mobilité d’un abonné (roaming)
Chaque message de signalisation est rattaché à un abonné unique. En d’autres termes, ils contiennent des informations à caractère personnel se devant d’être sécurisées.
Afin d’expliquer les différents problèmes liés à ces messages, l’infrastructure des réseaux mobiles doit être explicitée.
Tout d’abord, chaque opérateur mobile est composé d’un « back-end » contenant les profils des abonnés et stockant les SMS des abonnés de l’opérateur vers leurs destinataires. Un « front-end » est aussi présent afin de prendre en charge les services et connexions des abonnés ainsi que de maintenir à jour leur localisation.
Les opérateurs sont interconnectés à travers des IPX/GRX (IP exchange et GPRS Roaming eXchange) afin d’échanger les messages de signalisation. Ainsi, quand l’abonné est à l’étranger, c’est le front-end de l’opérateur à l’étranger qui va chercher le back-end d’origine de l’abonné à travers ces fournisseurs d’IPX/GRX.
Plusieurs entités ont donc accès aux réseaux de signalisation. Tout d’abord les fournisseurs d’IPX/GRX (une dizaine dans le monde),mais aussi les opérateurs importants du marché qui s’interconnectent en direct, et les fournisseurs de services tiers avec un business model particulier comme l’envoi de SMS en masse. Il est cependant difficile de connaitre précisément le nombre d’entités présentes sur ce réseau. Chaque entité est censée déclarer à la Global System for Mobile Association (GSMA) son infrastructure (650 environ). Cependant, de nombreux fournisseurs de services tiers et de petits fournisseurs se mettent directement en relation avec les fournisseurs d’IPX/GRX afin de s’interconnecter avec les autres entités.
Ainsi, l’accès aux réseaux de signalisations nécessite une petite infrastructure et un accès auprès des fournisseurs d’IPX/GRX (environ 1000$/mois). La porte d’entrée pour mener différentes attaques ne nécessite donc pas de moyens étatiques. Toute entité souhaitant voler des informations à caractères personnels, sous couvert de vouloir faire du commerce en tant que service tiers, peut ainsi accéder aux messages de signalisation à un coût raisonnable.
Une fois sur le réseau de signalisation, les messages transitent en clair :aucune cryptographie n’entre en jeu afin d’assurer la confidentialité ou la provenance des messages.
Maintenant que l’infrastructure des réseaux mobiles, l’accès aux signalisations contenant des données à caractères personnels et le profil des attaquants ont été établis, nous allons présenter les différentes attaques possibles, décrites par Benoit Michau lors de la conférence.
Il existe 3 principaux types d’attaques :
- L’obtention de l’IMSI d’un abonné à partir du MSISDN (numéro de téléphone) : précurseur à toutes les autres attaques, il permet de récupérer les informations personnelles de l’abonné
- La localisation d’un abonné (savoir quel front-end le prend en charge) : précurseur aux attaques de détournements, elle permet de connaitre la localisation approximative d’un abonné, voire de détourner la localisation
- Le détournement des SMS, appels ou connexions de données via une attaque de l’homme du milieu: pour cela, l’attaquant doit tout d’abord obtenir l’IMSI de l’abonné et localiser le front en charge de l’IMSI. Ensuite, l’attaquant se fait passer pour un « front-end » et indique au « back-end » d’origine que l’abonné est chez lui (en l’absence de cryptographie, le « back-end » fait confiance aux messages qu’il reçoit et relocalise l’abonné chez l’attaquant). Ainsi, l’attaquant reçoit tous les services envoyés vers cet abonné.
Pour tenter de se prémunir contre ses attaques, différentes protections, plus ou moins efficaces, sont mises en place actuellement. Tout d’abord, les fournisseurs d’IPX/GRX mettent en place des systèmes anti-spoofing et du filtrage concernant les messages de signalisation. De même, les opérateurs mobiles tentent de réduire la possibilité de retrouver l’IMSI à partir du MSISDN (numéro de téléphone) et mettent aussi en place un filtrage des messages de signalisation.
Ce filtrage de la signalisation est composé de 3 catégories, définies par la GSMA dans des guides techniques pour la sécurité du roaming:
- Catégorie 1 : messages interdits pour le roaming
- Catégorie 2 : messages autorisés pour les roamers-in
- Catégorie 3 : messages autorisés par les roamers-out
Cependant, ce filtrage rencontre certaines difficultés, notamment pour différencier une localisation légitime d’une localisation illégitime.
Pour résumer, l’absence de régulation mondiale laisse les opérateurs et les fournisseurs d’IPX/GRX s’autoréguler, en favorisant une logique de rentabilité plutôt que la sécurité des abonnés. En effet, les opérateurs sont peu enclins à empêcher l’espionnage des réseaux de signalisation, car cela n’engendre pas de perte financière pour eux. Cependant, certains régulateurs nationaux arrivent à imposer des mesures aux fournisseurs. Mais la mise en place de moyens de défense demande des investissements financiers et humains considérables, tout en demeurant perfectible. En tant qu’abonné, il n’y a pas grand-chose à faire. Pour l’heure, il n’existe aucun moyen de voir que l’on est traqué, car les messages de signalisation, contenant nos données sont entièrement gérés par les opérateurs. Pour le moment, il est seulement possible de protéger le contenu de ses communications en passant par des applications de messageries sécurisées et en éteignant le portable pour éviter la géolocalisation.
Analyse forensique de la mémoire de GnuPG, Nils Amiet @tmlxs & Sylvain Pelissier @Pelissier_S
Les chercheurs en sécurité de la société KudelSecurity Nils Amiet et Sylvain Pelissier ont présenté leurs travaux d’analyse forensique de la mémoire de GnuPG.
GnuPG est une implémentation du standard OpenPGP et une solution de chiffrement de signature de données.
GPG peut être utilisé pour :
- Signer et chiffrer des mails
- Signer des commits git
- Signer des paquets pour les distributions Linux
- Réaliser une authentification SSH
L’application GnuPG VS-Desktop a été approuvée par le gouvernement allemand pour sécuriser les données classées restreintes.
GPG présente deux composants :
- L’outil en ligne de commandes gpg
- Le daemon gpg-agent qui tourne en arrière-plan et se charge de la mise en cache des passphrases permettant de déchiffrer les clés GPG.
Les auteurs ont ainsi analysé la manière dont GPG protège ces passphrases. Ainsi, les commentaires au sein de GPG indiquent que ces passphrases sont stockées de manière chiffrée, avec une clé de chiffrement générée au démarrage du processus, afin de se prémunir contre leur récupération via un grep sur une image mémoire du processus gpg-agent. La documentation indique également la possibilité dans le futur de recourir à un TPM afin de protéger la clé secrète.
L’analyse du code a permis d’identifier les éléments suivants :
- Les passphrases mises en cache sont stockées chiffrées dans la mémoire en utilisant le mode d’opération key wrap d’AES
- La clé utilisée pour chiffrer les passphrases est générée aléatoirement au démarrage du processus gpg-agent
- Cette clé est stockée en clair au sein de la mémoire du processus gpg-agent
Le mode AES propose le chiffrement et un contrôle d’intégrité (via un vecteur d’initialisation fixé) des clés.
Les auteurs ont ensuite tenté d’identifier en clair la phrase secrète au sein de la mémoire. Pour cela, une empreinte mémoire du processus en cours d’exécution a été réalisée. Après analyse de cette empreinte mémoire, la présence des 8 premiers octets de la phrase secrète présente en clair a été relevée. Il s’agit d’un défaut de nettoyage de la mémoire d’une variable au sein de la bibliothèque libgcrypt. Cette vulnérabilité a été corrigée au sein de la version 1.8.9, publiée le 07 février 2022.
Les auteurs ont ensuite essayé de retrouver la phase secrète complète au sein de l’image mémoire.
La phase secrète chiffrée est stockée au sein d’une structure contenant des timestamps permettant d’indiquer les dates de mise en cache, ou la date de dernier accès. Ainsi, pour identifier les emplacements mémoires contenant la phrase secrète chiffrée, il est possible d’analyser la mémoire afin d’identifier des structures contenant des timestamps, en s’assurant que le timestamp de la date de création est antérieur au timestamp de dernière utilisation pour limiter les faux positifs.
Après avoir identifié les éléments chiffrés mis en cache, il est nécessaire d’identifier au sein de la mémoire la clé utilisée pour chiffrer les phrases secrètes. Pour cela, les chercheur ont utilisé une méthode se basant sur l’initialisation d’AES. En effet, AES se base sur un algorithme d’expansion de clé afin de générer 10 autres sous-clés. Ainsi, il est possible de scanner la mémoire du processus octet par octet afin d’identifier un modèle avec les octets à proximité, afin d’identifier si ceux-ci proviennent de l’algorithme d’expansion de clé. L’utilisation de cette méthode permet d’identifier des zones de la mémoire qui ont une forte probabilité de contenir une clé AES.
Une fois cette clé AES récupérée depuis la mémoire, il est possible de tenter de déchiffrer la phrase secrète identifiée précédemment. Pour s’assurer qu’il s’agit de la bonne clé AES, il est possible de vérifier l’intégrité de l’élément déchiffré via l’algorithme AES keywrap.
Les auteurs ont ensuite présenté l’implémentation de cette méthodologie afin d’extraire depuis la mémoire les phrases secrètes. Pour cela, ils se sont basés sur l’outil Volatility 3. Ils ont ainsi développé 2 modules https://github.com/kudelskisecurity/volatility-gpg d’extension pour Volatility. Le premier permet d’identifier les 8 premiers caractères de la phrase secrète. Le deuxième est, quant à lui, en mesure de récupérer l’ensemble de la phrase secrète.
En conclusion, les auteurs reconnaissent que la protection de la mémoire vive est difficile à implémenter en pratique. Afin de protéger pleinement la mémoire, ils recommandent de mettre en place des solutions telles que des Trusted Platform Module (TPM).
Au sein de la séance de question-réponse, les auteurs indiquent également que les travaux ont permis d’identifier des défauts au sein de l’implémentation du stockage des codes PIN pour les smartcards, sans pouvoir divulguer davantage d’information pour le moment.
Fuzzing Microsoft’s RDP Client using Virtual Channels – Valentino Ricotta (FACE0XFF)
Valentino RICOTTA a présenté ses travaux de recherche sur le fuzzing des clients RDP qui lui ont valu la découverte de nombreuses CVEs !
Ses recherches se sont basées sur une présentation de la Black Hat Europe en 2019, sur le sujet du fuzzing de clients RDP qui évoquait déjà le fonctionnement des Virtual Channels.
Le client RDP permet à l’utilisateur de recevoir l’image du bureau distant ainsi que les entrées clavier et souris. En réalité, cette vision est réductrice : bien plus d’informations transitent ou peuvent transiter entre le client et le serveur via des Virtual Channels : le presse-papier, des données imprimante, des données liées au smart-cards, etc… Le passage de toutes ces informations confère aux clients RDP une grande surface d’attaque.
Pour s’attaquer aux clients RDP, Valentino RICOTTA s’est appuyé sur du fuzzing. Portée par des outils tels que WinAFL, cette technique consiste à générer des payloads et à les tester successivement sur une cible (ici les clients RDP). Certains payloads pourront provoquer des erreurs de traitement au sein de la cible, l’amenant à un état qui pourra être exploité par un attaquant.
Une problématique importante du fuzzing est d’être en mesure de décider la période à partir de laquelle il est temps d’arrêter de fuzzer (Une après-midi ? Une journée ? Une semaine ?). Pour cela, l’auteur a choisi de modifier l’outil WinAFL afin de sauvegarder les tentatives ayant mené à de nouveaux chemins dans le code de la cible. Une représentation visuelle a pu être obtenue à l’aide du plugin LightHouse d’IDA qui colore les basics blocs selon leur couverture. Une bonne connaissance des clients RDP a été nécessaire pour être pleinement conscient du degré de couverture, puisque de nombreux chemins dans le code du client sont liés à des erreurs et ne seront donc jamais empruntés.
Plusieurs vulnérabilités ont ainsi été découvertes grâce au fuzzing comme les CVEs CVE-2021-38665 et CVE-2021-38666, cette dernière étant qualifiée de critique ! La première permet de faire fuiter des octets sur le tas (heap). Un attaquant peut alors identifier des adresses pouvant lui permettre ensuite de contourner l’ASLR (protection mémoire). La deuxième vulnérabilité est de type heap overflow : la longueur d’un buffer utilisé pour effectuer de la désérialisation n’était pas vérifiée. Cette vulnérabilité pourrait être utilisée à des fins d’exécution de code à distance (RCE), bien qu’à ce jour aucun aucun POC n’a pu être produit.
L’auteur a quand même pu recevoir un bounty pour ses travaux ; il rappelle d’ailleurs qu’une analyse de risques poussée ainsi que des explications techniques peuvent être reçues de la part Microsoft. Bravo à lui 🙂 !
Pour plus d’informations, référez-vous aux actes du SSTIC disponibles ici ou aux billets du blog de Thalium écrits par Valentino RICOTTA disponibles ici.
