6 juin 2019

Retours sur le SSTIC – 17e édition – Jour 1

SSTIC

Article mis à jour le 07 juin 2019

Le Symposium sur la Sécurité des Technologies de l’Information et des Communications (SSTIC) réunit depuis bien des années de nombreux professionnels de la sécurité informatique pendant 3 jours à Rennes pour traiter de divers sujets techniques dans l’ensemble des domaines de la sécurité informatique.

Cette année, BSSI était présent à la 17e édition. Dans cet article nous vous proposons des résumés de quelques conférences du premier jour :

Keynote

La conférence d’introduction à cette 17e édition du SSTIC a été réalisée par Alex Ionescu, reverser depuis plus de 20 ans.

Alex a fait un retour sur l’évolution de la recherche de vulnérabilité depuis ses débuts jusqu’à nos jours en parlant également des Bug Bounty.

Sa conférence, particulièrement appréciée et relativement longue (1 heure) ne pouvant être résumée en quelques lignes, nous vous invitons à regarder la redifusion sur https://www.sstic.org/2019/presentation/keynote_2019/

Évaluation de portefeuille open source de cryptomonnaie avec des attaques par canaux auxiliaires.

Par Charles Guillemet, Manuel San Pedro, Victor Servant (Ledger)

Charles commence par introduire les portefeuilles matériels en expliquant que pour détenir des crypto monnaies, il est nécessaire de disposer d’un portefeuille. Il en existe de plusieurs types, cependant les trois présentateurs se sont concentrés sur les portefeuilles matériels (open source afin de faciliter l’étude).

Après réception d’un portefeuille matériel, des Mnemonics (liste de 12 ou 24 mots) doivent être générés. À partir de la dérivation de ces Mnemonics, une Seed peut être générée. Grâce à cette Seed, une paire de clés privé/public par cryptomonnaie. La clé privée est utilisée pour effectuer des signatures afin de valider les transactions. La clé publique est utilisée pour générer l’adresse à laquelle il sera possible de recevoir des cryptomonnaies.

Les mnemonics, la seed et les clés privées sont stockées sur le portefeuille de manière sécurisé. Pour utiliser le portefeuille, il est nécessaire de s’authentifier avec un code PIN. De plus, en cas de perte, les Mnémonics peuvent servir à récupérer son portefeuille.

Une transaction est ainsi effectuée en 4 étapes :

  1. Authentification par PIN
  2. Préparation de la transaction (adresse et montant)
  3. Demande de confirmation à l’utilisateur puis signature de la transaction
  4. Envoi de la transaction signée à la blockchain

Dans le cadre de leur évaluation, les présentateurs ont effectué des attaques par canaux auxiliaires sur les fonctions de vérification de PIN et de signature ECDSA (utilisé dans le cadre du bitcoin).

Les attaques par canaux auxiliaires consistent à exploiter une dépendance entre une grandeur physique produite par un appareil et les données qu’il manipule. Dans le cas présenté, la grandeur physique considérée est la consommation de courant électrique. Celle-ci était mesuré avec un oscilloscope. Lascar, un de leurs outils open source, a été utilisé pour récupérer, traiter et visualiser les grandeurs mesurées.

Pour cette attaque, ils ont effectué des authentifications par PIN sur un portefeuille A, en évaluant la consommation de courant de chaque digit entré. Après avoir le profil de chaque digit, ils ont analysé la consommation d’une authentification par PIN sur une machine B, en essayant de retrouver le PIN entré, ce qu’ils ont réussi à accomplir avec du machin learning en moins de 5 essais.

Une attaque par multiplication scalaire utilisée lors de la signature ECDSA est présentée dans un second temps. Lorsqu’une signature ECDSA est effectuée, une multiplication scalaire est réalisée à partir d’un nonce. L’objectif de cette attaque est de récupérer ce nonce à partir duquel il est possible de reconstituer la clé privée.

Cette attaque a également été fructueuse, bien qu’elle a eu un taux de succès de 99% d’après les tests qu’ils ont pu effectuer. Cette attaque n’est cependant pas critique, car il faut être authentifié pour la réaliser. Il est toutefois possible d’imaginer que certains constructeurs utiliseront cette fonctionnalité sans authentification auquel cas la vulnérabilité sera critique.

L’audit des GPO

Par Aurélien Bordes (ANSSI)

Lors de cette conférence, Aurélien Bordes a présenté deux outils d’audit de GPO (Group Policy Object) permettant d’analyser différents éléments affectant la sécurité d’un poste de travail ou environnement des utilisateurs.

Tout d’abord, il a commencé par redéfinir ce que sont les GPO et ce qu’elles permettent de réaliser. Elles facilitent grandement le déploiement de configuration de postes sur un grand parc informatique via le domaine Active Directory. Chaque GPO est définie par des objets de classe groupPolicyContainer (objet de classe container). De plus, les attributs acceptés par la classe permettent d’en définir les propriétés (cn, displayName, etc.).

Malgré la puissance que peuvent apporter ces GPO, il n’est pas rare de constater que certains domaines d’entreprise déploient des milliers de GPO rendant la détection d’anomalies ou de défauts de configuration, pouvant mener à des failles de sécurité, difficile.

Comment extraire ces données de l’AD ? L’extraction des GPO et propriétés associées se fait via une requête LDAP (filtre : objectClass=groupPolicyContainer) qui permet ainsi la récupération de tous les objets de type groupPolicyContainer.

Ensuite, le chercheur en sécurité a présenté les CSE (Client Side Extension) qui sont des bibliothèques dynamiques chargées par le moteur GPO. Ces extensions jouent un rôle important, car permettent d’appliquer un type de paramètre particulier.

Pour aider à identifier ces défauts de configuration/incohérences, deux outils ont été développés par le conférencier. Chacun détient sa propre utilité. Le premier gpocheck permet de remonter d’éventuelles anomalies de droits entre l’AD et le répertoire SYSVOL (droits abusifs de fichiers présents dans SYSVOL). Le second, gpo2sql permet d’importer dans une base de données SQL tous les paramètres définis par un ensemble de GPO via les fichiers XML exportés, afin de pouvoir réaliser des requêtes plus complexes et d’automatiser l’analyse (via l’utilisation de conditions comportant des opérateurs logiques).

Pour terminer, Aurélien préconise qu’au niveau des propriétés des GPO (groupPolicyContainer) il soit nécessaire de s’assurer que :

  • L’attribut gPCFunctionalityVersion soit toujours à 2 (niveau fonctionnel) ;
  • Les répertoires des GPO soient bien dans le SYSVOL et sous la forme \\<domain.tld>\SYSOL\Policies\<GUID_GPO> (attribut gPCFileSysPath) ;
  • Les CSE soient tous identifiés et connus (attributs gPCMachineExtensionNames et gPCUserExtensionNames).

Liens Github des outils présentés :

WEN ETA JB? A 2 million dollars problem

Par Eloi Benoist-Vanderberken et Fabien Perigaud

Introduction

Pour la première journée du SSTIC, les deux conférenciers venant de Synacktiv ont présenté des failles de sécurité qui sont présentes dans les mobiles d’Apple. Il est vrai que les intérêts pour la sécurisation d’iOS sont de plus en plus importants ainsi que les récompenses. Du côté d’Apple, la compagnie propose de plus en plus d’extensions pour renforcer sa sécurité telles que Gigacage, KTRR ou encore PAC. Les présentateurs ont voulu nous démontrer que la récompense de Zerodium d’un montant de 2 millions de dollars pour un « jailbreak » à distance n’est pas exagérée. Leur sujet traitera principalement de codes d’exécution et l’élévation des privilèges en s’attaquant aux objets arbitraires.


Safari

Le navigateur internet Safari est la première idée qui a été mentionnée comme moyen pour s’attaquer à un système iOS. Safari utilise l’outil WebKit et de 2 sous-frameworks LGPL qui sont Webcore et JavaScriptCore. La première étape est d’obtenir les droits d’écriture sur les primitives qui sont par défaut plus accessibles et faciles à modifier. Par exemple, cette vulnérabilité peut compromettre les objets de type « array » tels que les pointeurs de tampons de stockage.

Pour y remédier, Apple a implémenté un outil Gigacage qui permet d’emprisonner dans une très large zone de 32 GB des objets dangereux. Par exemple, si la taille ou le pointeur du tampon posait un problème, ils seraient pointés vers cette zone.

Les pages JIT

Une fois que l’attaquant a la main sur du code arbitraire qui n’est pas protégé par la Gigacage, il lui est possible d’exécuter un shellcode via des pages de JIT qui est utilisé par le navigateur internet d’Apple afin de compiler rapidement à la volée et gagner en performance. Ces pages JIT de protection sont allouées comme RW et possèdent une grosse zone mémoire pour y inscrire un code JavaScript, par exemple. Cependant, Apple a déjà implémenté des mises à jour pour iOS, mais pas encore sur macOS.

Un des moyens de mitigation est de séparer la page de JIT en 2 « mappings » différents en RX et RW. Avec une simple primitive de lecture, il n’est plus possible d’écrire du code arbitraire. La page RW est désormais localisée aléatoirement. De plus, des primitives RW ne peuvent pas être utilisées seules pour éditer du code arbitraire sur des fichiers JIT.

Élévation des privilèges

Maintenant que les codes arbitraires sont disponibles, l’une des premières actions de l’attaquant est d’obtenir des droits plus élevés. Ainsi, les nouvelles surfaces d’attaques augmentent telles que les « daemons », le Kernel ou KEXTs et ses extensions. Pour les sécuriser, il existe la sandbox d’Apple qui protège ses surfaces. La sandbox KEXT basée sur l’architecture MACF est difficile à décrypter. Aussi, les « daemons » sont de plus en plus « sandboxé » et Apple restreint leur périmètre d’exécution au maximum. Les attaques se sont concentrées sur les « daemons », car ils sont composés de codes qui changent régulièrement et peuvent atteindre des données sensibles.  Le « jailbreak » accessible à tous devient donc compliquer, et le prix au marché noir grimpe.

Conclusion

Pour conclure, Apple est très concerné par la sécurité de sa flotte mobile en maîtrisant physiquement et logiciellement ses appareils. Il est aussi difficile de s’immerger pour un néophyte à cause d’une documentation en ligne assez restreinte. Les vulnérabilités connues par Apple sont rapidement prises en compte et ajoutées dans les futures mises à jour. Le « full jailbreak » est devenu coûteux et dangereux, car Apple continue d’investir sur des extensions de sécurité et de rendre son code plus complexe. Ce sera donc de plus en plus compliqué d’utiliser les mêmes outils dans le futur. Ainsi, il est donc difficile de trouver des failles de sécurité non connues par Apple et d’où des récompenses très élevées pour les chasseurs de « bug bounties ».

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *