XMCO a assisté à la dernière édition de la conférence SSTIC qui s’est déroulée le 5, 6 et 7 juin derniers à Rennes.
Comme l’année précédente, l’événement a eu lieu au couvent des jacobins, en plein centre de la ville.
Cette année a été marquée par les dix ans du challenge, organisé en amont de la conférence et remporté par 19 personnes, ainsi que par la restructuration du comité d’organisation de la conférence.
Le gagnant du classement “qualité” du challenge nous a d’ailleurs présenté sa solution lors du deuxième jour de conférence.
En attendant le prochain numéro de l’Actu-Sécu, nous vous proposons de revenir sur quelques conférences qui nous ont marquées. Les vidéos de toutes les présentations sont disponibles à l’adresse suivante :
De plus, une session de rumps a été organisée le jeudi 6 après-midi. Les vidéos de celles-ci sont disponibles à l’adresse suivante :
La mort du génie logiciel – Alex Ionescu
https://www.sstic.org/2019/presentation/keynote_2019/
Alex Ionescu est venu présenter son point de vue sur l’état actuel des efforts mis dans la sécurité. Il a commencé sa keynote en rappelant les différents enjeux économiques du Bug Bounty.
Selon lui, il n’y avait avant pas d’outils automatiques, peu de connaissances dans le domaine et pas de code d’exploitation évidents. Les différents programmes de Bug Bounty n’existant alors pas, les vulnérabilités étaient souvent rapportées sur les blacks markets car la motivation des hackers était moindre sans récompenses.
Aujourd’hui grâce au Bug Bounty, et grâce au travail de Katie Moussouris dans le cas de Microsoft, ça a plutôt changé. Les failles sont corrigées dans les uns à trois mois et quelqu’un voulant vivre du Bug Bounty peut facilement se faire 2000$ à 2500$ par mois.
Cependant il déplore les faits suivants:
- Les développeurs de logiciel Open Source ont peu de temps pour corriger;
- On a tendance aujourd’hui à prioriser la création de features par rapport à la correction de bug;
- Il y a de moins en moins de développeurs.
- L’Union européenne a alloué un million d’euros pour la découverte de bugs dans les logiciels Open Source, ce qui est une bonne chose, mais il y a un manque de qualité dans les logiciels, car les développeurs sont moins bien payés.
Alex Ionescu remarquait également que, depuis l’arrivée du Bug Bounty, la plupart des personnes trouvent des failles sans même les comprendre.
Son constat est donc le suivant :
Actuellement, on cherche souvent à réduire l’impact des problèmes et non pas des solutions, alors qu’on oublie souvent des principes de bases du développement, comme vérifier la taille d’un tableau. Selon lui, on devrait plus investir dans l’éducation et la formation et arrêter les programmes de Fuzz et de Pentest sans avoir fait cette formation préalable.
Le Monitoring de BGP : où la sécurité rencontre la géométrie Riemannienne – Kavé Salamatian
https://www.sstic.org/2019/presentation/invite1_2019/
Kavé Salamatian, professeur à l’université de Savoie, nous a présenté un modèle mathématique fondé sur la géométrie Riemannienne permettant d’observer des anomalies qui correspondent à des attaques sur BGP.
BGP, pour Border Gateway Protocol, est un protocole de routage interdomaine utilisé par le réseau internet permettant d’échanger des informations d’accessibilité réseau entre les différents AS (Autonomous System). Il définit ses décisions de routage sur les chemins parcourus et utilise l’agrégation de routes afin de limiter la taille de sa table de routage.
Il est tout d’abord revenu sur la façon mathématique de surveiller un graphe d’un point de vue de robustesse et de sécurité. Cela consiste à observer la structure d’un graphe dynamique et de décider ensuite si un changement local aura une incidence sur la globalité du graphe. Ces travaux de surveillance des graphes ont, selon lui, un large spectre d’applications, allant de la robustesse des structures biologiques à la sécurité des réseaux.
Il a ensuite montré ses travaux de monitoring sur BGP a travers la création d’un “feed” BGP au format JSON lui permettant d’avoir une vision globale d’internet chaque minute. Pour cela il récupère toutes les annonces effectuées par le réseau et par minute, auxquels il ajoute des informations (comme à quel pays appartient l’AS), afin de construire un graphe. Ce flux représente pas moins de 10000 à 50000 annonces par seconde, ce qui signifie que dans la totalité d’internet, il y a 10000 à 50000 changements de route par seconde.
Cela lui permet de savoir quel pays possède le plus de connexion vers l’extérieur et ainsi d’observer les différentes attaques sur BGP.
En calculant les courbures sur le graphe précédent et celles sur le graphe suivant ainsi que leurs différences, il est capable de détecter les événements importants sur le réseau, comme ceux de hijack BGP.
Mirage : un framework offensif pour l’audit du Bluetooth Low Energy – Eric Alata, Guillaume Auriol, Jonathan Roux, Romain Cayre, Vincent Nicomette
Jonathan Roux et Romain Cayre, tous deux membres du LAAS CNRS (société rattachée à Airbus), ont présenté leurs travaux sur la réalisation d’un outil d’audit offensif des technologies sans fils intitulé “Mirage”.
Dans un premier temps, les conférenciers sont partis du constat que la sécurité des objets connectés (IoT) et plus particulièrement des risques liés aux connexions sans fils est réelle. En effet, la diversité des protocoles et des standards de communication utilisés par les différents objets connectés rend difficile l’analyse et la sécurisation de chacun d’entre eux.
De ce constat, un projet de création d’un IDS (Intrusion Detection System) dédié à la détection d’attaque sans fil, dans le contexte des objets connectés, a été réalisé. Néanmoins, afin de tester le bon fonctionnement de cet IDS il a été nécessaire de simuler des attaques sans fil sur des objets connectés. De ce fait, les conférenciers ont réalisé un état de l’art des outils offensifs dédié à l’attaque sans fil d’objet connecté.
Ces recherches ont permis de mettre en lumière l’absence d’outils générique (multiprotocole), exploitant différents types d’attaques (Man-in-the-Middle, hijack d’équipement, etc.) et réellement dédiés à la mise en place de scénarios offensifs. De plus, des outils tels que BtleJuice ou Gattacker, connues notamment pour permettre la mise en place de scénario de Man-In-the-Middle BLE, se basent sur l’utilisation de technologies ne permettant pas l’utilisation d’un système d’exploitation unique pour réaliser une même attaque. Par exemple, la bibliothèque BLE Node.js “Noble Bleno” ne permet pas de supporter deux dongles Bluetooth sur un même système d’exploitation.
Pour répondre à ces différentes problématiques, le framework Mirage a été pensé afin de permettre l’utilisation d’un outil offensif ayant les caractéristiques suivantes:
- Approche unifiée: utilisation d’une API commune permettant la transmission et la réutilisation des informations entre chaque module.
- Approche modulaire: segmentation des différentes tâches et décomposition des scénarios d’attaques en plusieurs composants facilitant ainsi le développement et l’ajout de nouvelles fonctionnalités, décorréler les unes des autres.
- Approche générique: redéveloppement des piles protocolaires au plus bas niveau possible afin de restreindre les limitations liées aux bibliothèques plus haut niveau.
- Approche générique: architecture générique permettant l’intégration de nouveaux protocoles sans fils sans dépendance à leurs spécificités.
Une revue de l’implémentation en Python des différents éléments constituant ce framework a ensuite été réalisée. En plus de la description du schéma d’architecture globale du framework, les trois notions suivantes ont pu être présentées:
- Le framework se présente sous forme d’un outil en ligne de commande ou d’une console à la manière de celle fournie par le projet metasploit. Un opérateur similaire au pipe sous Unix permet le chaînage de différents modules.
- L’architecture de communication se base sur les composants “émetteur” et “récepteur” afin de rendre le fonctionnement du framework le plus générique possible pour tous les protocoles. À cela est ajouté un “design pattern” de type “proxy” afin de pallier aux différences entre les différents composants matériels utilisés. Celui-ci offre la possibilité d’accéder depuis les composants “émetteur” et “récepteur” à des fonctionnalités spécifiques.
- La notion de scénario a également été présentée. Un scénario permet s’interfacer sur les signaux générés par les différents modules afin d’exécuter un comportement particulier ou non.
Par la suite, une présentation sur la structure du protocole Bluetooth Low Energy a été effectuée. Au cours de cette partie de la présentation, les différentes couches liées à la pile BLE ont été décrites. Au niveau des couches dites “hautes” de la pile BLE on notera les composants suivants, utiles à un attaquant:
- GATT / ATT: Ces couches applicatives permettent à l’équipement connecté de stocker ses caractéristiques sous forme d’attributs. Ces couches permettent également de définir les méthodes d’accès (lecture/écriture) à ces données.
- Security Manager: Cette couche permet de gérer la sécurité du protocole BLE. Cette couche est responsable de l’établissement d’une connexion sécurisée (définition du niveau de sécurité à adopter, génération des clés de chiffrements du trafic, etc.).
Enfin, les conférenciers ont présenté les modules disponibles au sein de framework afin d’auditer la sécurité d’un objet connecté via le protocole BLE. Ces modules répartis en cinq catégories principales:
- Utilitaires: actions courantes sur le protocole (connexion à un équipement, énumération des informations associées à une interface, etc.)
- Collecte d’information: permettent de collecter des informations sur les équipements alentour en phase de recherche ou encore d’accéder aux caractéristiques d’un équipement stockées au sein des couches ATT/GATT.
- Usurpation d’identité: permettent de simuler le comportement d’un équipement afin par exemple d’usurper l’identité d’un objet connecté.
- Attaques passives: permettent de réaliser des actions d’écoutes des communications effectuées par le biais de ce protocole.
- Attaques actives: permettent la mise en place d’attaque tel que le Man-In-The-Middle ou l’hijacking d’une communication BLE établie.
Un exemple d’utilisation des modules de collecte d’informations (ble_discover), d’attaques actives (ble_mitm, ble_master, ble_hijack) et d’attaque passive (ble_sniff) appliquée à l’utilisation d’une lampe connectée a ensuite été réalisé. Via cette démonstration, les conférenciers ont été en mesure de montrer le fonctionnement du protocole de communication entre un téléphone et la lampe connectée, d’intercepter et rejouer le trafic avec ou sans modification des trames, ainsi que de prendre la main sur la lampe.
L’utilisation de cet outil d’automatisation des attaques sans fils a permis à ses développeurs de mettre en évidence 20 vulnérabilités concernant 5 objets connectés en BLE présent dans le commerce.
L’outil est open-source et est disponible à l’adresse suivante:
De plus, une documentation est également mise à disposition:
DLL shell game and other misdirections – Lucas Georges
https://www.sstic.org/2019/presentation/dll_shell_game_and_other_misdirections/
Lucas Georges, consultant chez Synacktiv à Rennes, est revenu au travers de cette présentation sur les dépendances binaires sous Windows et sur les mécanismes liés au chargement de ces dépendances.
Le conférencier a dans un premier temps présenté ce que ce sont les DLL (Dynamic Link Library). Ces dépendances sur Windows permettent l’intégration de code au sein de la mémoire d’un programme dynamiquement.
Néanmoins, l’aspect modulaire offert par l’utilisation de ces DLL implique la création de schémas d’interdépendances parfois complexes. Dès lors, il n’est pas rare lors de l’exécution d’un programme d’observer des messages d’erreurs liés à un problème de chargement d’une ou plusieurs DLL. De ce constat, le conférencier est revenu sur les méthodes d’investigation sur les chargements des DLL et leur utilisation au sein d’un exécutable donné.
L’une des méthodes consiste à utiliser l’outil Windows “WinDbg” afin de s’attacher au programme en question et de poser des points d’arrêts sur chaque chargement des DLL. Bien que cette méthode fonctionne, elle reste néanmoins manuelle et chronophage.
Une alternative proposée par le conférencier consiste à utiliser l’outil “Dependency Walker” développé par un développeur Microsoft. Via cette interface graphique, il est alors possible d’investiguer sur les dépendances d’un module Windows que ce soit un “.exe” ou un “.dll”. Cependant, cet outil développé il y a plus de 20 ans ne fonctionne pas sous les nouvelles versions de Windows. En effet, des évolutions ont eu lieu concernant les composants Windows liés au chargement des DLL (“Loader NT”). Ces évolutions n’ont pas été prises en compte sur cet outil et celui-ci n’est plus maintenu.
De ce fait, l’auteur a développé un outil intitulé “Dependencies” dédié à l’investigation des dépendances d’un module Windows, de la même manière que le faisait “Dependency Walker”. Le conférencier a pu réaliser une démonstration de cet outil sur les programmes “notepad” et “Chrome”. Ainsi, l’interface graphique permet de mettre en évidence les chemins vers les différentes DLL chargées par ces programmes.
Par la suite, l’auteur a présenté les mécanismes de redirections des DLL sur Windows. L’objectif de ces mécanismes est de répondre aux problématiques d’incompatibilité entre DLL partagées (“DLL Hell”).
- API Set: Le noyau Windows ayant pour vocation à être utilisé sur les différentes plateformes Microsoft (XBOX, serveur, smartphone, etc.) un mécanisme de table de correspondance virtuelle a été implémenté. Ce schéma de nommage est injecté au sein de l’ensemble des processus et permet de rediriger le chargement d’une DLL en se basant sur une correspondance par nom générique de DLL.
- WinSxS: L’objectif permet de répondre aux problématiques du besoin de différente version d’une DLL en fonction du programme. Ce mécanisme fonctionne en insérant un Manifest au sein d’un programme permettant ainsi de spécifier quelle version de DLL il est en mesure de supporter. Ce Manifest est inséré directement au sein du PE.
- KnownDLLs: Afin d’accélérer le démarrage d’un processus, une phase de préchargement permet de charger une liste de DLL communément utilisée par tous les processus. Cette liste est stockée au sein d’une entrée de la base de registre et est chargée au démarrage du système.
- System32 folder redirection: lors de l’utilisation d’un binaire compilé en 32 bits, une redirection est effectuée afin de forcer le chargement de DLL compatible au sein du dossier SysWow64.
Pour finir, le conférencier a mis en évidence deux vulnérabilités liées à l’usurpation de DLL sur un système menant à une élévation de privilège.
La première de ces deux vulnérabilités a été identifiée via l’utilitaire “ProcMon”, présente au sein des “sysinternals” de Windows, et impacte un produit Asus. En effet, l’auteur a pu identifier le chargement d’une DLL non présente sur le système. Le répertoire ciblé étant accessible en écriture, il est possible de positionner sa DLL malveillante. De plus, l’exécution de ce programme est réalisée avec des privilèges administrateurs via une tâche planifiée. Ainsi, un utilisateur est en mesure d’exécuter du code arbitraire afin d’élever ses privilèges sur le système.
La seconde vulnérabilité quant à elle, impactait une tâche d’auto-update du navigateur Opera, exécutée en tant qu’administrateur. Celle-ci exécute un programme d’installation dans le dossier “C:WindowsTemp” accessible en écriture à tous. L’auteur a pu observer une tentative en premier lieu de chargement d’une DLL via le dossier courant en “.local”. Ce dossier n’étant pas présent, le processus de chargement des DLL récupère la bibliothèque au sein d’un autre dossier légitime. Un attaquant est alors en mesure de créer le dossier manquant et d’y insérer une DLL malveillante afin d’élever ses privilèges sur le système.
L’audit des GPO – Aurélien Bordes
https://www.sstic.org/2019/presentation/audit-gpo/
https://www.sstic.org/media/SSTIC2019/SSTIC-actes/audit-gpo/SSTIC2019-Article-audit-gpo-bordes.pdf
Aurélien BORDES, ingénieur spécialisé dans la sécurité des systèmes d’information, a présenté cette année deux outils liés à l’audit des GPO (Group Policy Object).
Cette conférence s’est effectuée en deux temps: d’abord, un retour assez complet sur le fonctionnement des GPO, leurs différents attributs, leur emplacement, etc. Puis il a présenté deux outils: gpocheck et gpo2sql, qui permettent respectivement de détecter les problèmes de configuration liés aux GPO et de faciliter leur analyse en important tous les paramètres dans une base SQL.
Sur de vastes environnements avec un domaine Active Directory contenant plusieurs milliers de GPO, les outils abordés permettent de faciliter grandement l’audit de configuration des GPO.
Aurélien BORDES aborde de nombreux points sur le fonctionnement des GPO :
Tout d’abord, les GPO correspondent à une collection de paramètres de configuration qui s’applique soit à des ordinateurs soit à des utilisateurs. Elles sont distribuées via un domaine Active Directory.
Il en existe deux types :
- Les GPO de domaine, récupérable au moyen d’une requête LDAP;
- Les GPO locales qui permettent d’appliquer des paramètres pour un système hors domaine ou un compte local. Leur configuration est stockée au sein d’un fichier gpt.ini.
Plusieurs éléments sont décrits:
- Les paramètres des GPO peuvent être stockés soit dans l’annuaire AD, où elles prennent la forme d’objets avec des classes particulières, soit dans des fichiers, avec un répertoire dédié au stockage des paramètres d’une GPO. Ces répertoires se situent au sein du répertoire SYSVOL (répertoire que chaque contrôleur de domaine partage).
- Les machines ou utilisateurs sur lesquels les GPO s’appliquent sont définis dans deux attributs gPLink et gPOptions.
- Le service GPSvc met en oeuvre l’application des GPO côté client.
- Les CSE (Client Side Extension) sont des bibliothèques dynamiques qui permettent d’appliquer un type de paramètre particulier.
- Le filtrage WMI permet d’affiner l’application des GPO en fonction de plusieurs filtres qui peuvent être la version du système ou encore une lettre contenue dans le nom du système ciblé.
- Par ailleurs, plusieurs clés dans le registre et maintenues par le moteur GPO permettent de garder un état de l’application des GPO.
D’autres mécanismes sont abordés comme la version des GPO, la journalisation, leur mise en cache, ainsi que la sécurité des échanges.
Lorsque l’on veut auditer la sécurité des GPO, on peut s’intéresser en premier lieu aux droits d’accès, notamment les droits d’accès des répertoires GPO où sont enregistrés les fichiers contenant les paramètres de configuration.
L’outil GPOCheck permet de vérifier les droits d’un répertoire SYSVOL en vérifiant plusieurs points de contrôle. L’idée est de s’assurer qu’il ne soit pas possible de modifier une GPO directement via l’édition d’un fichier.
D’autres aspects rendent très complexe l’analyse des paramètres définis par une GPO. En effet, les paramètres sont stockés sous des formes différentes : fichier texte, fichier CSV, fichier binaire, fichier texte à section, fichier XML, etc.
Il est possible d’exporter ces éléments via gpresult au format HTML ou XML. Cependant, pour simplifier et automatiser l’analyse des paramètres GPO via des requêtes SQL, l’outil gpo2sql permet de convertir les fichiers XML en tables SQL.
Globalement, ces deux outils vont permettre de faciliter le contrôle des GPO, qui joue un rôle significatif dans la sécurité des environnements Active Directory.
IDArling, plateforme de rencontre pour reverseur – Alexandre Adamski, Joffrey Guilbon
Lors de la conférence Recon 2016, un outil collaboratif de Reverse Engineering pour IDA appelé Sol[IDA]rity avait été présenté. Cependant, l’outil est resté indisponible au public.
Alexandre Adamski et Joffrey Guilbon ont donc décidé de développer leur propre outil, IDArling. Ils présentent dans cette conférence les différents choix qu’ils ont pris, les fonctionnalités mises en place, ainsi que les difficultés rencontrées.
IDArling correspond à un plug-in de reverse collaboratif pour IDA pro (un désassembleur et un debuger) et Hex Rays (un decompiler). L’idée est de connecter plusieurs instances d’IDA et de permettre à plusieurs personnes de collaborer avec une synchronisation en temps réel des changements réalisés entre les utilisateurs (changement de types, de structures, etc.)
Les auteurs ont pu implémenter les fonctionnalités suivantes sur leur outil :
- IDArling peut s’exécuter soit à partir d’un serveur dédié via un script Python externe, soit directement dans l’interface d’IDA.
- Il n’est pas nécessaire d’avoir de dépendance externe, l’installation peut se faire directement via un glisser-déposer dans le dossier plug-ins ou via IdaPython, et pour installer le serveur, uniquement PyQt5 pour Python3 est nécessaire.
- Chaque utilisateur est identifié via un curseur de couleur.
- Deux fonctionnalités intéressantes permettent également de proposer à un utilisateur de visualiser une zone de code et de suivre sur son écran les différentes actions réalisées.
Au niveau des difficultés rencontrées, lorsque l’on charge un binaire à analyser, une archive .idb est créée. Or il n’y a pas d’API pour charger une IDB dans IDA. Les auteurs ont donc dû combiner deux fonctionnalités, la fonctionnalité d’initialisation et de terminaison d’une base de données, ainsi que la fonctionnalité de snapshot pour pouvoir restaurer un IDB.
Deuxième difficulté rencontrée: colorer une fonction. Utiliser l’attribut color de Python va colorer toute la fonction désassemblée, ce qui n’est pas le but recherché. Là encore, n’étant pas proposés par IDA, les auteurs ont utilisé Qt et ajouté un proxy.
Enfin, un bug dans IdaPython provoque le fait que les bindings Python sont soit cassés, soit inexistants.
Thermomix : all your recipes are belong to us (Jean-Michel Besnard @jmbesnard_maz)
https://www.sstic.org/2019/presentation/rumps_2019/
Jean-Michel Besnard, consultant au cabinet Mazars, nous a présenté son étude sur la sécurité apportée à la gestion des recettes au sein robot de cuisine Thermomix. Cette présentation, bien qu’au format Rump, était initialement prévue pour être présentée sous un format de 15 min. C’est sur un fond d’humour que l’auteur nous a parlé de la technique qu’il a employée pour réussir à modifier le contenu d’une recette malgré les protections en place.
Le Thermomix est basé sur un système Linux. Les recettes sont stockées au sein de petites capsules qui sont fournies par le fabricant. En démontant cette capsule l’orateur a découvert qu’il s’agissait d’un flash drive UDP dont le contenu est chiffré.
L’étude a ensuite porté sur le système d’exploitation mis à disposition par le fabricant au format CD. Cela a permis de découvrir un système de chiffrement AES dont les clés ont été enlevées de la version envoyée au public.
Une fois ces deux points d’entrée étudiés, la dernière possibilité a été d’utiliser les modules de recette possédant une antenne WIFI. Son analyse a révélé que les communications étaient chiffrées via HTTPS et l’identité du serveur était vérifiée grâce à son certificat, mais également des requêtes OCSP. Ces protections rendaient impossible toute interception SSL/TLS.
Cette étape logicielle effectuée, l’équipement a à son tour été démonté et s’est avéré ne pas être chiffré. Il contenait deux partitions, une avec des fichiers, et la seconde avec une archive tar du contenu de la première. La modification du contenu des fichiers entraine la restauration de cette partition depuis l’archive lorsque la capsule est rebranchée au Thermomix.
Cela a permis au chercheur de déterminer que la fonction tar était appelée avec une archive contrôlée par un attaquant. En recherchant des vulnérabilités au sein de la version de tar encapsulé dans Busybox, une vulnérabilité datant de 2011 a été identifiée CVE-2011-5325 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5325). Cependant, la description de la CVE affirme que cette vulnérabilité a été corrigée au sein de la version 1.22, or la version présente dans le Thermomix est la 1.23. C’est en effectuant des recherches au sein du code source de la version de tar de Busybox que le chercheur a découvert des commentaires laissant entendre que la vulnérabilité était toujours présente (https://git.busybox.net/busybox/tree/archival/tar.c?h=1_19_stable).
Après avoir effectué des tests, il s’est avéré qu’elle est présente jusqu’à la version 1.28.
La vulnérabilité était donc toujours présente, cependant, seulement les répertoires /tmp, /var et /etc n’étaient pas en lecture seule, mais ne persistait pas après un redémarrage. De plus, très peu d’outils étaient présents dans la version de busybox. La vulnérabilité affectant tar a été utilisée afin d’écraser le fichier de configuration du client DHCP. Le fichier a été écrasé par sa valeur originale où a été ajoutée une déclaration de type « script » afin de pouvoir exécuter un script Shell.
Le déroulement de l’exploitation était donc le suivant:
- 1 exploitation de la vulnérabilité affectant tar pour copier des fichiers arbitraires sur le système.
- dépôt d’un script Shell dans /etc
- écrasement du fichier dhcp.conf
- 2 exécutions du script Shell via DHCP
- lancement d’un reverse Shell en utilisant tcpsvd
Ce scénario permet de se connecter à l’appareil au travers d’un Shell. Une fois cet accès récupéré, un backup du système de fichier a été réalisé afin de pouvoir le parcourir plus aisément en local. À partir de cette sauvegarde, un grep à la recherche d’un appel à « losetup » à permis de trouver une référence ainsi que la clé de chiffrement utilisé lors de l’appel à losetup. Malgré tout, cette clé n’était pas celle utilisée pour déchiffrer l’équipement contenant les recettes.
En regardant le fonctionnement du chiffrement implémenté dans le système il s’est avéré que le driver DCP était modifié. Ce dernier utilise une première clé (celle trouvée dans le système de fichier) qu’il compare à une valeur dans le driver pour ensuite déchiffrer l’équipement à l’aide d’une autre clé.
Mr Besnard a donc réalisé un dump du noyau afin de récupérer la mémoire du driver DCP. De cette manière, il a effectué une recherche de la clé déjà connue au sein de la mémoire afin de trouver la deuxième proche en mémoire.
Cette technique a porté ses fruits, car elle lui a permis de récupérer la deuxième clé et ainsi de pouvoir déchiffrer le périphérique de stockage.
Ce n’est pourtant pas la dernière étape nécessaire, car tous les fichiers SQLite contenant les recettes sont signés. La signature étant basée sur une clé privée non présente dans l’appareil, forger une signature valide n’était pas envisageable. C’est au niveau de la vérification de la signature qu’un élément a permis de contourner cette sécurité.
En effet, la signature est considérée comme valide lorsque checksig retourne la valeur 0, et invalide autrement. Comme l’appel à checksig est réalisé avec en argument le fichier, le numéro de série de l’appareil et le fichier de signature de référence, une possibilité était de forcer un retour de la valeur 0 au travers d’une injection de commande.
Pour se faire le chercheur a utilisé un Raspberry Zero afin de simuler un flash drive. L’usage de cet outil a permis d’injecter du code dans le numéro de série de l’appareil et ainsi de contourner la vérification des signatures.
Ces vulnérabilités ont toutes été rapportées au fabricant qui les a corrigées et a accepté la publication de cette présentation.
WEN ETA JB? A 2 million dollars problem – Eloi Benoist-Vanderbeken, Fabien Perigaud
https://www.sstic.org/2019/presentation/WEN_ETA_JB/
Le constat de base est que Zerodium paye jusqu’à deux millions de dollars pour une prise de contrôle à distance complète d’un appareil iOS. La question est de savoir si cela est mérité.
Actuellement, Apple ajoute toujours de plus en plus de sécurité physique et software à ses appareils. Les deux chercheurs de Synacktiv nous ont proposé un scénario d’attaque complet portant sur un équipement. L’idée étant de présenter les protections qu’Apple a développée pour contrer chacune des attaques présentées.
La première étape était la prise de contrôle de l’équipement via une vulnérabilité au sein du navigateur Safari qui est celui par défaut. Elle a été présentée par Fabien Perigaud.
La méthodologie qui nous est présentée est de débuter par la recherche de primitives d’écriture et de lecture au sein du processus du navigateur. Pour ce faire, ils proposent de corrompre un objet JavaScript de type tableau. Ces derniers contenant une taille de 32 bits et un pointeur pointant vers un espace de stockage sur le tas. En théorie, la compromission de ce tableau permettrait de modifier l’adresse pointée en mémoire et d’avoir un accès en lecture et en écriture partout dans la mémoire.
C’est dans le but de contrer ce type d’attaque que le mécanisme Gigacage a été ajouté. Cette protection datant de 2018 permet de stocker les objets jugés dangereux dans un buffer de 32Gb. Ainsi la taille du tableau étant stockée sur 32 bits ne peut pas dépasser les 32Gb alloués. De plus, lors d’un accès à la zone mémoire pointé par le tableau, un masque est appliqué au pointeur afin de s’assurer qu’il pointe toujours dans la Gigacage. Cela empêche de modifier directement le pointeur vers lequel pointe le tableau afin de sortir de cet espace.
Dans le cas où un attaquant réussit à contourner la Gigacage afin d’obtenir ces primitives, l’étape suivante consiste à les utiliser pour exécuter du code.
Les deux employés de Synacktiv nous ont ensuite présenté comment les moteurs de code JavaScript moderne utilisent la technique du Jit (Just In Time) sur le code utilisé régulièrement afin de compiler le JavaScript en code natif et de gagner en performance. Historiquement, l’espace où le code est compilé était en RWX (read, write, execute). Il était donc envisageable de créer une fonction JavaScript puis de l’appeler un grand nombre de fois afin que le mécanisme de JIT lui soit appliqué. Une fois l’espace alloué dans l’espace RWX on pouvait l’écraser avec notre Shellcode. Cette action est toujours possible sur macOS, mais plus sur iOS.
À présent sous iOS les processus n’ont plus le droit de réaliser des allocations de pages mémoire en RWX excepté Safari. De plus, l’espace de JIT est divisé en deux espaces. Le premier est en RX et le seconde en RW. Ce dernier est alloué à une adresse mémoire aléatoire. C’est une fonction propre au mécanisme de JIT qui est utilisée pour écrire dans la zone Read et Write, et qui va ensuite la marquer en « execute only ». Cela nous empêche donc de pouvoir aller y écraser notre Shellcode à postériori. De plus, l’adresse de cette espace mémoire n’est connue que par la fonction en charge d’effectuer la copie. Cette dernière étant en « execute only » on ne peut pas y lire l’adresse de la zone allouée. L’usage d’une ROP Chain faisant appel à cette fonction pour écrire notre payload est nécessaire.
Les versions plus récentes d’appareils iOS possèdent la nouvelle protection au niveau des registres de la puce A11 appelée S3_4_c15_c2_7. L’état de ce registre permet de définir le statut de la zone mémoire. Avant chaque écriture de code JIT le statut de ce registre est modifié à l’aide d’une fonction. Cette dernière n’est pas exportée et est inliné à l’intérieur de toutes les fonctions faisant usage du JIT. Cela a pour conséquence de grandement compliquer l’usage du ROP. Afin d’y avoir recours, il faudrait réaliser un JUMP au milieu d’une fonction et ainsi devoir exécuter de nombreuses instructions avant la fin du gadget.
L’étude présente ensuite la protection ajoutée avec les appareils Iphone XS et XR qui possèdent encore un autre mécanisme de sécurité propre aux puces A12. Ce dernier n’est autre que PAC (Pointer Authentication Code) qui a été introduit avec la norme ARMv8.3. Ce dernier permet de signer cryptographiquement les pointeurs jugés dangereux, à l’aide de cinq clés cryptographiques distinctes en fonction du type de pointeur. Cette signature étant basée sur le pointeur et son contexte, elle permet d’obtenir une signature différente pour un même pointeur dans deux contextes distincts. Pour ce qui est de son stockage, les pointeurs sont actuellement stockés sur 39 bits avec un bit supplémentaire pour définir s’il s’agit d’un pointeur Userland ou Kernelland. Cela permet d’utiliser les bits restant pour signer le pointeur. La présentation nous a permis de remarquer que seulement 16 bits étaient utilisés pour signer les pointeurs en Userland alors que la totalité des 24 bits restants est utilisée pour signer un pointeur en Kernelland.
Cela a pour conséquence d’empêcher les attaques de type ROP. Seule une attaque portant sur les mécanismes de vérification et de signature permet dans certains cas très précis de contourner cette protection. À noter qu’actuellement PAC ne protège que les pointeurs d’instructions.
La seconde partie de la présentation a été présentée par Éloi Benoist-Vanderbeken et portait sur l’élévation de privilèges.
Le postulat envisagé est la capacité à exécuter du code dans le navigateur Safari. Cette étape s’est donc focalisée sur les possibilités d’échappement de la sandbox iOS.
Dans un premier temps, l’orateur nous a présenté les protections qu’apporte cette sandbox. Cette dernière est une extension du noyau basé sur le framework MACF qui provient de TrustedBSD. Avant chaque exécution de code jugée dangereuse, le processus va faire appel à la sandbox afin de savoir s’il a le droit de communiquer avec un autre processus ou daemon.
Le second point, présenté comme ajoutant une difficulté à l’élévation de privilèges, est la signature de code. Cette dernière est nécessaire avant toute exécution de code sous iOS. Cette signature permet entre autres d’obtenir des autorisations qui seront fournies à la sandbox lors des demandes d’autorisation.
La vérification de la signature est réalisée par un autre module kernel dénommé AMFI. Ce dernier agit différemment en fonction du type de binaire qu’il traite. Si ce dernier est fourni par Apple, il vérifie le hash qui est directement stocké dans le kernel. Autrement, le binaire est signé par une chaine de confiance de certificat et la vérification est réalisée par un démon en Userland. Comme l’orateur l’a souligné, cette dernière implique un bien plus grand nombre de vérifications avec notamment la gestion de l’expiration de certificats au travers des CRL. Ce démon (AMFId) était jugé comme de confiance par le kernel jusqu’a iOS 12 et sa compromission permettait d’exécuter du code sans avoir à le signer. Depuis, une nouvelle extension kernel, nommée CoreTrust, est chargée de vérifier l’intégrité de la chaine de vérification côté Userland.
Une fois ces deux protections présentées, Éloi Benoist-Vanderbeken nous a présenté les protections propres aux daemon userland.
Premièrement, les Platform Binaries (PB) et les restrictions qu’il applique aux daemons. Cela les empêche de charger des bibliothèques qui ne sont pas Platform Binaries.
Un point d’attention a été apporté au fait qu’actuellement, seulement les applications fournies par Apple peuvent utiliser les instructions liées à PAC présenté au début de cette séance.
En dehors des daemon Userland, les deux autres cibles ayant été présentées sont directement le noyau ainsi que ses extensions. Ces deux cibles permettent, en cas de compromission, d’exécuter du code avec des privilèges élevés.
Dans ce cadre nous avons vu qu’en plus de contrôler le cloisonnement entre les processus, la sandbox a également pour rôle de restreindre les droits d’accès à l’API du kernel. De cette manière, les accès aux syscall, et entre autres à la manipulation de fichier, la gestion d’IOCTL et de socket, sont limités.
D’autres protections qui ont été présentées ont été ajoutées avec les processeurs A10. Ces dernières appelées RoRgn et KTRR consistent à marquer des pages physiques de la mémoire comme étant en lecture seul ou bien en exécution uniquement depuis le niveau noyau.
La dernière protection présentée est PPL/APRR ajouté avec les puces A12. Elle permet de définir des pages comme étant accessible en écriture uniquement si certains registres contiennent une valeur prédéfinie. Bien que la manipulation de ces registres permette de contourner cette restriction, elle nécessite elle-même d’exécuter du code.
Pour conclure, Éloi Benoist-Vanderbeken et Fabien Perigaud nous ont très clairement présenté quelques protections mises en place par Apple aux files des mises à jour de ses OS et de ses composants. Nous avons pu percevoir l’importance que la firme donne à ces protections et la manière dont elles entravent les différents scénarios d’exploitation.
Nous vous donnons rendez-vous dans le prochain numéro de l’ActuSécu pour un résumé complet et détaillé de cette édition !
