Bilal BenamroucheDans cet article, nous allons vous résumer quelques présentations de la conférence SSTIC, Symposium sur la sécurité des technologies de l'information et des communications, qui a eu lieu à Rennes du 1er au 3 juin 2022.
Building Open Security Tooling For Fun & Profit (Conférence d'ouverture) - Colin O'Flynn
La conférence SSTIC commence son premier jour par la présentation de Colin O’Flynn sur les outils open source utilisés dans la sécurité matérielle. Cette présentation nous parle de travaux actuels et futurs dans le domaine de l'outillage de sécurité matérielle, y compris des projets tels que l'analyse de puissance et l'outillage d'injection de fautes.
Les différents points de la présentation portaient sur :
Les outils de sécurité matérielle open source
Dans cette partie des solutions académiques matérielles de test et d’analyse sont présentées. Ces outils permettent de faire (comme exemple) l’analyse side channel d’un dispositif cryptographique AVR XMEGA.
On y présente notamment ChipWhisperer, un outil d’attaque side channel sur les dispositifs embarqués permettant de valider la résistance de ces systèmes embarqués à des attaques. En particulier, ChipWhisperer se concentre sur l'analyse de la puissance qui utilise les informations récupérées par la consommation d'énergie d'un dispositif pour mettre en oeuvre une attaque, mais également sur les attaques de tension et d'horloge qui perturbent brièvement l'alimentation ou l'horloge d'un dispositif pour provoquer un comportement involontaire (comme bypasser une vérification de mot de passe).
https://github.com/newaetech/chipwhisperer
On établit également une comparaison entre le coût de développement de ces outils et le bénéfice de lancer des affaires en les commercialisant.
Outils de sécurité, nouvelle génération
OpenTitan
OpenTitan est le premier projet open source qui élabore un modèle de référence transparent et de haute qualité ainsi que des directives d'intégration pour les puces RoT (root of trust) en silicium.
PicoEMP - Open Source EMFI
L’une des méthodes de vérification de fiabilité matériel est l’injection de faute qui permet d’injecter des données dans le dispositif matériel, voir son comportement et décider s'il est robuste aux défauts ou pas. Un outil qui permet de faire de l’injection de fautes est présenté dans cette partie, il s’agit d’une bobine contrôlée à l’aide de matériels électronique (Ras-Pi). Il permet d’envoyer dans la bobine du courant électrique dans le but de générer un champ magnétique avec lequel on pourra injecter des fautes dans le dispositif cible.
https://github.com/newaetech/chipshouter-picoemp
Analyse de consommation énergétique
Une autre méthode présentée, elle permet également d’analyser la fiabilité d’un système matériel, il s’agit de l’analyse de consommation. Cette méthode permet de comparer la consommation du système en fonction des calculs et les algorithmes cryptographiques utilisés et essayer d’en déduire des informations utiles pour le déchiffrement.
La conférence est conclue par une démo sur le dispositif d’injection de fautes.
https://static.sstic.org/videos2022/1080p/ouverture_2022.mp4
Smartphone et forensique : comment attraper Pegasus for fun and non-profit - Etienne Maynier
Etienne Maynier est chercheur pour le programme d’Amnesty Tech, filiale d’Amnesty International constituée d’avocats, de hackers et de chercheurs en sécurité
Dans cette présentation, Etienne Maynier, nous présente son approche forensic sur le logiciel Pegasus, un outil d’espionnage développé par NSO Group. Ce logiciel est l’un des plus employés par certains pays et entités juridiques afin d’obtenir des informations par des moyens douteux (utilisation massive de vulnérabilités 0-day). Il a été utilisé par exemple dans l’affaire d’Ahmed Mansoor, blogueur activiste émirien des droits de l’homme condamné à 10 ans de prison ferme pour atteinte à la sécurité de l’état.
Le projet donne naissance au Mobile Verification Toolkit, un framework permettant d’automatiser le processus de récolte de traces forensic d’éventuelle infection par Pegasus. Les traces incluent notamment :
- les liens malveillants reçus par SMS sur le téléphone de la victime
- Historique de navigation permettant de détecter les attaques par redirection d’url
- Logs réseau du téléphone : ces logs permettent de faire le lien entre un processus et son utilisation du réseau (ces logs on permis d’établir une liste de noms de process Pegasus),
- ID status Cache : contient des traces du compte iCloud qui a intéragi avec le téléphone, ce qui permet de découvrir les compte iCloud de NSO Group ainsi que de pouvoir avoir le nom de leurs clients,
MVT permet de construire une timeline des attaques afin de mieux comprendre les différents schémas d’attaque utilisés par NSO Group.
Cet outil a permis de lever le voile sur la vulnérabilité Megalodon et son exploitation sur iPhone ainsi que de mieux comprendre l’utilisation de Pegasus à des fins d’espionnage.
Analyse forensique de la mémoire de GnuPG - Nils Amiet & Sylvain Pelissier
GnuPG est l’implémentation GNU du standard OpenPGP. Cet outi permet la transmission de messages signés et chiffrés permettant de garantir l’authenticité, l’intégrité et la confidentialité.
La présentation est focalisée sur l’analyse forensique de GnuPG (GPG). L’agent gpg-agent permet de mettre en cache les mots de passe dans le but de faciliter et minimiser les accès mémoire et gagner en temps d’exécution. Dans un premier temps, ce travail met en évidence un problème de nettoyage de la mémoire de libgcrypt, qui permet de lire 8 octets du mot de passe dans le cache de GPG. Ensuite, il démontre des techniques générales pour récupérer les mots de passe complets dans le cache de GPG à partir d'une image de la mémoire de gpg-agent ou du système complet. Pour démontrer leur travail, deux modules d'extension pour Volatility sont fournis, ils permettent de récupérer un mot de passe stocké dans le cache de GPG.
Dans cette présentation le chiffrement AES est utilisé avec une fonction de dérivation de clés. Ces clés sont stockées en mémoire. Avec l’image mémoire, le but est de retrouver l’ensemble de clés stockées en mémoire et ensuite les utiliser avec l’outil Volatility, un outil open source pour l'extraction l'extraction d'artefacts numériques à partir d'échantillons de mémoire volatile (RAM), afin de récupérer les mots de passe (démo dans la vidéo).
https://static.sstic.org/videos2022/1080p/gnupg_memory_forensics.mp4
Surface d’attaque des solutions Active Directory Self-Service
Antoine Cervoise et Wilfried Becard ont présenté plusieurs vulnérabilités et scénarios d’attaque sur les solutions AD Self Service.
Certaines entreprises ont recourt à ces services d’AD Self Service (abrévié ADSS) **afin de permettre à leurs employés de réinitialiser leur mot de passe de manière autonome.
L’ADSS permet de réduire le nombre d’appels au support, de fluidifier le processus de réinitialisation et permet ainsi pour l’entreprise de réduire le coût du support. On peut également lister d’autres avantages comme le fait de pouvoir réinitialiser le mot de passe même si le support est fermé ou encore de réinitialiser son mot de passe sans être connecté aux infrastructures de l’entreprise en exposant la solution sur internet.
Architecture d’un ADSS
Voici l’architecture type d’un ADSS :
Le serveur de la solution ADSS héberge une application Web qui possède un compte de service ainsi qu’un compte du domaine qui lui permet de réinitialiser les mots de passes des utilisateurs.
Le client peut être un client lourd, un navigateur ou un mobile.
Surface et scénario d’attaque
Voici la surface d’attaque d’un ADSS :
- Client lourd pré-authentifié
- Process de déploiement des clients lourds
- Application web qui a accès à un compte privilégié de l’AD
Et les scénarios d’attaque envisagés :
- Client lourd
- Attaquant avec un accès physique à l’ordinateur d’un employé
- Employé malicieux essayant d’élever ses privilèges
- Serveur web
- Exploitation d’une vulnérabilité présente dans l’API du service web
Ils ont ensuite compromis le client lourd en présentant un fausse application web qu’ils contrôlent car le client lourd peut être configuré pour autoriser les connexions en HTTP ou ne vérifie pas le certificat envoyé par le serveur.
Une fois connecté sur le faux service, l’application web peut grâce à la ligne suivante faire apparaître une fenêtre d’impression :
<script>document.print();<script>
Ce qui permet par la suite d’invoquer une invite de commande avec les droits système.
Wilfried a ensuite présenté la partie exploitation du serveur de l’ADSS, que je vous laisse regarder dans la vidéo (lien à la fin de l’article).
Recommandations
Voici les bonnes pratiques à appliquer pour réduire le risque lié à l’utilisation d’un ADSS.
Client lourd :
- Ne pas déployer le client lourd sur les serveur (et à fortiori un contrôleur de domaine)
- Mettre à jour le client lourd
- Forcer la vérification des certificats
- Chiffrer les disques de l’ordinateur
Serveur :
- Mettre à jour le serveur
- Réduire les privilèges du compte du domaine au strict minimum
- Utiliser les solutions déjà existantes, notamment pour le déploiement des clients lourds on peut utiliser les GPO ou SCCM
- Restreindre l’accès à la partie admin (filtrage IP par ex.)
- Mettre en place un CAPTCHA pour empêcher le bruteforce
- Mettre un WAF en frontal pour intercepter les attaques
Un grand merci à eux pour leur présentation très claire et instructive !
Si vous souhaitez regarder leur présentation, la vidéo est disponible sur le site du SSTIC :
Practical timing and SEMA on embedded OpenSSL’s ECDSA — Adrian Thillard, Franck Rondepierre, Guenael Renault, Julien Eynard
Les attaques par temps de réponse sont une classe d'attaques par canal auxiliaire permettant à un adversaire de récupérer des données sensibles en observant le temps d'exécution d'un algorithme sous-jacent. Plusieurs bibliothèques cryptographiques se sont révélées vulnérables à ces attaques, permettant souvent des récupérations de clés privées. Bien que des articles récents aient montré que ces menaces sont bien connues des développeurs, ces bibliothèques sont souvent laissées sans correctif, en raison de la charge perçue de la mise en œuvre de contre-mesures efficaces. Au lieu de cela, de nombreuses bibliothèques ont choisi de modifier leur modèle de menace et de ne plus considérer les attaques où l'adversaire a un accès local à la cible.
Adrian Thillard nous présente ces travaux sur la recherche d'attaques par temps de réponse dans la librairie OpenSSL.
https://static.sstic.org/videos2022/1080p/practical_timing_and_sema_on_embedded_openssls_ecdsa.mp4
DroidGuard: A Deep Dive into SafetyNet - Romain Thomas
SafetyNet est un composant Android développé par Google pour vérifier l’intégrité des appareils. Ces vérifications sont utilisées par les développeurs pour empêcher l’exécution de leurs applications sur des appareils ne respectant pas certaines contraintes de sécurité (appareil rooté, firmware customisé, émulé, bootloader modifié).
SafetyNet permet aux développeurs d'applications critiques de s'assurer que leurs applis ne tournent pas dans des environnements compromis (jeux vidéos, fintech, apps de messagerie).
La conférence est un état de l’art de l’implémentation courante de SafetyNet et de ses mécanismes internes. On présente plus particulièrement le fonctionnement du module DroidGuard : architecture de la VM, ses mécanismes internes ainsi que les différents security checks effectués par SafetyNet pour détecter des outils comme Magisk, des émulateurs, des appareils rootés et même Pegasus.
Fonctionnement de SafetyNet
SafetyNet est une API que le développeur appelle en fournissant un nonce pour éviter des attaques de rejeu et une API_KEY pour l’authentification côté Google Backend. Le SDK de SafetyNet va packager ces informations et les envoyer à travers un Intent (format de message sur Android) à GMS Core.
GMS Core effectue des checks d’intégrité sur le téléphone (vérifications de la présence de certains binaires liés au rootage notamment) et package un message Protobuf (format de sérialisation de données structurées) qui va contenir des informations sur l’état du téléphone, il va également déclencher une requête à DroidGuard avec le message Protobuf.
DroidGuard effectue une requête au Backend Google avec le message Protobuf auquel est ajouté un token unique. Le Backend Google détermine si l’appareil est intègre, signe le message avec une clé cryptographique et renvoie le message signé. Enfin, GMS Core renvoie le message signé à l’application qui a fait la demande.
https://static.sstic.org/videos2022/1080p/droidguard_a_deep_dive_into_safetynet.mp4
OASIS: un framework pour la détection d'intrusion embarquée dans les contrôleurs Bluetooth Low Energy
La présentation est centrée sur la sécurité d’un protocole largement utilisé dans la communication IoT, le protocole Bluetooth Low Energy. Ils parlent dans un premier temps le principe de protocole BLE et ses différents avantages, ils présentent ensuite, OASIS, un Framework générique permettant d’automatiser l’instrumentation des contrôleurs BLE, pour y inclure des modules de détection d’attaques.
ça existe un certain nombre d’attaques sur les systèmes embarqués visant les contrôleurs Bluetooth Low Energy. Introduire un moyen de détection d’attaque sur ces contrôleurs va donc apporter un vrai avantage, ils expliquent donc le contexte d’OASIS avec des solutions de détection sur trois types d'attaques différentes.
OASIS: Module de détection - GATTACKER
Le principe de ce module est d’analyser en temps réel le délai entre l’émission de deux paquets par un même émetteur. Dans le cas d’une attaque, l’émission d’autres paquets par l’attaquant va impliquer une superposition de ces parquets avec le trafiquer légitime ce qui va mener à la réduction de ce temps d’émission entre deux paquets. On collecte les timestamps de chaque paquet d’un même émetteur et on calcule le temps intertrame successif, ensuite on estime l’intervalle minimum et on établi un seuil correspondant au pire cas ligitime.
OASIS: Module de détection - BTLEJUICE
Ce module de détection est basé sur le principe que le périphérique reçoit une demande de connexion et en parallèle de la validation et l’établissement de cette connexion, il initie également une opération de scan. Donc on peut détecter l’attaque si on remarque une émission de paquet utilisant le même Bluetooth Devise Adresse de périphérique en parallèle de la connexion.
OASIS: Module de détection - BTLEJACK
Ce module permet de détecter le type d’attaque de détournement de connexion (Hijacking), le but est d’analyser en temps réel le nombre de paquets consécutifs émis par le slave dont le CRC est invalide
Architecture d’OASIS
Dans la deuxième partie de la présentation, l’architecture OASIS est présentée. elle est basée sur trois principaux blocs:
- Un firmware analyser basé sur la rétro-ingénierie automatique, où on procède à faire une analyse automatique de firmware du contrôleur BLE et générer automatiquement les fichiers de la configuration et du wrapper décrivant une cible matérielle.
- Des logiciels de détection embarqués qui sont indépendants de la plate-forme, ils implémentent le calcul des métriques (temps intertrames).
- Build system qui, en fonction des fichiers en entrée, va générer une liste de patches à appliquer sur le contrôleur matériel
La présentation est conclue par des travaux expérimentaux montrant l’efficacité de dispositif de détection implémenté - OASIS.
TPM is not the holy way
Depuis quelque temps, les ordinateurs embarquent des puces sécurisées appelées TPM. Cette puce, appelée Trusted Platform Module (TPM), est utilisée pour générer et protéger les secrets utilisés par l'ordinateur. Elle est par exemple utilisée lors du boot d’un OS, et permet à chaque composant de vérifier cryptographiquement le composant sous-jacent avant de l'exécuter.
Benoît Forgette nous présente durant cette conférence les travaux qu'il a pu mener sur l'émulation du système d'exploitation et l'interception des communications vers le TPM. Ces travaux lui ont permis de mettre en évidence des mauvaises configurations sur cette puce.
