Depuis 2011, la Sthack est une conférence de sécurité informatique se tenant annuellement à Bordeaux.

D’un simple CTF organisé par des étudiants, elle est devenue au fil des années une conférence accueillant plusieurs présentations tout le long d’une journée. Le CTF est toujours présent et se déroule la nuit qui suit les conférences. Ce cru 2021 a permis également de fêter les 10 ans de la Sthack. Cette année, RandoriSec était sponsor de l’évènement et plusieurs consultants sont venus suivre les conférences et participer au CTF (un billet de blog est en cours de préparation).

La conférence a débuté par une keynote de Florian Gaultier retraçant les 10 ans de la Sthack.

Voici un résumé des 5 présentations qui ont suivies :

• Discovering and exploiting a kernel pool overflow on modern Windows 10 par Fabien Perigaud

Pwn2Own est une compétition biannuelle organisée par ZDI (Zero Day Initiative), où plusieurs cibles majeures sont proposées aux participants qui tentent de les compromettre. Des systèmes d’exploitation comme Windows, Linux (Ubuntu) ou encore des navigateurs web comme Firefox et Chrome sont sur la liste et les participants doivent trouver un maximum de vulnérabilités critiques de type 0day (élévation de privilèges, exécution de code, etc.) pour remporter l’épreuve et devenir le Master of Pwn. Des récompenses sont attribuées aux gagnants des différentes catégories. C’est dans le cadre de cette compétition qu’a été trouvé par Fabien une élévation de privilège locale sur un Windows 10 standard. Après présentation de la surface d’attaque, constituée principalement du noyau avec ntoskrnl.exe et win32k pour la partie graphique, c’est aux modules noyau qu’il s’est intéressé. L’idée étant de cibler un module qui n’avait pas été trop testé par les chercheurs. La vulnérabilité identifiée est un dépassement de tampon relativement classique: un attaquant contrôle la taille et les données source lors d’un appel a la fonction memcpy. Le débordement se situant dans le pool (heap du noyau windows), l’exploitation utilise naturellement une technique pour cette classe de vulnérabilité, qui provient d’un travail de recherche antérieur fait par Synacktiv sur le pool. Ce travail de recherche a été présenté au SSTIC en 2020. Plutôt que de chercher de l’exécution de code directement via la vulnérabilité, l’exploitation se “contente” d’une primitive d’écriture arbitraire en mémoire, suffisante pour obtenir une élévation de privilège par un vol de jeton (Token). L’idée est alors de créer un processus cmd.exe et d’utiliser la primitive d’écriture de la vulnérabilité pour réécrire le Token du processus.

• Mécanismes de détection de jailbreak, et comment les éviter par Eloi Benoist-Vanderbeken

Le système d’exploitation iOS développé par Apple est très cloisonné. Il utilise plusieurs techniques comme de la signature d’application ou du sandboxing pour veiller à la bonne sécurité de ce qui est exécuté sur le téléphone. Le système empêche par ailleurs aux utilisateurs d’obtenir un accès complet au système afin d’empêcher de modifier son fonctionnement. Néanmoins, certains utilisateurs souhaitent avoir cet accès privilégié à leurs iPhones, car cela donne un accès total au téléphone et permet par exemple d’installer des applications non signées ou d’accéder au système de fichier. C’est le cas, notamment, des chercheurs en sécurité qui souhaitent auditer une application mobile. Pour avoir cet accès privilégié, la seule manière de procéder est d’exploiter une faille du système souvent dans le kernel, pour s’octroyer les droits attendus, les fameux jailbreaks. Une fois découvertes, ces failles sont bien entendues corrigées par Apple, rendant ainsi le jailbreak caduque. Les utilisateurs peuvent néanmoins continuer d’utiliser la faille en ne mettant pas à jour leur système. Plusieurs éditeurs d’application mobiles ne souhaitent pas que les utilisateurs disposent d’un téléphone jailbreaké. C’est le cas des applications bancaires, qui veulent garder le code de l’application le moins accessible possible ainsi que d’empêcher les utilisateurs de compromettre eux-même la sécurité de leurs données bancaires. Les éditeurs de jeux sont également réticents au jailbreak, car il rend possible la triche sur les applications. La présentation prend le cas d’une application bancaire et s’intéresse à voir les mécanismes utilisés par l’application pour détecter le fait qu’elle soit exécutée sur un téléphone jailbreaké et d’arrêter son exécution le cas échéant. L’idée est alors d’étudier par quelles techniques un utilisateur (par exemple un chercheur en sécurité) peut contourner cette détection, pour laisser l’application s’exécuter normalement malgré le jailbreak. Différentes techniques sont utilisées par les applications mobiles pour détecter le jailbreak. Par exemple, certains jailbreaks créent des dossiers à la racine du système de fichier, facilitant leur détection. Il est également possible de regarder les permissions associés à certains dossiers système, habituellement en lecture seule, mais qui deviennent accessibles en lecture/écriture avec un jailbreak. Dans le cas de la présentation, l’application stoppe son exécution volontairement lorsqu’elle détecte un jailbreak. Pour contourner cette détection, la technique présentée utilise l’outil d’instrumentation Frida, qui permet plusieurs choses. Par exemple, il est possible via cet outil de modifier la valeur de retour d’une fonction lors de l’exécution. L’idée étant que les mécanismes de détection de jailbreak s’appuie souvent sur une fonction renvoyant une valeur booléenne : vrai si le téléphone est jailbreaké et faux sinon. Un utilisateur de Frida peut alors modifier la valeur de retour de cette fonction pour qu’elle renvoie faux lors de l’exécution. La présentation se termine par plusieurs idées pour améliorer les mécanismes de détection des jailbreaks. Une d’entre elle consiste à mieux séparer l’endroit où est détecté le jailbreak, de l’endroit où est terminé l’application. Cela dans le but de compliquer la tache de rétro-ingénierie.

• RFID for dummies - par où commencer ? par ArnC

La technologie RFID est présente partout au quotidien. Pour les badges d’immeubles, les titres de transports, les cartes de crédit, etc. Cette présentation donne un tour d’horizon des cartes RFID, leurs concepts et leur sécurité. Les cartes RFID (tag) sont comme des micros ordinateur, disposant de leur propre RAM, ROM (mémoire non volatile), CPU, etc. Pas totalement autonome, elles tirent leur alimentation du lecteur qui lit le contenu de la carte, via le mécanisme physique bobine + aimant pour créer de l’électricité. Elles communiquent ensuite par onde radio. Trois catégories se dessinent alors :

1. les cartes “bêtes” (courte fréquence), qui sont juste inscriptibles une unique fois. Elles ne disposent presque d’aucune sécurité.
2. les cartes haute fréquence courte distance avec de la logique. C’est le cas des cartes bleues qui intègrent des composants cryptographiques.
3. les cartes haute fréquence haute distance (dizaine de mètres), utilisée par exemple dans le cas des badges d’autoroute.

Plusieurs attaques classiques sont alors présentées notamment le clonage. Cette technique consiste à dupliquer le contenu mémoire d’un tag, ce qui permet la duplication d’un badge d’immeuble par exemple. Les lecteurs de cartes, plus ou moins intelligents, utilisent des techniques pour détecter le clonage. Dans le cas des “chinese cards”, ces cartes autorisent la modification de l’uid du tag (identifiant principalement utilisé pour reconnaître le tag). Les lecteurs sont en mesure de détecter que l’uid est réinscriptible et ainsi bloquer l’accès au détenteur d’une telle carte. D’autres cartes disposent d’un mécanisme d’OTP (One-Time Programmable) permettant à l’utilisateur d’écrire une unique fois en mémoire du tag par exemple pour cloner le contenu d’un autre tag. Une fois l’écriture effectuée, le tag est alors rigoureusement identique au tag d’origine, rendant la détection du clonage impossible pour les lecteurs. La présentation passe également en revue les tags les plus populaires à l’achat, ceux à éviter, ainsi que les lecteurs et les fonctionnalités des versions haut de gamme.

• PHP-FPM local root par Cfreal_

PHP est un langage majeur utilisé par les applications web souhaitant générer du contenu dynamique. Le fonctionnement classique utilise un serveur web (nginx, IIS, etc.), recueillant des requêtes utilisateurs avant de les transférer à un serveur PHP pour traitement. Ces requêtes étant souvent accompagnées de paramètres (login/mot de passe, id d’utilisateur, mot d’un formulaire de recherche, ..etc.), c’est le serveur PHP qui va alors faire le travail d’enrichir le contenu de la page web selon les paramètres, avant de le renvoyer au serveur web. C’est ce dernier qui donne alors la réponse à la requête du client :

Client <–> Serveur web <–> Serveur PHP

Dans le cadre de cette présentation, on suppose avoir déjà un accès shell restreint sur le serveur PHP et on s’intéresse à une faille dans le coeur du code de PHP, le processus PHP-FPM, qui va permettre d’élever ses privilèges au niveau root. Ce processus PHP-FPM est en effet exécuté en tant que root. Il s’occupe de créer et tuer des sous-processus (les workers), qui vont avoir pour role de compiler les requêtes du serveur web en php vers des page web enrichies. Ces workers sont des processus qui tournent sous le compte de www-data, le compte standard d’un serveur web. Le problème majeur utilisé par la vulnérabilité est lié au fait que les workers et le processus root parent disposent d’une mémoire partagée. Étant donné que l’on dispose par hypothèse d’un accès shell (compte www-data), il nous est possible de modifier cette mémoire partagée. Une vulnérabilité dans le code PHP-FPM qui utilise cette mémoire partagée ouvre la porte à une exploitation depuis le shell non privilégié. La vulnérabilité trouvée offre deux primitives :

• une qui permet de modifier un int32 de 0 à 1 en mémoire
• une qui permet de mettre à 0 environ 1000 bytes en mémoire

La seconde primitive n’est pas vraiment utilisable en pratique, mais la première permet de modifier un champ booléen en mémoire bien choisi. Cependant, elle n’est pas suffisante pour obtenir une primitive d’exécution de code. Une seconde vulnérabilité est présentée permettant un dépassement de tampon dans le tas. Cette seconde vulnérabilité n’est atteignable qu’après avoir utilisé la première primitive. L’exploitation complète est présentée et une démonstration du PoC s’en suit.

• REX Ransomware par le Cert ADVENS

Cette présentation donne un retour d’expérience sur une gestion de crise d’un ransomware ayant chiffré toute l’infrastructure d’un système d’information. Le contenu n’étant pas ouvert au public, nous ne pouvons pas le détailler dans ce billet de blog.