Comme tous les ans, XMCO vous propose une revue de certaines conférences du SSTIC.
Introduction
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.
L’édition du SSTIC a pris cette année une tournure très spéciale. En raison de la crise COVID-19, les conférences ont été enregistrées en amont et sont diffusées en direct et gratuitement en ligne.
Pour maintenir une interactivité malgré tout, les organisateurs ont également mis en place un chat IRC permettant de poser des questions aux conférenciers au cours de l’évènement.
Comme tous les ans, XMCO a suivi cette conférence et vous propose un résumé tous les jours de quelques conférences choisies parmi celles diffusées dans la journée. Ces dernières seront également regroupées au sein de notre prochain numéro d’ActuSecu.
Références SSTIC :
- Site officiel : https://www.sstic.org
- Programme de Conférence : https://www.sstic.org/2020/programme
- Direct : https://streaming.sstic.org
- Actes : https://actes.sstic.org/SSTIC20/sstic-2020-actes.pdf
Android_Emuroot: Outils de rooting d’un émulateur Android Google API PlayStore, Anaïs Gantet, Mouad Abouhali
Contexte
La première présentation de cette deuxième journée de conférences présentait un outil de rooting d’émulateur Android Google API PlayStore.
Cet outil, baptisé Android_Emuroot, gomme la différence existant entre les deux types d’émulateurs Android proposés par Google :
- un émulateur Android Google API ;
- un émulateur Android Google PlayStore.
L’émulateur Google PlayStore propose l’application PlayStore, contrairement au type d’émulateur Google API. Cependant, l’émulateur Google PlayStore ne permet pas d’obtenir de Shell superutilisateur (root) sur le système.
Ainsi, un auditeur peut être limité dans son analyse d’une application installée via le PlayStore sur un émulateur de type Google PlayStore. En effet, ne disposant pas des privilèges superutilisateur, il n’est pas possible d’exploiter des outils comme Frida (ou d’exploiter ces outils que partiellement). Ce point bloquant est ainsi levé avec Android_Emuroot. L’outil permet également de contourner les mécanismes anti-rooting d’Android.
Fonctionnement
Pour réaliser l’élévation de privilège du Shell de l’émulateur Google PlayStore, Android_Emuroot utilise le serveur de débogage GDB afin d’accéder à la mémoire interne du noyau Linux. Dans cette mémoire réside un ensemble de structures task_struct, qui définissent un ensemble de paramètres internes de chaque application exécutée sur le système. Ces structures sont stockées au sein d’une liste chaînée. La structure task_struct comporte une sous-structure creds qui détaille les permissions et les capabilities SELinux associées au processus en question.
Android_Emuroot cherche donc à écraser la structure creds du processus Shell en lui attribuant les permissions maximales. Pour trouver l’emplacement mémoire de cette structure, l’outil identifie en premier lieu l’emplacement mémoire de la structure task_struct associée au processus init. Cette dernière comporte un pointeur vers la suite de la liste chaînée, qui est parcourue successivement jusqu’à identifier la structure associée au Shell. Une fois que la structure associée au Shell standard est trouvée en mémoire, l’outil écrase ses permissions.
Utilisation
L’outil supporte actuellement 4 versions d’Android (7.0, 7.1, 8.0 et 8.1). Pour chaque nouvelle version supportée, une étape de rétro-ingénierie sera nécessaire afin d’ajouter des informations sur l’organisation de la mémoire interne, propres à chaque version du système Android.
Suite à l’exécution d’Android_Emuroot (en bas à gauche), les permissions superutilisateur sont attribuées au Shell standard (en haut à gauche).
Source: sstic.org
L’outil est publié en code source ouvert sur Github :
Testing for Weak Key Management in Bluetooth Low Energy Implementations José Lopes Esteves, Tristan Claverie
Tristan Claverie a présenté une étude sur le protocole Bluetooth Low Energy et son implémentation, étude réalisée avec José Lopes Esteves.
La présentation se concentrait notamment sur deux aspects sécuritaires implémentés sur le Bluetooth, liés au protocole d’appairage (pairing) et à la génération et la gestion de clefs secrètes (bonding).
Contexte
Le conférencier a tout d’abord effectué quelques rappels sur le Bluetooth Low Energy. Ce protocole standardisé en 2010 définit les propriétés de sécurité suivantes :
- il doit permettre de garantir la vie privée à ses utilisateurs ;
- les communications doivent être confidentielles, intègres et authentifiées.
L’objectif de ce protocole est de se protéger contre un modèle d’attaquant passif (en écoute seulement) ou attaquant actif (en capacité d’écoute, d’interception et de manipulation des échanges).
Deux versions du protocole BLuetooth Low Energy ont été analysées par les conférenciers, la version BLE 4.0 Legacy pairing et la version BLE 4.2 Secure Pairing.
Des mécanismes de sécurité (en vert dans la capture suivante) sont définis par le protocole afin de garantir les propriétés de sécurité.
Liens entre fonctionnalités, propriétés de sécurité et mécanismes de sécurité du Bluetooth Low Energy (LE Legacy Pairing et LE Secure Pairing)
Source: sstic.org
Pairing
Le protocole de Pairing du Bluetooth Low Energy permet d’établir une connexion Bluetooth sécurisée entre deux parties. Il fait intervenir une étape de génération de clef et d’authentification.
Le Legacy Pairing est présenté par les conférenciers en deux temps :
- l’échange d’une donnée secrète (TK) entre deux équipements ;
- une clef STK est dérivée à partir de TK de part et d’autre.
Le Secure Pairing fait quant à lui intervenir l’algorithme d’échange de clefs Diffie-Hellman sur courbes elliptiques (ECDH) pour échanger des données d’authentification et établir une clef partagée DHKey. Une clef LTK est dérivée de cette clef partagée DHKey.
Les clefs STK et LTK sont finalement utilisées pour chiffrer les communications entre les deux parties (étape nommée link encryption).
Bonding
Le protocole de Bonding du Bluetooth Low Energy permet de générer des clefs. Il ne doit être utilisé qu’au travers d’un lien chiffré (à l’issue d’un Pairing).
Par exemple, ce protocole est utilisé pour générer des clefs complémentaires sur le Legacy Pairing et sur le Secure Pairing.
Tristan Claverie a rappelé que le mode de génération des clefs n’est pas imposé par le standard. Soit la génération d’une clef est complètement aléatoire, soit elle s’appuie sur le concept de Key Hierarchy présentant une entropie limitée (présenté ci-après).
Cas 1 d’étude : Implémentation de l’échange Diffie-Hellman sur courbes elliptiques
La spécification du Bluetooth Low Energy impose de vérifier systématiquement des clefs publiques ECDH reçues. Elle impose également le changement “régulier” des clefs privées/publiques.
En pratique, le conférencier a rapporté que les clefs publiques échangées lors de l’échange ECDH sont parfois partiellement vérifiées. Certaines implémentations ne vérifient même pas l’authenticité des clefs publiques. Ce défaut permet à un attaquant soumettant des appairages successifs de récupérer la clef privée de l’équipement vulnérable, et ainsi de retrouver la clef DHKey générée.
Une méthodologie de test à ces défauts d’implémentation est par ailleurs proposée par José Lopes Esteves et Tristan Claverie.
Cas 2 d’étude : Génération de clef par Key Hierarchy
La Key Hierarchy au sein du Bluetooth est un procédé de génération de clefs aléatoires pouvant générer 2^16 clefs possibles.
Ce nombre de candidats est relativement faible d’un point de vue des standards de sécurité. La spécification Bluetooth elle-même recommande de ne pas utiliser ce type de générateur pour des fonctionnalités ayant un besoin de sécurité. En effet, un attaquant peut générer en un temps raisonnable toutes les clefs possibles.
Les chercheurs ont identifié 2 types de clefs générées par ce procédé qui sont utilisées sur des fonctionnalités de sécurité (dont le chiffrement des communications, link encryption).
Ce type d’implémentation peut être détecté en réalisant tout d’abord un nombre important de Pairing suivi de Bonding. Dans un second temps, il convient de vérifier si une collision est identifiée sur toutes les clefs générées.
Conclusion
Au travers de la présentation, les chercheurs de l’ANSSI ont rappelé l’importance de vérifier les implémentations relativement au standard.
Ils ont également proposé des procédures pour tester ces implémentations sur le Bluetooth Low Energy et ont identifié des composants sujets à des défauts d’implémentation sur la génération des clefs utilisées à des fins de sécurité.
Les aléas d’un ransomware, Yoann Guillot
La dernière présentation de la matinée était proposée par Yoann Guillot de l’ANSSI, qui y présente un cas de réponse à une attaque par rançongiciel. Ce rançongiciel est de la famille des cryptolockers, qui chiffrent les fichiers sensibles identifiés sur le réseau d’une entreprise.
Pour réaliser le chiffrement, le programme génère pour chaque fichier une clef RC4 de 117 octets, suffisamment longue pour rendre impossible toute tentative d’énumération exhaustive. Cependant, l’étape de génération de clef est affectée d’une faiblesse cryptographique importante dans sa conception. Elle se base sur un générateur pseudo-aléatoire (PRNG), qui utilise comme graine un marqueur temporel obtenu par un appel à la fonction GetTickCount() de l’API standard Windows. Cette fonction, qui donne le nombre de millisecondes (ou ticks) écoulées depuis le démarrage du système, renvoie une valeur codée sur 32 bits. Dès lors, l’ensemble des valeurs de clefs possibles se trouve considérablement réduit.
Pseudo-code de l’algorithme de génération de clefs
(source: sstic.org)
De plus, les chercheurs ont remarqué que l’étape de chiffrement des fichiers était exécutée sur une fenêtre réduite de temps. Or, dès qu’une première clef est identifiée, on connaît l’instant où elle a été générée. La recherche des clefs utilisées pour chiffrer les autres fichiers peut ainsi être accélérée en considérant des valeurs de graine proches de l’instant où a été générée la première clef.
Les chercheurs de l’ANSSI ont donc développé une méthode spécifique qui exploite les constats énoncés ci-dessus:
- Une première phase consiste à identifier au moins une clef valide parmi un jeu de 200 fichiers choisis aléatoirement. Pour déterminer si un fichier est correctement déchiffré, un calcul d’entropie sur les premiers octets du fichier est effectué. Une faible valeur obtenue indique donc que le fichier original a pu être retrouvé.
- La seconde phase consiste donc à exploiter la valeur du tick identifiée, qui a été utilisée pour générer la première clef cassée. Les nouvelles recherches de clefs se concentrent dès lors en cherchant des graines de valeur proche de ce tick.
Enfin, Yoann Guillot présente les résultats de la campagne de déchiffrement qui a été ainsi menée. Pour un jeu de 17 000 fichiers chiffrés, 95% de ces fichiers ont pu être retrouvés en un temps de 8h. Les 5% restants tombent dans le cas de fichiers possédant naturellement une forte entropie, qui n’ont donc pas pu être identifiés par cette méthode.
En conclusion, le conférencier rappelle les bonnes pratiques à suivre pour se prémunir des conséquences de ce type d’attaques :
Réalisez régulièrement une sauvegarde de vos fichiers, à stocker en dehors de votre réseau !
